Hi Sasha and James,

It seems that the draft expired on 25th of August, is there a newer version of 
it (or plans to continue the work)?
I fully support this idea and I would love to see this work coming to 
implementation.



Kind Regards

Stavros Konstantaras
Sr. Network Engineer | AMS-IX NOC



From: Sasha Romijn <[email protected]>
Date: Thursday, 6 March 2025 at 15:09
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [GROW] Re: draft-romijn-grow-rpsl-registry-scoped-members

[You don't often get email from [email protected]. Learn 
why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hello Douglas,

Thanks for the feedback. Responses inline.

On 5 Mar 2025, at 11:38, Douglas Fischer <[email protected]> wrote:
> However, the first thing that came to mind when I read about the creation of 
> this attribute was the lack of creation of the member-of attribute equivalent 
> to this hierarchical model.
> The suggestion here is to create a src-member-of attribute, with the same 
> precedence and validation logic proposed for src-member, but equivalent to 
> (mp-)member objects.
>
> Although I am aware that today there is no effective use of this attribute 
> for cross-validation of the actual belonging of the object to the collection 
> that mentions it, this is the method provided for by previous RFCs for such 
> cross-check. As was mentioned in the introduction to versions 00 and 01 of 
> this draft.

In my interpretation of member-of, it is already scoped to a single registry, 
i.e., if a route(6) or aut-num contains member-of, the referred set, if it 
exists, must only be looked up in the same source.

The reason for this is authentication: the set object authorizes this inclusion 
through mbrs-by-ref, referring a mntner. Any mntner references only make sense 
within the same IRR registry. In the same way that, for regular object changes, 
the mntner referred from an mnt-by is only ever matched in the same registry. 
This is the current implementation in IRRDv4.

That said, this argument would not apply when mbrs-by-ref is ANY. For 
consistency though, I follow the same behavior by looking only in the same IRR 
registry. Also, RFC2622 does not bring this up. RFC2725 9.6 mentions options 
for cross-registry authorization, but I don't think there are any 
implementations.

Nonetheless, in my opinion the only sensible interpretation of 
mbrs-by-ref/member-of is within the same registry, therefore scoping is not 
needed.

Sasha
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to