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

[Lars Eggert <[e-mail]>]

Thomas, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On 2022-9-9, at 15:57, 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).
> 
> 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: [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>
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art