RTP-Mixer Formatting of Multiparty Real-Time Text
RFC 9071

Received changes through RFC Editor sync (created alias RFC 9071, changed title to 'RTP-Mixer Formatting of Multiparty Real-Time Text', changed abstract to 'This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time Transport Protocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions.

Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP-mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations.

A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".

This document updates RFC 4103 ("RTP Payload for Text Conversation").

A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided.', changed pages to 35, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-07-06, changed IESG state to RFC Published, created updates relation between draft-ietf-avtcore-multi-party-rtt-mix and RFC 4103)

[Ballot comment]
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

[Ballot discuss]
I'm not sure I understand how the examples are consistent with the main
specification, so let's please discuss it to either un-confuse me or fix
the document.

Section 3.9 seems to say that the oldest (source or redundant) text at
the mixer takes priority when there is text from more than one source
waiting to be sent, but the examples in Section 3.21 seem to show (e.g.)
text received from A at time 20400 that is to be sent as redundancy,
being sent after text from B received at time 20500 (sent as primary).
Is the intent that if there is any primary text, the oldest primary text
is sent first, and only if there is no outstanding primary text do we
consider the redundant text?

In a related vein, Section 3.10 says that a packet is sent when (among
other things) "330 ms has passed since already transmitted text was
queued for transmission as redundant text".  But that doesn't say
anything about the timer being reset by subsequent transmission or
queuing of redundant text, so I'm not sure how in the Section 3.21
example, we say that transmitting B1 and B2 as redundancy was planned as
330 ms after packet 105 -- the original B2 was sent in packet 104, so
shouldn't the 330ms start from packet 104's transmission?  (The stated
time for this seems to match 330ms after 104, so maybe the "105" is just
a typo?)


I also left a note in the comment that there's a remark about "lower
security level" in Section 3.19 that's not really accurate; we should
resolve that in some manner before the document proceeds.

[Ballot comment]
The abstract is perhaps pushing the boundary of length reasonable for an
abstract.

There were a couple interesting remarks in the shepherd writeup:

% The specification has not been implemented yet, so it is possible that
% issues could arise in implementation. This is more of a concern than
% for typical AVTCORE documents, since this specification is likely to
% become a regulatory requirement prior to advancing beyond Proposed
% Standard.

Are there still no implementations?  Are we happy with publishign the
specification at this time in the absence of implementations?

% During review, the question was raised as to whether the specification
% will require development of an RTT mixer, or whether it could be made
% compatible with existing conferencing servers implementing Selective
% Forwarding.

What was the outcome of the discussion?  Should that be reflected in the
document?

Abstract

  mixer model.  The possibility to implement the solution in a wide
  range of existing RTP implementations made the RTP-mixer model be
  selected to be fully specified in this document.

It's a little surprising to see this claim given the absence (per the
shepherd writeup) of any actual implementations.

Section 1.2

  Multiple sources per packet
      A new "text" media subtype would be specified with up to 15
      sources in each packet.  The mechanism would make use of the RTP
      mixer model specified in RTP [RFC3550].  Text from up to 15
      sources can be included in each packet.  [...]

(How was the "15" number determined?)

Section 2.3.2

  A party receiving an offer containing the "rtt-mixer" SDP attribute
  and being willing to use the RTP-mixer-based method of this
  specification for sending or receiving or both sending and receiving
  SHALL include the "rtt-mixer" SDP attribute in the corresponding
  "text" media section in the answer.

This requirement doesn't quite seem to match up with what I expect -- an
answerer that's willing to use rtt-mixer and also willing to use
something else seems to still be bound by the "SHALL include" in the
first paragraph, which makes the willingness to use something else a bit
irrelevant and precludes choosing the other option.  Perhaps we want to
say only "chooses to use the RTP-mixer-based method of this
specification"?

Section 3.2

What purpose does the initial BOM serve?  I note that, e.g., RFC 5198
has an explicit BOM "MUST NOT appear at the beginning of these text
strings" and that RFC 4103 specifies UTF-8 encoding of the text.
I see in Section 3.17.4 (and 4.2.1) we mention that it might be used for
keepalive, but in rtt-mix don't we have lots of non-BOM keepalive
options?

Section 3.4

  If the "CPS" value is reached, longer transmission intervals SHALL be
  applied and only as much of the text queued for transmission SHALL be
  sent at the end of each transmission interval that can be allowed
  without exceeding the "CPS" value, until the transmission rate falls
  under the "CPS" value again.  [...]

