Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams
draft-ietf-avtcore-multiplex-guidelines-12

[Ballot comment]
Thank you for addressing my Discuss point.

A couple things I noticed while reviewing the diff:

Section 3.1's "might not be the choice suitable in another
situation or combination of reasons" seems like it's comparing things of different types.

Section 4.3.1 now has:

  SRTP [RFC3711] as specified uses per SSRC unique keys, however the
  original assumption was a single session master key from which SSRC
  specific RTP and RTCP keys where derived.  However, that assumption
  was proven incorrect, as the application usage and the developed key-
  mamangement mechanisms have chosen many different methods for
  ensuring SSRC unique keys.  The key-management functions have

I didn't try to look at RFC 3711 and see if there was now-believed-to-be-incorrect
text in need of an update or not.  I guess any potential violations of 3711 are
in the "application usage and the developed-key-management techniques" that
we describe, not in this document itself, so there's not really a question of this
document being in conflict with 3711.
Also, nit: s/mamangement/management/

Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still welcome by the authors probably).

[Ballot discuss]
As Mirja maybe already noted, Section 3.4.3 says:

  Section 8.3 of the RTP Specification [RFC3550] recommends using a
  single SSRC space across all RTP sessions for layered coding.  Based
  on the experience so far however, we recommend to use a solution with
  explicit binding between the RTP streams that is agnostic to the used
  SSRC values.  That way, solutions using multiple RTP streams in a

This sounds an awful lot like we're trying to update the recommendations
from RFC 3550, and looks like different text than was discussed in
Mirja's ballot thread.  Let's discuss whether the formal Updates:
mechanism is appropriate here or we should consider rewording.

[Ballot comment]
Abstract, Introduction

Do we consider SRTP to be included in discussion of "RTP"?

Section 1

  from a particular usage of the RTP multiplexing points.  The document
  will provide some guidelines and recommend against some usages as
  being unsuitable, in general or for particular purposes.

If something is unsuitable in general, should the protocol feature be
deprecated/removed?

Section 2.1

  RTP Session Group:  One or more RTP sessions that are used together
      to perform some function.  Examples are multiple RTP sessions used
      to carry different layers of a layered encoding.  In an RTP
      Session Group, CNAMEs are assumed to be valid across all RTP
      sessions, and designate synchronisation contexts that can cross
      RTP sessions; i.e. SSRCs that map to a common CNAME can be assumed
      to have RTCP SR timing information derived from a common clock
      such that they can be synchronised for playout.

I suggest expanding "RTCP SR timing" or providing a definition.

Section 3.1

It seems a little surprising to use simulcast as an example in the
"needed to represent one media source" bullet and then have separate
bullets for simulcast permutations.

  sessions to group the RTP streams.  The choice suitable for one
  reason, might not be the choice suitable for another reason.  The

nit: is it the "reason" or the "situation"/"scenario" that is relevant
here?

Section 3.2

  RTP streams.  Figure 1 outlines the process of demultiplexing
  incoming RTP streams starting already at the socket representing
  reception of one or transport flows, e.g. an UDP destination port.

nit: "one or more"?

I'd consider putting more arrowheads in the downward direction, though
it's unclear if the resultant vertical expansion of the figure is worth
it.

Section 3.2.1

  For RTP session separation within a single endpoint, RTP relies on
  the underlying transport layer, and on the signalling to identify RTP
  sessions in a manner that is meaningful to the application.  A single
  endpoint can have one or more transport flows for the same RTP
  session, and a single RTP session can therefore span multiple
  transport layer flows even if all endpoints use a single transport
  layer flow per endpoint for that RTP session.  The signalling layer

