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