Change:
be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. <del> 16.6. </del> <ins> 16.7. </ins> This document registers the "message/mls" MIME media type in order to allow other protocols (e.g., HTTP RFC7540) to convey MLS messages.

Discussion:
I think this is unnecessary and capricious.
Interim 2022-12-08: Make ProtocolVersion and WireFormat two bytes Leave other enums as-is Define an IANA registry for WireFormat
Fixed by
Comment by NAME Would it really do harm to turn this into two octets? I don't think message size is a real concern here. Same for ContentType and SenderType. Note: thank you for skipping 0 as a valid entry!! Implementers applaud you :)
Yep, we have tried to reserve 0 in all the enums, precisely because I was a grumpy implementor!
On the one hand, yes, one octet is not that much more, and it saves worrying about space. On the other hand, in its long life, TLS has only exhausted 4 of its 65k versions, and its HandshakeType and ContentType enums are both still comfortable at 1 byte (the analogous to the other ProposalType and ContentType here). Among the identifiers we have, we should be most worried about the intended extension points, namely ExtensionType and ProposalType. Both of those are already. There's no mechanism for adding new values to ContentType and SenderType, so I would leave them at . (Technically they could be updated by an extension -- but an extension could also make them 16 bits!) I can live with expanding ProtocolVersion, in case we decide to do some of the GREASE-like stuff that QUIC is doing.
I don't have a strong opinion about this either, but if we make this 16-bit wide, we should do the same for consistency for ContentType, SenderType & WireFormat (the MLS extension document does introduce a new WireFormat for example).
Hi, I don't think there is any expectation that we are going to exhaust the version space (and we could do an extension later to fix that in the event we are wildly successful). As for the idea that implementations will be easier if things are aligned on 16-bit or 32-bit boundaries, that doesn't help us because the Vector lengths are variable. I would leave this as is.
I can agree with the reasoning here
We talked about quite a number of different ways to do deletion in *ART groups. Give at least a high-level overview of the main ones, and mention their pros and cons.

These include: just rebuild the tree Pros: simple, easy, no extra operations Cons: inefficient, puts the deleter in a trusted position in the group until every remaining member has updated update deletee's key to blank Pros: fairly simple, no extra operations Cons: puts the deleter in a trusted position until the sibling or cousin of the deletee has updated send a delete secret over pairwise channels Pros: no trusted positions Cons: O(N), leaves a potentially-compromised leaf node in the tree send a delete secret by KEMing to everyone else Pros: no trusted positions, efficient Cons: leaves a potentially-compromised leaf node in the tree, multiple deletes interact in a complex way
I don't quite follow the deletion algorithm that's in there at the moment. Does it require double-join bookkeeping, NAME If so I can add a note about that.
I'm going to look at clarifying deletion in the doc; but essentially we're going for replace-then-blank in this initial draft. Keeping punctured trees is an option we should discuss once it's out there.
NAME I think the algorithm in is explicitly double-joined. When I get time, I'll file another PR to move to the delete-without-double-join algorithm I posted to the list (i.e., puncture the tree).
Since we're no longer using ART, I think this issue is no longer relevant.