Ballot for draft-ietf-lsr-ospf-reverse-metric
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Even, if I cannot really parse `During the WG last call, a number of WG members the draft with the only issue being the predominant use cases.`. Please note that Wassim Haddad is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Wassim will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/reviewrequest/16329/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Abstract `that receiving neighbor(s) should use for a link to the signaling router` should the neighbor be qualified by "OSPF" ? More generally about the abstract: it is rather hard to parse and to understand (at least for a native English reader). ### Generic Should this be "mirrored metric" rather than "reverse metric". I appreciate that this is late in the process, but it sounds clearer. ### Section 1 s/and/or/ in `Open Shortest Path First (OSPFv2) [RFC2328] and OSPFv3 [RFC5340] `? ``` ... then R2 advertises this value as its metric to R1 in its Router-LSA instead of its locally configured value. ``` Suggest to s/in its Router-LSA/in its Router-LSAs to all its OSPF neighbors/ ### Section 2.2 s/some point T/some point in time T/ ? Please expand "CLOS" ### Section 6 ` When using multi-topology routing with OSPF [RFC4915],` what about OSPFv3 ? ### Section 7 s/The use of reverse metric signaling does not alter the OSPF metric/The use of *received* reverse metric *signalling* does not alter the OSPF metric/ ? Rather than `If routers that receive a reverse metric advertisement log an event to notify system administration, `, what about using "It is RECOMMENDED" or a "SHOULD" ? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
Apologies for being late to the party. Just a few things to add beyond the feedback my colleagues have already provided: The first sentence in Section 2.2 uses the phrase "toward the core" three times. Seems like it could do with some common factoring. There's a SHOULD at the bottom of Section 6. Why's it only a SHOULD? When might an implementer legitimately decide to do something else? In Section 9, I suggest making it explicit that you're talking about the "Link Local Signalling TLV Identifiers" registry in the "Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)" registry group.
Thank you to Steve Hanna for the SECDIR review.
Thank you for this document -- I must admit that I find the opportunities that this creates for a: shooting yourself in the foot or b: getting very confused by trying to be too clever with this somewhat scary, but, well, I don't need to use this if I don't want to. Other than that, it seems like it could be a useful capability for people a: brighter and/or b: braver than me.
Thanks for addressing my DISCUSS. https://mailarchive.ietf.org/arch/msg/lsr/FsFWbhbwxOFWdg6uhPdzzMfaMdo/
# GEN AD review of draft-ietf-lsr-ospf-reverse-metric-08 CC @larseggert Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/b581armfQ6xiXV2kBwnoChODULQ). ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Grammar/style #### Section 3, paragraph 1 ``` se Metric TLV is a new LLS TLV. It has following format: 0 1 ^^^^^^^^^^^^^^^^ ``` The article "the" may be missing. #### Section 8, paragraph 1 ``` edgements The authors would like to thanks Jay Karthik for his contributions ^^^^^^^^^ ``` Did you mean "to thank"? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Thanks for handling by DISCUSS. I understand you and Alvaro are working on the details, but I'll be satisfied with the outcome of that. *** A "don't be stupid" warning in 2.2 certainly wouldn't hurt, either.
Discuss cleared. Thanks for accommodating my concern.