Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-tsvwg-ecn-encap-guidelines-20

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

Lars

> On Oct 29, 2023, at 01:17, Susan Hares via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Susan Hares
> Review result: Ready with Issues
> 
> 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://wiki.ietf.org/en/group/gen/GenArtFAQ>.
> 
> Document: draft-ietf-tsvwg-ecn-encap-guidelines-??
> Reviewer: Susan Hares
> Review Date: 2023-10-28
> IETF LC End Date: 2023-11-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document summarizes decades of work on congestion work in IEEE
> 802.1 and IETF.  It provides a set of good guidelines/recommendations for
> designers of Layer-2 (L2) or L2/L3 shim layer.
> 
> The authors (John Kaippallimalil and Bob Briscoe) and the original author/
> now-contributor (Pat Thaler) should be commended for their work.
> 
> The text is generally readable with relatively few English and editorial
> issues.  However, the authors would be wise to fix the editorial issues prior
> to sending it to the RFC editor since phrasing needs to be precise.
> 
> Major issues: none.
> 
> Minor issues:
> 
> 1. Have the authors considered the SR-routing pathways with tunnels in this
> draft?
>   If so, the authors might add a side note in the document.
> 2. Has this document been circulated by the IETF liaisons to IEEE 802.1, MEF,
> and 3GPP? 3. Are you really sure your security and manageability sections are
> complete?
>        RFC7713 predates large deployment of SR routing.
> 
> Nits/editorial comments:
> 
> Formatting in the pdf seems to be problematic.  I am not commenting on this
> point since html form does not have hte same problem.
> 
> Nits in Editing:
> Section 2
> Old/Not-ECN-PDU:
> A PDU at the IP layer or below that is part of a congestion control
> feedback-loop within which at least one node necessary to propagate any
> explicit congestion notification signals back to the Load Regulator is not
> capable of doing that propagation./ New:/Not-ECN-PDU: A PDU at the IP layer or
> below that is part of a congestion control feedback-loop within which at least
> one node necessary to propagate any explicit congestion notification signals
> back to the Load Regulator this PDU is not capable of doing that propagation./
> 
> Section 3
> Text:/
> The router forwards the marked L3 header into subnet 2, and when it adds a new
> L2 header it copies the L3 marking into the L2 header as well, as shown by the
> 'C's in both layers (assuming the technology of subnet 2 also supports explicit
> congestion marking)./
> 
> Question - did you mean subnet b instead of subnet 2 (per figure 1)
> 
> Section 4.3
> Text:/
> This ensures that bulk congestion monitoring of outer headers (e.g. by a
> network management node monitoring ECN in passing frames) will measure
> congestion accumulated along the whole upstream path — since the Load Regulator
> not just since the ingress of the subnet. /
> 
> The portion of this sentence that has me confused is "since the Load Regulator
> not just since the ingress of the subnet.".   I'm not really sure what you are
> trying to say - so I have no suggested new text.
> 
> 
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call