Re: Routing WG Minutes - RIPE 27, Dublin

Dear Carol,

you wrote:
>  >> RIPE 27    : Routing WG Draft Minutes
>  >> Chair      : Joachim Schmitz (JS395-RIPE)
>  >> Scribe     : Anne Lord (AL12-RIPE)
>  >> Attenders  : 57
>  >> 
[...]
>  >> 2. Hierarchical Authorisation / Cross Notification of Route Objects
>  >>    in the IRR (Carol Orange)
>  >> 
>  >> 2.1 Cross Notification
[...]
> >>  After a fairly lengthy and interesting discussion, it was agreed to go
> >>  ahead with implementing the draft proposal given the following
> >>  modifications which were agreed:
> >> 
> >>  - the submitter of the route will always be notified as to whether the
> >>    object submitted was successful. Notification of overlaps can be
built
> >>    into the acceptance/feedback message returned to the submitter.
> >> 
> >>  - for deleting a conflicting object, it was agreed to notify the 
> >>    submitter of the conflicting object that there was no longer a
> >>    conflict in the database
> >> 
> >>  - notifications on overlap - either for newly submitted route objects,
> >>    or for deletions - will only be done for *existing* route objects if
> >>    explicitly requested by the "x-notify" attribute
>  
>  I've reworded the above adjustments as I understood them, and have
>  incorporated them in the newest version (to be submitted on the list).
>  You can keep whichever version you find clearer. They say the same
>  thing.
>  
>  - Whenever a route object is submitted in the RR, a notification
>  should be generated to the submitter if the address space overlaps
>  with any other route object in the RR. This is regardless of whether
>  the new attribute for cross notification is used.
I agree with this one. However, I suggest to keep the note that the notifi-
cation to the submitter is included in the acceptance/feedback message
on the submission mail - this keeps mail traffic low.
>  
>  - If the address space covered in the route object matched the
>  address space in another route object, be sure this is clear in the
>  notification message.
Agreed.
>  
>  - Notifications should be sent to the appropriate contact not only if
>  an overlap is introduced, but also when an overlap is eliminated. 
Again agreed.
However, in your proposal I am missing a bit the distinction between
the two parties involved: (a) the submitter, and (b) the owner of a
route object which already exists in the RR and the new submission
is in conflict with it.
I try to think a bit more about the text and probably rewrite it taking
your suggestions into account.
[...]
>  >> 
>  >> 2.2 Hierarchical authorisation in the RR (Carole Orange)
>  >>     (or "aut-num authorisation for route objects in the RR")
>  >> 
>  >>    The proposal is documented in a draft document which was previously 
>  >>    circulated to the Database WG and Routing WG mailing lists.
Agreement
>  >>    on this proposal is now sought so that it can be implemented. 
>  >> 
>  >>    The goal of the proposal is to allow network operators who announce
a 
>  >>    route in their AS to delegate this authority to others. 
>  
>  No, the goal is to allow network operators who maintain an aut-num
>  object to determine who can submit a route object with their AS number
>  as origin. 
Yes. We must change this in the minutes.
>  
>  >>    There has been 
>  >>    much discussion on the mailing lists and a specific "non-goal" of
the
>  >>    proposal is to produce an optimal hierarchical authorisation scheme 
>  >>    for the RR. This proposal is not CIDR based; hence the change of
name
>  >>    for the draft to avoid any confusion about CIDR based hierarchy in
the
>  >>    proposal to "Aut-num authorisation for route objects in the RR". 
>  >> 
>  >>    The proposal works briefly by the following mechanism:
>  >> 
>  >>    A "mnt-route" attribute (in former drafts called "mnt-lower") is
added
>  >>    to the aut-num object. Currently the "mntner" object referenced
>  >>    determines who can add/update/delete an object associated with that
>  >>    aut-num (for more details see the draft which can be found at the
>  >>    reference above in the archives of the mailing list, or look at the
>  >>    Working Documents section of the Routing WG at the RIPE web server).
>  
>  No, this is not the case. There are currently no restrictions on who
>  can add/update/delete a route object specifying a given aut-num in the
>  origin. The proposal is intended address this authorization gap, by 
>  allowing network operators to specify these restrictions, and as you 
>  state above, by also allowing them to delegate this authority if they 
>  so desire.
You are again right. Sorry, this slipped.
[...]  
>  >> 
>  >> 5. Route Flap Dampening Parameters (Christian Panigl)
[...]
>  What I miss in this summary is that there seemed to be consensus at
>  the meeting that "it is beneficial if everyone adopts the same
>  parameters, because it allows problems to be detected and addressed on
>  the home front."  (but perhaps that was obvious, and I'm being picky.)
No, you are not picky. I consider this an important point and will add it
to the minutes.

Thank you very much for your comments!
Regards
    Joachim