John - Thank you for the followup. Murray - my sincere apologies for not responding to your comments. I remember reviewing your email but somehow I lost track of it and never responded.
I have posted V7 of the draft to address both the original comments from Murray and the additional comments from John. Responses inline... > -----Original Message----- > From: John Scudder <j...@juniper.net> > Sent: Tuesday, September 27, 2022 1:42 PM > To: Murray Kucherawy <superu...@gmail.com>; draft-ietf-lsr-isis- > rfc5316...@ietf.org > Cc: The IESG <i...@ietf.org>; lsr-cha...@ietf.org; lsr <lsr@ietf.org>; > Christian > Hopps <cho...@chopps.org>; t...@ietf.org > Subject: Re: [Teas] Murray Kucherawy's No Objection on draft-ietf-lsr-isis- > rfc5316bis-04: (with COMMENT) > > Hi Les and other authors, > > I didn’t see a reply to Murray’s comment. It’s not a DISCUSS so not > mandatory for you to reply but it would be appreciated. > > Of Murray’s comments, I personally don’t think RFC 7981 needs to be > normative, the test being that if you never looked at 7981 you’d still know > how to update the registry as Section 6.3 requests. > > On looking at the RFC 4271 references, in looking at the second reference to > it: > > Note further that if BGP is used to exchange TE > information as described in Section 4.1, the inter-AS BGP session > SHOULD be secured using mechanisms as described in [RFC4271] to > provide authentication and integrity checks. > > I noticed a more serious concern of my own; I’m not sure how I missed this. > To wit, RFC 4271 specifies use of TCP-MD5 [RFC 2385] for > authentication/integrity. But 2385 was obsoleted by TCP-AO [RFC 5925]. > Probably it would be better to say something like > > Note further that if BGP is used to exchange TE > information as described in Section 4.1, the inter-AS BGP session > SHOULD be secured using mechanisms such as those described in > [RFC5925] to > provide authentication and integrity checks. > > And then add 5925 as, I suppose, a normative reference. Although I did > sneak “such as” in there, since there are other ways to secure BGP as well > (for example it’s been known to run it over IPSec, or people do use TCP-MD5 > despite it being obsoleted). > [LES:] Done > I apologize for not noticing this sooner! > > Regarding Murray’s comments on SHOULDs, it looks as though the ones > regarding Section 3 (all subsections) are overtaken by events (Murray, check > if you like; most of the SHOULDs are gone and IMO the ones in §3.1 are > sufficiently qualified). The points about Section 4 are unchanged but I’d like > to point out that Section 4 itself is unchanged vs. the base RFC 5316 so I had > chosen to let sleeping dogs lie. > > —John > > > On Sep 22, 2022, at 2:17 AM, Murray Kucherawy via Datatracker > <nore...@ietf.org> wrote: > > > > Murray Kucherawy has entered the following ballot position for > > draft-ietf-lsr-isis-rfc5316bis-04: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/stat > ements/handling-ballot-positions/__;!!NEt6yMaO-gk!HB2wVApMPYK0lcGJi- > MJje2u_7UwRYvbgYV8xUgKlMyST3sMGh33yhvlbOGfQcFEZ2AE-vijj-SY$ > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- > lsr-isis-rfc5316bis/__;!!NEt6yMaO-gk!HB2wVApMPYK0lcGJi- > MJje2u_7UwRYvbgYV8xUgKlMyST3sMGh33yhvlbOGfQcFEZ2AE-sFQ5Tno$ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I support Alvaro's DISCUSS, and add my own comments related to his first > point: > > > > The first two SHOULDs in Section 3.1 would benefit from some guidance > about > > when an implementer might opt to deviate from that advice. This occurs > again > > Sections 3.3.4, 3.4.1, 3.4.2, the top of Section 4 (two SHOULDs) and the > bottom > > of Section 4 (two SHOULD NOTs). > > [LES:] As John indicated, I think the changes which Alvaro and I agreed upon should address your concerns as well - please let me know if not. > > Given Section 6.3, I think RFC7981 should be a normative reference rather > than > > an informative one. [LES:] Done > > > > I think RFC4271 also needs to be normative since it's referenced by a > SHOULD. [LES:] Done. Les > > > > > > > > _______________________________________________ > > Teas mailing list > > t...@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__ > ;!!NEt6yMaO-gk!HB2wVApMPYK0lcGJi- > MJje2u_7UwRYvbgYV8xUgKlMyST3sMGh33yhvlbOGfQcFEZ2AE-i-Sv7mQ$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
