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@xxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
