Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT)

[Martin Duke <[e-mail]>]

LGTM

On Mon, May 17, 2021 at 2:29 PM Gunnar Hellström <
[e-mail]> wrote:

> The new version mentioned in a recent mail answering the comments by
> both Martin Duke and Lars Eggert is available.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-18.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-18
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Regards
> Gunnar
>
> Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker:
> > Martin Duke has entered the following ballot position for
> > draft-ietf-avtcore-multi-party-rtt-mix-17: 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/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > - It is not completely clear to me what the actions in the case of
> congestion
> > are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to
> 500ms. So
> > what is the hiearchy here. My guess is:
> >
> > Step 1. Senders MUST go from 300ms to 2 seconds
> > Step 2. Senders SHOULD (further?) limit the number of characters sent
> > Step 3. Senders SHOULD go from 2 seconds to 5 seconds
> > Step 4. Senders SHOULD exclude nodes from the session
> >
> > Is this correct?
> >
> > - Assuming it is correct, I don't understand the motivation behind the
> > congestion considerations in Section 8.
> >
> > The first and third paragraphs make perfect sense to me. But if the total
> > traffic to a receiver, regardless of the number of senders, remains
> limited to
> > 1 packet / 300ms, I don't see why you would change the RFC 4103 guidance
> of
> > 500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to be
> more
> > conservative, but I would like to understand your reasoning.
> >
> > No need to reply to the comments below:
> >
> > - In (3.16) and (4.2.2), you mention various privacy-sensitive fields
> and then
> > say "Integrity SHALL be considered..." I think you mean confidentiality?
> > Integrity means the data hasn't been altered by an attacker.
> >
> > - It would be helpful to clarify in this draft that the CPS limit
> applies only
> > to new, not redundant, text, assuming that is in fact the case.
> >
> >
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
>
> --
> Gunnar Hellström
> GHAccess
> [e-mail]
>
>