Re: [Masque] Re: draft-ietf-masque-connect-ethernet-06 early Httpdir review

On Thu, May 29, 2025, at 00:51, Alejandro Sedeño wrote:
> I'm inclined to split the vlan-identifier text and examples into a
> separate paragraph with a bit more focus on the "implementations MAY"
> aspect of it.  I do not want to go into details of how a vlan-identifier
> parameter might be encoded since that should involve some out-of-band
> communication.

That sounds reasonable.  The VLAN stuff is probably a detail that you can't standardize, so you shouldn't make it a prominent part of the document.  Just like the bridging stuff below.

> Here, as Mirja said, I'm going for consistency with the rest of the
> MASQUE suite.  Would it be more palatable if the /.well-known/ example
> was only for the non-parameterized case and not the hypothetical and
> underspecified vlan-identifier case?  Adding the "ethernet" entry to the
> "masque" table in the .well-known registry is cheap, and registering it
> now means it's available for future extension work.

Just because it takes you five minutes to type the text that gets something into an IANA registry, or even the code that adds it to your implementation, that doesn't make it cheap.  Even if this isn't used, once you do that, this is a resource that now exists on every web server in existence.

What you need to do is establish whether there is an actual need for someone to be given a domain name and use that as the only input they need to create a new Ethernet tunnel.  Given the additional information that this to-be-standard requires, from authentication details to all the business of how to Ethernet, that seems like a pretty unlikely case to me.

>>> (This talks
>>> about "falsified" source MACs, but what does that even mean with Ethernet
>>> anyway?)
>
> Would arbitrary work better than falsified here?

Probably.

>> It seems like there should be an established understanding of what
>> side of the bridge has things like gateways and so forth.  Otherwise,
>> this won't interoperate very well.
>
> I disagree.  There are use cases I can imagine (though perhaps slightly
> contrived) where an isolated Ethernet segment gets bridged to a client
> providing a gateway for the duration of the session.  There are also
> cases where there may not be any gateways, and all communication is only
> between nodes on the segment.

Maybe that is what you need to say: this document does not say anything about where things like gateways might be found: on the client side of the tunnel or the server side of the tunnel.  That situation needs to be understood using out-of-band information.  I would still recommend limiting clients to be clients with a single MAC (and not to have a fully bridged layer 2 by default) but that would be - at best - advisory.

Because of this:

> I expect connect-ethernet deployments to be very particular and often
> used between endpoints controlled by the same party.  Maybe that is due
> to a lack of imagination on my part.  For most use cases—not all or I
> wouldn't be writing this draft—I would expect that using higher-level
> mechanisms such as connect-ip or connect[-udp] would be superior.
> Perhaps the draft should make that more explicit and encourage readers
> to consider using higher-level options first.

That would help, yes.  Be very clear about what your expectations are.

Received on Tuesday, 3 June 2025 06:38:56 UTC