[Lsr] Éric Vyncke's Yes on draft-ietf-lsr-ospf-reverse-metric-08: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-08: Yes

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-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-ospf-reverse-metric/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# É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