nit: "therefore" seems misplaced; the relevant linkage in the logic
seems to be that there could be one transport flow per endpoint pair
(as we don't require multicast usage).

  Independently if an endpoint has one or more IP addresses, a single

nit: I'm not sure if "independently" is the right conjunctive adverb,
but whatever is used it should have a comma after it.

Section 3.2.2

  Endpoints that are both RTP sender and RTP receiver use the same SSRC
  in both roles.

If I have multiple SSRCs as a sender, do I have freedom to vary amongst
them when acting as an RTP receiver (or RTCP sender)?

  SSRC values are unique across RTP sessions.  For the RTP
  retransmission [RFC4588] case it is recommended to use explicit
  binding of the source RTP stream and the redundancy stream, e.g.
  using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid].

Some indication of whether this recommendation is new in this document
or "long-standing" might be worthwhile.

  Note that RTP sequence number and RTP timestamp are scoped by the
  SSRC and thus specific per RTP stream.

And now I wonder about the behavior of these two in the retransmission
case from the previous paragraph.  But that's likely off-topic for this
document :)

  An endpoint that generates more than one media type, e.g.  a
  conference participant sending both audio and video, need not (and,
  indeed, should not) use the same SSRC value across RTP sessions.

I'm not sure I understand why the guidance on cross-session behavior is
specific to the multi-media-type case.

  RTCP compound packets containing the CNAME SDES item is the
  designated method to bind an SSRC to a CNAME, effectively cross-
  correlating SSRCs within and between RTP Sessions as coming from the
  same endpoint.  The main property attributed to SSRCs associated with
  the same CNAME is that they are from a particular synchronisation
  context and can be synchronised at playback.

I am curious (but not necessarily needing to see in this document) where
the security considerations regarding CNAME spoofing (where an attacker
claims the CNAME of an existing source to attempt to be treated as part
of the victim's output) are discussed.

Section 3.2.4

  The RTP payload type is scoped by the sending endpoint within an RTP
  session.  PT has the same meaning across all RTP streams in an RTP
  session.  All SSRCs sent from a single endpoint share the same

I'd suggest "same meaning across all RTP streams from that sender",
though given the previous (and next!) sentence it is probably not
strictly necessary.

Section 3.3

  o  Does my communication peer support RTP as defined with multiple
      SSRCs per RTP session?

There's potentially some ambiguity about grouping/binding in this text.

  gateway, for example a need to monitor the RTP streams.  Beware that
  changing the stream transport characteristics in the translator, can
  require thorough understanding of the application logic, specifically
  any congestion control or media adaptation to ensure appropriate
  media handling.

While congestion control and media adaptation are important, they're
hardly the only things that a middlebox might need to know about (but
fail to implement properly, which is the point of this warning).  I'd
suggest rephrasing to be a range/selection rather than drilling into
specific points (e.g., "from congestion control to media adaptation or
particular application-layer semantics").

  Within the uses enabled by the RTP standard the point to point
  topology can contain one to many RTP sessions with one to many media
  sources per session, each having one or more RTP streams per media
  source.

micro-nit: "one to many", "one to many", "one or more" ruins the parallelism
:)

3.4.3

  o  Signalling based (SDP)

"e.g., SDP", no?

  An RTP/RTCP-based grouping solution is to use the RTCP SDES CNAME to
  bind related RTP streams to an endpoint or to a synchronization
  context.  For applications with a single RTP stream per type (media,
  source or redundancy stream), CNAME is sufficient for that purpose
  independent if one or more RTP sessions are used.  However, some

nit: "independent if" doesn't parse properly; maybe "independently of
whether"?

  independent if one or more RTP sessions are used.  However, some
  applications choose not to use CNAME because of perceived complexity
  or a desire not to implement RTCP and instead use the same SSRC value
  to bind related RTP streams across multiple RTP sessions.  RTP

[It's interesting to see this noted, given that we talk about how if you
don't implement RTCP you're not actually using RTP, just the RTP packet
formats; and how we discuss that reusing the same SSRC value across
multiple RTP sessions can be risky.  That said, this should not
discourage us from documenting what implementations actually do...]

Section 3.4.4

  There exist a number of Forward Error Correction (FEC) based schemes
  for how to reduce the packet loss of the original streams.  Most of

nit: I think this is either "mitigate packet loss" or "reduce lost data
from a media stream", but "reduce packet loss" it is not.

  Using multiple RTP sessions supports the case where some set of
  receivers might not be able to utilise the FEC information.  By
  placing it in a separate RTP session and if separating RTP sessions
  on transport level, FEC can easily be ignored already on transport
  level, without considering any RTP layer information.

nit: "the transport level"

Section 4.1.2

  BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], it is possible for
  the RTP translator to map the RTP streams between both sides using
  some method, e.g. if the number and order of SDP "m=" lines between
  both sides are the same.  There are also challenges with SSRC