This doesn't seem as precisely specified as it could be, given that the
CPS rate is supposed to be enforced over "any 10-second interval".  As
written, this seems to suggest that the entire 10-second history of
packet size/spacing needs to be retained, so that at each transmission
the earliest time for next transmission can be computed that retains the
CPS limit.  It's not clear that there's real need for such a complicated
solution vs something that more bluntly backs off the transmit rate and
uses bucketed averages for tracking the transmission rate.

(I have no idea why it's 330ms for a mixer and 300ms for a non-mixer,
but assume there is some reason for the difference.)

Section 3.6

  Text received by a mixer from a participant SHOULD NOT be included in
  transmission from the mixer to that participant, because the normal
  behavior of the endpoint is to present locally-produced text locally.

When would the SHOULD NOT be ignored?  (How might a mixer know that the
other endpoint is not using the "normal behavior" of presenting
locally-produced text locally?)

Section 3.7

  A mixer SHALL handle reception, recovery from packet loss, deletion
  of superfluous redundancy, marking of possible text loss and deletion
  of 'BOM' characters from each participant before queueing received
  text for transmission to receiving participants.

Are there specific references available for each of these operations?

Section 3.9

  The source with the oldest text received in the mixer or oldest
  redundant text SHALL be next in turn to get all its available unsent
  text transmitted.  Any redundant repetitions of earlier transmitted

Just to confirm: this is really *all* its available unsent text, not
just however much will fit in one packet/flight/etc.?  Can a participant
"hog the mic" by continuing to append to that list even as transmission
has commenced?

Section 3.13

It took me a bit of searching to realize that it is RFC 2198 that
specifies the additional header that includes the "timestamp offset"
field.  A specific reference here (or maybe from an earlier section?)
would have helped me out.

Section 3.14

  The SSRC of the mixer for the RTT session SHALL be inserted in the
  SSRC field of the RTP header.

As written, this could be taken to say that the non-mixer endpoint
should also use the SSRC of the mixer.

Section 3.16

  Confidentiality SHALL be considered when composing these fields.

I think "privacy considerations" would be more relevant than
"confidentiality".

  Similar considerations SHALL be taken as for other media.

This seems rather vague and it's not really clear how the implementor is
supposed to take action based on it.  (Note that media are typically
straight over (S)RTP, but these reports are (S)RTCP, which admittedly is
also over (S)RTP, but is still different.)

Section 3.17.2

  If it is known that only one source is active in the RTP session,
  then it is likely that a gap equal to or larger than the agreed
  number of redundancy generations (including the primary) causes text
  loss.  [...]

Some more care in description may be needed here, as the gap in RTP
sequence numbers is measured in the RTP sequence units (e.g., time), but
the redundancy generation number is just a dimensionless generation
count.  We need to assume the max inter-packet spacing in order to
convert that into a time value that is suitable for assuming loss.

  evaluate if three or more packets were lost within one second.  If
  this simple method is used, then a t140block SHOULD be created with a
  marker for possible text loss [T140ad1] and associated with the SSRC
  of the transmitter as a general input from the mixer.

Does "input from the mixer" mean that it uses the mixer's SSRC value?
Or is this injected by the mixer (in contrast to the previous paragraph,
where it was the receiver that injects the marker for possible text
loss)?

Section 3.17.3

  If the packet is not the first packet from a source, then if the
  second generation redundant data is available, its timestamp SHALL be
  created by subtracting its timestamp offset from the RTP timestamp.
  If the resulting timestamp is later than the latest retrieved data
  from the same source, then the redundant data SHALL be retrieved and
  appended to the receive buffer.  The process SHALL be continued in
  the same way for the first generation redundant data.  After that,
  the primary data SHALL be retrieved from the packet and appended to
  the receive buffer for the source.

I think I can come up with reordering scenarios that cause this
procedure to discard data that would otherwise have recovered from loss.

Also, this procedure as written says that the primary data shall always
be appended to the receive buffer (with no time check), which could
result in doubled content in the case of reordering.

Section 3.19

  Security SHOULD be applied when possible regarding the capabilities
  of the participating devices by use of SIP over TLS by default

"Security" is not some all-encompassing attribute that can be
generically applied; there are specific security properties that may or
may not be achieved by any given mechanism, and it's generally worth
being precise about what properties are (or are not) achieved.  So here
we might say "security mechanisms to provide confidentiality and
integrity protection and peer authentication SHOULD be applied".  We
cannot in general achieve source authenticity with just SRTP when a
mixer is involved, though RFC 8723 does specify a double-encryption
mechanism that applies in some cases when there is a central media
distributor.

                                                            In
  applications where legacy endpoints without security may exist, a
  negotiation SHOULD be performed to decide if encryption on the media
  level will be applied.  [...]

