Hi Dean and list, I don't want to add more implementation to the whois DB. Currently I thought remarks field as you mentioned.
But at this case, to using remarks field for detailed information, guidelines and help message/warning/alert would be changed. To inform this among member Registries(and its users), APNIC will announce a lot and it will bring them additional work. For security reason, set privilege to show will cost much to implement, I suppose. I hope making only a little change of policy would be better to do this. I would like to make consensus on the problem statement then discuss more about its detail on execution/implementation. Regards, On 2015/03/01 7:04, Dean Pemberton wrote: > I am currently neither in favour or opposed to this proposal, but I > would like to ask for a point of clarification... > > Is the author suggesting that new fields in the whois be added to > allow this funtionality? > > It would seem that this is something which operators could choose to > implement today using the 'remarks' field as they do for BGP community > information as shown below. > > $ whois -h rr.Level3.net as702 > > % RIPEdb(3.0.0a13) with ISI RPSL extensions > > aut-num: AS702 > as-name: AS702 > descr: Verizon Business EMEA - Commercial IP service provider in > Europe > admin-c: DUMY-RIPE > tech-c: DUMY-RIPE > remarks: -------------------------------------------------------------- > Verizon Business filters out inbound prefixes longer than /24. > We also filter any networks within AS702:RS-INBOUND-FILTER. > -------------------------------------------------------------- > VzBi uses the following communities with its customers: > 702:80 Set Local Pref 80 within AS702 > 702:120 Set Local Pref 120 within AS702 > 702:20 Announce only to VzBi AS'es and VzBi customers > 702:30 Keep within Europe, don't announce to other VzBi AS's > 702:1 Prepend AS702 once at edges of VzBi to Peers > 702:2 Prepend AS702 twice at edges of VzBi to Peers > 702:3 Prepend AS702 thrice at edges of VzBi to Peers > -------------------------------------------------------------- > Advanced communities for customers > 702:7020 Do not announce to AS702 peers with a scope of > National but advertise to Global Peers, European > Peers and VzBi customers. > 702:7001 Prepend AS702 once at edges of VzBi to AS702 > peers with a scope of National. > 702:7002 Prepend AS702 twice at edges of VzBi to AS702 > peers with a scope of National. > 702:7003 Prepend AS702 thrice at edges of VzBi to AS702 > peers with a scope of National. > 702:8020 Do not announce to AS702 peers with a scope of > European but advertise to Global Peers, National > Peers and VzBi customers. > 702:8001 Prepend AS702 once at edges of VzBi to AS702 > peers with a scope of European. > 702:8002 Prepend AS702 twice at edges of VzBi to AS702 > peers with a scope of European. > 702:8003 Prepend AS702 thrice at edges of VzBi to AS702 > peers with a scope of European. > -------------------------------------------------------------- > Additional details of the VzBi communities are located at: > http://www.verizonbusiness.com/uk/customer/bgp/ > -------------------------------------------------------------- > Details of VzBi's peering policy and how to get in touch with > VzBi regarding peering policy matters can be found at: > http://www.verizonbusiness.com/uunet/peering/ > -------------------------------------------------------------- > remarks: **************************** > remarks: * THIS OBJECT IS MODIFIED > remarks: * Please note that all data that is generally regarded > as personal > remarks: * data has been removed from this object. > remarks: * To view the original object, please query the RIPE Database > at: > remarks: * http://www.ripe.net/whois > remarks: **************************** > mnt-by: WCOM-EMEA-RICE-MNT > changed: [email protected] 20000101 > source: RIPE > -- > Dean Pemberton > > Technical Policy Advisor > InternetNZ > +64 21 920 363 (mob) > [email protected] > > To promote the Internet's benefits and uses, and protect its potential. > > > On Thu, Feb 5, 2015 at 5:52 AM, Masato Yamanishi <[email protected]> wrote: >> 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 >> [email protected] >> >> Tomohiro Fujisaki >> [email protected] >> >> >> 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 >> [email protected] >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > [email protected] > http://mailman.apnic.net/mailman/listinfo/sig-policy > -- =================================== 株式会社インテック 先端技術研究所 研究開発部 廣海（ひろみ）緑里 * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
