Hello,

I have been selected to do a routing directorate “early” review of this draft.

The routing directorate will, on request from the working group chair,
perform an “early” review of a draft before it is submitted for
publication to the IESG. The early review can be performed at any time
during the draft’s lifetime as a working group document. The purpose
of the early review depends on the stage that the document has
reached. As this document is in working group last call, my focus for
the review was to determine whether the document is ready to be
published. Please consider my comments along with the other working
group last call comments.

These comments are intended to help improve the document and should be
considered along with other WG Last Call comments that you receive.

Document: draft-ietf-masque-connect-ethernet-07
Reviewer: Donald Eastlake
Review Date: 8 August 2025
IIntended Status: Standards Track

Summary:  This document is reasonably well written but I have some
minor concerns about it that I think should be resolved before it is
submitted to the IESG.


Comments and Questions:
This document primarily specifies how to tunnel an Ethernet segment
over various versions of HTTP and I believe it does a good job of that
from my somewhat limited knowledge of the varieties of HTTP.

I found Section 7 to be a bit incomplete (or perhaps confusing).
Looking at the example in Section 8.2, it seems to me that to
implement that example, the Client box and the L2 Proxy boxes must act
as bridges, or perhaps together as one bridge when viewed externally.
In particular, the frames accepted by and sent from the Client and the
L2 Proxy to their local broadcast domain would not have the MAC
address of the Client or L2 Proxy ethernet ports. This potentially
leads to various questions as to which LLDP multicast address those
ports respond to? And are they visible to 802.1 CFM (Connectivity
Fault Management)? Can the ethernet tunneling service really
interoperate if such decisions are not coordinated at the two ends?
     I assume the idea is to try to sweep all this under the carpet or
the like. But I think that, at a minimum, the draft needs to say that,
in cases where the Client or L2 Proxy is connected to an ethernet
segment, then the port through which that connection occurs must act
like a bridge port, and not a router port, in that it will receive
ethernet frames despite the frame destination MAC address not being
the port address and will send ethernet frames with a source MAC
address other than the port address.

Section 10: Should mention, perhaps in the 2nd paragraph, the
possibility of 802.1X port based authentication to authenticate access
by devices on the broadcast domain at either end.

Section 4, last paragraph: Why is the requirement to use HTTP over TLS
or QUIC encryption a MUST? What if MACSEC [IEEE Std 802.1AE] is in use
on the virtual Ethernet segment being set up?

Section 9.1, particularly the last paragraph: In the IEEE 802.1
Ethernet world, re-ordering of frames is considered MUCH, worse than
dropping frames. Obviously, if the traffic is actually IP or some
protocol engineered to tolerate re-ordering, this does not apply. But
for general ethernet traffic, in order delivery is commonly assumed.
However, this only applies within a priority level, if the ethernet
frame is VLAN or priority tagged (a priority tag is just a VLAN tag
with a zero VLAN ID).

Section 9.2: Stripping and applying VLAN tags (which can result in
mapping one VLAN to another) is definitely the sort of thing that
bridge ports do, so this further pushes towards the Client and L2
Proxy ports on their local broadcast domain being bridge ports.

Section 12: Should Reference appropriate IEEE 802 standard. 802.1Q and
802.3 at a minimum.

Nits:
-----

Section 4, paragraph 1: Since you have just referred to a Section in
another RFC, it is not immediately obvious which document the final
"Section 6." is referring to. I suggest saying "Section 6 of this
document."

The draft uses SHALL in some cases and MUST in others. Best to be consistent.

Section 4.4: Maybe the paragraph after the list should be a little
more explicit. Something like: "An Ethernet proxying request that does
not conform to these restrictions is malformed and results in an error
response as discussed in Section 8.1.1 of [HTTP/2] and Section 4.1.2
of [HTTP/3]."

Section 4.5, right after the list: "any" -> "either"

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com