Hi Peter, Chris, I agree that a number of IS-IS IANA registries have this level of specification. For example:
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 Thanks, Acee On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" <[email protected] on behalf of [email protected]> wrote: > On Mar 9, 2020, at 6:36 AM, Peter Psenak <[email protected]> wrote: > > Hi Chris, > > On 07/03/2020 15:46, Christian Hopps wrote: >> 1) I think we should have an IANA registry instead of just a table defined in section 10 of draft-ietf-lsr-isis-srv6-extensions-06. >> The registry could be cross-referenced by and to "SRv6 Endpoint Behaviors" for each protocol carrying these behaviors (IS-IS, OSPFv3, ...). If/when new behaviors are added they could then update where they are supposed to be advertised in the underlying protocols. > > why do we need a protocol specific registry to advertise values that are defined in another protocol independent registry? I have never seen such a duplication. Looks completely redundant to me. You are creating some new sub TLVs (End, End.X, LAN End.X), and you are restricting and directing which externally defined behaviors (values) can be advertised in which of these TLVs. The registry would keep track of this (e.g., "Valid behaviors for sub-TLVs End, End.X, LAN End.X") What happens when new behaviors are defined (externally), which TLVs are they supposed to be advertised in? Either the document that defines the new behavior or a related LSR document will have to indicate where this new behavior should be advertised too. That new document would update this registry to track that. Keeping track of this stuff is what registries are for. Your table literally looks like a template for the initial content of a registry. :) Later in your IANA section you are updating other registries that bear a striking resemblance to this (e.g., what sub-TLV types are valid to advertise in what TLVs). >> 2) It's odd that we are referring to the section as "Legal Behaviors" in the TLV definitions, and then in the actual section using "MAY" terms and no "MUST"/"MUST NOT", but then using "Yes" and "No" in the table. > > a) Legal Behavior - refers to the set of values defined in the [I-D.ietf-spring-srv6-network-programming] which can be advertised in a particular TLV > > b) We can not use MUST in section 10, as all these TLVs are optional What's wrong with "If this behavior is advertised it MUST only be advertised in the TLV[s] as indicated by "Y" in the table below, and MUST NOT be advertised in the TLV[s] as indicated by "N" in the table below." or something like that. Thanks, Chris. (as WG member) > c) Yes/No means whether the particular behavior is allowed in the particular END-SID TLV. > >> Are these suggestions or are they documenting the required behavior? > > these are limitations as to which behavior is allowed to be advertised in which TLV. > thanks, > Peter > >> Thanks, >> Chris. > > _______________________________________________ > 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