(There's nothing in SDP that requires that to be the case, though, this
would merely be a "convenient property shared by the two applications'
behavior"?)

Section 4.1.3

  For applications that use any security mechanism, e.g., in the form
  of SRTP, the gateway needs to be able to decrypt and verify source
  integrity of the incoming packets, and re-encrypt, integrity protect,
  and sign the packets as peer in the other application's security
  context.  This is necessary even if all that's needed is a simple

Can you clarify what is meant by "sign the packets as peer" here?  Is it
implying that the terminating gateway needs to have credentials so as to
impersonate both "real" participants to the other?
(Also, nit: "sign packets as the peer" might be a more grammatical
wording, as "peer" needs an article.)

  If one uses security functions, like SRTP, and as can be seen from
  above, they incur both additional risk due to the requirement to have
  the gateway in the security association between the endpoints (unless
  the gateway is on the transport level), and additional complexities
  in form of the decrypt-encrypt cycles needed for each forwarded
  packet.  SRTP, due to its keying structure, also requires that each

This sentence is pretty complicated.  Even in the first part, I'm not
sure what "they" in "they incur both" refers to...it seems that the risk
is to the participant(s) ("one") rather than the "security functions"
themselves...

  RTP session needs different master keys, as use of the same key in
  two RTP sessions can for some ciphers result in two-time pads that
  completely breaks the confidentiality of the packets.

I'd suggest discussing this as "reuse of a one-time pad" rather than a
"two-time pad".

Section 4.1.4

  Endpoints that aren't updated to handle multiple streams following
  these recommendations can have issues with participating in RTP
  sessions containing multiple SSRCs within a single session, such as:

Talking about endpoints being "updated [...] following these
recommendations" also makes me wonder whether an Updates relationship to
3550 or other document(s) would be appropriate.

Section 4.2.2

      the, in most cases 2-3, additional flows.  However, packet loss
      causes extra delays, at least 100 ms, which is the minimal
      retransmission timer for ICE.

Doesn't RFC 8445 say 500 ms, not 100?

  Deep Packet Inspection and Multiple Streams:  Firewalls differ in how
      deeply they inspect packets.  There exist some risk that deeply
      inspecting firewalls will have similar legacy issues with multiple
      SSRCs as some RTP stack implementations.

Re "some risk", can we say that this has definitely been seen in the
wild at least once?

Section 4.3.1

  only premium users are allowed to access.  The mechanism preventing a
  receiver from getting the high quality stream can be based on the
  stream being encrypted with a key that user can't access without
  paying premium, using the key-management to limit access to the key.

nit: there seems to be a missing word here ("paying a premium"?)

  SRTP [RFC3711] has no special functions for dealing with different
  sets of master keys for different SSRCs.  The key-management
  functions have different capabilities to establish different sets of
  keys, normally on a per-endpoint basis.  For example, DTLS-SRTP
  [RFC5764] and Security Descriptions [RFC4568] establish different
  keys for outgoing and incoming traffic from an endpoint.  This key
  usage has to be written into the cryptographic context, possibly
  associated with different SSRCs.

I don't really understand what this paragraph is trying to say.

Section 4.3.2

  Transport translator-based sessions and multicast sessions, can

This doesn't seem to match the terminology we used in § 4.1.2.
(This terminology appears a couple other times, later.)

Section 5.1

  h.  If the applications need finer control over which session
      participants that are included in different sets of security
      associations, most key-management will have difficulties
      establishing such a session.

nit: the grammar is off, here (remove "that" and use "key-management
techniques"?)

Section 5.3

  2.  The application can indicate its usage of the RTP streams on RTP
      session level, in case multiple different usages exist.

nit: is this "in case" (precautionary) or "in the case when"
(descriptive)?

Section 6

  Transport Support Extensions:  When defining new RTP/RTCP extensions

nit: should we swap the order of "Support" and "Extensions"?

Section 11.1

RFC 3830 does not feel like it needs to be normative.

Appendix A

  4.  Sending multiple streams in the same sequence number space makes
        it impossible to determine which payload type, which stream a
        packet loss relates to, and thus to which stream to potentially
        apply packet loss concealment or other stream-specific loss
        mitigation mechanisms.

I don't think this parses properly (around "which payload type,")

Appendix B.1

  One aspect of the existing signalling is that it is focused on RTP
  sessions, or at least in the case of SDP the media description.

nit: I think there's an extra or missing word here (around "the media
description").

  o  Bitrate/Bandwidth exist today only at aggregate or as a common
      "any RTP stream" limit, unless either codec-specific bandwidth
      limiting or RTCP signalling using TMMBR is used.

Should we have a reference for TMMBR?

Appendix B.3

  RTP streams being transported in RTP has some particular usage in an
  RTP application.  This usage of the RTP stream is in many

nit: singular/plural mismatch "has"/"streams"

[Ballot comment]
One processing question: Should this document update RFC3550 given the last paragraph each in section 3.4.1 and 3.4.3?

And one comment on section 4.2.1:
"Different Differentiated
  Services Code Points (DSCP) can be assigned to different packets
  within a flow as well as within an RTP stream. "
not sure what you mean by flow here but at least RFC7657 says
"Should use a single DSCP for all packets within a reliable
      transport protocol session"
Maybe you can say a bit more here to ensure the guidance provided in RFC7657 is reflected accurately.

Even though I didn't see any discussion of the TSV-ART review (Thanks Bernard!) I believe all comments have been addressed. Thanks for that!

Fully editorial minor comments:
1) In the intro maybe:
OLD
The authors hope that clarification on the usefulness
  of some functionalities in RTP will result in more complete
  implementations in the future.
NEW
This document aims to clarify the usefulness
  of some functionalities in RTP which will hopefully result in more complete
  implementations in the future.

2) sec 3.2
s/one or transport flows/one or more transport flows/
And maybe also
s/transport flows, e.g. an UDP destination port./transport flows, e.g. based on the UDP destination port./?

