RTP-Mixer Formatting of Multiparty Real-Time Text
draft-ietf-avtcore-multi-party-rtt-mix-20

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

Thank you to Rich Salz for the SECDIR review.

** Section 11.  Per “Participants with malicious intentions may appear ...”, this text seems to be describing an attacker that is party to the call.  If the mitigations suggested in the next sentence (i.e., secure signaling ... and authentication) aren’t present, this style of attack may also be possible by an on-path attacker as might be simple eavesdropping or injection of arbitrary content. 

** Section 11. Would the caution of the mixer not revealing that a user is hearing or speech impaired noted in Section 8 of RFC5194 apply here too?

A big thank you for handling my discuss and comment points.

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 6, nit:
>  packets together with new text. However the redundancy header format has no
>                                  ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 1, paragraph 8, nit:
> g is intended to be done in a general way so that presentation can be arrang
>                                       ^^^
Use a comma before 'so' if it connects two independent clauses (unless they are
closely connected and short).

Section 1.2, paragraph 3, nit:
> e users actually transmit information. Thus an SFM solution would not need to
>                                        ^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 1.3, paragraph 2, nit:
>  between mixers and endpoints in centralised mixing configurations. It is al
>                                  ^^^^^^^^^^^
Do not mix variants of the same word ('centralise' and 'centralize') within a
single text.

Section 2.4, paragraph 3, nit:
> according to Section 3 if it acts as an rtp-mixer and sends multiparty text.
>                                      ^^
Use "a" instead of 'an' if the following word doesn't start with a vowel sound,
e.g. 'a sentence', 'a university'.

Section 3.21, paragraph 7, nit:
> ms. The mixer has A3 redundancy to send but no new text appears from A and
>                                    ^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.2, paragraph 4, nit:
> col elements. They are instead composed from the information in [T140] and a
>                                ^^^^^^^^^^^^^
The usual collocation for "composed" is "of", not "from". Did you mean
"composed of"?

Section 4.2.2, paragraph 4, nit:
> tor or CRLF). A label SHALL be composed from information in the CNAME and NA
>                                ^^^^^^^^^^^^^
The usual collocation for "composed" is "of", not "from". Did you mean
"composed of"?

Section 4.2.4, paragraph 14, nit:
> r MUST NOT transmit more backspaces. Instead it is RECOMMENDED that a letter
>                                      ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 4.2.6, paragraph 3, nit:
>  line separator and inactivity. Therefore the time to switch to present waiti
>                                 ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 4.2.6, paragraph 5, nit:
> se facts make it strongly RECOMMENDED to implement multiparty awareness in RT
>                           ^^^^^^^^^^^^^^^^^^^^^^^^
The verb 'RECOMMENDED' is used with the gerund form: "RECOMMENDED
implementing".

Section 6.2, paragraph 6, nit:
>  users with the label parameter composed from the NAME field in RTCP on the R
>                                 ^^^^^^^^^^^^^
The usual collocation for "composed" is "of", not "from". Did you mean
"composed of"?

Section 11, paragraph 2, nit:
> om the conference participants. Therefore the mixer needs to be trusted to a
>                                 ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 12.10, paragraph 2, nit:
> ext/rex" because of the longer standardization and implementation period it n
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ('standardization' and 'standardisation')
within a single text.

Section 12.11, paragraph 5, nit:
> is a kind of forward error correction.. 12.12. Changes included in draft-ietf
>                                      ^^
Two consecutive dots

Section 12.20, paragraph 5, nit:
>  with low functionality but SHOULD a be implemented in mixers. Presentation
>                                    ^^^^
After 'a', do not use a verb. Make sure that the spelling of 'be' is correct.
If 'be' is the first word in a compound adjective, use a hyphen between the two
words. Note: This error message can occur if you use a verb as a noun, and the
word is not a noun in standard English.

Section 12.20, paragraph 10, nit:
> acket only includes participants who's text is included in one or more text
>                                  ^^^^^^^^^^
Did you mean "whose text"?

- 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.

Hi,

Thanks for this document.  This document is quite a long way from my core knowledge base, so I'm not sure whether there is much that I can really add.  It doesn't seem to have any obvious manageability concerns.

I was initially surprised by the capability exchange mechanism (offer/exchange), in that if both offeror and receiver could support multiple options then it is always the the receiver that decides which to use (by only selecting one).  I think that this is probably fine.  I don't know which parties generally initiate these exchanges, and whether there is ever a case where both offeror and receiver support multiple options where it would be beneficial for the offeror to make the final decision as to which should be used (e.g., when coordinating between more than two devices).

As one minor nit, I would have preferred to see section 1.2, "Selected solution and considered alternatives" as an appendix.  I wasn't convinced that it is core to understanding this document, but I'm happy to leave it to the authors discretion as to whether they should move it, or leave it where it is.

Thanks,
Rob