Hello David, Yes, it is what I want to the list. I wanted to know about this question, is this proposal beyond the scope of using whois db? But if it is so, I want to have opinions where is the best place to discuss and what we can choose for universal common information resource to check?
Regards, On 2015/03/03 8:55, David Woodgate wrote: > > I do not support this proposal, on the basis that it seems its intent is > to extend the scope of the APNIC whois database well beyond its > traditional scope. > > I believe the purpose of the APNIC database is to assert the > authorisation of an assignee to use specified IP addresses, for purposes > such as route validations or route dispute resolutions. The database > only relates to the network layer identifiers that APNIC is chartered to > administrate (i.e. IP addresses and AS numbers). > > APNIC does not administrate or register the use of transport-layer > identifiers (TCP or UDP ports); APNIC does not have the charter to state > that certain TCP/UDP ports have been duly assigned and provide any > authority for their use. Also, standard Internet routing does not > function on the basis of TCP/UDP ports. > > I therefore feel that any recording of any TCP/UDP port assignments > would be outside of the scope of APNIC's business. > > Regards, > > David Woodgate > > On 1/03/2015 11:30 PM, Ajay Kumar wrote: >> Personally,I don't see any benefit,which community may be getting >> after accepting this proposal. I don't support this proposal. >> Regards, >> Ajai Kumar >> >> On 24 February 2015 at 22:41, Owen DeLong <o...@delong.com >> <mailto:o...@delong.com>> wrote: >> >> I don’t believe the proposal offers enough benefit to be worth >> what implementation would likely >> cost. >> >> First, I am sincerely hoping that CGN is an extremely temporary >> situation. I’m not sure >> it should be worth the effort to recode the registry to support it. >> >> Second, I’m wondering if there’s any real advantage to having this >> level of detail on >> residential subscribers that don’t even get full addresses, since >> we don’t really tend >> to have it for single-address subscribers now. >> >> IMHO, best to just let each ISP keep this information for >> themselves as the relevant contact >> for abuse and such is usually the ISP and not the residential user >> anyway. >> >> Owen >> >>> On Feb 23, 2015, at 10:53 , Masato Yamanishi <myama...@gmail.com >>> <mailto:myama...@gmail.com>> wrote: >>> >>> Dear Colleagues, >>> >>> And, here is prop-115. No comment has not been made for this >>> proposal. >>> >>> If reached consensus, it may needs significant change for whois >>> database. >>> I just reviewed implementation impact assessment by the Secretariat, >>> and it says it might take more than 6 months. >>> I think same thing will happen for whois database of each NIRs. >>> And if your company have a system linked with APNIC/NIR whois >>> database, it will be impacted also. >>> >>> As Chair, I'm always very neutral for each proposal, including >>> prop-115. >>> However, I would like to emphasis prop-115 should be discussed >>> more widely as it has wide impact. >>> It is very appreciated if you will express your views. >>> >>> Regards, >>> Masato Yamanishi, Policy SIG Chair (Acting) >>> >>> >>> 2015-02-04 14:52 GMT-06:00 Masato Yamanishi <myama...@gmail.com >>> <mailto:myama...@gmail.com>>: >>> >>> Dear SIG members >>> >>> The Problem statement "Registration of detailed assignment >>> information >>> in whois DB" has been assigned a Policy Proposal number >>> following the >>> submission of a new version sent to the Policy SIG for >>> consideration. >>> >>> The proposal, "prop-115-v001: Registration of detailed assignment >>> information in whois DB" now includes an objective and >>> proposed solution. >>> >>> Information about this and earlier versions is available from: >>> >>> http://www.apnic.net/policy/proposals/prop-115 >>> >>> You are encouraged you to express your views on the proposal: >>> >>> - Do you support or oppose this proposal? >>> - Does this proposal solve a problem you are experiencing? >>> If so, >>> tell the community about your situation. >>> - Do you see any disadvantages in this proposal? >>> - Is there anything in the proposal that is not clear? >>> - What changes could be made to this proposal to make it more >>> effective? >>> >>> >>> >>> Regards, >>> >>> Masato >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> prop-115-v001: Registration of detailed assignment information in >>> whois DB >>> >>> ------------------------------------------------------------------------ >>> >>> Proposer: Ruri Hiromi >>> hir...@inetcore.com <mailto:hir...@inetcore.com> >>> >>> Tomohiro Fujisaki >>> fujis...@syce.net <mailto:fujis...@syce.net> >>> >>> >>> 1. Problem statement >>> -------------------- >>> >>> Recently, there are some cases need to get IP address >>> assignment >>> information in more detail to specify user IP address. >>> >>> With out this information, operators cannot filter out >>> specific >>> address range, and it might lead to 'over-filter' (i.e. >>> filtering >>> whole ISP's address range). >>> >>> For example: >>> >>> 1) 'Port' range information in IPv4 >>> >>> ISPs are using 'CGN' or other kinds of IPv4 address >>> sharing >>> technology with assignment of IP address and >>> specified port >>> range to their users. >>> >>> In this case, port information is necessary to >>> specify one user. >>> >>> ex) 192.0.2.24/32 <http://192.0.2.24/32> 1-256 is for >>> HomeA >>> 192.0.2.24/32 <http://192.0.2.24/32> 257-511 is >>> for HomeB >>> >>> or 192.0.2.0/24 <http://192.0.2.0/24> 1-65536 is >>> shared address of ISP-X >>> minimum size is /32 >>> >>> 2) address assignment size information in IPv6 >>> >>> The IPv6 address assignment size may be different from >>> ISP to >>> ISP, and address ranges in one ISP. Address assignment >>> prefix >>> size will be necessary. >>> >>> ex) 2001:db8:1::0/56 is for HomeA >>> 2001:db8:1:1::0/48 is for HomeB >>> >>> or 2001:db8:1::/36's minimum size is /56 >>> >>> >>> 2. Objective of policy change >>> ----------------------------- >>> >>> Lots of operators look a record when harmful behavior >>> coming to >>> their network to identify its IP address confirming it can be >>> filtered or not. >>> >>> The goal is providing more specific information to >>> support these >>> actions. >>> >>> >>> 3. Situation in other regions >>> ----------------------------- >>> >>> No same regulation/discussion can be seen in other regions. >>> >>> >>> 4. Proposed policy solution >>> --------------------------- >>> >>> Provide accurate filtering information generated from >>> whois DB. >>> >>> For IPv4, propose to add 'port range' information to IP >>> address >>> entry. >>> >>> For IPv6, propose to provide 'assignment prefix size' >>> information >>> for specific IPv6 address. >>> >>> >>> 5. Advantages / Disadvantages >>> ----------------------------- >>> >>> Advantages: >>> >>> - operators can set filtering by IP address based on correct >>> assignment >>> information base. >>> >>> - users who share same address space can be avoid to be >>> including bulk >>> filtering. >>> >>> Disadvantages: >>> >>> - registration rule will move to more strict manner. >>> >>> - strict watch and control in registration of database records. >>> >>> - additional record or option will be considered. >>> >>> - privilege for withdrawing detailed information will be set >>> for these >>> records. >>> >>> >>> 6. Impact on APNIC >>> ------------------ >>> >>> This might be beyond the scope of using whois DB. >>> >>> >>> 7. Other Consideration >>> ---------------------- >>> >>> For the security reason, this detailed records may be >>> able to see >>> only by operators.(some kind of user control/privilege >>> setting is >>> needed) >>> >>> For hosting services, /32 in IPv4 and /128 in IPv6 >>> registration >>> should be discussed based on its operability and >>> possibility. But a >>> harmful activities to filter by IP addresses are coming >>> from hosting >>> services as well. Here it seemed to be some demands. >>> >>> >>> References >>> ---------- >>> >>> TBD >>> >>> >>> * sig-policy: APNIC SIG on resource management >>> policy * >>> _______________________________________________ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> >>> http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> >> * sig-policy: APNIC SIG on resource management >> policy * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> >> >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net >> http://mailman.apnic.net/mailman/listinfo/sig-policy > > > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy > -- =================================== 株式会社インテック 先端技術研究所 研究開発部 廣海（ひろみ）緑里 * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