3) sec 3.2.1:
"  RTP does not contain a session identifier, yet different RTP sessions
  must be possible to identify both across different endpoints and
  within a single endpoint."
Not sure I can parse this sentence correctly...

4) sec 4.1.3:
s/Signalling, choosing and policing/Signalling, choosing, and policing/ -> missing comma

5) sec 6 maybe:
s/specification writers/specification designers/

[Ballot comment]
One processing question: Should this document update RFC3550 given the last paragraph each in section 3.4.1 and 3.4.3?

And one comment on section 4.2.1:
"Different Differentiated
  Services Code Points (DSCP) can be assigned to different packets
  within a flow as well as within an RTP stream. "
not sure what you mean by flow here but at least RFC7657 says
"Should use a single DSCP for all packets within a reliable
      transport protocol session"
Maybe you can say a bit more here to ensure the guidance provided in RFC7657 is reflected accurately.

Fully editorial minor comments:
1) In the intro maybe:
OLD
The authors hope that clarification on the usefulness
  of some functionalities in RTP will result in more complete
  implementations in the future.
NEW
This document aims to clarify the usefulness
  of some functionalities in RTP which will hopefully result in more complete
  implementations in the future.

2) sec 3.2
s/one or transport flows/one or more transport flows/
And maybe also
s/transport flows, e.g. an UDP destination port./transport flows, e.g. based on the UDP destination port./?

