Hi Peter, > On Dec 15, 2022, at 8:11 AM, Peter Psenak > <[email protected]> wrote: > > On 15/12/2022 13:51, John Scudder wrote: >> Thanks, Peter. >> Doesn’t this mean that the OSPFv3 draft needs to create its own registry for >> the flags, then? > > it does.
Section 2 defines the flags field in the OSPFv3 SR capabilities TLV. I don’t see an IANA registry defined for these flags. Thanks, Acee > > thanks, > Peter >> —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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
