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). 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/statements/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). > > Given Section 6.3, I think RFC7981 should be a normative reference rather than > an informative one. > > I think RFC4271 also needs to be normative since it's referenced by a SHOULD. > > > > _______________________________________________ > 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