3) sec 3.2.1:
"  RTP does not contain a session identifier, yet different RTP sessions
  must be possible to identify both across different endpoints and
  within a single endpoint."
Not sure I can parse this sentence correctly...

4) sec 4.1.3:
s/Signalling, choosing and policing/Signalling, choosing, and policing/ -> missing comma

5) sec 6 maybe:
s/specification writers/specification designers/

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

The IANA Functions Operator has reviewed draft-ietf-avtcore-multiplex-guidelines-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-10):

From: The IESG
To: IETF-Announce
CC: avtcore-chairs@ietf.org, ben@nostrum.com, rachel.huang@huawei.com, avt@ietf.org, draft-ietf-avtcore-multiplex-guidelines@ietf.org, Rachel Huang
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams) to Informational RFC


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document: - 'Guidelines
for using the Multiplexing Features of RTP to Support
  Multiple Media Streams'
  as Informational RFC

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
ietf@ietf.org mailing lists by 2019-04-10. 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


  The Real-time Transport Protocol (RTP) is a flexible protocol that
  can be used in a wide range of applications, networks, and system
  topologies.  That flexibility makes for wide applicability, but can
  complicate the application design process.  One particular design
  question that has received much attention is how to support multiple
  media streams in RTP.  This memo discusses the available options and
  design trade-offs, and provides guidelines on how to use the
  multiplexing features of RTP to support multiple media streams.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines/ballot/


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

This is my AD evaluation of draft-ietf-avtcore-multiplex-guidelines-08.

I have a few material comments and a number of editorial comments. I don’t think any of these need block IETF LC. They can be handled along with any other IETF LC feedback.

Also, Barry will become the responsible AD after today, so the resolution of my comments will be at his discretion.

————————————————

*** Substantive Comments ***

§ 3.4.1: Please don’t quote that much material. It’s better to reference it, especially since RFC 3550 predates the current IPR rules.

§3.4.3, last paragraph: This paragraph recommends going against a 3550 recommendation. I realize this is an informational draft offering opinions rather than normative text, but did the WG consider an update to 3550?

§3.4.4: "Those receivers that are not seeing packet loss don’t need to join
the multicast group with the FEC data, and so avoid the overhead of
receiving unnecessary FEC packets, for example.”

Does this require the receiver to predict in advance whether packet loss may occur during the session?

§4.1.3: "For applications that uses any security mechanism, e.g., in the form
of SRTP, the gateway needs to be able to decrypt incoming packets and
re-encrypt them in the other application’s security context.”

It seems like this should also talk about authentication/signing, at least for when modifications to the packets occur.

§4.3.2: It’s not clear to me that this section is specific to multiplexing.

§10.2: The following references need to be normative since they are needed to fully understand guidance or security considerations:

ietf-avtcore-multi-media-rtp-session
[I-D.ietf-mmusic-rid]
[I-D.ietf-mmusic-sdp-bundle-negotiation]
[I-D.ietf-mmusic-sdp-simulcast]
[I-D.ietf-perc-srtp-ekt-diet]
RFC 3551
RFC 3711
RFC 3830
RFC 4585
RFC 5760
RFC 5761
RFC 5776
RFC 7667

- Appendix A: "To use payload type as the single discriminator for
multiple streams implies that all the different RTP streams are being
sent with the same SSRC, thus using the same timestamp and sequence
number space.”

That doesn’t seem to make sense. How could discriminating on PT mean that all streams use the same PT?

*** Editorial Comments ***

- General:

