Hello Douglas, Thanks for the feedback. Responses inline.
On 5 Mar 2025, at 11:38, Douglas Fischer <fischerdoug...@gmail.com> 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 -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