How would endpoints know if legacy endpoints might exist?

How would this negotiation be performed?

  security levels.  The mixing for conference-unaware endpoints has
  lower security level than the mixing method for conference-aware
  endpoints, because there may be an opportunity for a malicious mixer
  or a middleman to masquerade the source labels accompanying the text
  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
  endpoints as specified here also requires that the mixer can be
  trusted.  [...]

As the last sentence indicates, the provided reasoning in the first
sentence is not really accurate, since the mixer could just as easily
adjust the CSRC value in the header as change the label in the in-band
text stream.  This does not inherently invalidate the claim that there
are different security levels, though, as the correct behavior of the
mixer seems easier to independently validate in the conference-aware
endpoint case (with the well-formed RTP payloads providing information
that can be validated out-of-band with other participants).  But I don't
think this description should be left in the document as-is; it doesn't
seem accurate.

In the case of unencrypted media, it does seem technically true that it
is easier for a non-mixer middleman to masquerade the source labels,
since in that case it only adjusts the payload directly without needing
to keep state on the RTP sender information and produce well-formed RTP
headers after its adjustment.  But this is only a modest level of
additional difficulty and does not reflect any kind of effective
security control, so it may not be worth mentioning at all.

  End-to-end encryption would require further work and could be based
  on WebRTC as specified in Section 1.2.

Is RFC 8723 not applicable to these scenarios at all?  I do not think it
is WebRTC-specific.

Section 3.21

          Transmission of A2 and A3 as redundancy is planned for 330 ms
  after packet 101 if no new text from A is ready to be sent before
  that.

I thought new text from *anyone* would trigger sending A2 and A3 as
redundancy, per §3.9.


Is there any reason why the dummy offsets in 104 are 300/600 but the
dummy offsets in 103 are 330/660?

Section 4.2

              In order to expedite source switching, a user can, for
  example, end its turn with a new line.

How would a user know that there is a legacy endpoint in the coversation
so as to choose to end its turn in this way?

Section 4.2.2

  *  A long pause (e.g., > 10 seconds) in received text from the
      currently transmitted source

  *  If text from one participant has been transmitted with text from
      other sources waiting for transmission for a long time (e.g., > 1
      minute) and none of the other suitable points for switching has

I think I'm confused how we could hit the 1 minute timer before the 10
seconds timer has triggered.

Section 11

I think that the obvious attacks involving control characters are
addressed in one way or another, but it might be worth a reminder to
implementors that control characters should not be allowed to let one
user's content affect the display of other users' content, or the
presentation-format's label of the sender, etc.

It might be appropriate to have yet another reminder here that SRTP is
the recommended mode of operation.

  The requirement to transfer information about the user in RTCP
  reports in SDES, CNAME, and NAME fields, and in conference
  notifications, for creation of labels may have privacy concerns as
  already stated in RFC 3550 [RFC3550], [...]

Could you point me to where this is stated in RFC 3550?  I looked in the
security considerations (section 14) and searched for all instances of
"CNAME", but didn't see discussion about SDES/CNAME/NAME being privacy
sensitive.

Section 13.1

RFC 8825 is not currently referenced in any context that specifically
requires it to be listed as a normative reference.  This may suggest
that it should be referenced in more places (e.g., in the discussion of
gateway considerations with WebRTC).

NITS

Section 1

  Use of RTT is increasing, and specifically, use in emergency calls is
  increasing.  Emergency call use requires multiparty mixing.  [...]

I expect the conclusion that emergency-call use requires mixing to be
non-intuitive to many readers, so additional explanation might be
helpful.

                                                                RFC 4103
  "RTP Payload for Text Conversation" mixer implementations can use
  traditional RTP functions for source identification, but the

The word "mixer" (or even "mix") does not appear in RFC 4103, so I'm not
sure how to interpret "RFC 4103 mixer implementations".  Perhaps it is
an RFC 3550 mixer acting on RFC 4103 payloads?

  The document updates [RFC4103] by introducing an attribute for
  indicating capability for the RTP-mixer-based multiparty mixing case
  and rules for source indications and interleaving of text from
  different sources.

I think "indicating capability for the RTP-mixer-based multiparty mixing
case" needs another verb.

