Reviewer: Thomas Fossati Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lsr-ospf-reverse-metric-?? Reviewer: Thomas Fossati Review Date: 2022-09-09 IETF LC End Date: 2022-09-20 IESG Telechat date: Not scheduled for a telechat Summary: This is a clear and easy to read document, thank you authors for the great job. I only have a couple of very minor issues / clarifications. The tail of my review consists of a bunch of typographic nits and one suggestion for how to align the Contributors section to most recent interpretations of the RFC Style Guide (RFC7322). Major issues: none Minor issues: * It looks that the H and O flags are mutually exclusive? If so, I think the fact should be made explicit. (This applies to both the reverse and reverse TE metrics.) * "If authentication is being used [...] then the Cryptographic Authentication TLV [RFC5613] SHOULD also be used to protect the contents of the LLS block." Please explain why this is not a MUST, i.e., under which conditions it is OK to not authenticate the LLS block. Nits/editorial comments: Section 1., paragraph 1: OLD: Thus the configuration on R1 influences the traffic that it forwards NEW: Thus, the configuration on R1 influences the traffic that it forwards Section 2.1., paragraph 2: OLD: when a large number of CE routers connect to a PE router, an NEW: when many CE routers connect to a PE router, an Section 2.1., paragraph 3: OLD: router to advertise the maximum metric for that link and also to [...] returns to using its provisioned metric for the link and also stops NEW: router to advertise the maximum metric for that link and to [...] returns to using its provisioned metric for the link and stops Section 2.2., paragraph 2: OLD: reverse metric to some or all of the R1-RN routers. When the R1-RN NEW: reverse metric to some or all the R1-RN routers. When the R1-RN Section 3., paragraph 1: OLD: This ensures that the RM signaling is scoped ONLY to each specific [...] Metric TLV in its Hello packets on the link as long as it needs its [...] NEW: This ensures that the RM signaling is scoped only to each specific [...] Metric TLV in its Hello packets on the link for as long as it needs its [...] Section 6., paragraph 4: OLD: instability in the network due to churn in their metric due to signaling of RM: NEW: instability in the network due to churn in their metric caused by signaling of RM: Section 6., paragraph 7: OLD: RM metric signaling based on the RM metric signaling initiated by some other router. NEW: RM metric signaling based on the RM metric signaling initiated by some other routers. Section 6., paragraph 10: OLD: (also refer to Section 7 for details on enablement of RM). The rules [...] NEW: (refer to Section 7 for details on enablement of RM). The rules [...] Section 7., paragraph 5: OLD: For the use case in Section 2.1, it is RECOMMENDED that the network operator limit the period of enablement of the reverse metric NEW: For the use case in Section 2.1, it is RECOMMENDED that the network operator limits the period of enablement of the reverse metric Section 9., paragraph 1: OLD: This document allocates code points from Link Local Signalling TLV Identifiers registry for the TLVs introduced by it as below. NEW: This document allocates code points from the Link Local Signalling TLV Identifiers registry for the introduced TLVs. Regarding the Contributors section, I think BCP is to make it similar to the Authors section, e.g.: Section 11., paragraph 1: OLD: Thanks to Jay Karthik for his contributions to the use cases and the review of the solution. NEW: Jay Karthik Cisco Systems, Inc. Email: jakarthi@xxxxxxxxx Jay contributed to the use cases and the review of the solution. If you are using kramdown-rfc you can add this snippet after your "author" block contributor: - name: Jay Karthik email: jakarthi@xxxxxxxxx contribution: Jay contributed to the use cases and the review of the solution. Otherwise (xml2rfc): <contact initials="J." surname="Karthik" fullname="Jay Karthik"> <organization>Cisco Systems, Inc.</organization> <address> <email>jakarthi@xxxxxxxxx</email> </address> </contact> <t> Jay contributed to the use cases and the review of the solution. </t> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
