<div dir="ltr"><div>The road map for the ARIN IRR re-spin states:</div><div><br></div><div>>>   * Provide an Easy IRR integration tool within ARIN Online:  ARIN will provide an simple tool within ARIN online for </div><div>>>     those users who wish to explore the routing of their existing number resources and after successful review, </div><div>>>     automatically update their corresponding IRR records to match existing routing.</div><div><br></div><div>I have concerns that the text above suggests a less close coupling between WHOIS data and IRR data that I had hoped</div><div>for.  I think without a close coupling the work to reform the IRR becomes a lot less meaningful.</div><div><br></div><div>Either my memory is faulty as to the extent the community wanted tight coupling with the WHOIS data, or the message</div><div>was not clear enough.  Either way I think it is worth while to get a clearer picture of what the community desires WRT</div><div>close coupling of WHOIS and IRR data.</div><div><br></div><div>This is not a simple question.  There are a lot of different relationships, and there is a spectrum of the strength of the </div><div>relationship between ARIN and the resource holder.  For clarity I think it is best to initially scope our discussion to </div><div>only the strongest ARIN - resource holder relationships, and decide about the level of coupling that makes sense,</div><div>and then open the discussion up to some of the weaker relationships, and if we draw the line differently in those </div><div>cases.</div><div><br></div><div>For ARIN direct allocations, ARIN direct assignments,and ARIN assigned ASes, the relationship is strongest.  </div><div>ARIN knows the OrgID, ARIN has contact info, and ARIN interacts with the Organization at least once a year </div><div>for payment.  These resources can be managed by any ARIN Online account linked to the Org.  Lets only </div><div>consider these resources initially.</div><div> </div><div><br></div><div>1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR.  It should be impossible for these to be</div><div>out of sync.  </div><div><br></div><div>- If a resource's ARIN WHOIS information is updated, if there is IRR data it must also be updated.</div><div>  (see examples below ====)</div><div><br></div><div>- If a resource is revoked / marked stale in WHOIS , the IRR (if it exists) must also be revoked / marked.</div><div><br></div><div><br></div><div>2. ARIN knows who can manage the resources of a given OrgID based on linked ARIN Online accounts</div><div> and API keys those accounts have created.</div><div>These same accounts / API Keys should be the ones that can manage IRR data either through </div><div>ARIN online or a more traditional way that is tied back to the ARIN online account.</div><div><br></div><div>(perhaps ARIN online accounts can be linked to maintainers managed in ARIN online)</div><div><br></div><div>(might be useful for an ARIN online account to generate different API Keys, label them, </div><div>and restrict access.  e.g. the GFiber-SWIP key can SWIP /deSWIP anything in these </div><div>ranges, and the bulk-whois key can download bulk whois, but nothing else.)</div><div><br></div><div>- If a resource is transfered and that is reflected in the WHOIS, ownership of the IRR data</div><div>  must like wise be transfered.  </div><div><br></div><div><br></div><div>3. When an IRR contains a relationship between two or more resources that have different</div><div>owners is authorization from both required?  </div><div>(i think we have to sort this out a bit.  Please Help)</div><div><br></div><div>3.a. Should a route holder be able to to designate an origin AS that they do not hold</div><div>       without the AS holder's acknowledgment?   (maybe)</div><div><br></div><div>3.b. Should an AS holder be able to designate their AS as an origin for a route they </div><div>       do not hold with out the route holder's acknowledgement? </div><div>       (no.  they can do all the work and just get the route holder to ack it though)</div><div><br></div><div>3.c. Should a route holder be able to remove an origin AS from their route without</div><div>      the AS holder's acknowledgment? (yes)</div><div><br></div><div>3.d. Should a route holder be able to adjust the routing policy associated with </div><div>        someone else's AS, but only with respect to their route without AS holders </div><div>        acknowledgment ?  (no)</div><div><br></div><div>3.e. Should an AS holder be able to document a Peering relationship, transit</div><div>       customer relationship, or transit provider relationship with another AS without</div><div>       that AS holder's approval? (maybe yes)</div><div><br></div><div>4. If we include routes where the strength of the relationship between ARIN and</div><div>the resource holder is weaker, then I suggest we clearly mark them.</div><div>- Think there is a big spectrum here and we should table this discussion until</div><div>   we sort out the clear case first.    </div><div>  </div><div><br></div><div>In short to what extent do we think ARIN's IRR data should leverage </div><div>(where it exists) the unique relationship ARIN has between it and </div><div>the resource holders?</div><div><br></div><div>___Jason</div><div> </div><div><br></div><div>=============</div><div>this should not be possible:</div><div><br></div><div><br></div><div>whois -h <a href="http://rr.arin.net">rr.arin.net</a> as19527</div><div><br></div><div>% Information related to 'AS19527'</div><div><br></div><div>aut-num:        AS19527</div><div>as-name:        MEEBO</div><div>descr:          Meebo, Inc.</div><div>admin-c:        CKO60-ARIN</div><div>tech-c:         CKO60-ARIN</div><div>mnt-by:         MNT-MEEBO</div><div>source:         ARIN # Filtered</div><div><br></div><div>whois -h <a href="http://whois.arin.net">whois.arin.net</a> 19527</div><div><br></div><div>#</div><div># The following results may also be obtained via:</div><div># <a href="https://whois.arin.net/rest/asns;q=19527?showDetails=true&ext=netref2">https://whois.arin.net/rest/asns;q=19527?showDetails=true&ext=netref2</a></div><div>#</div><div><br></div><div>ASNumber:       19527</div><div>ASName:         GOOGLE-2</div><div>ASHandle:       AS19527</div><div>RegDate:        2007-08-17</div><div>Updated:        2018-01-10</div><div>Ref:            <a href="https://whois.arin.net/rest/asn/AS19527">https://whois.arin.net/rest/asn/AS19527</a></div><div><br></div><div>OrgName:        Google LLC</div><div>OrgId:          GOOGL-2</div><div>Address:        1600 Amphitheatre Parkway</div><div>City:           Mountain View</div><div>StateProv:      CA</div><div>PostalCode:     94043</div><div>Country:        US</div><div>RegDate:        2006-09-29</div><div>Updated:        2017-12-21</div><div>Ref:            <a href="https://whois.arin.net/rest/org/GOOGL-2">https://whois.arin.net/rest/org/GOOGL-2</a></div><div><br></div><div>OrgNOCHandle: GCABU-ARIN</div><div>OrgNOCName:   GC Abuse</div><div>OrgNOCPhone:  +1-650-253-0000 </div><div>OrgNOCEmail:  <a href="mailto:google-cloud-compliance@google.com">google-cloud-compliance@google.com</a></div><div>OrgNOCRef:    <a href="https://whois.arin.net/rest/poc/GCABU-ARIN">https://whois.arin.net/rest/poc/GCABU-ARIN</a></div><div><br></div><div>OrgAbuseHandle: GCABU-ARIN</div><div>OrgAbuseName:   GC Abuse</div><div>OrgAbusePhone:  +1-650-253-0000 </div><div>OrgAbuseEmail:  <a href="mailto:google-cloud-compliance@google.com">google-cloud-compliance@google.com</a></div><div>OrgAbuseRef:    <a href="https://whois.arin.net/rest/poc/GCABU-ARIN">https://whois.arin.net/rest/poc/GCABU-ARIN</a></div><div><br></div><div>OrgTechHandle: ZG39-ARIN</div><div>OrgTechName:   Google LLC</div><div>OrgTechPhone:  +1-650-253-0000 </div><div>OrgTechEmail:  <a href="mailto:arin-contact@google.com">arin-contact@google.com</a></div><div>OrgTechRef:    <a href="https://whois.arin.net/rest/poc/ZG39-ARIN">https://whois.arin.net/rest/poc/ZG39-ARIN</a></div><div><br></div><div><br></div><div><br></div><div>whois -h <a href="http://rr.arin.net">rr.arin.net</a> "<a href="http://74.114.24.0/21">74.114.24.0/21</a>"</div><div><br></div><div>% Information related to '<a href="http://74.114.24.0/21AS19527">74.114.24.0/21AS19527</a>'</div><div><br></div><div>route:          <a href="http://74.114.24.0/21">74.114.24.0/21</a></div><div>descr:          meebo-east</div><div>origin:         AS19527</div><div>mnt-by:         MNT-MEEBO</div><div>source:         ARIN # Filtered</div><div><br></div><div><br></div><div><br></div><div>whois -h <a href="http://whois.arin.net">whois.arin.net</a> 74.114.24.0</div><div><br></div><div>#</div><div># The following results may also be obtained via:</div><div># <a href="https://whois.arin.net/rest/nets;q=74.114.24.0?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2">https://whois.arin.net/rest/nets;q=74.114.24.0?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2</a></div><div>#</div><div><br></div><div>NetRange:       74.114.24.0 - 74.114.31.255</div><div>CIDR:           <a href="http://74.114.24.0/21">74.114.24.0/21</a></div><div>NetName:        GOOGLE</div><div>NetHandle:      NET-74-114-24-0-1</div><div>Parent:         NET74 (NET-74-0-0-0-0)</div><div>NetType:        Direct Allocation</div><div>OriginAS:       AS15169</div><div>Organization:   Google LLC (GOGL)</div><div>RegDate:        2009-05-21</div><div>Updated:        2018-01-12</div><div>Ref:            <a href="https://whois.arin.net/rest/net/NET-74-114-24-0-1">https://whois.arin.net/rest/net/NET-74-114-24-0-1</a></div><div><br></div><div><br></div><div><br></div><div>OrgName:        Google LLC</div><div>OrgId:          GOGL</div><div>Address:        1600 Amphitheatre Parkway</div><div>City:           Mountain View</div><div>StateProv:      CA</div><div>PostalCode:     94043</div><div>Country:        US</div><div>RegDate:        2000-03-30</div><div>Updated:        2017-12-21</div><div>Ref:            <a href="https://whois.arin.net/rest/org/GOGL">https://whois.arin.net/rest/org/GOGL</a></div><div><br></div><div><br></div><div>OrgAbuseHandle: ABUSE5250-ARIN</div><div>OrgAbuseName:   Abuse</div><div>OrgAbusePhone:  +1-650-253-0000 </div><div>OrgAbuseEmail:  <a href="mailto:network-abuse@google.com">network-abuse@google.com</a></div><div>OrgAbuseRef:    <a href="https://whois.arin.net/rest/poc/ABUSE5250-ARIN">https://whois.arin.net/rest/poc/ABUSE5250-ARIN</a></div><div><br></div><div>OrgTechHandle: ZG39-ARIN</div><div>OrgTechName:   Google LLC</div><div>OrgTechPhone:  +1-650-253-0000 </div><div>OrgTechEmail:  <a href="mailto:arin-contact@google.com">arin-contact@google.com</a></div><div>OrgTechRef:    <a href="https://whois.arin.net/rest/poc/ZG39-ARIN">https://whois.arin.net/rest/poc/ZG39-ARIN</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 9, 2018 at 4:27 PM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p><span class="">Over the last several years, ARIN has received multiple ARIN
      Consultation and Suggestion Process (ACSP) requests and fielded
      many customer suggestions about our existing Internet Routing
      Registry (IRR), and as a result, a community consultation was
      issued to gauge community interest for ARIN to take on the project
      of improving this service. The consensus response was that the
      community would like ARIN to:<br>
      <br>
        *  Improve the validity of the IRR data<br>
        *  Work with the other RIR's on authorization schemes<br>
        *  Provide appropriate proxy registration services<br>
        *  Integrate/validate with the registration database<br>
      <br>
      To accomplish these goals, we anticipate that this work effort
      will involve a fair bit of community involvement (RIR communities,
      IETF, and operational forums such as NANOG and CaribNOG) in order
      to create the appropriate incremental upgrades to the IRR.<br>
      <br>
      We are opening a new Community Consultation to solicit feedback on
      the ARIN IRR Roadmap, detailed below.<br>
      <br>
      Please provide comments to <a class="m_5262826877337724770moz-txt-link-abbreviated" href="mailto:arin-consult@arin.net" target="_blank">arin-consult@arin.net</a>. <br>
      <br></span></p><div><div class="h5">
      This consultation will remain open through 5:00 PM EST on Friday,
      9 February 2018.<br>
      <br>
      Regards,<br>
      <br>
      John Curran<br>
      President and CEO<br>
      American Registry for Internet Numbers (ARIN)<br>
      <br>
      <b>ARIN IRR Roadmap</b><b><br>
      </b><b><br>
      </b><b>Background</b><br>
      <br>
      In response to multiple ACSPs regarding IRR route validation (i.e.
      the function whereby route objects are validated via the
      authorization of the appropriate number resource holder), ARIN
      conducted an IRR community consultation in April 2015. This
      consultation was opened because the issues around IRR route
      validation are complex, and implementation was anticipated to
      exceed the cost of most ACSP implementations.<br>
      Within the consultation, the ARIN community was asked three
      questions:<br>
      <br>
          * Should ARIN begin a new project to enable IRR route object
      validation to the ARIN registry database?<br>
          * If yes, should this effort be coordinated with other RIRs to
      help facilitate cross-registry authentication?<br>
          * If yes, should this effort also support third party IRR
      route object authentication?<br>
      <br>
      There were eighteen individual participants in the consultation. 
      Thirteen were in favor of ARIN creating a more robust IRR, two
      were publicly against, and three were unclear in their support or
      opposition.<br>
      <br>
      Nine participants expressed support for efforts to facilitate
      inter-RIR authentication, and eight participants expressed support
      for 3rd party or proxy registrations for authentication of route
      objects.<br>
      <br>
      Two participants suggested ARIN provide facilities for
      authentication/authorization or delegation to IRRs not operated by
      an RIR.<br>
      Several participants had concerns regarding the implementation of
      an ARIN-validated IRR. Three noted ARIN's past experience with the
      implementation and cost of RPKI with respect to both community
      adoption and opportunity-cost, and one participant expressed
      concerns for contractual obligations that ARIN may place on
      resource holders provisioning information in a validated IRR.<br>
      <br>
      <b>Implementation Experience Regarding ARIN's Current IRR</b><br>
      <br>
      ARIN initially setup a RIPE-based IRR years ago.  Over the years,
      we upgraded it based on ACSP suggestions: IPv6 support was
      implemented in December 2009, and PGP support with additional
      notifications was released in September 2011. In both of these
      releases, we replicated the original approach of using the RIPE
      database software system with loose coupling to our mainline ARIN
      Online registry system.  These upgrades did allow for additional
      functionality, but it came at a very substantial cost of time and
      unanticipated functionality issues related to the upgrades.<br>
      <br>
      When we undertook these upgrades, we chose to continue the
      separation in the hopes of doing minimal environmental changes to
      ARIN's infrastructure to add the suggested improvements. However,
      the RIPE codebase was not modularized, with significant
      dependencies on RIPE environment, and consequently was not ideal
      for use in ARIN's environment. One consequence was the repeated
      need to pull down the latest release from RIPE, adjust the
      environment for their software to work, make changes to it to
      allow functionality that we support, remove out dependencies to
      resource checks that would not exist in our system, and add
      dependency links to our system. This has been a very
      labor-intensive process and it took a lot of engineering time to
      make the system work.<br>
      <br>
      Adjusting to each upgrade from RIPE has also been challenging
      because of innate differences our database structures. RIPE had
      two systems – one being a front-end database and the other being a
      back-end database with manual synchronization between these two
      systems. At ARIN, we have just one system that is placed behind
      the firewall and replicated out to the publically available ARIN
      slaves as changes are made. The RIPE IRR codebase provided for
      limited information to be shared to slaves via its replication
      schemes.   Given that ARIN's publically available interface is a
      slave, the output available to our community was not the same as
      our internal master, and has resulted in some confusion for ARIN
      IRR users.<br>
      <br>
      ARIN Registration Services Department also has challenges
      providing customer support to IRR users. Common problems include:<br>
      <br>
          * Maintainers not being notified upon changes<br>
          * Cryptic responses to pgp-validation errors<br>
          * General lack of customer support features<br>
      <br>
      It was our hope that code re-use would save time and money.
      Unfortunately, this was not the case, and the result was an
      awkward, difficult-to-operate, and user-unfriendly system that
      requires considerable engineering time to maintain.<br>
      It should also be noted that the IRR codebase in use by ARIN is no
      longer supported or maintained by the RIPE NCC, as they have since
      completely rewritten their IRR software.<br>
      <br>
      <b>Proposed Roadmap</b><br>
      <br>
      Given the community feedback received in the consultation, and
      with due regard to the past experience with reusing code for IRR
      software, ARIN staff proposes a "ground-up" implementation of a
      validated IRR that will better integrate with ARIN's current web
      portal, provisioning system, and other registry functions. This
      path forward will be a multi-phased approach and will rely on
      community–defined specifications and global RIR community
      consensus.<br>
      <br>
      This approach will allow ARIN to field a routing registry
      incrementally, providing utility to the community much sooner than
      a monolithic "big-bang" release, and it will provide the community
      an opportunity to provide feedback with respect to features and
      cost as the project progresses.<br>
      <br>
          * Produce a Simplified Profile of RPSL: Most of the complexity
      of RPSL comes from routing registry features rarely used by the
      community. To reduce the implementation costs around data modeling
      and parsing of complex RPSL structures, ARIN will work with the
      operational community to identify the most commonly used features
      of the language, and this subset will be documented as an
      simplified RPSL profile to be used to guide development efforts.  
      <br>
          * Schedule Frequent Deployments: ARIN will adopt "continuous
      deployment" strategies to allow for more frequent deployments,
      similar to the strategy used today in development of the ARIN
      Online registry system. This will allow the community to use new
      features of the IRR as they are developed.<br>
      <br>
          * Collaborate on Cross-RIR Authentication: ARIN will work with
      the other RIRs engineering coordination activities to create an
      appropriate mechanism for authentication and authorization of
      routing registry objects for which the resources cross regional
      boundaries.<br>
      <br>
          * Provide an Easy IRR integration tool within ARIN Online: 
      ARIN will provide an simple tool within ARIN online for those
      users who wish to explore the routing of their existing number
      resources and after successful review, automatically update their
      corresponding IRR records to match existing routing.<br>
      <br>
          * Migrate Data to the New IRR: Where possible, ARIN will
      create tools and practices to help migrate data from the existing
      IRR to the new IRR under the authority of resource holders in the
      ARIN registry.<br>
      <br>
          * Cooperate on Standards and Best Practices: Where applicable
      and appropriate, ARIN will work with the IETF and the other RIRs
      on documenting any resulting operational standards, profiles, and
      best practices.<br>
      <br>
      We do feel that this effort, once deployed, will help improve
      routing coordination that exists on the Internet today. The
      proposed new ARIN IRR will provide a clear and consistent path to
      allow ISPs to share their routing policies.<br>
    </div></div><p></p>
  </div>

<br>______________________________<wbr>_________________<br>
ARIN-Consult<br>
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br>
List (<a href="mailto:ARIN-consult@arin.net">ARIN-consult@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-consult" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-consult</a> Please contact the ARIN Member Services<br>
Help Desk at <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>