Roman -
I am not an author on this draft - and I defer responses to your comments on this draft to the author. However, I am the author of RFC 7370 - and am therefore responding to your comments on that document. I don’t think it is within the purview of this review to raise questions about the content of RFC 7370. As an IETF member you are certainly entitled to make such comments, but draft-ietf-lsr-labv-registration-02 is not making changes to RFC 7370 nor should it - so this isn’t the right context to make such comments. Nevertheless, I will respond to your comments below. I suggest that if you want to continue the discussion of RFC 7370, please start a separate thread and I will do my best to respond. Please see inline. > -----Original Message----- > From: Roman Danyliw via Datatracker <[email protected]> > Sent: Monday, July 29, 2024 11:54 AM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; > [email protected] > Subject: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-labv- > registration-02: (with COMMENT) > > Roman Danyliw has entered the following ballot position for > draft-ietf-lsr-labv-registration-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> > positions/<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-labv-registration/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Ines Robles for the GENART review. > > ** Section 2 > > The registration procedure for the "IS-IS Neighbor Link-Attribute Bit > Values" registry is changed to be "Expert Review". General guidance > for the designated experts is defined in [RFC7370] and more specific > guidance can be found in [RFC5029]. > > I read through RFC5029 and didn’t find any text scoped as guidance to the > designated expert. [LES:] Though in this case I defer, I will mention that this text was added in response to a comment from Sue Hares in her ops-dir review. I think the comment was intended to cover the point that in order to fully understand assignment of Bit Values one has to be familiar with RFC 5029. This reference will, in any case, be included by IANA in the registry itself - so I think mention of it in the draft is benign but unnecessary. > > I read through Section 4 of RFC7370 and had the following questions: > > -- Per “The Designated Experts SHOULD then review the assignment requests > on their technical merit”, is there any further guidance? When would the DE > not evaluate the request on technical merits? > [LES:] I am not sure what you expect. I point out that https://www.rfc-editor.org/rfc/rfc8126#section-4.5 cites the following as excellent examples: <snip> Extensible Authentication Protocol (EAP) [RFC3748], Sections 6 and 7.2 North-Bound Distribution of Link-State and TE Information Using BGP [RFC7752], Section 5.1 <end snip> In reading those two examples, I think that https://www.rfc-editor.org/rfc/rfc7370.html#section-4 compares well (just my opinion of course). > -- Is the WG confident that “expert review” is the correct registration > policy? > I ask because the text in this section seems to be preferring a reference of > some kind which hints that “specification required” (which also includes an > expert review and could be an I-D) might be more appropriate. > [LES:] RFC 7370 was written specifically for IS-IS IANA registries - and all other IS-IS registries use Expert Review. So I am completely confident that this is the correct choice. "Specification Required" allows that non-IETF documents (see https://www.rfc-editor.org/rfc/rfc8126#section-4.6 ) could serve as the place where codepoints are defined and we did not want to allow that. Thanx. Les > ** Idnits reported: > > -- The draft header indicates that this document updates RFC5029, but the > abstract doesn't seem to directly say this. It does mention RFC5029 > though, so this could be OK. > > The abstract text explicitly needs text to the effect of “This document > updated > RFC5029 ...” > > > > _______________________________________________ > Lsr mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
