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

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

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.

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.

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.

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"

5. -----

   is the timestamp of packet 102 THAT was received.  So B1 does not

FP: nit - all capitals THAT.

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?

7. -----

    |                                              | |
    |(mix)[Bob)] Bob as well.                       | |

FP: one space character too much