<div dir="ltr">Sounds to me like David and I are in agreement, WRT a close <div>coupling between ARIN WHOIS and ARIN IRR, and the autnum <div>and related objects need some real discussion here. </div><div><br></div><div>Before plunging into that I think it is worth while and solicit what other's opinions </div><div>are WRT a tight coupling between  the ARIN IRR and ARIN WHOIS at least for</div><div>ARIN direct allocations, ARIN direct assignments, ARIN issued ASNs.</div><div><br></div><div>Looks like Tony is supportive of this approach. </div><div><br></div><div>Can others take a moment to comment on this particular question?</div><div><br></div><div>__Jason</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 12, 2018 at 11:52 AM, David R Huberman <span dir="ltr"><<a href="mailto:daveid@panix.com" target="_blank">daveid@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have concerns that the text above suggests a less close coupling between WHOIS data and IRR data that I had hoped for.  I think without a close coupling the work to reform the IRR becomes a lot less meaningful.<br>
</blockquote>
<br></span>
I strongly agree.<br>
<br>
The first level of abstraction is the start_ip and end_ip of inetnum objects. Rules I think must exist:<br>
<br>
- inetnum objects must exactly match a NET object in ARIN Whois<br>
- inet6num objects must exactly match a NET object in ARIN Whois<br>
<br>
No inetnum or inet6num object may be asserted in ARIN IRR if it does not already exist in ARIN Whois. Why? Because this is how "bad actors" have abused RIPEdb and other wide open IRRs to perform one critical function of setting up a malevolent operation.<br>
<br>
RIPE's db-wg has been having this discussion, and there is very clear consensus on the rules I propose above<span class=""><br>
<br>
The second level of abstraction is authorization. As Jason writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For ARIN direct allocations, ARIN direct assignments,and ARIN assigned ASes, the relationship is strongest. ARIN knows the OrgID, ARIN has contact info, and ARIN interacts with the Organization at least once a year for payment.  These resources can be managed by any ARIN Online account linked to the Org.<br>
</blockquote>
<br></span>
A rule that I think would make sense:<br>
<br>
- maintainer objects are always authorized by the ORG objects in Whois.<br>
<br>
This is obvious.  What is less obvious is that you want to authorize scripting to ADD/UPDATE/DELETE objects under your maintainer. So something like:<br>
<br>
- While authorized contacts can add NIC handles to maintainers, notifications (notify:) for the maintainer object must always be sent to the current ORG pocs to ensure they are aware of changes.<br>
<br>
Now Jason brings up data integrity<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR. It should be impossible for these to be out of sync.<br>
</blockquote>
<br></span>
Agreed.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- If a resource's ARIN WHOIS information is updated, if there is IRR data<br>
it must also be updated.<br>
</blockquote>
<br></span>
Agreed. But with forewarning.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- If a resource is revoked / marked stale in WHOIS , the IRR (if it exists) must also be revoked / marked.<br>
</blockquote>
<br></span>
Absolutely, and obvious to everyone I hope.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. ARIN knows who can manage the resources of a given OrgID based on linked ARIN Online accounts and API keys those accounts have created. These same accounts / API Keys should be the ones that can manage IRR data either through ARIN online or a more traditional way that is tied back to the ARIN online account.<br>
</blockquote>
<br></span>
Gotta speak up here for "more traditional".  Every operator I've ever been at still does this the old and reliable way: email, with cryto<br>
signatures.  Â At scale, it makes sense to have an API for all this, and leverage the API KEY infrastructure already in ARIN Whois.  But for discrete changes (which affect the majority of IRR users), email needs to remain an option, in my opinion.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- If a resource is transfered and that is reflected in the WHOIS, ownership of the IRR data must like wise be transfered.<br>
</blockquote>
<br></span>
Ding ding ding!  Nice thinking, Jason.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. When an IRR contains a relationship between two or more resources that have different owners is authorization from both required? (i think we have to sort this out a bit.  Please Help)<br>
</blockquote>
<br></span>
No.  There is no need for IRR to worry about multiple parties.  Just like SWIP, if authorization exists, authorization exists.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.a. Should a route holder be able to to designate an origin AS that they do not hold without the AS holder's acknowledgment?  Â (maybe)<br>
</blockquote>
<br></span>
The autnum and related objects need some real discussion here. Like Jason, I suspect the answer is maybe, but I don't know enough to know.  I can rope in experts into this thread if you need us to.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.b. Should an AS holder be able to designate their AS as an origin for a route they<br>
  Â  Â  do not hold with out the route holder's acknowledgement?<br>
  Â  Â  (no.  they can do all the work and just get the route holder to ack<br>
it though)<br>
</blockquote>
<br></span>
Disagree here, because if the route object is valid, the IRR doesn't need to authorize the AS relationship.  But that's all part of "the autnum and related objects need some real discussion here".<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.c. Should a route holder be able to remove an origin AS from their route without the AS holder's acknowledgment? (yes)<br>
</blockquote>
<br></span>
Yes<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3.d. Should a route holder be able to adjust the routing policy associated with someone else's AS, but only with respect to their route without AS<br>
holders acknowledgment ?  (no)<br>
</blockquote>
<br></span>
Didn't grok the situation you're describing.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.e. Should an AS holder be able to document a Peering relationship, transit customer relationship, or transit provider relationship with another<br>
AS without that AS holder's approval? (maybe yes)<br>
</blockquote>
<br></span>
Yes but same as above.<span class="HOEnZb"><font color="#888888"><br>
<br>
David<br>
</font></span></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>