Hi John, None of these are functional changes - just clarifying the OSPFv3 SR usage of the same IANA registry IS-IS SR. I don’t see why we can’t make these now or during AUTH48.
> On Dec 14, 2022, at 4:59 PM, John Scudder <[email protected]> > wrote: > > Hi Authors, WG, > > As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at > these documents and came up with a few comments that would otherwise become > part of my AD review for ospfv3-srv6-extensions, so I thought I’d share them > now. > > draft-ietf-lsr-isis-srv6-extensions-19 is currently in RFC-EDITOR state so it > may or may not be reasonable to make any changes, but I’m going to mention > them below anyway. I’m sorry I didn’t notice this before we got through IESG > review. > > draft-ietf-lsr-ospfv3-srv6-extensions-08 Section 2 defines the flags field in > a way that (as per usual) conveniently happens to be identical to how the > IS-IS document defines it. However, I don’t see any language in > draft-ietf-lsr-ospfv3-srv6-extensions-08 saying that the IANA Registry from > the IS-IS draft MUST be used for the assignment of flags for the OSPFv3 > field. Shouldn’t you say this? > > Also, the registry should probably refer back to both (all three, if we > include the BGP-LS one, but that's another story) specs that make assignments > from it, shouldn’t it? So where the IS-IS document says, > > "This document requests a new IANA registry be created under the IS-IS TLV > Codepoints registry to control the assignment of bits 0 to 15 in the Flags > field of the ISIS SRv6 Capabilities sub-TLV specified in this document > (Section 2):" > > Maybe it should add something like “… as well as the corresponding field > defined in Section 2 of draft-ietf-lsr-ospfv3-srv6-extensions-08.” (And maybe > “and Section 3.1 of draft-ietf-idr-bgpls-srv6-ext-12”?). It might be easier > to drop that change into the IS-IS draft now, before it exits RFC-EDITOR > state (if agreed of course) but we could also do it by patching the registry > text in the OSPFv3 (and BGP-LS?) draft’s IANA section. > > Also, a minor point: draft-ietf-lsr-isis-srv6-extensions-19 uses inconsistent > hyphenation for the protocol name — “ISIS” or “IS-IS”. My own preference is > “IS-IS” as both more accurate and not as subject to conflation with other > uses of “Isis”, but anyway please pick one and stick with it? I guess the RFC > Editor will take care of this, but I apologize for not catching it during > IESG review I would go further and say all these should be “IS-IS”. I have been making this comment consistently when I review documents. I’m not sure how I missed them in this document. Thanks, Acee > > (This also leads me to wonder why we even put this registry, that’s shared by > two (three?) protocols, under the IS-IS TLV Codepoints registry instead of > under Interior Gateway Protocol (IGP) Parameters, but given the publication > stage we’re at it may not be worth trying to change that.) > > Thanks, > > —John > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