Section 2.2

  A party acting as a mixer, which has not negotiated any method for
  true multiparty RTT handling, but negotiated a "text/red" or "text/
  t140" format in a session with a participant SHOULD in order to
  maintain interoperability, if nothing else is specified for the
  application, format transmitted text to that participant to be
  suitable to present on a multiparty-unaware endpoint as further
  specified in Section 4.2.

comma after "SHOULD".
The whole sentence is a bit long, though, and the parenthetical "if
nothing else is specified for the application" is somewhat in the way in
its current location.  Further reworking may be in order.

I'd also consider s/format transmitted text/transmit formatted text/ or
/format text transmitted/.

Section 2.3.4

  If the modified offer deletes indication of support for multiparty
  real-time text by excluding the "rtt-mixer" SDP attribute, the answer
  MUST NOT contain the "rtt-mixer" attribute, and both parties SHALL
  after processing the SDP exchange NOT send real-time text formatted
  for multiparty-aware parties according to this specification.

The BCP 14 keyword "SHALL NOT" is supposed to appear as the specific
phrase, so something like "SHALL NOT, after processing the SDP exchange,
send" seems more appropriate.

Section 3.4

  transmission MUST then be made at T140block borders.  See also
  Section 8

full stop at end of sentence.

Section 3.10

  The mixer SHALL compose and transmit an RTP packet to a receiver when
  one of the following conditions has occurred:

Maybe "one or more" (or "one or both")?

Section 3.16

  Confidentiality SHALL be considered when composing these fields.
  They contain name and address information that may be sensitive to
  transmit in its entirety e.g., to unauthenticated participants.

comma before "e.g." (as well as after)

Section 3.17

  presentation areas for each source.  Other receiver roles, such as
  gateways or chained mixers are also feasible, and requires
  consideration if the stream shall just be forwarded, or distributed

"such as gateways or chained mixers" seems like a parenthetical phrase
that should be offset by commas on both sides.

Also, "require consideration" seems to match up better with the plural
"roles".

Section 3.17.3

  When a packet is received in an RTP session using the packetization
  for multiparty-aware endpoints, its T140blocks SHALL be extracted in
  the following way.  The description is adapted to the default
  redundancy case using the original and two redundant generations.

Is this supposed to imply that the extension to the generic case with
other levels of redundancy is trivial for the reader to perform?

Section 3.18

  This solution has good performance with low text delays as long as
  the sum of characters per second during any 10-second interval sent
  from a number of simultaneously sending participants to a receiving
  participant does not reach the 'CPS' value.  [...]

"sum of characters per second during any 10-second interval" seems to
mean "compute CPS for each second, then add them up".  I don't think
that's the intended meaning.

                                  Only in large unmanaged conferences
  with a high number of participants there may on very rare occasions
  appear situations when many participants happen to send text
  simultaneously, resulting in unpleasantly jerky presentation of text
  from each sending participant.  [...]

This sentence seems a bit long and winding.

Section 3.20

      Offer example for "text/red" format including multiparty
      and security:
            a=fingerprint: (fingerprint1)

I think it would be preferred to make up some random fingerprints and
use them instead of the placeholder string (throughout).

Section 3.21

  offset 660 ms.  The timestamp of packet 106 minus 660 is 20500 which
  is the timestamp of packet 102 THAT was received.  So B1 does not

I don't see why "THAT" needs to be in all majuscule letters.

Section 3.22

  to transmission to a receiver.  The value MAY be modified in the
  "CPS" parameter of the FMTP attribute in the media section for the
  "text/t140" media.  [...]

RFC 4103 seems to show the lowercase "cps" parameter name (there are
subsequent occurrences that I do not quote).

Section 4.2

  one presentation area.  The mixer SHALL group text in suitable groups
  and prepare for presentation of them by inserting a new line between
  them if the transmitted text did not already end with a new line.  A

Is "new line" specified somewhere?  Up in toplevel §4 we cover the
unicode line separator and CRLF sequences but don't use the phrase "new
line".

Section 4.2.2

  Information available to the mixer for composing the label may
  contain sensitive personal information that SHOULD not be revealed in

"SHOULD NOT" in all caps

  sessions not securely authenticated and protected.  Integrity

"confidentiality protected"

  considerations regarding how much personal information is included in
  the label SHOULD therefore be taken when composing the label.

I don't think "integrity" is the right word here.

Section 11

  Therefore, the mixer needs to be trusted to achieve security in
  confidentiality and integrity.  [...]

