Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)

[Gunnar Hellström <[e-mail]>]

Francesca,

I am preparing a new version, with actions on your comments.

Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: 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:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document. I have some minor non-blocking
> comments (feel free to take them or leave them), but I'd like some response to
> point 6. about the normative MUST.
>
> Francesca
>
> 1. -----
>
> FP: Please expand acronyms (CSRC, SDP, BOM, PSTN,...) on first use.
[GH] Done
>
> 2. -----
>
>        Since
>        simultaneous typing by more than two parties is very rare, this
>        method can be used successfully with good performance.  Recovery
>
> FP: I had question on this point, i.e. how was it evaluated that simultaneous
> typing by more than two parties is very rare, but that was answered in section
> 1.3 Intended application - so I would suggest adding a forward reference to
> that section in the paragraph quoted above.
[GH] Accepted.
>
> 3. -----
>
>     text stream using the RTP-mixer method.  The capability is indicated
>     by use of an SDP media attribute "rtt-mixer".
>
> FP: Please add a reference to RFC 8866.
[GH] Accepted
>
> 4. -----
>
>     streams in text format.  This is especially true if support of un-
>     encrypted SIP and media is supported because of lack of such support
>     in the target endpoints.  However, the mixing for conference-aware
>
> FP: I have a problem parsing this sentence "... if support ... is supported
> because of lack of such support"
[GH] Simplified wording applied
>
> 5. -----
>
>     is the timestamp of packet 102 THAT was received.  So B1 does not
>
> FP: nit - all capitals THAT.
[GH]Changed to lower case.
> 6. -----
>
>     the stream.  Some of them are optional.  Implementations MUST be able
>     to ignore optional control codes that they do not support.
>
> FP: I am really unsure how this MUST can be verified for interoperability.
> Maybe this does not need to be a BCP 14 MUST?
[GH] Changed as adviced by Spencer Dawkins and agreed by Francesca.
>
> 7. -----
>
>      |                                              | |
>      |(mix)[Bob)] Bob as well.                       | |
>
> FP: one space character too much
[GH] Done

Thanks,

Gunnar

>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[e-mail]