Thanks to Shawn E. for the SECDIR review, quite helpful.

I will comment that there are many acronyms used in the document without expanding them on first use:

MAC
VLAN
STP
RSTP
etc.

it would be really good to expand all except for the absolute most obvious ones.

Thanks to Shawn Emery for their secdir review.

Section 10, para 1:  In the list of possible auth methods, consider removing 'or even bearer tokens'.  Bearer tokens are problematic with respect to security, so unless it is a real option, I'd remove it.

Thank you for the work put into this document. I have reviewed various revisions of this document within the MASQUE WG and appreciate the additions to the document on each occasion. This review is a member of the IESG.

# Gorry Fairhurst, WIT AD, comments for Proxying Ethernet Frames in HTTP. 
The following issues are all thought to be resolved in draft-ietf-masque-connect-ethernet-12.

# My previous DISCUSS topic for draft-ietf-masque-connect-ethernet-11:

## I see the clause: "Implementations SHOULD be aware of physical topology and work to prevent loops."
### I do not understand the meaning of a normative requirement to be "aware".
### I agree that loops at layer 2 (and broadcast storms) can generate large volumes of frames that have implications at the receiver and on the network load, thank you for raising this topic. I also suggest that appropriate mechanisms are really needed to detect this.
### How does a user of the service detect respond if this happens?  It would be useful to describe a way(s) to respond when this is detected (I can see how for instance rate-limiting of broadcast could be required?) I also see that the L2 techniques could be used). Can this guidance and be improved?

# I have the following editorial COMMENTS:

## I think that the IEEE 802.3 Ethernet specification capitalises "Frame Check Sequence" as a formal field name.

## Please check the term: "MAC destination field", I think formally known as "Destination MAC Address". Pleasdse aslo note that the text relating needs to also be updated to say the *start* of the address, to remove any ambiguity about whether that field is included.

## The section: "MTU and Frame Ordering Considerations" could benefit from a sentence or two reminding the reader that there are multiple modes that can be used and that these have different implications on the supported frame size and the ordering of the delivered Ethernet frames.

## The sentence: "If an Ethernet proxying endpoint fails to deliver a frame to an underlying Ethernet segment, the endpoint MUST drop the frame." Would likely benefit by adding "Ethernet" before each use of the word "frame" to differentiate from QUIC frames. Thanks for clearly doing this elsewhere!

Best wishes,
Gorry

Thanks to the authors and the WG for their work on this document.

Also thanks to the authors for the discussion and the document updates to address my concerns and comments in the original ballot.

Section 3, VLAN/variable configuration:

170 >    An implementation that supports connecting to multiple Ethernet
171 >    segments might add a "vlan-identifier" variable to specify the
172 >    segment to which to connect.  The optionality of variables needs to
173 >    be considered when defining the template so that variables are either
174 >    self-identifying or possible to exclude in the syntax.  How valid
175 >    values for such variables are communicated to the client is not a
176 >    part of this protocol.

Three separate directorate reviewers, over three different revisions, have
flagged the same gap here: Sheng Jiang (INTDIR, -07) asked how a
"vlan-identifier" is formatted and how failure to reach a pre-configured
VLAN is handled; Martin Thomson (HTTPDIR, -06) said the missing encoding
(decimal vs. hex) was a genuine interop risk; and Brian Haberman (INTDIR,
-11) is still asking, as of last week, what happens when the two ends of a
connection are configured with different formats for the same variable.
That's a wide spread of independent reviewers landing on the same open
question, and the text hasn't moved to close it.

A sentence noting that the per-VLAN-URI
approach in Section 9.2 avoids the need for a standardized variable format,
and that "vlan-identifier" above is illustrative only, would head off a
fourth reviewer raising this again after publication.

---

Section 10, buffering and resource exhaustion:

I don't see the Section 6 buffering guidance cross-referenced from Security
Considerations, and I think it should be. This is as much a security-
relevant DoS surface than just a performance note:

466 >    Note that buffering datagrams (either because the request was not yet
467 >    received or because the Context ID is not yet known) consumes
468 >    resources.  Receivers that buffer datagrams SHOULD apply buffering
469 >    limits in order to reduce the risk of resource exhaustion occurring.

An attacker who doesn't even need to complete the Ethernet proxying request
can still cause a receiving implementation to buffer datagrams against an
unregistered Context ID or against a not-yet-received request. Section 10
covers spoofing, ARP/NDP/CAM poisoning, and request smuggling in detail, but
says nothing about this resource-exhaustion angle even though the mitigation
already exists in Section 6. A one-line pointer from Section 10 to this
guidance would make the Security Considerations section a more complete
inventory of the attack surface without requiring any new normative text.

---

Section 3 and Section 10, RFC 2119 keyword strength:

170 >    An implementation that supports connecting to multiple Ethernet
171 >    segments might add a "vlan-identifier" variable to specify the
172 >    segment to which to connect.  The optionality of variables needs to

664 >    its use to authorized users who have properly authenticated to the
665 >    HTTP server.  Depending on the deployment, possible authentication
666 >    mechanisms include mutual TLS between Ethernet proxying endpoints and
667 >    HTTP-based authentication via the HTTP Authorization header field
668 >    [HTTP].  Once authenticated, proxies can enforce policies on
669 >    authorized users to further constrain client behavior or deal with
670 >    possible abuse.  For example, proxies can rate limit individual

681 >    connections might limit clients to a single source MAC address, or
682 >    Ethernet proxying endpoints might be configured to limit forwarding
683 >    to pre-configured MAC addresses, or clients could be authenticated by

Brian Haberman's INTDIR review suggested strengthening "needs to be
considered" (line 172) to a MUST, "can enforce" (line 669) to a SHOULD, and
"might limit" (lines 681-682) to a SHOULD. I think he's right on all three.
None of these are describing optional behavior; they're describing what a
careful implementation actually has to do to avoid the failure modes the
surrounding text just finished describing. Lower-case language here reads
as weaker guidance than the document intends.

---

Operational Considerations: this document has no Operational Considerations
section. draft-ietf-opsawg-rfc5706bis recommends one for documents defining
new protocol extensions, and this one introduces manageable state --
per-context buffering limits, rate limiting, loop-prevention configuration
-- without a YANG module or other management interface. Since rfc5706bis is
still a WG document, I'm not asking for a section, but the authors might
consider adding a sentence noting that this will be handled via a data
model to be defined in a separate document.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 8.1, STREAM and Quarter Stream ID values:

535 >    STREAM(44): HEADERS
...
548 >    Quarter Stream ID = 11

Elwyn Davies asked in his GENART review whether these example values are
arbitrary or meaningful. A one-line note or a reference that STREAM(44) and Quarter Stream
ID 11 follow from the QUIC stream-to-datagram-ID mapping in RFC 9000/9221
(rather than being arbitrary example numbers) would help readers who try to
follow the arithmetic.

Section 9, "benefitial":

598 >    Some implementations might find it benefitial to maintain a small
s/benefitial/beneficial/

Section 9.2, "Etherent":

642 >    When the proxy transports Etherent frames that carry an IEEE 802.1Q
s/Etherent/Ethernet/

I support both Éric and Ketan positions.

Thank you to Elwyn Davies for the GENART review.

Strongly support Éric's DISCUSS.