From info at arin.net Mon Oct 2 11:19:36 2017 From: info at arin.net (ARIN) Date: Mon, 2 Oct 2017 11:19:36 -0400 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information Message-ID: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> ARIN was previously requested via the ARIN Consultation and Suggestion Process (ACSP) to open a consultation to generate discussion about the possibility of sun-setting RWhois support by the ARIN organization. ARIN's initial response to the ACSP indicated we would open a consultation following the completion of the Registration Data Access Protocol (RDAP) specification inside the IETF processes. This work has been completed and the RFC has been published. ARIN took the additional step of implementing RDAP inside its own directory services offering with referral support to the other Regional Internet Registries (RIRs). With this work complete, we are following through with the formalized request to open a consultation on this topic. https://www.arin.net/participate/acsp/suggestions/2013-22.html In accordance with ARIN's Number Resource Policy Manual (NRPM), Organizations are required to report certain types of customer network sub-delegation information (reassignments and reallocations) to ARIN. Currently there are two reporting methods available. Both are delineated in the NRPM and supported by ARIN's production services. There is also a third possible method of reporting sub-delegation information that could be made available, but is not yet offered. Method 1: SWIP (currently available): The reporting of sub-delegation information using ARIN's database. This can be done either by submitting a SWIP template, interfacing with ARIN's RESTful API, or by creating a sub-delegation inside ARIN Online using ARIN's SWIP-EZ functionality. https://www.arin.net/resources/request/reassignments.html Method 2: RWhois (currently available): The reporting of sub-delegation information on your own hosted and operated RWhois server with referral link information provided in ARIN Whois as part of your own organization's Whois records. In order for a user of ARIN's directory services to view sub-delegation information hosted by an RWhois server, they would have to submit a separate query to that RWhois server, and are not referred in an automated fashion. https://www.arin.net/resources/request/reassignments_rwhois.html Method 3: RDAP: The five RIRs currently use RDAP for referrals to each other's Whois data. Although the specification language of the RDAP could allow it to be used as a third method for the reporting of sub-delegation information to ARIN, it is not currently offered as an option. In order to make this option available, associated registry software would need to be created. This possible method would allow users of ARIN's directory services to view sub-delegation information available on customer hosted RDAP servers in an automated fashion. This RDAP method may also be viewed as redundant to RWhois. https://tools.ietf.org/html/rfc7482 https://www.arin.net/resources/rdap.html Options Going Forward ARIN expects to continue offering Method 1 (SWIP) into the foreseeable future. As previously described, we are acting on a formal suggestion to consult with the community about the future of RWhois support, and also have potential options with RDAP. * Question (general): Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which should ARIN support in the future? * Question (SWIP/RESTful API specific): The existing RESTful API allows users to report (SWIP) one sub-delegation at a time to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API? * Question (RWhois specific): As noted, RWhois servers are not referred to in an automated fashion when users query ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service? * Question (RDAP specific): If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated enabling software would be required. Should ARIN enable this method by creating an RDAP software suite that would allow ARIN registrants to run RDAP service locally? The feedback you provide during this consultation will help inform decisions about software tools and support for the reporting of network sub-delegation information to ARIN in the future. Thank you for your participation in the ARIN Consultation and Suggestion Process. Discussion onarin-consult at arin.netwill close on 27 October 2017. If you have any questions, please contact us atinfo at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marla.Azinger at FTR.com Mon Oct 2 12:34:26 2017 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 2 Oct 2017 16:34:26 +0000 Subject: [ARIN-consult] Opposed to removal of RWHOIS - Available Methods of Reporting Network Sub-Delegation Information Message-ID: Hello Frontier Communications opposes getting rid of RWHOIS. This is what Frontier has used for over 15 years and it works great. It would require a lot of time, money and effort to change how we report our assignments. This wheel is not broken, so please don't try to "fix" it. If someone desperately wants a new method for whatever their reason is, then please add if you must but do not remove RWHOIS. Thank you Marla Azinger Supervisor Network ENG IP Address Management ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.r.middleton at verizon.com Mon Oct 2 12:37:16 2017 From: stephen.r.middleton at verizon.com (Middleton, Stephen R) Date: Mon, 2 Oct 2017 16:37:16 +0000 Subject: [ARIN-consult] Opposed to removal of RWHOIS - Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: Message-ID: <378317f9dab7400586b355b7c4f67a2f@OMZP1LUMXCA06.uswin.ad.vzwcorp.com> Hello, I agree with our esteemed colleague and am a strong proponent of 'if it's not broke, don't fix it'. Best Regards, [Verizon] Stephen R Middleton, Sr. Global Wireline IP Address Management Public Data Network Engineering 22001 Loudoun County Parkway; F1-2-277 Ashburn, VA 20147 Office 703.694.6965 stephen.r.middleton at one.verizon.com [Twitter] [LinkedIn] From: ARIN-consult [mailto:arin-consult-bounces at arin.net] On Behalf Of Azinger, Marla Sent: Monday, October 02, 2017 12:34 PM To: arin-consult at arin.net Subject: [E] [ARIN-consult] Opposed to removal of RWHOIS - Available Methods of Reporting Network Sub-Delegation Information Hello Frontier Communications opposes getting rid of RWHOIS. This is what Frontier has used for over 15 years and it works great. It would require a lot of time, money and effort to change how we report our assignments. This wheel is not broken, so please don't try to "fix" it. If someone desperately wants a new method for whatever their reason is, then please add if you must but do not remove RWHOIS. Thank you Marla Azinger Supervisor Network ENG IP Address Management ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1378 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 306 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 446 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 351 bytes Desc: image004.png URL: From jschiller at google.com Mon Oct 2 13:10:18 2017 From: jschiller at google.com (Jason Schiller) Date: Mon, 2 Oct 2017 13:10:18 -0400 Subject: [ARIN-consult] Opposed to removal of RWHOIS - Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: <378317f9dab7400586b355b7c4f67a2f@OMZP1LUMXCA06.uswin.ad.vzwcorp.com> References: <378317f9dab7400586b355b7c4f67a2f@OMZP1LUMXCA06.uswin.ad.vzwcorp.com> Message-ID: I also agree with the assessment of continue to support what we are currently using... How every my read of the consultation is as follows: 1. We currently support SWIP 2. We currently support RWhois 3. When you do a whois lookup on the ARIN server for a block managed by another RIR, the ARIN server will fetch the info via RDAP and display it. Q1. Should ARIN add the support for its customers to run their own RDAP server, and display the results on behalf of their customer when someone does a whois lookup on an ARIN server? sure. Q2. Should ARIN continute to support all 3, or is only a sub-set needed? (the community already voiced continued support for SWIP) All 3. Q3. Should ARIN add bulk-upload features to the RESTful API to add SWIPs? ARIN should fist offer a bulk removal with the RESTful API as a higher priority. Bulk removal with text based SWIP would be just as high a priority. Bulk addition using the RESTful API would be nice, (but not a priority) Q4. Should ARIN provide an RDAP software suite that would allow ARIN registrants to run RDAP service locally? I would think providing the part of the source code they use should be fairly easy. I'm guessing someone in the community could easily open source that into a suite of utilities. ARIN could also provide a software suit as a lower priority item. On Mon, Oct 2, 2017 at 12:37 PM, Middleton, Stephen R < stephen.r.middleton at verizon.com> wrote: > Hello, > > > > I agree with our esteemed colleague and am a strong proponent of ?if it?s > not broke, don?t fix it?. > > > > Best Regards, > > > [image: Verizon] > > Stephen R Middleton, Sr. > Global Wireline IP Address Management > Public Data Network Engineering > > 22001 Loudoun County Parkway; F1-2-277 > Ashburn, VA 20147 > > Office 703.694.6965 <(703)%20694-6965> > stephen.r.middleton at one.verizon.com > > [image: Facebook] [image: Twitter] > [image: LinkedIn] > > > > > *From:* ARIN-consult [mailto:arin-consult-bounces at arin.net] *On Behalf Of > *Azinger, Marla > *Sent:* Monday, October 02, 2017 12:34 PM > *To:* arin-consult at arin.net > *Subject:* [E] [ARIN-consult] Opposed to removal of RWHOIS - Available > Methods of Reporting Network Sub-Delegation Information > > > > Hello > > > > Frontier Communications opposes getting rid of RWHOIS. This is what > Frontier has used for over 15 years and it works great. It would require a > lot of time, money and effort to change how we report our assignments. > > > > This wheel is not broken, so please don?t try to ?fix? it. > > > > If someone desperately wants a new method for whatever their reason is, > then please add if you must but do not remove RWHOIS. > > > > Thank you > > > > Marla Azinger > > Supervisor Network ENG > > IP Address Management > > > > > > > ------------------------------ > > > This communication is confidential. Frontier only sends and receives email > on the basis of the terms set out at http://www.frontier.com/email_ > disclaimer > > . > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 351 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1378 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 446 bytes Desc: not available URL: From jer at mia.net Mon Oct 9 11:14:57 2017 From: jer at mia.net (Jeremy Anthony Kinsey) Date: Mon, 9 Oct 2017 10:14:57 -0500 Subject: [ARIN-consult] Opposed to removal of RWHOIS - Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: Message-ID: <7D21E8E1-2589-4B7B-94BD-386F319A4641@mia.net> I?d have to second this. If it ain?t broke, don?t fix it. > On Oct 2, 2017, at 11:34 AM, Azinger, Marla wrote: > > Hello > > Frontier Communications opposes getting rid of RWHOIS. This is what Frontier has used for over 15 years and it works great. It would require a lot of time, money and effort to change how we report our assignments. > > This wheel is not broken, so please don?t try to ?fix? it. > > If someone desperately wants a new method for whatever their reason is, then please add if you must but do not remove RWHOIS. > > Thank you > > Marla Azinger > Supervisor Network ENG > IP Address Management > > > > > This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer . > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. Regards, Jeremy Anthony Kinsey HostDrive.Com P.O. Box 686 Lake Geneva, WI. 53147 Dedicated Servers since 1997 Web: https://hostdrive.com Tel: 262-248-6759 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Thu Oct 12 16:33:54 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 12 Oct 2017 13:33:54 -0700 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: I'm writing to support the sunsetting of the rwhois protocol as a method for ARIN members to document reallocation and reassignment records.? That doesn't mean this year or next year, but I believe we should set a timeline for deprecating this protocol.? Perhaps a date of 2022 would be reasonable.? (Yes, some organizations will not do the work despite the 4 years of time to do it, but a shorter time frame would also be unacceptable to some) I have seen those who have posted on this consultation noting that "rwhois works and isn't broken so don't fix it."? While I will agree that it is "technically" not broken, I believe that it is operationally broken.? These are some of the reasons why I believe we should move on to something better.? Any by better, I mean moving to records stored in the ARIN database (SWIP) or RDAP. -Rwhois doesn't support encryption or data-integrity during transport -There is no automatic referral, so when most people query ARIN whois they don't know there is potentially another more specific record and even if they are aware, how to do rwhois is not "easy" for many users.? Yes its easy for engineers and some operators, but there are many users of "whois" data for whom this is a barrier too high.? Could we invest in lots of training for rwhois, yes, but we will always be behind on this as long as its not a click away for most users. -As was noted in the most recent ARIN meeting, law enforcement agencies use whois data as a source for their investigations and other work, and having accurate records available on a timely basis is very important to them.? I don't believe that rwhois data is as accessible and available as data in the ARIN database. -RDAP was designed with referral in mind from the ground up, so that you get all the records no matter where they are located with a single query.? -ARIN (in possible collaboration with other RIRS) should develop an RDAP package for those who like to host their own,? distributed database.? The new package should support bulk retrieval of records to assist in data collection and analysis.? (Also it was noted in the most recent ARIN meeting that there are differences today in how the different RIRs are reporting fields/data via RDAP.? It would be good for the RIRs in collaboration with each other and other organizations that want to run RDAP servers for IP number resources to work to create a standard met of fields which are required for IP number resource records, along with other optional fields for additional data) It has been noted casually that there are many rwhois servers which are down or aren't available.? I believe this also contributes to this data set being operationally unavailable.? I'd like to ask if ARIN staff can confirm some of these details with data from the ARIN's database and operational practices.? Specifically if ARIN could provide the following details about how rwhois is being operated today I believe it would inform the community in this consultation process. 1) Number of orgs which have IPv4 or IPv6 resources and a rwhois record on their org-id. ? 2) Number of IPv4 and IPv6 blocks with a rwhois server under the org-id records ? 3) Number of /24 IPv4 equivalents covered by the above records ? 4) Number of /32 IPv6 equivalents covered by the above records ? 5) Total number of unique rwhois servers ? 6) Percent of rwhois servers which are online (complete a tcp connection accept a string and respond with some text) ? 7) Percent of rwhois server who appear to respond with a valid record for an address within each allocated block Thanks, Andrew On 10/2/2017 8:19 AM, ARIN wrote: > > ARIN was previously requested via the ARIN Consultation and Suggestion > Process (ACSP) to open a consultation to generate discussion about the > possibility of sun-setting RWhois support by the ARIN organization. > ARIN's initial response to the ACSP indicated we would open a > consultation following the completion of the Registration Data Access > Protocol (RDAP) specification inside the IETF processes. This work has > been completed and the RFC has been published. ARIN took the > additional step of implementing RDAP inside its own directory services > offering with referral support to the other Regional Internet > Registries (RIRs). With this work complete, we are following through > with the formalized request to open a consultation on this topic. > > https://www.arin.net/participate/acsp/suggestions/2013-22.html > > In accordance with ARIN's Number Resource Policy Manual (NRPM), > Organizations are required to report certain types of customer network > sub-delegation information (reassignments and reallocations) to ARIN. > Currently there are two reporting methods available. Both are > delineated in the NRPM and supported by ARIN's production services. > There is also a third possible method of reporting sub-delegation > information that could be made available, but is not yet offered. > > Method 1:? > > SWIP (currently available):? The reporting of sub-delegation > information using ARIN's database. This can be done either by > submitting a SWIP template, interfacing with ARIN's RESTful API, or by > creating a sub-delegation inside ARIN Online using ARIN's SWIP-EZ > functionality.? > > https://www.arin.net/resources/request/reassignments.html > > Method 2:? > > RWhois (currently available):? The reporting of sub-delegation > information on your own hosted and operated RWhois server with > referral link information provided in ARIN Whois as part of your own > organization's Whois records. In order for a user of ARIN's directory > services to view sub-delegation information hosted by an RWhois > server, they would have to submit a separate query to that RWhois > server, and are not referred in an automated fashion. > > https://www.arin.net/resources/request/reassignments_rwhois.html??????????? > > Method 3:? > > RDAP:? The five RIRs currently use RDAP for referrals to each other's > Whois data. Although the specification language of the RDAP could > allow it to be used as a third method for the reporting of > sub-delegation information to ARIN, it is not currently offered as an > option. In order to make this option available, associated registry > software would need to be created. This possible method would allow > users of ARIN's directory services to view sub-delegation information > available on customer hosted RDAP servers in an automated fashion. > This RDAP method may also be viewed as redundant to RWhois. > > https://tools.ietf.org/html/rfc7482 > https://www.arin.net/resources/rdap.html > > Options Going Forward > > ARIN expects to continue offering Method 1 (SWIP) into the foreseeable > future. As previously described, we are acting on a formal suggestion > to consult with the community about the future of RWhois support, and > also have potential options with RDAP. > > * Question (general):? > > > ??? ??? Of the three sub-delegation reporting methods listed (SWIP, > RWhois, RDAP), which should ARIN support in the future? > > * Question (SWIP/RESTful API specific):? > > > ??? ??? The existing RESTful API allows users to report (SWIP) one > sub-delegation at a time to be added to ARIN Whois. Should ?? ARIN add > bulk-upload features to the RESTful API? > > * Question (RWhois specific):? > > > ??? ???? As noted, RWhois servers are not referred to in an automated > fashion when users query ARIN Whois. Should ARIN ? automate referrals > to RWhois servers from ARIN's Whois service? > > * Question (RDAP specific):? > > > ??? ??? If ARIN was to allow the reporting of network sub-delegation > information using RDAP, associated enabling software would be > required. Should ARIN enable this method by creating an RDAP software > suite that would allow ARIN registrants to run ??? ??? RDAP service > locally? > > The feedback you provide during this consultation will help inform > decisions about software tools and support for the reporting of > network sub-delegation information to ARIN in the future. Thank you > for your participation in the ARIN Consultation and Suggestion Process. > > Discussion on?arin-consult at arin.net?will close on 27 October 2017. If > you have any questions, please contact us at?info at arin.net. > > > Regards, > > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > > > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Oct 12 17:18:09 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Oct 2017 14:18:09 -0700 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: > On Oct 12, 2017, at 1:33 PM, Andrew Dul wrote: > > I'm writing to support the sunsetting of the rwhois protocol as a method for ARIN members to document reallocation and reassignment records. > > That doesn't mean this year or next year, but I believe we should set a timeline for deprecating this protocol. Perhaps a date of 2022 would be reasonable. (Yes, some organizations will not do the work despite the 4 years of time to do it, but a shorter time frame would also be unacceptable to some) > > I have seen those who have posted on this consultation noting that "rwhois works and isn't broken so don't fix it." While I will agree that it is "technically" not broken, I believe that it is operationally broken. > > These are some of the reasons why I believe we should move on to something better. Any by better, I mean moving to records stored in the ARIN database (SWIP) or RDAP. > > -Rwhois doesn't support encryption or data-integrity during transport Neither does WHOIS for records stored in the ARIN database (SWIP), so why should ISPs face an increased burden here if you are not also planning to eliminate whois? > -There is no automatic referral, so when most people query ARIN whois they don't know there is potentially another more specific record and even if they are aware, how to do rwhois is not "easy" for many users. Yes its easy for engineers and some operators, but there are many users of "whois" data for whom this is a barrier too high. Could we invest in lots of training for rwhois, yes, but we will always be behind on this as long as its not a click away for most users. That?s a client implementation problem? There?s no reason clients couldn?t automatically follow referrals. The reality is that very few people actually use genuine rwhois clients (some of which will automatically follow referrals) and instead use a whois client (which works, but doesn?t do automatic referrals as you noted). > -As was noted in the most recent ARIN meeting, law enforcement agencies use whois data as a source for their investigations and other work, and having accurate records available on a timely basis is very important to them. I don't believe that rwhois data is as accessible and available as data in the ARIN database. That depends on the provider implementing the RWHOIS server. In many (most?) cases, I think it is equally available. > -RDAP was designed with referral in mind from the ground up, so that you get all the records no matter where they are located with a single query. This is also true with RWHOIS if you use an appropriate RWHOIS client. The difference is that RDAP is not backwards compatible with your WHOIS client, so it simply breaks unless you have an RDAP client. > -ARIN (in possible collaboration with other RIRS) should develop an RDAP package for those who like to host their own, distributed database. The new package should support bulk retrieval of records to assist in data collection and analysis. (Also it was noted in the most recent ARIN meeting that there are differences today in how the different RIRs are reporting fields/data via RDAP. It would be good for the RIRs in collaboration with each other and other organizations that want to run RDAP servers for IP number resources to work to create a standard met of fields which are required for IP number resource records, along with other optional fields for additional data) RIPE?s WHOIS and RDAP is so thoroughly integrated to their IRR that you can?t manage their whois without dealing with the hassles and syntactic pedantry of RPSL. I would not consider inflicting this on the rest of the world to be an improvement. > It has been noted casually that there are many rwhois servers which are down or aren't available. I believe this also contributes to this data set being operationally unavailable. I?d argue that ISPs depending on RWHOIS to meet their ARIN obligations who have servers that are down or unavailable are not in compliance with their RSA obligations and these issues should be addressed on a case by case basis. If you have specific examples, report them to ARIN for investigation. Owen From bill at herrin.us Thu Oct 12 18:16:44 2017 From: bill at herrin.us (William Herrin) Date: Thu, 12 Oct 2017 18:16:44 -0400 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: On Mon, Oct 2, 2017 at 11:19 AM, ARIN wrote: > ARIN expects to continue offering Method 1 (SWIP) into the foreseeable > future. As previously described, we are acting on a formal suggestion to > consult with the community about the future of RWhois support, and also > have potential options with RDAP. > > - Question (general): > > > Of the three sub-delegation reporting methods listed (SWIP, > RWhois, RDAP), which should ARIN support in the future? > Howdy, The main problem I had with rwhois, way back when I ran rwhois, was that the software would crash after a few weeks and since nothing noticeable broke, I wouldn't realize it for a few months. Even if the software is now rock solid, something on the server hosting it will break. It's just not a first class element of the system. On the other hand, SWIP is push-style database replication involving mismatched and custom pieces of software plus manual submissions. The probability of data synchronization problems approaches 1. RDAP at least operates as an HTTP web app that can presumably be managed the same way you maintain availability of your other web servers. In the far future, I think ARIN should support RDAP. Period. Getting from here to there in the intermediate term is another matter. > - Question (SWIP/RESTful API specific): > > > The existing RESTful API allows users to report (SWIP) one > sub-delegation at a time to be added to ARIN Whois. Should ARIN add > bulk-upload features to the RESTful API? > Not necessary. If changes are happening in enough bulk for that to be needful, there's a programmer who needs a spanking. On the other hand, if it's not available now then there should be a facility for a registrant to **bulk-download** all their SWIP entries at once for comparison with their local database. Otherwise data synchronization requires a nasty dance. > - Question (RWhois specific): > > > As noted, RWhois servers are not referred to in an automated > fashion when users query ARIN Whois. Should ARIN automate referrals to > RWhois servers from ARIN's Whois service? > If you keep rwhois then yes, of course. Caveat that by "automate" I mean publish the referral in a machine-readable form in the rwhois response, expect rwhois client software to follow it and make sure your own rwhois clients (e.g. on your web site) follow it. Last I checked (which was a very long time ago) ARIN did this brokenly: published both the referral and contradictory SWIP data which really confused things. > - Question (RDAP specific): > > > If ARIN was to allow the reporting of network sub-delegation > information using RDAP, associated enabling software would be required. > Should ARIN enable this method by creating an RDAP software suite that > would allow ARIN registrants to run RDAP service locally? > No. JSON over HTTP is easy enough to work with and writing appropriate interface modules should be the responsibility of the folks vending IPAM software. On the other hand, curl --head http://rdap.org/ip/199.33.224.1 lands at http://whois.arin.net/rest/ip/199.33.224.1 which does not output RDAP formatted results (XML != JSON), so there's some work to be done on ARIN's side just to report RDAP correctly with ARIN's own data. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsweeting at arin.net Fri Oct 13 10:18:38 2017 From: jsweeting at arin.net (John Sweeting) Date: Fri, 13 Oct 2017 14:18:38 +0000 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: <163D3B9C-D9E0-4123-A638-FADB7542C187@arin.net> Andrew, Here is the information for your set of questions below: 1) Number of orgs with an rwhois server on any of their records There are 778 orgs with resources with rwhois servers. Of those, 610 are unique. For clarification, rwhois servers are attributes of Orgs in the ARIN database. 2) Number of IPv4 and IPv6 blocks with a rwhois server on the record a) For IPv6, the number is 2044 b) For IPv4, the number is 8563 3) Number of /24 IPv4 equivalents covered by the above records There are 638799 IPv3 /24 equivalents covered by the above records. 4) Number of /32 equivalents covered by above records There are 23385 IPv6 /32 equivalents covered by the above networks. 5) Total number of unique rwhois servers See 1, there are 610 6) Percent of rwhois servers which are online (complete a tcp connection accept a string and respond with some text) 39% of servers in 1.b 7) Percent of rwhois server who appear to respond with a valid record for an address within each allocated block. 86% of servers in 6 From: ARIN-consult on behalf of Andrew Dul Reply-To: "andrew.dul at quark.net" Date: Thursday, October 12, 2017 at 4:35 PM To: "arin-consult at arin.net" Subject: Re: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information I'm writing to support the sunsetting of the rwhois protocol as a method for ARIN members to document reallocation and reassignment records. That doesn't mean this year or next year, but I believe we should set a timeline for deprecating this protocol. Perhaps a date of 2022 would be reasonable. (Yes, some organizations will not do the work despite the 4 years of time to do it, but a shorter time frame would also be unacceptable to some) I have seen those who have posted on this consultation noting that "rwhois works and isn't broken so don't fix it." While I will agree that it is "technically" not broken, I believe that it is operationally broken. These are some of the reasons why I believe we should move on to something better. Any by better, I mean moving to records stored in the ARIN database (SWIP) or RDAP. -Rwhois doesn't support encryption or data-integrity during transport -There is no automatic referral, so when most people query ARIN whois they don't know there is potentially another more specific record and even if they are aware, how to do rwhois is not "easy" for many users. Yes its easy for engineers and some operators, but there are many users of "whois" data for whom this is a barrier too high. Could we invest in lots of training for rwhois, yes, but we will always be behind on this as long as its not a click away for most users. -As was noted in the most recent ARIN meeting, law enforcement agencies use whois data as a source for their investigations and other work, and having accurate records available on a timely basis is very important to them. I don't believe that rwhois data is as accessible and available as data in the ARIN database. -RDAP was designed with referral in mind from the ground up, so that you get all the records no matter where they are located with a single query. -ARIN (in possible collaboration with other RIRS) should develop an RDAP package for those who like to host their own, distributed database. The new package should support bulk retrieval of records to assist in data collection and analysis. (Also it was noted in the most recent ARIN meeting that there are differences today in how the different RIRs are reporting fields/data via RDAP. It would be good for the RIRs in collaboration with each other and other organizations that want to run RDAP servers for IP number resources to work to create a standard met of fields which are required for IP number resource records, along with other optional fields for additional data) It has been noted casually that there are many rwhois servers which are down or aren't available. I believe this also contributes to this data set being operationally unavailable. I'd like to ask if ARIN staff can confirm some of these details with data from the ARIN's database and operational practices. Specifically if ARIN could provide the following details about how rwhois is being operated today I believe it would inform the community in this consultation process. 1) Number of orgs which have IPv4 or IPv6 resources and a rwhois record on their org-id. 2) Number of IPv4 and IPv6 blocks with a rwhois server under the org-id records 3) Number of /24 IPv4 equivalents covered by the above records 4) Number of /32 IPv6 equivalents covered by the above records 5) Total number of unique rwhois servers 6) Percent of rwhois servers which are online (complete a tcp connection accept a string and respond with some text) 7) Percent of rwhois server who appear to respond with a valid record for an address within each allocated block Thanks, Andrew On 10/2/2017 8:19 AM, ARIN wrote: ARIN was previously requested via the ARIN Consultation and Suggestion Process (ACSP) to open a consultation to generate discussion about the possibility of sun-setting RWhois support by the ARIN organization. ARIN's initial response to the ACSP indicated we would open a consultation following the completion of the Registration Data Access Protocol (RDAP) specification inside the IETF processes. This work has been completed and the RFC has been published. ARIN took the additional step of implementing RDAP inside its own directory services offering with referral support to the other Regional Internet Registries (RIRs). With this work complete, we are following through with the formalized request to open a consultation on this topic. https://www.arin.net/participate/acsp/suggestions/2013-22.html In accordance with ARIN's Number Resource Policy Manual (NRPM), Organizations are required to report certain types of customer network sub-delegation information (reassignments and reallocations) to ARIN. Currently there are two reporting methods available. Both are delineated in the NRPM and supported by ARIN's production services. There is also a third possible method of reporting sub-delegation information that could be made available, but is not yet offered. Method 1: SWIP (currently available): The reporting of sub-delegation information using ARIN's database. This can be done either by submitting a SWIP template, interfacing with ARIN's RESTful API, or by creating a sub-delegation inside ARIN Online using ARIN's SWIP-EZ functionality. https://www.arin.net/resources/request/reassignments.html Method 2: RWhois (currently available): The reporting of sub-delegation information on your own hosted and operated RWhois server with referral link information provided in ARIN Whois as part of your own organization's Whois records. In order for a user of ARIN's directory services to view sub-delegation information hosted by an RWhois server, they would have to submit a separate query to that RWhois server, and are not referred in an automated fashion. https://www.arin.net/resources/request/reassignments_rwhois.html Method 3: RDAP: The five RIRs currently use RDAP for referrals to each other's Whois data. Although the specification language of the RDAP could allow it to be used as a third method for the reporting of sub-delegation information to ARIN, it is not currently offered as an option. In order to make this option available, associated registry software would need to be created. This possible method would allow users of ARIN's directory services to view sub-delegation information available on customer hosted RDAP servers in an automated fashion. This RDAP method may also be viewed as redundant to RWhois. https://tools.ietf.org/html/rfc7482 https://www.arin.net/resources/rdap.html Options Going Forward ARIN expects to continue offering Method 1 (SWIP) into the foreseeable future. As previously described, we are acting on a formal suggestion to consult with the community about the future of RWhois support, and also have potential options with RDAP. ? Question (general): Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which should ARIN support in the future? ? Question (SWIP/RESTful API specific): The existing RESTful API allows users to report (SWIP) one sub-delegation at a time to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API? ? Question (RWhois specific): As noted, RWhois servers are not referred to in an automated fashion when users query ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service? ? Question (RDAP specific): If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated enabling software would be required. Should ARIN enable this method by creating an RDAP software suite that would allow ARIN registrants to run RDAP service locally? The feedback you provide during this consultation will help inform decisions about software tools and support for the reporting of network sub-delegation information to ARIN in the future. Thank you for your participation in the ARIN Consultation and Suggestion Process. Discussion on arin-consult at arin.net will close on 27 October 2017. If you have any questions, please contact us at info at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Fri Oct 13 14:39:31 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 13 Oct 2017 11:39:31 -0700 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: <163D3B9C-D9E0-4123-A638-FADB7542C187@arin.net> References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> <163D3B9C-D9E0-4123-A638-FADB7542C187@arin.net> Message-ID: <33f87604-af10-d90e-f5be-9f68223fa07c@quark.net> My interpretation of this is that we clearly have a operational problem with rwhois services.? Even taking the less strict test of 39% active, this would mean that almost the equivalent of 7 IPv4 /8s under rwhois have no operational reassignment or reallocation records currently available.? rwhois isn't a priority for organizations because those who use it are often not-customers, and there is no revenue from providing this service.? Is this all the protocol's fault, no, but making the data more accessible, visible, and useful would make keeping rwhois or rdap distributed servers up and operational more important when people see lookup failures. There is no simple answer here, but I believe as a community we can and should do better.? Andrew On 10/13/2017 7:18 AM, John Sweeting wrote: > > Andrew, > > ? > > Here is the information for your set of questions below: > > ? > > 1) Number of orgs with an rwhois server on any of their records > > ? > > There are 778 orgs with resources with rwhois servers. Of those, > > 610 are unique. For clarification, rwhois servers are attributes of > Orgs in the ARIN > > database. > > ? > > 2) Number of IPv4 and IPv6 blocks with a rwhois server on the record > > ? > > a) For IPv6, the number is 2044 > > b) For IPv4, the number is 8563 > > ? > > 3) Number of /24 IPv4 equivalents covered by the above records > > ? > > There are 638799 IPv3 /24 equivalents covered by the above records. > > ? > > 4) Number of /32 equivalents covered by above records > > ? > > There are 23385 IPv6 /32 equivalents covered by the above networks. > > ? > > 5) Total number of unique rwhois servers > > ? > > See 1, there are 610 > > ? > > 6) Percent of rwhois servers which are online (complete a tcp connection > > accept a string and respond with some text) > > ? > > 39% of servers in 1.b > > ? > > 7) Percent of rwhois server who appear to respond with a valid record > > for an address within each allocated block. > > ? > > 86% of servers in 6 > > ? > > ? > > *From: *ARIN-consult on behalf of > Andrew Dul > *Reply-To: *"andrew.dul at quark.net" > *Date: *Thursday, October 12, 2017 at 4:35 PM > *To: *"arin-consult at arin.net" > *Subject: *Re: [ARIN-consult] NEW Consultation: Available Methods of > Reporting Network Sub-Delegation Information > > ? > > I'm writing to support the sunsetting of the rwhois protocol as a > method for ARIN members to document reallocation and reassignment > records.? > > That doesn't mean this year or next year, but I believe we should set > a timeline for deprecating this protocol.? Perhaps a date of 2022 > would be reasonable.? (Yes, some organizations will not do the work > despite the 4 years of time to do it, but a shorter time frame would > also be unacceptable to some) > > I have seen those who have posted on this consultation noting that > "rwhois works and isn't broken so don't fix it."? While I will agree > that it is "technically" not broken, I believe that it is > operationally broken.? > > These are some of the reasons why I believe we should move on to > something better.? Any by better, I mean moving to records stored in > the ARIN database (SWIP) or RDAP. > > -Rwhois doesn't support encryption or data-integrity during transport > -There is no automatic referral, so when most people query ARIN whois > they don't know there is potentially another more specific record and > even if they are aware, how to do rwhois is not "easy" for many > users.? Yes its easy for engineers and some operators, but there are > many users of "whois" data for whom this is a barrier too high.? Could > we invest in lots of training for rwhois, yes, but we will always be > behind on this as long as its not a click away for most users. > -As was noted in the most recent ARIN meeting, law enforcement > agencies use whois data as a source for their investigations and other > work, and having accurate records available on a timely basis is very > important to them.? I don't believe that rwhois data is as accessible > and available as data in the ARIN database. > -RDAP was designed with referral in mind from the ground up, so that > you get all the records no matter where they are located with a single > query.? > -ARIN (in possible collaboration with other RIRS) should develop an > RDAP package for those who like to host their own,? distributed > database.? The new package should support bulk retrieval of records to > assist in data collection and analysis.? (Also it was noted in the > most recent ARIN meeting that there are differences today in how the > different RIRs are reporting fields/data via RDAP.? It would be good > for the RIRs in collaboration with each other and other organizations > that want to run RDAP servers for IP number resources to work to > create a standard met of fields which are required for IP number > resource records, along with other optional fields for additional data) > > It has been noted casually that there are many rwhois servers which > are down or aren't available.? I believe this also contributes to this > data set being operationally unavailable.? > > I'd like to ask if ARIN staff can confirm some of these details with > data from the ARIN's database and operational practices.? Specifically > if ARIN could provide the following details about how rwhois is being > operated today I believe it would inform the community in this > consultation process. > > 1) Number of orgs which have IPv4 or IPv6 resources and a rwhois > record on their org-id. > ? > 2) Number of IPv4 and IPv6 blocks with a rwhois server under the > org-id records > ? > 3) Number of /24 IPv4 equivalents covered by the above records > ? > 4) Number of /32 IPv6 equivalents covered by the above records > ? > 5) Total number of unique rwhois servers > ? > 6) Percent of rwhois servers which are online (complete a tcp connection > accept a string and respond with some text) > ? > 7) Percent of rwhois server who appear to respond with a valid record > for an address within each allocated block > > > Thanks, > Andrew > > > > On 10/2/2017 8:19 AM, ARIN wrote: > > ARIN was previously requested via the ARIN Consultation and > Suggestion Process (ACSP) to open a consultation to generate > discussion about the possibility of sun-setting RWhois support by > the ARIN organization. ARIN's initial response to the ACSP > indicated we would open a consultation following the completion of > the Registration Data Access Protocol (RDAP) specification inside > the IETF processes. This work has been completed and the RFC has > been published. ARIN took the additional step of implementing RDAP > inside its own directory services offering with referral support > to the other Regional Internet Registries (RIRs). With this work > complete, we are following through with the formalized request to > open a consultation on this topic. > > https://www.arin.net/participate/acsp/suggestions/2013-22.html > > In accordance with ARIN's Number Resource Policy Manual (NRPM), > Organizations are required to report certain types of customer > network sub-delegation information (reassignments and > reallocations) to ARIN. Currently there are two reporting methods > available. Both are delineated in the NRPM and supported by ARIN's > production services. There is also a third possible method of > reporting sub-delegation information that could be made available, > but is not yet offered. > > Method 1:? > > SWIP (currently available):? The reporting of sub-delegation > information using ARIN's database. This can be done either by > submitting a SWIP template, interfacing with ARIN's RESTful API, > or by creating a sub-delegation inside ARIN Online using ARIN's > SWIP-EZ functionality.? > > https://www.arin.net/resources/request/reassignments.html > > Method 2:? > > RWhois (currently available):? The reporting of sub-delegation > information on your own hosted and operated RWhois server with > referral link information provided in ARIN Whois as part of your > own organization's Whois records. In order for a user of ARIN's > directory services to view sub-delegation information hosted by an > RWhois server, they would have to submit a separate query to that > RWhois server, and are not referred in an automated fashion. > > https://www.arin.net/resources/request/reassignments_rwhois.html??????????? > > Method 3:? > > RDAP:? The five RIRs currently use RDAP for referrals to each > other's Whois data. Although the specification language of the > RDAP could allow it to be used as a third method for the reporting > of sub-delegation information to ARIN, it is not currently offered > as an option. In order to make this option available, associated > registry software would need to be created. This possible method > would allow users of ARIN's directory services to view > sub-delegation information available on customer hosted RDAP > servers in an automated fashion. This RDAP method may also be > viewed as redundant to RWhois. > > https://tools.ietf.org/html/rfc7482 > https://www.arin.net/resources/rdap.html > > Options Going Forward > > ARIN expects to continue offering Method 1 (SWIP) into the > foreseeable future. As previously described, we are acting on a > formal suggestion to consult with the community about the future > of RWhois support, and also have potential options with RDAP. > > ????????? Question (general):? > > > ??? ??? Of the three sub-delegation reporting methods listed > (SWIP, RWhois, RDAP), which should ARIN support in the future? > > ????????? Question (SWIP/RESTful API specific):? > > > ??? ??? The existing RESTful API allows users to report (SWIP) one > sub-delegation at a time to be added to ARIN Whois. Should ?? ARIN > add bulk-upload features to the RESTful API? > > ????????? Question (RWhois specific):? > > > ??? ???? As noted, RWhois servers are not referred to in an > automated fashion when users query ARIN Whois. Should ARIN ? > automate referrals to RWhois servers from ARIN's Whois service? > > ????????? Question (RDAP specific):? > > > ??? ??? If ARIN was to allow the reporting of network > sub-delegation information using RDAP, associated enabling > software would be required. Should ARIN enable this method by > creating an RDAP software suite that would allow ARIN registrants > to run ??? ??? RDAP service locally? > > The feedback you provide during this consultation will help inform > decisions about software tools and support for the reporting of > network sub-delegation information to ARIN in the future. Thank > you for your participation in the ARIN Consultation and Suggestion > Process. > > Discussion on?arin-consult at arin.net > ?will close on 27 October 2017. If > you have any questions, please contact us at?info at arin.net > . > > ? > > Regards, > > ? > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > ? > > ? > > > > > _______________________________________________ > > ARIN-Consult > > You are receiving this message because you are subscribed to the ARIN Consult Mailing > > List (ARIN-consult at arin.net ). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > > Help Desk at info at arin.net if you experience any issues. > > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Fri Oct 13 15:22:17 2017 From: jschiller at google.com (Jason Schiller) Date: Fri, 13 Oct 2017 15:22:17 -0400 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: Comments in line. Question (general): Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which should ARIN support in the future? Answer: ARIN should support all three in the future. Question (SWIP/RESTful API specific): The existing RESTful API allows users to report (SWIP) one sub-delegation at a time to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API? Answer: 1. Bulk removal is more important that bulk additions. e.g. can you remove all SWIPs for prefixes within 1.2.0.0/18. 2. If we offer bulk additions, it should be supported for all update types (template, RESTful API) 3. Sure, but I don't think the priority is very high. Question (RWhois specific): As noted, RWhois servers are not referred to in an automated fashion when users query ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service? Answer: Yes. This seems to work for my whois client (whois Version 5.1.1. Report bugs to ). (example below) When somoene does a "SEARCH WhoisRWS" on the ARIN website, it should likewise chase the rwhois referral, and display it on the ARIN web site. Furthermore, ARIN should keep stats on when these referrals time out, and when they work. If there is not a requirement for all whois clients to follow the referral, and this can be addressed on the server side, then lets address this on the server side. Double especially if this addresses an issue where providers publish rwhois data, but make it only accessible to the RIRs. Question: How will this interact with a whois client that currently follows the referral? Question (RDAP specific): If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated enabling software would be required. Should ARIN enable this method by creating an RDAP software suite that would allow ARIN registrants to run RDAP service locally? Answer: Yes. It should be fairly easy to just open (part of) the source of your RDAP service. People can crib of that, and integrate with their IPAM / radius logs etc. Surely someone will voluntarily provide a packed binary, and the source for it. If not ARIN should fill this gap. If ARIN supports RDAP referrals, should it sunset rwhois? No. Is RDAP referrals better than rwhois referrals? I suspect mileage varies by organization. Whois example =============== whois -h whois.arin.net 23.228.169.1 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # # # The following results may also be obtained via: # https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 # NetRange: 23.228.128.0 - 23.228.191.255 CIDR: 23.228.128.0/18 NetName: GOOGLE-FIBER NetHandle: NET-23-228-128-0-1 Parent: NET23 (NET-23-0-0-0-0) NetType: Direct Allocation OriginAS: AS16591 Organization: Google Fiber Inc. (GF) RegDate: 2013-09-13 Updated: 2014-03-26 Ref: https://whois.arin.net/rest/net/NET-23-228-128-0-1 OrgName: Google Fiber Inc. OrgId: GF Address: 1600 Amphitheatre Parkway City: Mountain ViewNeither does WHOIS for records stored in the ARIN database (SWIP), so why should ISPs face an increased burden here if you are not also planning to eliminate whois? StateProv: CA PostalCode: 94043 Country: US RegDate: 2010-10-08 Updated: 2017-01-28 Ref: https://whois.arin.net/rest/org/GF ReferralServer: rwhois://rwhois.googlefiber.net:8987 OrgAbuseHandle: GFA32-ARIN OrgAbuseName: Google Fiber Abuse OrgAbusePhone: +1-650-253-0000 OrgAbuseEmail: abuse at googlefiber.net OrgAbuseRef: https://whois.arin.net/rest/poc/GFA32-ARIN OrgTechHandle: ZG39-ARIN OrgTechName: Google Inc OrgTechPhone: +1-650-253-0000 OrgTechEmail: arin-contact at google.com OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # Found a referral to rwhois.googlefiber.net:8987. %rwhois V-1.5:000090:00 rwhois.googlefiber.net network:ID:NET-GF-V4-23-228-169-0 network:IP-Network:23.228.169.0/29 network:Org-Name:Wasatch Mental Health network:Street-Address:750 N 200 W network:Unit-Number: network:City:Provo network:State:UT network:Postal-Code:84601 network:Country-Code:US %ok =============== end Whois example What problem are we trying to solve? If it is having On Thu, Oct 12, 2017 at 4:33 PM, Andrew Dul wrote: > I'm writing to support the sunsetting of the rwhois protocol as a method > for ARIN members to document reallocation and reassignment records. > > That doesn't mean this year or next year, but I believe we should set a > timeline for deprecating this protocol. Perhaps a date of 2022 would be > reasonable. (Yes, some organizations will not do the work despite the 4 > years of time to do it, but a shorter time frame would also be unacceptable > to some) > > I have seen those who have posted on this consultation noting that "rwhois > works and isn't broken so don't fix it." While I will agree that it is > "technically" not broken, I believe that it is operationally broken. > > These are some of the reasons why I believe we should move on to something > better. Any by better, I mean moving to records stored in the ARIN > database (SWIP) or RDAP. > > -Rwhois doesn't support encryption or data-integrity during transport > As Owen points out, neither does WHOIS for records stored in the ARIN database (SWIP), so why should ISPs face an increased burden here if you are not also planning to eliminate whois? > -There is no automatic referral, so when most people query ARIN whois they > don't know there is potentially another more specific record and even if > they are aware, how to do rwhois is not "easy" for many users. Yes its > easy for engineers and some operators, but there are many users of "whois" > data for whom this is a barrier too high. Could we invest in lots of > training for rwhois, yes, but we will always be behind on this as long as > its not a click away for most users. > as stated above whois to rwhois automatic referrals needs to work everywhere. whois -h whois.arin.net 23.228.169.1 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # # # The following results may also be obtained via: # https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 # NetRange: 23.228.128.0 - 23.228.191.255 CIDR: 23.228.128.0/18 NetName: GOOGLE-FIBER NetHandle: NET-23-228-128-0-1 Parent: NET23 (NET-23-0-0-0-0) NetType: Direct Allocation OriginAS: AS16591 Organization: Google Fiber Inc. (GF) RegDate: 2013-09-13 Updated: 2014-03-26 Ref: https://whois.arin.net/rest/net/NET-23-228-128-0-1 OrgName: Google Fiber Inc. OrgId: GF Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US RegDate: 2010-10-08 Updated: 2017-01-28 Ref: https://whois.arin.net/rest/org/GF ReferralServer: rwhois://rwhois.googlefiber.net:8987 OrgAbuseHandle: GFA32-ARIN OrgAbuseName: Google Fiber Abuse OrgAbusePhone: +1-650-253-0000 OrgAbuseEmail: abuse at googlefiber.net OrgAbuseRef: https://whois.arin.net/rest/poc/GFA32-ARIN OrgTechHandle: ZG39-ARIN OrgTechName: Google Inc OrgTechPhone: +1-650-253-0000 OrgTechEmail: arin-contact at google.com OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # Found a referral to rwhois.googlefiber.net:8987. %rwhois V-1.5:000090:00 rwhois.googlefiber.net network:ID:NET-GF-V4-23-228-169-0 network:IP-Network:23.228.169.0/29 network:Org-Name:Wasatch Mental Health network:Street-Address:750 N 200 W network:Unit-Number: network:City:Provo network:State:UT network:Postal-Code:84601 network:Country-Code:US %ok > -As was noted in the most recent ARIN meeting, law enforcement agencies > use whois data as a source for their investigations and other work, and > having accurate records available on a timely basis is very important to > them. I don't believe that rwhois data is as accessible and available as > data in the ARIN database. > If this is a problem, then we should get support procedures for all who run an rwhois server, publish them publicly, and see if that doesn't solve the problem. If that doesn't solve it, maybe go as far as naming and shaming, or even considering if the organization is in compliance the ARIN policy if the rwhois data is not generally reachable, and the data in SWIP is not sufficient for ARIN policy compliance on its own. John Sweeting, can ARIN staff reach out to the 372 orgs with an unresponsive rwhois server and ask them to fix it and run another test? > -RDAP was designed with referral in mind from the ground up, so that you > get all the records no matter where they are located with a single query. > That seems to just work for my whois client. I don't see why it shouldn't work for all whois clients. > > -ARIN (in possible collaboration with other RIRS) should develop an RDAP > package for those who like to host their own, distributed database. The > new package should support bulk retrieval of records to assist in data > collection and analysis. (Also it was noted in the most recent ARIN > meeting that there are differences today in how the different RIRs are > reporting fields/data via RDAP. It would be good for the RIRs in > collaboration with each other and other organizations that want to run RDAP > servers for IP number resources to work to create a standard met of fields > which are required for IP number resource records, along with other > optional fields for additional data) > > It has been noted casually that there are many rwhois servers which are > down or aren't available. I believe this also contributes to this data set > being operationally unavailable. > I do not believe the problem space is any different with running a local RDAP server (at least at my organization). I suspect it is not good for the community if I update whois data with the frequency I update my rwhois data whether that be RESTful, template, RESTful bulk, or template bulk. > > I'd like to ask if ARIN staff can confirm some of these details with data > from the ARIN's database and operational practices. Specifically if ARIN > could provide the following details about how rwhois is being operated > today I believe it would inform the community in this consultation process. > > 1) Number of orgs which have IPv4 or IPv6 resources and a rwhois record on > their org-id. > > 2) Number of IPv4 and IPv6 blocks with a rwhois server under the org-id > records > > 3) Number of /24 IPv4 equivalents covered by the above records > > 4) Number of /32 IPv6 equivalents covered by the above records > > 5) Total number of unique rwhois servers > > 6) Percent of rwhois servers which are online (complete a tcp connection > accept a string and respond with some text) > > 7) Percent of rwhois server who appear to respond with a valid record > for an address within each allocated block > > > Thanks, > Andrew > > > > > On 10/2/2017 8:19 AM, ARIN wrote: > > ARIN was previously requested via the ARIN Consultation and Suggestion > Process (ACSP) to open a consultation to generate discussion about the > possibility of sun-setting RWhois support by the ARIN organization. ARIN's > initial response to the ACSP indicated we would open a consultation > following the completion of the Registration Data Access Protocol (RDAP) > specification inside the IETF processes. This work has been completed and > the RFC has been published. ARIN took the additional step of implementing > RDAP inside its own directory services offering with referral support to > the other Regional Internet Registries (RIRs). With this work complete, we > are following through with the formalized request to open a consultation on > this topic. > > https://www.arin.net/participate/acsp/suggestions/2013-22.html > > In accordance with ARIN's Number Resource Policy Manual (NRPM), > Organizations are required to report certain types of customer network > sub-delegation information (reassignments and reallocations) to ARIN. > Currently there are two reporting methods available. Both are delineated in > the NRPM and supported by ARIN's production services. There is also a third > possible method of reporting sub-delegation information that could be made > available, but is not yet offered. > > Method 1: > > SWIP (currently available): The reporting of sub-delegation information > using ARIN's database. This can be done either by submitting a SWIP > template, interfacing with ARIN's RESTful API, or by creating a > sub-delegation inside ARIN Online using ARIN's SWIP-EZ functionality. > > https://www.arin.net/resources/request/reassignments.html > > Method 2: > > RWhois (currently available): The reporting of sub-delegation information > on your own hosted and operated RWhois server with referral link > information provided in ARIN Whois as part of your own organization's Whois > records. In order for a user of ARIN's directory services to view > sub-delegation information hosted by an RWhois server, they would have to > submit a separate query to that RWhois server, and are not referred in an > automated fashion. > > https://www.arin.net/resources/request/reassignments_rwhois.html > > > Method 3: > > RDAP: The five RIRs currently use RDAP for referrals to each other's > Whois data. Although the specification language of the RDAP could allow it > to be used as a third method for the reporting of sub-delegation > information to ARIN, it is not currently offered as an option. In order to > make this option available, associated registry software would need to be > created. This possible method would allow users of ARIN's directory > services to view sub-delegation information available on customer hosted > RDAP servers in an automated fashion. This RDAP method may also be viewed > as redundant to RWhois. > > https://tools.ietf.org/html/rfc7482 > https://www.arin.net/resources/rdap.html > > Options Going Forward > > ARIN expects to continue offering Method 1 (SWIP) into the foreseeable > future. As previously described, we are acting on a formal suggestion to > consult with the community about the future of RWhois support, and also > have potential options with RDAP. > > - Question (general): > > > Of the three sub-delegation reporting methods listed (SWIP, > RWhois, RDAP), which should ARIN support in the future? > > - Question (SWIP/RESTful API specific): > > > The existing RESTful API allows users to report (SWIP) one > sub-delegation at a time to be added to ARIN Whois. Should ARIN add > bulk-upload features to the RESTful API? > > - Question (RWhois specific): > > > As noted, RWhois servers are not referred to in an automated > fashion when users query ARIN Whois. Should ARIN automate referrals to > RWhois servers from ARIN's Whois service? > > - Question (RDAP specific): > > > If ARIN was to allow the reporting of network sub-delegation > information using RDAP, associated enabling software would be required. > Should ARIN enable this method by creating an RDAP software suite that > would allow ARIN registrants to run RDAP service locally? > > The feedback you provide during this consultation will help inform > decisions about software tools and support for the reporting of network > sub-delegation information to ARIN in the future. Thank you for your > participation in the ARIN Consultation and Suggestion Process. > > Discussion on arin-consult at arin.net will close on 27 October 2017. If you > have any questions, please contact us at info at arin.net. > > > Regards, > > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > > > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Fri Oct 13 16:15:24 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 13 Oct 2017 13:15:24 -0700 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: On 10/13/2017 12:22 PM, Jason Schiller wrote: > > > On Thu, Oct 12, 2017 at 4:33 PM, Andrew Dul > wrote: > > I'm writing to support the sunsetting of the rwhois protocol as a > method for ARIN members to document reallocation and reassignment > records.? > > That doesn't mean this year or next year, but I believe we should > set a timeline for deprecating this protocol.? Perhaps a date of > 2022 would be reasonable.? (Yes, some organizations will not do > the work despite the 4 years of time to do it, but a shorter time > frame would also be unacceptable to some) > > I have seen those who have posted on this consultation noting that > "rwhois works and isn't broken so don't fix it."? While I will > agree that it is "technically" not broken, I believe that it is > operationally broken.? > > These are some of the reasons why I believe we should move on to > something better.? Any by better, I mean moving to records stored > in the ARIN database (SWIP) or RDAP. > > -Rwhois doesn't support encryption or data-integrity during transport > > > As Owen points out, neither does WHOIS for records stored in the ARIN > database (SWIP),? > so why should ISPs face an increased burden here if you are not also > planning to eliminate whois? > I'd be in support of sunsetting WHOIS support too at some point.?? But, I'm guessing that is an even less popular opinion.? > ? > > ? > > -As was noted in the most recent ARIN meeting, law enforcement > agencies use whois data as a source for their investigations and > other work, and having accurate records available on a timely > basis is very important to them.? I don't believe that rwhois data > is as accessible and available as data in the ARIN database. > > > If this is a problem, then we should get support procedures for all > who run an rwhois server,? > publish them publicly, and see if that doesn't solve the problem. > > If that doesn't solve it, maybe go as far as naming and shaming, or > even considering if the organization > is in compliance the ARIN policy if the rwhois data is not generally > reachable, and the data in SWIP is > not sufficient for ARIN policy compliance on its own.?? > While I'm certainly in support of improving the current situation, I believe that as long as there are incentives for organizations to ignore or deprioritize these requirements they will.? Perhaps naming & shaming will help at the largest organizations which aren't in compliance.?? I'm guessing many organizations don't even know their rwhois servers are broken.? Not all of the incentives change by moving to rdap, but with referral being built in, the lookup failures become far more visible. > John Sweeting, can ARIN staff reach out to the 372 orgs with an > unresponsive rwhois server and ask them to fix it and run another test?? > ? > > -RDAP was designed with referral in mind from the ground up, so > that you get all the records no matter where they are located with > a single query.? > > That seems to just work for my whois client.? I don't see why it > shouldn't work for all whois clients.? > > > -ARIN (in possible collaboration with other RIRS) should develop > an RDAP package for those who like to host their own,? distributed > database.? The new package should support bulk retrieval of > records to assist in data collection and analysis.? (Also it was > noted in the most recent ARIN meeting that there are differences > today in how the different RIRs are reporting fields/data via > RDAP.? It would be good for the RIRs in collaboration with each > other and other organizations that want to run RDAP servers for IP > number resources to work to create a standard met of fields which > are required for IP number resource records, along with other > optional fields for additional data) > > It has been noted casually that there are many rwhois servers > which are down or aren't available.? I believe this also > contributes to this data set being operationally unavailable.? > > > I do not believe the problem space is any different with running a > local RDAP server (at least at my organization). > I suspect it is not good for the community if I update whois data with > the frequency I update my rwhois data whether that be RESTful, > template, RESTful bulk, or template bulk. Because you suspect that ARIN can't handle the transaction count on a daily basis on their database?? Or because there are other features which aren't available? Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Oct 16 12:53:13 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Oct 2017 09:53:13 -0700 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: <79A64BEF-49B9-4FF2-A6E1-5B8D3AB1E6E7@delong.com> > On Oct 13, 2017, at 13:15 , Andrew Dul wrote: > > On 10/13/2017 12:22 PM, Jason Schiller wrote: > > >> >> >> On Thu, Oct 12, 2017 at 4:33 PM, Andrew Dul > wrote: >> I'm writing to support the sunsetting of the rwhois protocol as a method for ARIN members to document reallocation and reassignment records. >> >> That doesn't mean this year or next year, but I believe we should set a timeline for deprecating this protocol. Perhaps a date of 2022 would be reasonable. (Yes, some organizations will not do the work despite the 4 years of time to do it, but a shorter time frame would also be unacceptable to some) >> >> I have seen those who have posted on this consultation noting that "rwhois works and isn't broken so don't fix it." While I will agree that it is "technically" not broken, I believe that it is operationally broken. >> >> These are some of the reasons why I believe we should move on to something better. Any by better, I mean moving to records stored in the ARIN database (SWIP) or RDAP. >> >> -Rwhois doesn't support encryption or data-integrity during transport >> >> As Owen points out, neither does WHOIS for records stored in the ARIN database (SWIP), >> so why should ISPs face an increased burden here if you are not also planning to eliminate whois? >> > > I'd be in support of sunsetting WHOIS support too at some point. But, I'm guessing that is an even less popular opinion. > > >> >> >> >> -As was noted in the most recent ARIN meeting, law enforcement agencies use whois data as a source for their investigations and other work, and having accurate records available on a timely basis is very important to them. I don't believe that rwhois data is as accessible and available as data in the ARIN database. >> >> If this is a problem, then we should get support procedures for all who run an rwhois server, >> publish them publicly, and see if that doesn't solve the problem. >> >> If that doesn't solve it, maybe go as far as naming and shaming, or even considering if the organization >> is in compliance the ARIN policy if the rwhois data is not generally reachable, and the data in SWIP is >> not sufficient for ARIN policy compliance on its own. >> > > While I'm certainly in support of improving the current situation, I believe that as long as there are incentives for organizations to ignore or deprioritize these requirements they will. Perhaps naming & shaming will help at the largest organizations which aren't in compliance. I'm guessing many organizations don't even know their rwhois servers are broken. Not all of the incentives change by moving to rdap, but with referral being built in, the lookup failures become far more visible. You say this as if the referral lookup was built into RDAP more than in RWHOIS. As I pointed out previously, this is not actually true. If you use an RWHOIS client, referral is built in and automatic just as with an RDAP client. The difference is that RWHOIS servers maintain backwards compatibility with WHOIS clients (which don?t process referrals) while RDAP servers do not. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Oct 16 13:06:54 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Oct 2017 10:06:54 -0700 Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information In-Reply-To: References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: > On Oct 13, 2017, at 12:22 , Jason Schiller wrote: > > Comments in line. > > > Question (general): > > Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which > should ARIN support in the future? > > Answer: ARIN should support all three in the future. > > > Question (SWIP/RESTful API specific): > > The existing RESTful API allows users to report (SWIP) one sub-delegation at a time > to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API? > > Answer: 1. Bulk removal is more important that bulk additions. > e.g. can you remove all SWIPs for prefixes within 1.2.0.0/18 . The concern I have if we support this kind of bulk removal is that we must somehow validate that the removal comes from an entity allowed to remove all of 1.2.0.0/18 and its subordinates. We wouldn?t want, for example, the owner of 1.2.2.0/24 to be able to use their authority there to remove all of their fellow customers of the owner of 1.2.0.0/18. Obviously this is an implementation detail, but it?s an important one. > 2. If we offer bulk additions, it should be supported for all update types > (template, RESTful API) I disagree. As much as Mark likes to point out that I am the leading defender of templates, I don?t think adding bulk addition to templates really makes much sense. > 3. Sure, but I don't think the priority is very high. > > Question (RWhois specific): > > As noted, RWhois servers are not referred to in an automated fashion when users query > ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service? > > Answer: Yes. > This seems to work for my whois client (whois Version 5.1.1. Report bugs to > ). > (example below) > > When somoene does a "SEARCH WhoisRWS" on the ARIN website, it should likewise chase > the rwhois referral, and display it on the ARIN web site. > > Furthermore, ARIN should keep stats on when these referrals time out, and when they work. > > If there is not a requirement for all whois clients to follow the referral, and this can be addressed on > the server side, then lets address this on the server side. Double especially if this addresses an issue > where providers publish rwhois data, but make it only accessible to the RIRs. > > Question: How will this interact with a whois client that currently follows the referral? While I agree with the original design being cleaner (the server does not recurse and recursion is left to the client), the simple reality is that for whatever reason(s), most people are using whois clients that don?t support recursion and therefore don?t recurse. Since it is easy and within ARIN?s capability to mitigate the situation by modifying the server and outside of ARIN?s control and much more difficult to get everyone?s client software updated, I think that this is a case where pragmatism should rule over cleanliness and correctness and we should implement recursion in the server. The server should provide notices to the client that recursion is being attempted, the name of the server being recursed, etc. without any delay introduced by response time (or timeout) of the remote server. > > > Question (RDAP specific): > > If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated > enabling software would be required. Should ARIN enable this method by creating an RDAP > software suite that would allow ARIN registrants to run RDAP service locally? > > Answer: Yes. It should be fairly easy to just open (part of) the source of your RDAP service. > People can crib of that, and integrate with their IPAM / radius logs etc. > Surely someone will voluntarily provide a packed binary, and the source for it. > If not ARIN should fill this gap. If RDAP is to become an IETF standard, then IIRC, at least two implementations are required. I?m all for ARIN being the ones to develop one of these implementations for the community if that is necessary, but I?m not in favor of ARIN unnecessarily reinventing the wheel if someone else has already provided an open-source implementation of RDAP server and/or client, etc. > > > If ARIN supports RDAP referrals, should it sunset rwhois? No. > Is RDAP referrals better than rwhois referrals? I suspect mileage varies by organization. I also suspect that this depends on perspective (familiarity with RDAP, familiarity with whois/rwhois, existing installed base, publisher vs. consumer of data, etc.) Owen > > > Whois example > =============== > whois -h whois.arin.net 23.228.169.1 > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # https://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > # > # The following results may also be obtained via: > # https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 > # > > NetRange: 23.228.128.0 - 23.228.191.255 > CIDR: 23.228.128.0/18 > NetName: GOOGLE-FIBER > NetHandle: NET-23-228-128-0-1 > Parent: NET23 (NET-23-0-0-0-0) > NetType: Direct Allocation > OriginAS: AS16591 > Organization: Google Fiber Inc. (GF) > RegDate: 2013-09-13 > Updated: 2014-03-26 > Ref: https://whois.arin.net/rest/net/NET-23-228-128-0-1 > > > OrgName: Google Fiber Inc. > OrgId: GF > Address: 1600 Amphitheatre Parkway > City: Mountain ViewNeither does WHOIS for records stored in the ARIN database (SWIP), so why should ISPs face an increased burden here if you are not also planning to eliminate whois? > > StateProv: CA > PostalCode: 94043 > Country: US > RegDate: 2010-10-08 > Updated: 2017-01-28 > Ref: https://whois.arin.net/rest/org/GF > > ReferralServer: rwhois://rwhois.googlefiber.net:8987 > > OrgAbuseHandle: GFA32-ARIN > OrgAbuseName: Google Fiber Abuse > OrgAbusePhone: +1-650-253-0000 > OrgAbuseEmail: abuse at googlefiber.net > OrgAbuseRef: https://whois.arin.net/rest/poc/GFA32-ARIN > > OrgTechHandle: ZG39-ARIN > OrgTechName: Google Inc > OrgTechPhone: +1-650-253-0000 > OrgTechEmail: arin-contact at google.com > OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # https://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > > Found a referral to rwhois.googlefiber.net:8987 . > > %rwhois V-1.5:000090:00 rwhois.googlefiber.net > network:ID:NET-GF-V4-23-228-169-0 > network:IP-Network:23.228.169.0/29 > network:Org-Name:Wasatch Mental Health > network:Street-Address:750 N 200 W > network:Unit-Number: > network:City:Provo > network:State:UT > network:Postal-Code:84601 > network:Country-Code:US > > %ok > > =============== > end Whois example > > > > What problem are we trying to solve? > If it is having > > > > > > On Thu, Oct 12, 2017 at 4:33 PM, Andrew Dul > wrote: > I'm writing to support the sunsetting of the rwhois protocol as a method for ARIN members to document reallocation and reassignment records. > > That doesn't mean this year or next year, but I believe we should set a timeline for deprecating this protocol. Perhaps a date of 2022 would be reasonable. (Yes, some organizations will not do the work despite the 4 years of time to do it, but a shorter time frame would also be unacceptable to some) > > I have seen those who have posted on this consultation noting that "rwhois works and isn't broken so don't fix it." While I will agree that it is "technically" not broken, I believe that it is operationally broken. > > These are some of the reasons why I believe we should move on to something better. Any by better, I mean moving to records stored in the ARIN database (SWIP) or RDAP. > > -Rwhois doesn't support encryption or data-integrity during transport > > As Owen points out, neither does WHOIS for records stored in the ARIN database (SWIP), > so why should ISPs face an increased burden here if you are not also planning to eliminate whois? > > > -There is no automatic referral, so when most people query ARIN whois they don't know there is potentially another more specific record and even if they are aware, how to do rwhois is not "easy" for many users. Yes its easy for engineers and some operators, but there are many users of "whois" data for whom this is a barrier too high. Could we invest in lots of training for rwhois, yes, but we will always be behind on this as long as its not a click away for most users. > > as stated above whois to rwhois automatic referrals needs to work everywhere. > > whois -h whois.arin.net 23.228.169.1 > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # https://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > # > # The following results may also be obtained via: > # https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 > # > > NetRange: 23.228.128.0 - 23.228.191.255 > CIDR: 23.228.128.0/18 > NetName: GOOGLE-FIBER > NetHandle: NET-23-228-128-0-1 > Parent: NET23 (NET-23-0-0-0-0) > NetType: Direct Allocation > OriginAS: AS16591 > Organization: Google Fiber Inc. (GF) > RegDate: 2013-09-13 > Updated: 2014-03-26 > Ref: https://whois.arin.net/rest/net/NET-23-228-128-0-1 > > > OrgName: Google Fiber Inc. > OrgId: GF > Address: 1600 Amphitheatre Parkway > City: Mountain View > StateProv: CA > PostalCode: 94043 > Country: US > RegDate: 2010-10-08 > Updated: 2017-01-28 > Ref: https://whois.arin.net/rest/org/GF > > ReferralServer: rwhois://rwhois.googlefiber.net:8987 > > OrgAbuseHandle: GFA32-ARIN > OrgAbuseName: Google Fiber Abuse > OrgAbusePhone: +1-650-253-0000 > OrgAbuseEmail: abuse at googlefiber.net > OrgAbuseRef: https://whois.arin.net/rest/poc/GFA32-ARIN > > OrgTechHandle: ZG39-ARIN > OrgTechName: Google Inc > OrgTechPhone: +1-650-253-0000 > OrgTechEmail: arin-contact at google.com > OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # https://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > > Found a referral to rwhois.googlefiber.net:8987 . > > %rwhois V-1.5:000090:00 rwhois.googlefiber.net > network:ID:NET-GF-V4-23-228-169-0 > network:IP-Network:23.228.169.0/29 > network:Org-Name:Wasatch Mental Health > network:Street-Address:750 N 200 W > network:Unit-Number: > network:City:Provo > network:State:UT > network:Postal-Code:84601 > network:Country-Code:US > > %ok > > > -As was noted in the most recent ARIN meeting, law enforcement agencies use whois data as a source for their investigations and other work, and having accurate records available on a timely basis is very important to them. I don't believe that rwhois data is as accessible and available as data in the ARIN database. > > If this is a problem, then we should get support procedures for all who run an rwhois server, > publish them publicly, and see if that doesn't solve the problem. > > If that doesn't solve it, maybe go as far as naming and shaming, or even considering if the organization > is in compliance the ARIN policy if the rwhois data is not generally reachable, and the data in SWIP is > not sufficient for ARIN policy compliance on its own. > > John Sweeting, can ARIN staff reach out to the 372 orgs with an unresponsive rwhois server and ask them to fix it and run another test? > > -RDAP was designed with referral in mind from the ground up, so that you get all the records no matter where they are located with a single query. > That seems to just work for my whois client. I don't see why it shouldn't work for all whois clients. > > -ARIN (in possible collaboration with other RIRS) should develop an RDAP package for those who like to host their own, distributed database. The new package should support bulk retrieval of records to assist in data collection and analysis. (Also it was noted in the most recent ARIN meeting that there are differences today in how the different RIRs are reporting fields/data via RDAP. It would be good for the RIRs in collaboration with each other and other organizations that want to run RDAP servers for IP number resources to work to create a standard met of fields which are required for IP number resource records, along with other optional fields for additional data) > > It has been noted casually that there are many rwhois servers which are down or aren't available. I believe this also contributes to this data set being operationally unavailable. > > I do not believe the problem space is any different with running a local RDAP server (at least at my organization). > I suspect it is not good for the community if I update whois data with the frequency I update my rwhois data whether that be RESTful, template, RESTful bulk, or template bulk. > > > I'd like to ask if ARIN staff can confirm some of these details with data from the ARIN's database and operational practices. Specifically if ARIN could provide the following details about how rwhois is being operated today I believe it would inform the community in this consultation process. > > 1) Number of orgs which have IPv4 or IPv6 resources and a rwhois record on their org-id. > > 2) Number of IPv4 and IPv6 blocks with a rwhois server under the org-id records > > 3) Number of /24 IPv4 equivalents covered by the above records > > 4) Number of /32 IPv6 equivalents covered by the above records > > 5) Total number of unique rwhois servers > > 6) Percent of rwhois servers which are online (complete a tcp connection > accept a string and respond with some text) > > 7) Percent of rwhois server who appear to respond with a valid record > for an address within each allocated block > > > Thanks, > Andrew > > > > > On 10/2/2017 8:19 AM, ARIN wrote: >> ARIN was previously requested via the ARIN Consultation and Suggestion Process (ACSP) to open a consultation to generate discussion about the possibility of sun-setting RWhois support by the ARIN organization. ARIN's initial response to the ACSP indicated we would open a consultation following the completion of the Registration Data Access Protocol (RDAP) specification inside the IETF processes. This work has been completed and the RFC has been published. ARIN took the additional step of implementing RDAP inside its own directory services offering with referral support to the other Regional Internet Registries (RIRs). With this work complete, we are following through with the formalized request to open a consultation on this topic. >> >> https://www.arin.net/participate/acsp/suggestions/2013-22.html >> >> In accordance with ARIN's Number Resource Policy Manual (NRPM), Organizations are required to report certain types of customer network sub-delegation information (reassignments and reallocations) to ARIN. Currently there are two reporting methods available. Both are delineated in the NRPM and supported by ARIN's production services. There is also a third possible method of reporting sub-delegation information that could be made available, but is not yet offered. >> Method 1: >> >> SWIP (currently available): The reporting of sub-delegation information using ARIN's database. This can be done either by submitting a SWIP template, interfacing with ARIN's RESTful API, or by creating a sub-delegation inside ARIN Online using ARIN's SWIP-EZ functionality. >> >> https://www.arin.net/resources/request/reassignments.html >> Method 2: >> >> RWhois (currently available): The reporting of sub-delegation information on your own hosted and operated RWhois server with referral link information provided in ARIN Whois as part of your own organization's Whois records. In order for a user of ARIN's directory services to view sub-delegation information hosted by an RWhois server, they would have to submit a separate query to that RWhois server, and are not referred in an automated fashion. >> >> https://www.arin.net/resources/request/reassignments_rwhois.html >> Method 3: >> >> RDAP: The five RIRs currently use RDAP for referrals to each other's Whois data. Although the specification language of the RDAP could allow it to be used as a third method for the reporting of sub-delegation information to ARIN, it is not currently offered as an option. In order to make this option available, associated registry software would need to be created. This possible method would allow users of ARIN's directory services to view sub-delegation information available on customer hosted RDAP servers in an automated fashion. This RDAP method may also be viewed as redundant to RWhois. >> >> https://tools.ietf.org/html/rfc7482 >> https://www.arin.net/resources/rdap.html >> Options Going Forward >> >> ARIN expects to continue offering Method 1 (SWIP) into the foreseeable future. As previously described, we are acting on a formal suggestion to consult with the community about the future of RWhois support, and also have potential options with RDAP. >> Question (general): >> >> Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which should ARIN support in the future? >> Question (SWIP/RESTful API specific): >> >> The existing RESTful API allows users to report (SWIP) one sub-delegation at a time to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API? >> Question (RWhois specific): >> >> As noted, RWhois servers are not referred to in an automated fashion when users query ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service? >> Question (RDAP specific): >> >> If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated enabling software would be required. Should ARIN enable this method by creating an RDAP software suite that would allow ARIN registrants to run RDAP service locally? >> >> The feedback you provide during this consultation will help inform decisions about software tools and support for the reporting of network sub-delegation information to ARIN in the future. Thank you for your participation in the ARIN Consultation and Suggestion Process. >> >> Discussion on arin-consult at arin.net will close on 27 October 2017. If you have any questions, please contact us at info at arin.net . >> >> Regards, >> >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> >> _______________________________________________ >> ARIN-Consult >> You are receiving this message because you are subscribed to the ARIN Consult Mailing >> List (ARIN-consult at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services >> Help Desk at info at arin.net if you experience any issues. > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com |571-266-0006 > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: