I looked at this again and the long Email thread and agree with Peter, Les, and Joel that we don't need a protocol specific registry for the Endpoint behaviors and associated SIDs. Thanks, Acee
On 3/11/20, 1:42 PM, "Lsr on behalf of Joel M. Halpern" <[email protected] on behalf of [email protected]> wrote: It does seem to me that using a registry to capture the relationship between the OSPF or IS-IS advertisement (TLV, sub-TLV, ...) and the SR behavior (as defined in the NP registry and subsequent additions) is useful. I would not want to have to respin the base draft to add additional behaviors. We use registries for a reason. Now, if the advertisement registry has a note column, we could use that to record the information. As far as I know the current registries are not well-structured for such auxiliary information. Yours, Joel On 3/11/2020 11:52 AM, Christian Hopps wrote: > > >> On Mar 11, 2020, at 10:38 AM, Les Ginsberg (ginsberg) <[email protected]> wrote: >> >> Chris - >> >> >>> >>> Do you think we should get rid of the "used in" columns in the IS-IS TLV and >>> sub-TLV registries? The documents that define those TLVs and sub-TLVs >>> already indicate which PDUs and TLVs they go in, so why do we need that >>> info in the registry? >>> >> [Les:] The difference for me is that the definition of sub-TLVs associated with the related set of TLVs is scattered across multiple RFCs. The additional information in the registry allows us to find this information in one place. >> Here, there is only one relevant IS-IS draft on this technology (SRv6). If the set of behaviors which can be advertised in IS-IS changes, then an additional IS-IS document (or a bis) will be written - and it likely would be required for other reasons. >> >> We still may not agree - but I hope we at least understand each other better. > > Is the SR network programming document expected to respin a -bis for adding a behavior? > > Anyway, unless someone else thinks this is important, I guess we can just revisit it when the next SR End behavior gets added and we're faced with re-spinning this document, the OSPF companion document, and whatever other protocols support documents for advertising the new behavior, in order to support it (rather than e.g., it just going directly in a base document or a combined protocols document and updating a couple registries). > > Thanks, > Chris. > [as WG member] > >> Les >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
