Re: [MLS] Zaheduzzaman Sarker's No Objection on draft-ietf-mls-protocol-17: (with COMMENT)

[Richard Barnes <[e-mail]>]

Hi Zahed,

Thanks for the review.  A couple of comments inline below.  I have filed a
PR for these changes:

https://github.com/mlswg/mls-protocol/pull/852

On Wed, Feb 1, 2023 at 6:25 AM Zaheduzzaman Sarker via Datatracker <
[e-mail]> wrote:

> - There is a mismatch between intended status of this spec (PS) and what
> in the
> doc header (Informational). I see Lars already have a discuss on it, so
> supporting it.
>

Yep, this is covered in the PR for Lars's review:
https://github.com/mlswg/mls-protocol/pull/848


> - The specification says the UPDATE messages SHOULD be periodically sent
> and
> expects the applications to decided on the period between UPDATE messages.
> As I
> can see there are multiple implementations, can't we also recommend some
> guidelines and considerations on how to select the period? In some
> discussions
> I saw we were talking about hours and months..
>

Added some text to provide very general guidance, "usually on the order of
hours or days, not milliseconds".


> - it says -
>      " In general, however, applications should take care that they do not
> send
>      MLS messages at a rate that overwhelms the transport over which
> messages
>      are being sent."
>
>    I am not sure I understand what "overwhelms the transport" means. Are we
>    talking about the congestion control or bandwidth estimation part of
>    transport protocols? Usually the application have no or very vague
>    information about the internal protocol states, in that case how the
>    applications are expected to take care of this? are we suggesting some
>    interaction application rate control?
>

No, definitely don't need all that complexity!  I've added some text to
explain that in most cases, MLS will be on top of some transport that does
things like congestion control, so what we need here is mainly a reminder
that if you're *not* using such a transport, it's up to you to manage these
problems.  There's some text in the PR, but suggestions would be very
welcome.

Best,
--Richard