[MLS] Francesca Palombini's No Objection on draft-ietf-mls-architecture-10: (with COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

Francesca Palombini has entered the following ballot position for
draft-ietf-mls-architecture-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this document.

Many thanks to Valery Smyslov for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/uoBsyBurn4jzZu_AGqADSa-Jpx0/, also
reported below.

I have only had time to scan the document and haven't found any ART issues with
it. However, I hope Valery's review can be addressed before the document is
moved forward.

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.