s/trusted to achieve security in confidentiality and integrity/trusted
to maintain confidentiality and integrity of the RTT data/

  The requirement to transfer information about the user in RTCP
  reports in SDES, CNAME, and NAME fields, and in conference
  notifications, for creation of labels may have privacy concerns as

There's something awry with the commas around "for creation of labels".

[Ballot comment]
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?

[Ballot 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

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

[Ballot comment]
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"?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-avtcore-multi-party-rtt-mix-16. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the attribute-name (formerly "att-field") registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

a new registration will be made as follows:

Type: attribute
SDP Name: rtt-mixer
Usage Level: media
Mux Category: normal
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

Expert comments:

I took a look at it, and the registration is generally good, however I find the offer/answer procedures lacking in clarity and would like to see a bit more explicit text around those in Section 2.3, which currently simply states:

Both parties SHALL indicate their capability in a session setup or
modification, and evaluate the capability of the counterpart.


The text should more explicitly cover the procedures around the initial offer, initial answer, offerer processing of the initial answer and then modifying the session. I can sort of guess what the intent is, but it should be stated explicitly in the document.

The following Last Call announcement was sent out (ends 2021-05-03):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RTP-mixer formatting of multi-party Real-time text) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document: - 'RTP-mixer
formatting of multi-party Real-time text'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-05-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Enhancements for RFC 4103 real-time text mixing are provided in this
  document, suitable for a centralized conference model that enables
  source identification and rapidly interleaved transmission of text
  from different sources.  The intended use is for real-time text
  mixers and participant endpoints capable of providing an efficient
  presentation or other treatment of a multi-party real-time text
  session.  The specified mechanism builds on the standard use of the
  CSRC list in the RTP packet for source identification.  The method
  makes use of the same "text/t140" and "text/red" formats as for two-
  party sessions.

  Solutions using multiple RTP streams in the same RTP session are
  briefly mentioned, as they could have some benefits over the RTP-
  mixer model.  The possibility to implement the solution in a wide
  range of existing RTP implementations made the RTP-mixer model be
  selected to be fully specified in this document.

  A capability exchange is specified so that it can be verified that a
  mixer and a participant can handle the multi-party coded real-time
  text stream using the RTP-mixer method.  The capability is indicated
  by use of an SDP media attribute "rtt-mixer".

  The document updates RFC 4103 "RTP Payload for Text Conversation".

  A specification of how a mixer can format text for the case when the
  endpoint is not multi-party aware is also provided.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/



No IPR declarations have been submitted directly on this I-D.

Request for Publication
Document: RTP-mixer formatting of multi-party Real-time text
Link: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-13.txt
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Emergency call use of RFC 4103 "RTP Payload for Text Conversation"
  requires multi-party mixing.  Real-time text mixers for multi-party
  sessions need to identify the source of each transmitted group of
  text so that the text can be presented by endpoints in suitable
  grouping with other text from the same source, while new text from
  other sources is also presented in readable grouping as received
  interleaved in real-time.

  Enhancements for RFC 4103 real-time text mixing are provided in this
  document, suitable for a centralized conference model that enables
  source identification and rapidly interleaved transmission of text
  from different sources.  The intended use is for real-time text
  mixers and participant endpoints capable of providing an efficient
  presentation or other treatment of a multi-party real-time text
  session.  The specified mechanism builds on the standard use of the
  CSRC list in the RTP packet for source identification.  The method
  makes use of the same "text/t140" and "text/red" formats as for two-
  party sessions.

Working Group Summary:

WG Last Call of "RTP-mixer formatting of multi-party Real-time text" was
announced on November 25, 2020:
https://mailarchive.ietf.org/arch/msg/avt/tjGlWlXL5a54nhgl5nRV3jkD_tk/

WGLC concluded on December 9, 2020.

Of the 6 participants responding to the WGLC, 3 supported Advancement to
Proposed Standard, and 3 respondents provided comments, which were addressed
by the author.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd is Bernard Aboba. Responsible AD is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document and provided comments here:
https://mailarchive.ietf.org/arch/msg/avt/WJ5Yb5Qm-LrQXcIYxaOeLZD1i-c/

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The specification has not been implemented yet, so it is possible that issues could arise in implementation. This is more of a concern than for typical AVTCORE documents, since this specification is likely to become a regulatory requirement prior to advancing beyond Proposed Standard.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document does not raise any unique security, AAA, DNS, DHCP, XML or internationalization issues.
Since there are no implementations yet, it is possible that operational complexity concerns will arise that have not been forseen.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

