Skip to main content

Last Call Review of draft-ietf-mls-architecture-13

Request Review of draft-ietf-mls-architecture
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2024-04-08
Requested 2024-03-25
Authors Benjamin Beurdouche , Eric Rescorla , Emad Omara , Srinivas Inguva , Alan Duric
I-D last updated 2024-04-02
Completed reviews Artart Last Call review of -13 by Valery Smyslov
Secdir Early review of -09 by Yoav Nir (diff)
Genart Early review of -09 by Meral Shirazipour (diff)
Opsdir Early review of -09 by Tim Wicinski (diff)
Artart Early review of -09 by Valery Smyslov (diff)
Artart Last Call review of -10 by Valery Smyslov (diff)
Secdir Last Call review of -10 by Yoav Nir (diff)
Intdir Telechat review of -10 by Tatuya Jinmei (diff)
Dnsdir Telechat review of -10 by David C Lawrence (diff)
Assignment Reviewer Valery Smyslov
State Completed
Request Last Call review on draft-ietf-mls-architecture by ART Area Review Team Assigned
Posted at
Reviewed revision 13
Result Ready w/issues
Completed 2024-04-02
I am the assigned ART directorate reviewer for this document. These comments
were written primarily for the benefit of the ART area directors.  Document
editors and WG chairs should treat these comments just like any other last call

I reviewed the -09 and -10 versions of the draft before. Some of my concerns
were addressed in the -13 version. I still have the following minor issues with
the document.

1) It is still unclear to me if it is ever possible for a client (let it be
Alice) that support only version x of the protocol to join the group that was
formed using version y (y > x) of the protocol, even when all the members of
this group support both versions. In other words, if the group originally
included Alice, the members would have negotiated using version x. But if the
Alice tries to join the group later, then it is not clear for me whether she is
able to do it. The document seems to allow upgrading version of the group, but
seems to not allow downgrading it (even for a legitimate user wishing to join).

2) After adding a few clarification words into the document I now seem to
understand that DS type (Strongly Consistent / Eventually Consistent) also
influences clients' behavior. At least clients must be able to handle rejected
messages to to work with Strongly Consistent DS. I still would like to see more
words in the document discussing possible (in?)compatibility between clients
and Delivery Services depending on the type of the latters.

3) The issue of inability for a client to remove itself from the group by
its own seems unsolvable in the MLS architecture. I still think that some
recommendations in the document for clients wishing to exclude themselves in
situations when other members for some reasons don't cooperate in this process
would be helpful.

URL provided in the [CAPBR] reference doesn't contain full article, only its
abstract, that makes it difficult for readers to independently verify claims
made in the draft regarding "CAP theorem".

While I think these issues are important, I'd leave them on ADs' discretion.