<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">SWG Team.</div><div class=""><br class=""></div><div class="">First a bit of history:</div><div class=""><br class=""></div><div class="">This topic has been brought up many times in several forums. Roughly: Why is the ARIN region different than other regions and why are there so many 3rd party IRR services. How do we get better, more accurate, consistent, data from IRR service(s)?</div><div class=""><br class=""></div><div class="">There are a few different approaches to solving the underlying IRR issue, but none of them result in a single solution incorporating authentication, attestation, best current operational practices, cleanup, and a common way forward for all participating registry services. </div><div class=""><br class=""></div><div class="">This topic was also discussed at a few ARIN board meetings, one snipped from minutes:</div><div class=""><br class=""></div><div class="">Snippet from board minutes:<br class=""><br class="">[snip]<br class=""><br class="">6. Internet Routing Registry (IRR) Route Validation Consultation. The President noted that there had been an IRR for some time in the ARIN region, but it was one of many, and not as popular as other IRR services for the other RIRs. The President stated ARIN’s routing registry was based on an older version of RIPE’s IRR code base, but that differing architectures made difficult the use of external code and of interfacing it to existing systems. A consultation had been submitted for ARIN membership’s feedback on whether a new IRR was needed, including questions about the functionality of any new IRR development. The President reviewed the positive response of the ARIN community to the project and the potential level of effort needed to undertake it. The President asked the Board for their sense of whether or not to move forward with this project.<br class="">Aaron Hughes suggested it would be useful to have a global IRR software toolkit that would allow people to more easily interface to the IRRs. He strongly believed this could be accomplished by gathering a select few individuals who were very knowledgeable in developing this type of software, many of whom he personally knew.<br class="">The President stated that ARIN intended to perform cross-RIR validation. Bill Woodcock suggested identifying the individuals to do this, funding their travel and accommodation to Washington DC in the next 8-12 weeks, and holding such a meeting per Mr. Hughes’ suggestion. The President requested that Mr. Hughes provide him a draft of the invitation for distribution.<br class="">Bill Woodcock stated that one of the deliverables would be a draft Request For Comment (RFC). For clarity, the President asked what the RFC would be for, specifically. Bill replied that it would be for a modernized RPSL Interchange Format. Aaron Hughes added it would also be for ease of filtering, based on IRR validation. Bill Woodcock further suggested an API, or protocol, that data will move back and forth.<br class="">It was the sense of the Board to proceed in this direction.<br class=""><br class="">[end]<br class=""></div><div class=""><br class=""></div><div class="">At that time, I started discussing this with a few key people in community. Job Snijders, Jared Mauch, Andrew de la Haye, Mark Kosters and the like.. There was positive feedback that it would make sense to write some new RFCs to build standards for all RIRs and all IRR services to follow. This approach would require a great deal of thought on how to solve the authentication, attestation requirements, and less but some thought around RPSL and other IRR standards. The discussions, however, became far more challenging when talking about the feasibility of RKPI ever being implemented and weather or not we should take Secure Routing on as part of the Score of Work. The conversations broke down in great part due to the project not being managed well. (I was light on available time).</div><div class=""><br class=""></div><div class="">At the same time, (due to lack of progress from outside parties), ARIN staff worked on a proposal to address the IRR issue from an ARIN perspective.</div><div class=""><br class=""></div><div class="">The following was sent out then: (around the formation of the SWG)</div><div class=""><br class=""></div><div class="">[snip]</div><div class=""><br class=""></div><div class="">Here’s the staff report on our IRR consultation, including recommended<br class=""> next steps. This has been somewhat overtaken by your initiative with<br class=""> respect to ARIN IRR Strategy, but may be useful input (i.e. the default<br class=""> direction we’d head absent any other guidance.) <br class=""><br class=""> While I’ve asked Mark to put this work on hold pending Services WG<br class=""> guidance (and he is quite receptive to same), one of action items is<br class=""> already underway with other participants from the RIRs and the IETF<br class=""> (specifically, the "Produce a Simplified Profile of RPSL” item) - I believe<br class=""> it would be best to have Mark continue his participation in this effort,<br class=""> (unless the Services WG feel otherwise.)</div><div class=""><br class=""></div><div class=""></div></body></html>