During review, the question was raised as to whether the specification will require development of an RTT mixer, or whether it could be made compatible with existing conferencing servers implementing Selective Forwarding.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-multi-party-rtt-mix

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document has been reviewed by people knowledgeable about emergency services and the role of Realtime Text within those services.
It has also had some review from implementers of general communication services.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No appeal threats or extreme discontent expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits run on -13 shows no errors:

idnits 2.16.05


tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt:
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1351): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1353): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1355): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1358): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1361): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1363): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1365): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1368): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1689): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1691): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1694): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1697): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1698): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1707): Unexpected reference format: '...    |[Ali...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1714): Unexpected reference format: '...    |[Ali...'

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC4103, updated by this document, for
    RFC5378 checks: 2004-06-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

    IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
        This document may contain material from IETF Documents or IETF
        Contributions published or made publicly available before
        November 10, 2008.  The person(s) controlling the copyright in
        some of this material may not have granted the IETF Trust the
        right to allow modifications of such material outside the IETF
        Standards Process. Without obtaining an adequate license from the
        person(s) controlling the copyright in such materials, this
        document may not be modified outside the IETF Standards Process,
        and derivative works of it may not be created outside the IETF
        Standards Process, except to format it for publication as an RFC
        or to translate it into languages other than English.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140ad1'


    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document contains no MIBs or YANG modules and does not define media or URI types.
Section 3.20 does contain Offer/Answer examples which may benefit from review by the SDP Directorate.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is a normative reference to draft-ietf-mmusic-t140-usage-data-channel which should be updated to RFC 8865.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are references to non-IETF specifications (T.140), but no down references to IETF specifications.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Section 10.1 of the document requests registration of the "rtt-mixer" sdp media attribute.  There are no other IANA actions requested.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.

Draft Request for Publication
Document: RTP-mixer formatting of multi-party Real-time text
Link: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-13.txt
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Emergency call use of RFC 4103 "RTP Payload for Text Conversation"
  requires multi-party mixing.  Real-time text mixers for multi-party
  sessions need to identify the source of each transmitted group of
  text so that the text can be presented by endpoints in suitable
  grouping with other text from the same source, while new text from
  other sources is also presented in readable grouping as received
  interleaved in real-time.

  Enhancements for RFC 4103 real-time text mixing are provided in this
  document, suitable for a centralized conference model that enables
  source identification and rapidly interleaved transmission of text
  from different sources.  The intended use is for real-time text
  mixers and participant endpoints capable of providing an efficient
  presentation or other treatment of a multi-party real-time text
  session.  The specified mechanism builds on the standard use of the
  CSRC list in the RTP packet for source identification.  The method
  makes use of the same "text/t140" and "text/red" formats as for two-
  party sessions.

Working Group Summary:

WG Last Call of "RTP-mixer formatting of multi-party Real-time text" was
announced on November 25, 2020:
https://mailarchive.ietf.org/arch/msg/avt/tjGlWlXL5a54nhgl5nRV3jkD_tk/

WGLC concluded on December 9, 2020.

Of the 6 participants responding to the WGLC, 3 supported Advancement to
Proposed Standard, and 3 respondents provided comments, which were addressed
by the author.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd is Bernard Aboba. Responsible AD is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document and provided comments here:
https://mailarchive.ietf.org/arch/msg/avt/WJ5Yb5Qm-LrQXcIYxaOeLZD1i-c/

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The specification has not been implemented yet, so it is possible that issues could arise in implementation. This is more of a concern than for typical AVTCORE documents, since this specification is likely to become a regulatory requirement prior to advancing beyond Proposed Standard.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document does not raise any unique security, AAA, DNS, DHCP, XML or internationalization issues.
Since there are no implementations yet, it is possible that operational complexity concerns will arise that have not been forseen.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

During review, the question was raised as to whether the specification will require development of an RTT mixer, or whether it could be made compatible with existing conferencing servers implementing Selective Forwarding.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-multi-party-rtt-mix

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document has been reviewed by people knowledgeable about emergency services and the role of Realtime Text within those services.
It has also had some review from implementers of general communication services.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No appeal threats or extreme discontent expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits run on -13 shows no errors:

idnits 2.16.05


tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt:
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1351): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1353): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1355): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1358): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1361): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1363): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1365): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1368): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1689): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1691): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1694): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1697): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1698): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1707): Unexpected reference format: '...    |[Ali...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1714): Unexpected reference format: '...    |[Ali...'

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC4103, updated by this document, for
    RFC5378 checks: 2004-06-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

    IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
        This document may contain material from IETF Documents or IETF
        Contributions published or made publicly available before
        November 10, 2008.  The person(s) controlling the copyright in
        some of this material may not have granted the IETF Trust the
        right to allow modifications of such material outside the IETF
        Standards Process. Without obtaining an adequate license from the
        person(s) controlling the copyright in such materials, this
        document may not be modified outside the IETF Standards Process,
        and derivative works of it may not be created outside the IETF
        Standards Process, except to format it for publication as an RFC
        or to translate it into languages other than English.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140ad1'


    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document contains no MIBs or YANG modules and does not define media or URI types.
Section 3.20 does contain Offer/Answer examples which may benefit from review by the SDP Directorate.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is a normative reference to draft-ietf-mmusic-t140-usage-data-channel which should be updated to RFC 8865.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are references to non-IETF specifications (T.140), but no down references to IETF specifications.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Section 10.1 of the document requests registration of the "rtt-mixer" sdp media attribute.  There are no other IANA actions requested.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.

Draft Request for Publication
Document: RTP-mixer formatting of multi-party Real-time text
Link: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-13.txt
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Emergency call use of RFC 4103 "RTP Payload for Text Conversation"
  requires multi-party mixing.  Real-time text mixers for multi-party
  sessions need to identify the source of each transmitted group of
  text so that the text can be presented by endpoints in suitable
  grouping with other text from the same source, while new text from
  other sources is also presented in readable grouping as received
  interleaved in real-time.

  Enhancements for RFC 4103 real-time text mixing are provided in this
  document, suitable for a centralized conference model that enables
  source identification and rapidly interleaved transmission of text
  from different sources.  The intended use is for real-time text
  mixers and participant endpoints capable of providing an efficient
  presentation or other treatment of a multi-party real-time text
  session.  The specified mechanism builds on the standard use of the
  CSRC list in the RTP packet for source identification.  The method
  makes use of the same "text/t140" and "text/red" formats as for two-
  party sessions.

Working Group Summary:

WG Last Call of "RTP-mixer formatting of multi-party Real-time text" was
announced on November 25, 2020:
https://mailarchive.ietf.org/arch/msg/avt/tjGlWlXL5a54nhgl5nRV3jkD_tk/

WGLC concluded on December 9, 2020.

Of the 6 participants responding to the WGLC, 3 supported Advancement to
Proposed Standard, and 3 respondents provided comments, which were addressed
by the author.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are no existing implementations of the specification. 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd is Bernard Aboba. Responsible AD is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document and provided comments here:
https://mailarchive.ietf.org/arch/msg/avt/WJ5Yb5Qm-LrQXcIYxaOeLZD1i-c/

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The specification has not been implemented yet, so it is possible that issues could arise in implementation. This is more of a concern than for typical AVTCORE documents, since this specification is likely to become a regulatory requirement prior to advancing beyond Proposed Standard.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document does not raise any unique security, AAA, DNS, DHCP, XML or internationalization issues.
Since there are no implementations yet, it is possible that operational complexity concerns will arise that have not been forseen.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

During review, the question was raised as to whether the specification will require development of an RTT mixer, or whether it could be made compatible with existing conferencing servers implementing Selective Forwarding.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-multi-party-rtt-mix

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document has been reviewed by people knowledgeable about emergency services and the role of Realtime Text within those services.
It has also had some review from implementers of general communication services.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No appeal threats or extreme discontent expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDnits run on -13 shows no errors:

idnits 2.16.05


tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt:
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1351): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1353): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1355): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1358): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1361): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1363): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1365): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1368): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1689): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1691): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1694): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1697): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1698): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1707): Unexpected reference format: '...    |[Ali...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-13.txt(1714): Unexpected reference format: '...    |[Ali...'

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC4103, updated by this document, for
    RFC5378 checks: 2004-06-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

    IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
        This document may contain material from IETF Documents or IETF
        Contributions published or made publicly available before
        November 10, 2008.  The person(s) controlling the copyright in
        some of this material may not have granted the IETF Trust the
        right to allow modifications of such material outside the IETF
        Standards Process. Without obtaining an adequate license from the
        person(s) controlling the copyright in such materials, this
        document may not be modified outside the IETF Standards Process,
        and derivative works of it may not be created outside the IETF
        Standards Process, except to format it for publication as an RFC
        or to translate it into languages other than English.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140ad1'


    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document contains no MIBs or YANG modules and does not define media or URI types.
Section 3.20 does contain Offer/Answer examples which may benefit from review by the SDP Directorate.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is a normative reference to draft-ietf-mmusic-t140-usage-data-channel which should be updated to RFC 8865.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are references to non-IETF specifications (T.140), but no down references to IETF specifications.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Section 10.1 of the document requests registration of the "rtt-mixer" sdp media attribute.  There are no other IANA actions requested.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.

Draft publication request (not yet ready for IESG action)

Document: RTP-mixer formatting of multi-party Real-time text
Link: https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Emergency call use of RFC 4103 "RTP Payload for Text Conversation"
  requires multi-party mixing.  Real-time text mixers for multi-party
  sessions need to identify the source of each transmitted group of
  text so that the text can be presented by endpoints in suitable
  grouping with other text from the same source, while new text from
  other sources is also presented in readable grouping as received
  interleaved in real-time.

  Enhancements for RFC 4103 real-time text mixing are provided in this
  document, suitable for a centralized conference model that enables
  source identification and rapidly interleaved transmission of text
  from different sources.  The intended use is for real-time text
  mixers and participant endpoints capable of providing an efficient
  presentation or other treatment of a multi-party real-time text
  session.  The specified mechanism builds on the standard use of the
  CSRC list in the RTP packet for source identification.  The method
  makes use of the same "text/t140" and "text/red" formats as for two-
  party sessions.

Working Group Summary:

WG Last Call of "RTP-mixer formatting of multi-party Real-time text" was
announced on November 25, 2020:
https://mailarchive.ietf.org/arch/msg/avt/tjGlWlXL5a54nhgl5nRV3jkD_tk/

WGLC concluded on December 9, 2020.

Of the 6 participants responding to the WGLC, 3 supported Advancement to
Proposed Standard, and 3 respondents provided comments, which were addressed
by the author.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

As far as I know, there are no existing implementations of the specification. 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd is Bernard Aboba. Responsible AD is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document and provided comments here:
https://mailarchive.ietf.org/arch/msg/avt/WJ5Yb5Qm-LrQXcIYxaOeLZD1i-c/

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

As far as I know, the specification has not been implemented yet, so it is possible that issues could arise in implementation. This is more of a concern than for typical AVTCORE documents, since this specification is likely to become a regulatory requirement prior to advancing beyond Proposed Standard.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The SDP section of the document needs to be reviewed by the SDP Directorate.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

During review, the question was raised as to whether the specification will require development of an RTT mixer, or whether it could be made compatible with
existing conferencing servers implementing Selective Forwarding.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-multi-party-rtt-mix

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document has been reviewed by people knowledgeable about emergency services and the role of Realtime Text within those services.
It has also had some review from implementers of general communication services.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No appeal threats or extreme discontent expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are some ID nits. See run below:


idnits 2.16.05


tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt:
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1351): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1353): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1355): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1358): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1361): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1363): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1365): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1368): Unexpected reference format: '...        ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1689): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1691): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1694): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1697): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1698): Unexpected reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1707): Unexpected reference format: '...    |[Ali...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1711): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1714): Unexpected reference format: '...    |[Ali...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1719): Unexpected reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1721): Unexpected reference format: '...    |[Eve...'


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

    (Using the creation date from RFC4103, updated by this document, for
    RFC5378 checks: 2004-06-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

    IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
        This document may contain material from IETF Documents or IETF
        Contributions published or made publicly available before
        November 10, 2008.  The person(s) controlling the copyright in
        some of this material may not have granted the IETF Trust the
        right to allow modifications of such material outside the IETF
        Standards Process. Without obtaining an adequate license from the
        person(s) controlling the copyright in such materials, this
        document may not be modified outside the IETF Standards Process,
        and derivative works of it may not be created outside the IETF
        Standards Process, except to format it for publication as an RFC
        or to translate it into languages other than English.

  -- The document date (15 December 2020) is 56 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'Bob' is mentioned on line 1427, but not
    defined
'|[mix][Bob] And I on Wednesday evening.        | |...'

  == Outdated reference: draft-ietf-mmusic-t140-usage-data-channel has been
    published as RFC 8865

  ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140ad1'


    Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not require review from the above (no MIBs, YANG, media type requests, etc.)

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is a normative reference to draft-ietf-mmusic-t140-usage-data-channel which should be updated to RFC 8865.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downward references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Section 10.1 of the document requests Registration of the "rtt-mixer" sdp media attribute.  There are no other IANA actions requested.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.