Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.

- Document: draft-ietf-tsvwg-udp-ecn-05
- Reviewer: Carlos Pignataro
- Intended Status: Informational

---

## Summary 

Choose one: 

- Has Issues: I have some minor concerns about this document that I think should be resolved before publication.
 
---

This document is well-scoped, clearly written, and grounded in real implementation experience. Four issues below.

1. Is this really about "Configuration", or is it about API invocation? 

The title "Configuring UDP Sockets for ECN" implies persistent, operator-manageable configuration, parameters, defaults, deployment state. What the document describes is calling the correct system call on a socket for a session. Is there something to configure, store, or manage in the operational sense?

2. Missing "Operational Considerations" section

Per draft-ietf-opsawg-rfc5706bis, an Operational Considerations section is required, or explicit boilerplate explaining why none is needed. Potentially suggested text, before Security Considerations:

"There are no new operations or manageability requirements introduced by this document. This document records existing platform API behavior for enabling ECN on UDP sockets. It does not define a new protocol or protocol extension and introduces no new configuration parameters, management interfaces, or monitoring surfaces."

3. DSCP clobbering risk understated

Current text (Section 4.1):

"Except for Apple platforms, this setsockopt() call also sets the Differentiated Services Code Point (DSCP) that make up the rest of the header byte. Applications making this call will generally want to preserve any existing DSCP setting, which might require an additional getsockopt() call."

This understates the risk in two ways. (1) First, the consequence of not preserving DSCP (silently disrupting QoS policy in networks where DSCP-based classification is in use) is not stated. (2) Second, the getsockopt()/setsockopt() sequence is not atomic; in multi-threaded servers another thread can modify the TOS byte concurrently between the two calls. Applications in that context might prefer the per-packet approach in Section 4.2, which sets ECN without touching DSCP and avoids the race entirely.

Suggested replacement:

4. Scope clarification relative to UDP Options / RFC 9868

RFC 9868 defines UDP transport-layer options in the surplus area after UDP user data. This document is orthogonal: it addresses the IP-header ECN field via socket APIs only. One sentence in the Introduction would make this explicit preventing potential confusion:

"This document addresses access to the ECN field in the IP header via socket APIs. It does not address UDP transport-layer options [RFC9868], which are a separate extension mechanism operating at a different layer."

Might not be needed, but thought of bringing it up, since potential uses of options for congestion.

I hope these are useful and clear!

Carlos Pignataro.