— The doc spends more words on analysis than it does on guidance. It might be worth reconsidering the title.
-- Parts of this seem unnecessarily wordy. Please edit for “null words” (For example “It should be noted that…”, “A general observation is…”, and “It is worth pointing out…")

§1, 2nd paragraph: "The limitations in
some implementations, RTP/RTCP extensions, and signalling has also
been exposed. The authors also hope that clarification on the
usefulness of some functionalities in RTP will result in more
complete implementations in the future.”

First sentence: s/has/have
2nd sentence: “also” seems out of place (the authors hope this in addition to what?)

§2.1: "Note: The above definitions of RTP Receiver and RTP sender are
intended to be consistent with the usage in [RFC3550].”

Now that the section is written, did the authors succeed in this intent? Or is there a concern it might not be consistent?

§3.1: Expand FEC on first mention.

§3.2.1:

- "An RTP Session is the highest semantic layer in the RTP protocol, and
represents an association between a group of communicating endpoints.
RTP does not contain a session identifier, yet RTP sessions must be
possible to separate both across different endpoints and within a
single endpoint.”

I do not understand the last clause in the sentence.

- "A single
endpoint can have one or more transport flows for the same RTP
session, and a single RTP session can span multiple transport layer
flows.”

Isn’t the second part entirely implied by the first?

- "For example, when running RTP on top of UDP/IP,
an endpoint can identify and delimit an RTP session from other RTP
sessions by receiving the multiple UDP flows used as identified based
on their UDP source and destination IP addresses and UDP port
numbers.”

I don’t understand that sentence. (something is wrong around “flows used as identified based”)

- "SDP grouping framework [RFC5888] allows labeling…”
Missing article before SDP

- "With Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)[I-D.ietf-mmusic-sdp-bundle-negotiation],
multiple media descriptions where each represents the RTP streams
sent or received for a media source are part of a common RTP session.”

Convoluted sentence

§3.2.2: "An endpoint that changes its network transport address
during a session have to choose a new SSRC identifier to avoid being
interpreted as looped source...”

s/have/has  (plural mismatch)

§3.4.1:

- "One type
of application that can mix different media sources "blindly" is the
audio-only "telephone" bridge; most other types of applications need
application-specific logic to perform the mix correctly.”

I think this is an argument that the fourth argument is invalid, but that’s not clear from the text. Also, why the scare quotes?

§3.4.3:

- "These has previously been considered primarily as grouping RTP
sessions, [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple
media descriptions as a single RTP session”

plural disagreement between “these” and “has”.

- "This supports a lot of use cases.”

What is the antecedent of “this”? Should “this” be “these”?

- "For
applications with a single RTP stream per type (Media, Source or
Redundancy) this is sufficient independent if one or more RTP
sessions are used.”

I don’t understand the sentence. Also, later in that paragraph I got lost in all the instances of “this” with apparently different antecedents.

- "Therefore, it is not recommended to use identical SSRC
values to relate RTP streams.”

This kind of buried the lede. I suggest saying that first, then explaining why.

- "It can be noted that Section 8.3 of the RTP Specification…”
“It can be noted” are null words.

§3.4.4:

- "Most of
the FEC schemes will protect…”

Inconsistent tense. I suggest sticking to present tense.

- "This
sequence of redundant information also needs to be transmitted as its
own media stream”

I’m not sure what “also” adds here.

- "By
placing it in a separate RTP session and if separating RTP sessions
on transport level, FEC can easily be ignored already on transport
level.”

I don’t understand this sentence. Is something broken around “ignored already”?

§4.1: "There are several different kinds of interworking, and this section
discusses two; interworking between different applications including
the implications of potentially different RTP multiplexing point
choices and limitations that have to be considered when working with
some legacy applications.”

It’s not clear to me that this talks about two different kinds of interworking.

§4.1.1: "There are two fundamental approaches to building a gateway: using an
RTP Translator interworking (RTP bridging),”

Are there missing words around “an RTP Translator interworking"

§4.1.4: "This indicates that gateways attempting to interconnect to this class
of devices has”
Plural mismatch between “gateways” and “has”

§4.2.2: "However, it is worth pointing out that a real-time video
conference session with audio and video is likely using less than”

s/“is likely using”/“likely uses”

§4.2.3

- "Another
application is the Many to Many communication, which RTP [RFC3550]
was originally built to support, but the multicast semantics do
result in a certain number of limitations.”
I'm confusedby that sentence. the the limitations specific to many-to-many, or to multicast in general?

- "result in a certain number of limitations.
One limitation is that for any group, sender side adaptation to the
actual receiver properties causes degradation for all participants to
what is supported by the receiver with the worst conditions among the
group participants.”

Hard to parse.

§4.3.1:

- "At least unless TESLA source authentication
[RFC4383], which adds delay to achieve source authentication.”

Does not parse. Missing words?

- "A second case is when using security as an enforcing mechanism for
differentiation.”

I'm not sure what this means

§5 and subsections:

Please be consistent about whether the “pros” and “cons” use complete sentences or fragments.

§5.3, Con A: This is not so much a con but a design decision. It’s only a con in the sense of the other cons that it creates.

Con F is hard to parse.

- Appendix A:

- 2nd sentence: Improper capitalization of “Payload”.
- list item 1: s/restraint/constraints

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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?

RFC Type: Informational.
This is a document for providing guidelines when using the RTP protocol for support multiple media streams. RFC type is indicated in the title page header.


(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

  This document discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features to support multiple media streams in RTP.

Working Group Summary

  The WG is happy with current version. No technical issues are received.

Document Quality

  The document is well written and easy to read. All the technical parts have been agreed in the WG. A lot of implementations use RTP multiplexing, e.g., WebRTC and Teleprence. This will be a very useful document to the industry. The authors are from Ericsson, Huawei and Google.

Personnel

  Document Shepherd: Rachel Huang
Responsible AD: Ben Campell


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

As the Document Shepherd, I have carefully reviewed the version 08 being forwarded to IESG. I didn¡¯t find any big issues. In my opinion, it¡¯s mature enough for publication.

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

No

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

This document has a security consideration chapter in section 4.3. Reviews with regard to it are required.

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

No such issue.

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

I have confirmed that the authors are not personally aware of any IPR related to this document.

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

No.

(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? 

WG as a whole understand and agree with the document.

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

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

There are two normative words used in the document. However, they are from the content quoted from RFC3550 which is standard track. Thus, it¡¯s reasonable to keep them as they are.

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

No such review required.

(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?

No.

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

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

No.

(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 5226).

No IANA considerations.

(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 IANA considerations.

(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, etc.

No such formal language is used in this document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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?

RFC Type: Informational.
This is a document for providing guidelines when using the RTP protocol for support multiple media streams. RFC type is indicated in the title page header.


(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

  This document discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features to support multiple media streams in RTP.

Working Group Summary

  The WG is happy with current version. No technical issues are received.

Document Quality

  The document is well written and easy to read. All the technical parts have been agreed in the WG. A lot of implementations use RTP multiplexing, e.g., WebRTC and Teleprence. This will be a very useful document to the industry. The authors are from Ericsson, Huawei and Google.

Personnel

  Document Shepherd: Rachel Huang
Responsible AD: Ben Campell


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

As the Document Shepherd, I have carefully reviewed the version 08 being forwarded to IESG. I didn¡¯t find any big issues. In my opinion, it¡¯s mature enough for publication.

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

No

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

This document has a security consideration chapter in section 4.3. Reviews with regard to it are required.

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

No such issue.

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

I have confirmed that the authors are not personally aware of any IPR related to this document.

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

No.

(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? 

WG as a whole understand and agree with the document.

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

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

There are two normative words used in the document. However, they are from the content quoted from RFC3550 which is standard track. Thus, it¡¯s reasonable to keep them as they are.

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

No such review required.

(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?

No.

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

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

No.

(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 5226).

No IANA considerations.

(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 IANA considerations.

(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, etc.

No such formal language is used in this document.

Request for posting confirmation emailed to previous authors: avtcore-chairs@ietf.org, Colin Perkins , Bo Burman , Magnus Westerlund , Roni Even , Harald Alvestrand , Hui Zheng