Thanks, Peter. Doesn’t this mean that the OSPFv3 draft needs to create its own registry for the flags, then?
—John P.S.: I see 8 instances of “ISIS” in version 19 of isis-srv6, but maybe you’re looking at the RFCEd version. > On Dec 15, 2022, at 6:29 AM, Peter Psenak <[email protected]> wrote: > > John, > > On 14/12/2022 22:59, John Scudder 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? > > we kept the ISIS and OSPF SRv6 capabilities separate. One day they may > diverge. > >> >> 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 see one occurrence of "ISIS" in the latest version of the draft, I > will ask editors to fix that. > >> >> (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.) > > no, the flags are kept independent in each protocol. > > thanks, > Peter >> >> Thanks, >> >> —John _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
