[routing-wg] Notification/authorisation of references to aut-num from other RPSL objects

On 11 Jun 2014, at 7:06 pm, Job Snijders <job at instituut.net> wrote:

> On Wed, Jun 11, 2014 at 12:55:05PM +1000, George Michaelson wrote:
>> I am trying to understand how this change could {help,hinder} the APNIC
>> problem of route objects which reference differently maintained AS and
>> Inetnum objects, and the added complication of AS being vested from RIPE
>> and Inetnum from APNIC.
> 
> Can you elaborate on what the problem precisely is?

I presented on this at RIPE Dublin and/or Lublijana. AP region has a large (and growing) community of inetnum holders who are not the AS holder and the dual-authentication issues around securing a route object which references the upstream AS is proving a logistical issue. If this field has the potential to aide in automating processes so that party A, lodging a route object in reference to AS held by B, can see B told efficiently that A needs their permission to lodge the route object, its helping our problem.

If it can't do this, then its not relevant. Thats why I said "I'm trying to understand if this helps or hinders the APNIC problem..." I needed to try and understand if this notify field would get to the right person, at the right time.

> 
>> I think stripping/changing the notify-on-ref mail might hinder this. It
>> would be materially useful to preserve it, should exported IRR state be
>> used at another site aggregating data, to contact the prime information
>> manager.
> 
> To contact the owner of a resource there are other mechanisms (abuse-c,
> admin-c, contact-c, etc). I would deem the notify-on-ref email address
> only relevant for communication between the registry and the email
> address being notified. It should not concern others who is notified
> when a resource is referenced.

Well, I guess I'd seen another sense of use of the field. Thanks for clarifying.

> 
>> I suspect RPSS/RPSAUTH issues are out of scope. Within one IRR/RPSL data
>> set, I think the notify-on-ref thing would help the APNIC problem: it would
>> make it easier for non-related maintainer to understand changes were being
>> made in routing by address holders who want their AS to be in a route
>> object, and participate.
> 
> I am not sure I follow which problem or concern you are addresssing. Can
> you maybe use an example?

Sure. Inetnum holder in India, has upstream using AS assigned by RIPE, maintained by RIPE in RIPE IRR. Inetnum holder maintains Inetnum in APNIC WHOIS. There is no substantive RPSS/RPSAUTH to permit an external reference. They cannot effectively make a route object.

RIPES current solution satisfies only database purists: a 'dummy' record can be made in RIPE WHOIS which contextually, to be blunt, is a "lie" -the object in question (Autnum) has to be fictional, because there is no RIPE AS-SET or block over it, to permit it to exist. In effect, the nonce value us there only to satisfy dual-authentical requirements of the route object.

"lie" is uncharitable. Its a mechanism to permit RIPE address holders to make route objects without the consent/involvement of the AS holder which is only permitted because the AS holder is not in the RIPE region. If they are, then this mechanism is deprecated, or else functionally impossible since a real AUTNUM exists.

(If I have this wrong, I'd love to be corrected but this is how I understand it works)

-G

> 
> Kind regards,
> 
> Job

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/routing-wg/attachments/20140612/98c30d90/attachment.sig>