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> 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> 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>: > >> 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 >> >> Tomohiro Fujisaki >> 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 > 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
