Hi Valery, Thanks for the review ! Just a quick note about the inability of a client to remove itself from a group… This is expected from the protocol security point of view. As a client you can always delete your own state, however to ensure to everyone else that you don’t maliciously retain some secrets, someone honest other than you has to change those secrets. This is why to perform a self remove, a client will have to send a remove proposal that will be acted upon by someone else… : ) Cheers, Benjamin > On 19 Aug 2024, at 14:59, Valery Smyslov via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Valery Smyslov > Review result: Ready > > 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 > comments. > > I previously reviewed the -09, -10 and -13 versions of the draft and now reviewed the diff > between the -13 and the -15 versions. The added text about the ability to reinitialize > the group changing the protocol version and/or ciphersuite addresses my concerns. > > The issue of inability for a client to remove itself from the group by its own > seems unsolvable in the MLS architecture. While I think this issue is important, > I'd leave it on ADs' discretion. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
