Re: [Gen-art] Genart last call review of draft-ietf-lsr-ospf-reverse-metric-07

[Ketan Talaulikar <[e-mail]>]

Hi Thomas,

Thanks a lot for your detailed review and your suggestions. We've
incorporated all of those changes and they will reflect in the next update
of the document.

Please check inline below for some responses.


On Fri, Sep 9, 2022 at 6:27 PM Thomas Fossati via Datatracker <
[e-mail]> wrote:

> 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).
>

KT> Thanks for catching that. The goal was to actually acknowledge Jay. We
will remove the contributors section and use the acknowledgement section
instead.


>
> 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.)
>

KT> Yes, they are de facto mutually exclusive - i.e., when the O flag is
set, the offset is added to the existing metric and therefore guaranteed to
be not lower than the existing metric. Therefore, when the O flag is set,
the H flag can be ignored and we will add this explicitly in the text.


>
> * "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.
>

KT> RFC5613 indeed covers this already and so it is a MUST ... "when
authentication is used".

Thanks,
Ketan


>
> 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: [e-mail]
>
>     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: [e-mail]
>     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>[e-mail]</email>
>     </address>
>   </contact>
>   <t>
>     Jay contributed to the use cases and the review of the solution.
>   </t>
>
>
>
>
>