Skip to main content

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

Request Review of draft-ietf-mls-architecture
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-01-16
Requested 2022-12-19
Authors Benjamin Beurdouche , Eric Rescorla , Emad Omara , Srinivas Inguva , Alan Duric
I-D last updated 2022-12-29
Completed reviews 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 10 (document currently at 11)
Result Ready w/issues
Completed 2022-12-29
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 version of the draft before. Some of my concerns were
addressed in the -10 version. I still have the following issues with the

1) It is not clear from the document if it is ever possible for clients
that support only version x of the protocol to join the group that was formed
using version y of the protocol, but in fact all the current members of this
group support both versions. It seems to me that this scenario is common in
situations when newer version of the protocol becomes available: during some
period of time some clients will support both new and old version, while the
rest will support only old version. If some upgraded clients form a group, they
will probably choose the newest version of the protocol, so the un-upgraded
clients won't be able to join it. I think that this scenario should be
addressed in the document.

2) It is still not clear for me whether the type of DS (Strongly Consistent vs
Eventually Consistent) affects clients that use this DS. In other words - does
clients' behaviour depend on the type of DS or not, and if yes, then how it is
handled in the protocol.

3) The issue of inability for a client to remove itself from the group by
itself seems unsolvable. I would like to see recommendations in the document
for clients wishing to exclude themselves in situations when other members for
some reasons don't cooperate in this process.

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