I look forward to hearing more from the author. At present I do not support this proposal.
On Wednesday, 25 February 2015, Masato Yamanishi <myama...@gmail.com> wrote: > Dean, > > I totally agree that we should focus on the problem statement itself in > Fukuoka > since this problem statement has something new concept for Policy SIG > and Fukuoka will be first meeting. > > However, I don't think this proposal needs to be withdrawn to focus on the > problem statement in Fukuoka. > > Certainly, in past meeting, we made it clear that we can discuss "problem > statement only presentation" first, > but that is optional. > > Regards, > Masato > > > 2015-02-24 14:41 GMT-06:00 Dean Pemberton <d...@internetnz.net.nz > <javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz');>>: > >> Yeah I think this is a bit of a radical proposal to accept at present. >> I'm not convinced we should be supporting CGN in this way, nor am I a >> fan of seeing more and more information make it into Whois which might >> not be the best place. >> >> I would like to hear more from Hiromi-san about the problem statement >> and how this might be solved, but I'm not at all sure I would support >> the current proposal. >> >> Would it be possible to withdraw the proposal and use the scheduled >> time during the Policy Sig for an informational session to allow >> Hiromi-san to present to the community the problem here? >> >> >> Dean >> -- >> Dean Pemberton >> >> Technical Policy Advisor >> InternetNZ >> +64 21 920 363 (mob) >> d...@internetnz.net.nz >> <javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz');> >> >> To promote the Internet's benefits and uses, and protect its potential. >> >> >> On Wed, Feb 25, 2015 at 6:11 AM, Owen DeLong <o...@delong.com >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','hir...@inetcore.com');> >> >> >> >> Tomohiro Fujisaki >> >> fujis...@syce.net >> <javascript:_e(%7B%7D,'cvml','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 1-256 is for HomeA >> >> 192.0.2.24/32 257-511 is for HomeB >> >> >> >> or 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 >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net');> >> > http://mailman.apnic.net/mailman/listinfo/sig-policy >> > >> > > -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential.
* 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
