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.