A Framework for Session Description Protocol (SDP) Attributes When Multiplexing
draft-ietf-mmusic-sdp-mux-attributes-19

[Ballot comment]

- 4.5 and 5.7: What if the different a=crypto lines
specify different strength ciphersuites? Wouldn't it be
better to pick the strongest or to say they MUST be the
same (as is done in 5.35)? If picking the first is the
right answer then maybe warn folks to not put a stronger
ciphersuite anywhere else?

- 5.36 vs. 5.39: It wasn't clear to me why these have
different rules - can you explain?

[Ballot comment]
This document is a work of art. Thank you folks for accepting the challenge, because it's important.

I have a couple of observations, to go along with my Yes ballot. Please do the right thing.

I know Mirja also pushed on the TBD category, but I find RFC 2119 "SHOULD NOT" to be problematic.

  The attributes in the TBD category have not been analyzed under the
  proposed multiplexing framework and SHOULD NOT be multiplexed.
 
The point of SHOULD (NOT) is that you don't do this unless you understand the risks, and in this case, it seems to me that you don't know the risks. If you're determined to multiplex the TBD attribute "frommet=", won't you have to do your own analysis? Wouldn't that mean you might make assumptions ("it's IDENTICAL") that conflict with the analysis other implementers are doing ("it's TRANSPORT")?

I could imagine a couple of approaches that might be helpful here.

Saying "MUST NOT be multiplexed" would avoid implementers doing their own analysis and coming up with conflicting answers. Is it obvious why this is "SHOULD NOT" instead of "MUST NOT"? In other words, who needs to multiplex TBD attributes, and why?

Saying "cannot be assumed to be safe when multiplexed" probably captures what I think you are saying.

Would it be clearer if the category was called UNKNOWN?

In this text,

16.  Security Considerations

  This document does not add any new security considerations beyond the
  existing considerations in the RTP RFCs ([RFC3550] and [RFC3711])
  that are referenced by this specification.
 
I don't understand how the first paragraph ^^ and the third paragraph of the section are compatible, because you're referring to issues described in this specification. But if you delete the first paragraph, leaving only

  The primary security for RTP including the way it is used here is
  described in [RFC3550] and [RFC3711].

  When multiplexing SDP attributes with the category "CAUTION", the
  implementations should be aware of possible issues as described in
  this specification.

the security considerations would be consistent.

[Ballot comment]
Update: The reference to the obsolete RFC 4901 is to cover a deprecated attribute that is defined in that doc.

Is the reference to 4901 (obsoleted by 5245) intentional?

[Ballot comment]
Two comments:

1) The category TDB is not fully clear to me. It says: "The attributes in the TBD category have not been analyzed", but why? Can you further explain?

2) Is the new registry for the Mux Category really needed? Is it expected to (much) more categories in future?

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

IANA has completed its review of draft-ietf-mmusic-sdp-mux-attributes-13.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are nineteen actions which IANA must complete.

First, a new registry is to be created called the Multiplexing Categories registry. The new registry will be managed via First Come, First Served as defined in RFC 5226.

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

There are initial registrations in the new registry as follows:

+-------------------------+-----------------+
| Multiplexing Categories | Reference |
+-------------------------+-----------------+
| NORMAL | [ RFC-to-be ] |
| CAUTION | [ RFC-to-be ] |
| IDENTICAL | [ RFC-to-be ] |
| TRANSPORT | [ RFC-to-be ] |
| SUM | [ RFC-to-be ] |
| INHERIT | [ RFC-to-be ] |
| IDENTICAL-PER-PT | [ RFC-to-be ] |
| SPECIAL | [ RFC-to-be ] |
| TBD | [ RFC-to-be ] |
+-------------------------+-----------------+

Next, IANA understands that many subregistries of the Session Description Protocol (SDP) Parameters registry located at:

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

are to be modified. In each case below, a new column is to be added to the existing registry. In each case, the column is to be titled "Mux Category" and for every indicated SDP attribute.name, token or value, the reference of [ RFC-to-be ] is to be added to the existing reference.

IANA notes that many of the registries being modified have Specification Required or Expert Review as their mechanism for registry management as defined by RFC 5226. In these cases, the requirement will be noted. In those cases, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA Question --> IANA notes that many, but not all, of the subregistries of the subregistries of the Session Description Protocol (SDP) Parameters registry are being modified by having the "Mux Category" added to the subregistry. Is the author's intent to add this column to EVERY subregistry of the subregistries of the Session Description Protocol (SDP) Parameters registry, or only those detailed in section 15 of the current draft?

In the SDP bwtype subregistry, expert review is not required and the new column is as follows:

+----------+--------------+
| SDP Name | Mux Category |
+----------+--------------+
| CT | NORMAL |
| AS | SUM |
| RS | SUM |
| RR | SUM |
| TIAS | SPECIAL |
+----------+--------------+

In the att-field (session level) subregistry, expert review is required for the change and the new column is as follows:

+---------------------+--------------+
| SDP Name | Mux Category |
+---------------------+--------------+
| cat | NORMAL |
| keywds | NORMAL |
| type | NORMAL |
| type:broadcast | NORMAL |
| type:H332 | NORMAL |
| type:meeting | NORMAL |
| type:moderated | NORMAL |
| type:test | NORMAL |
| charset | NORMAL |
| charset:iso8895-1 | NORMAL |
| tool | NORMAL |
| ipbcp | SPECIAL |
| group | NORMAL |
| ice-lite | NORMAL |
| ice-options | NORMAL |
| bcastversion | NORMAL |
| 3GPP-Integrity-Key | CAUTION |
| 3GPP-SDP-Auth | CAUTION |
| alt-group | CAUTION |
| PSCid | NORMAL |
| bc_service | NORMAL |
| bc_program | NORMAL |
| bc_service_package | NORMAL |
| sescap | CAUTION |
| rtsp-ice-d-m | TBD |
+---------------------+--------------+

In the att-field (both session and media level) subregistry, expert review is required for the change and the new column is as follows:

+-------------------------+-------------------+
| SDP Name | Mux Category |
+-------------------------+-------------------+
| recvonly | NORMAL |
| sendrecv | NORMAL |
| sendonly | NORMAL |
| sdplang | NORMAL |
| lang | NORMAL |
| h248item | SPECIAL |
| sqn | NORMAL |
| cdsc | NORMAL |
| cpar | INHERIT |
| cparmin | SPECIAL |
| cparmax | SPECIAL |
| rtcp-xr | NORMAL |
| maxprate | SPECIAL |
| setup | TRANSPORT |
| connection | TRANSPORT |
| key-mgmt | IDENTICAL |
| source-filter | IDENTICAL |
| inactive | NORMAL |
| fingerprint | TRANSPORT |
| flute-tsi | TBD |
| flute-ch | TBD |
| FEC-declaration | TBD |
| FEC-OTI-extension | TBD |
| content-desc | TBD |
| ice-pwd | TRANSPORT |
| ice-ufrag | TRANSPORT |
| stkmstream | NORMAL |
| extmap | SPECIAL |
| qos-mech-send | TRANSPORT |
| qos-mech-recv | TRANSPORT |
| csup | NORMAL |
| creq | NORMAL |
| acap | INHERIT |
| tcap | INHERIT |
| 3GPP-QoE-Metrics | CAUTION |
| 3GPP-Asset-Information | CAUTION |
| mbms-mode | CAUTION |
| mbms-repair | CAUTION |
| ike-setup | IDENTICAL |
| psk-fingerprint | IDENTICAL |
| multicast-rtcp | IDENTICAL |
| rmcap | IDENTICAL-PER-PT |
| omcap | NORMAL |
| mfcap | IDENTICAL-PER-PT |
| mscap | INHERIT |
| 3gpp.iut.replication | TBD |
| bcap | INHERIT |
| ccap | IDENTICAL |
| icap | NORMAL |
| 3gpp_sync_info | NORMAL |
| 3gpp_MaxRecvSDUSize | NORMAL |
| etag | CAUTION |
| duplication-delay | NORMAL |
| range | CAUTION |
| control | CAUTION |
| mtag | CAUTION |
| ts-refclk | NORMAL |
| mediaclk | NORMAL |
| calgextmap | NORMAL |
+-------------------------+-------------------+

In the att-field (media level only) subregistry, expert review is required for the change and the new column is as follows:

+---------------------------+-------------------+
| SDP Name | Mux Category |
+---------------------------+-------------------+
| ptime | IDENTICAL-PER-PT |
| orient | NORMAL |
| orient:portrait | NORMAL |
| orient:landscape | NORMAL |
| orient:seascape | NORMAL |
| framerate | IDENTICAL-PER-PT |
| quality | NORMAL |
| rtpmap | IDENTICAL-PER-PT |
| fmtp | IDENTICAL-PER-PT |
| rtpred1 | CAUTION |
| rtpred2 | CAUTION |
| T38FaxVersion | TBD |
| T38MaxBitRate | TBD |
| T38FaxFillBitRemoval | TBD |
| T38FaxTranscodingMMR | TBD |
| T38FaxTranscodingJBIG | TBD |
| T38FaxRateManagement | TBD |
| T38FaxMaxBuffer | TBD |
| T38FaxMaxDatagram | TBD |
| T38FaxUdpEC | TBD |
| maxptime | IDENTICAL-PER-PT |
| des | CAUTION |
| curr | CAUTION |
| conf | CAUTION |
| mid | NORMAL |
| rtcp | TRANSPORT |
| rtcp-fb | IDENTICAL-PER-PT |
| label | NORMAL |
| T38VendorInfo | TBD |
| crypto | TRANSPORT |
| eecid | CAUTION |
| aalType | CAUTION |
| capability | CAUTION |
| qosClass | CAUTION |
| bcob | CAUTION |
| stc | CAUTION |
| upcc | CAUTION |
| atmQOSparms | CAUTION |
| atmTrfcDesc | CAUTION |
| abrParms | CAUTION |
| abrSetup | CAUTION |
| bearerType | CAUTION |
| lij | CAUTION |
| anycast | CAUTION |
| cache | CAUTION |
| bearerSigIE | CAUTION |
| aalApp | CAUTION |
| cbrRate | CAUTION |
| sbc | CAUTION |
| clkrec | CAUTION |
| fec | CAUTION |
| prtfl | CAUTION |
| structure | CAUTION |
| cpsSDUsize | CAUTION |
| all2CPS | CAUTION |
| all2CPSSDUrate | CAUTION |
| aal2sscs3661unassured | CAUTION |
| aal2sscs3661assured | CAUTION |
| aal2sscs3662 | CAUTION |
| aal5sscop | CAUTION |
| atmmap | CAUTION |
| silenceSupp | CAUTION |
| ecan | CAUTION |
| gc | CAUTION |
| profileDesc | CAUTION |
| vsel | CAUTION |
| dsel | CAUTION |
| fsel | CAUTION |
| onewaySel | CAUTION |
| codecconfig | CAUTION |
| isup_usi | CAUTION |
| uiLayer1_Prot | CAUTION |
| chain | CAUTION |
| floorctrl | IDENTICAL |
| confid | NORMAL |
| userid | NORMAL |
| floorid | NORMAL |
| FEC | NORMAL |
| accept-types | TBD |
| accept-wrapped-types | TBD |
| max-size | TBD |
| path | TBD |
| dccp-service-code | CAUTION |
| rtcp-mux | IDENTICAL |
| candidate | TRANSPORT |
| ice-mismatch | NORMAL |
| remote-candidates | TRANSPORT |
| SRTPAuthentication | TBD |
| SRTPROCTxRate | TBD |
| rtcp-rsize | IDENTICAL |
| file-selector | TBD |
| file-transfer-id | TBD |
| file-disposition | TBD |
| file-date | TBD |
| file-icon | TBD |
| file-range | TBD |
| depend | IDENTICAL-PER-PT |
| ssrc | NORMAL |
| ssrc-group | NORMAL |
| rtcp-unicast | IDENTICAL |
| pcfg | SPECIAL |
| acfg | SPECIAL |
| zrtp-hash | TRANSPORT |
| X-predecbufsize | CAUTION |
| X-initpredecbufperiod | CAUTION |
| X-initpostdecbufperiod | CAUTION |
| X-decbyterate | CAUTION |
| 3gpp-videopostdecbufsize | CAUTION |
| framesize | CAUTION |
| 3GPP-SRTP-Config | CAUTION |
| alt | CAUTION |
| alt-default-id | CAUTION |
| 3GPP-Adaption-Support | CAUTION |
| mbms-flowid | CAUTION |
| fec-source-flow | SPECIAL |
| fec-repair-flow | SPECIAL |
| repair-window | SPECIAL |
| rams-updates | CAUTION |
| imageattr | IDENTICAL-PER-PT |
| cfw-id | NORMAL |
| portmapping-req | CAUTION |
| g.3gpp.cat | NORMAL |
| g.3gpp.crs | NORMAL |
| ecn-capable-rtp | IDENTICAL |
| visited-realm | TRANSPORT |
| secondary-realm | TRANSPORT |
| omr-s-cksum | NORMAL |
| omr-m-cksum | NORMAL |
| omr-codecs | NORMAL |
| omr-m-att | NORMAL |
| omr-s-att | NORMAL |
| omr-m-bw | NORMAL |
| omr-s-bw | NORMAL |
| msrp-cema | TBD |
| dccp-port | CAUTION |
| resource | NORMAL |
| channel | NORMAL |
| cmid | NORMAL |
| content | NORMAL |
| lcfg | SPECIAL |
| loopback | NORMAL |
| loopback-source | NORMAL |
| loopback-mirror | NORMAL |
| chatroom | TBD |
| altc | TRANSPORT |
| T38FaxMaxIFP | TBD |
| T38FaxUdpECDepth | TBD |
| T38FaxUdpFECMaxSpan | TBD |
| T38ModemType | TBD |
| cs-correlation | TBD |
| rtcp-idms | NORMAL |
+---------------------------+-------------------+

In the att-field (source level) subregistry, expert review is required and the new column is as follows:

+----------------+-------------------+
| SDP Name | Mux Category |
+----------------+-------------------+
| cname | NORMAL |
| previous-ssrc | NORMAL |
| fmtp | IDENTICAL-PER-PT |
| ts-refclk | NORMAL |
| mediaclk | NORMAL |
+----------------+-------------------+

In the content SDP Parameters subregistry, expert review is required and the new column is as follows:

+----------+--------------+
| SDP Name | Mux Category |
+----------+--------------+
| slides | NORMAL |
| speaker | NORMAL |
| sl | NORMAL |
| main | NORMAL |
| alt | NORMAL |
+----------+--------------+

In the Semantics for the "group" SDP Attribute subregistry, expert review is not required. The new column is as follows:

+---------+--------------+
| Token | Mux Category |
+---------+--------------+
| LS | NORMAL |
| FID | NORMAL |
| SRF | NORMAL |
| ANAT | CAUTION |
| FEC | NORMAL |
| FEC-FR | NORMAL |
| CS | NORMAL |
| DDP | NORMAL |
| DUP | NORMAL |
+---------+--------------+

In the 'rtcp-fb' Attribute Values subregistry, expert review is not required.

IANA Question --> what should the "Mux Category" values for 3gpp-roi0arbitrary and 3gpp-roi-predefined be?

The new column for the remaining values is:

+------------+-------------------+
| Value Name | Mux Category |
+------------+-------------------+
| ack | IDENTICAL-PER-PT |
| app | SPECIAL |
| ccm | IDENTICAL-PER-PT |
| nack | IDENTICAL-PER-PT |
| trr-int | IDENTICAL-PER-PT |
+------------+-------------------+

In the "ack" and "nack" Attribute Values, expert review is not required. The new column is as follows:

+------------+-------------------+
| Value Name | Mux Category |
+------------+-------------------+
| sli | IDENTICAL-PER-PT |
| pli | IDENTICAL-PER-PT |
| rpsi | IDENTICAL-PER-PT |
| app | SPECIAL |
| rai | IDENTICAL-PER-PT |
| tllei | IDENTICAL-PER-PT |
| pslei | IDENTICAL-PER-PT |
| ecn | IDENTICAL |
+------------+-------------------+

In the 'depend' SDP Attribute Values subregistry, expert review is required and the new column is as follows:

+-------+-------------------+
| Token | Mux Category |
+-------+-------------------+
| lay | IDENTICAL-PER-PT |
| mdc | IDENTICAL-PER-PT |
+-------+-------------------+

In the 'cs-correlation' Attribute Values subregistry, expert review is required and the new column is as follows:

+-----------+--------------+
| Value | Mux Category |
+-----------+--------------+
| callerid | TBD |
| uuie | TBD |
| dtmf | TBD |
| external | TBD |
+-----------+--------------+

In the Semantics for the 'ssrc-group' SDP Attribute subregistry, expert review is not required. The new column is as follows:

+---------+--------------+
| Token | Mux Category |
+---------+--------------+
| FID | NORMAL |
| FEC | NORMAL |
| FEC-FR | NORMAL |
| DUP | NORMAL |
+---------+--------------+

In the SDP/RTSP key management protocol identifiers subregistry, expert review is required. The new column is as follows:

+------------+--------------+
| Value Name | Mux Category |
+------------+--------------+
| mikey | IDENTICAL |
+------------+--------------+

In the Codec Control Messages subregistry, expert review is required. The new column is as follows:

+------------+-------------------+
| Value Name | Mux Category |
+------------+-------------------+
| fir | IDENTICAL-PER-PT |
| tmmbr | IDENTICAL-PER-PT |
| tstr | IDENTICAL-PER-PT |
| vbcm | IDENTICAL-PER-PT |
+------------+-------------------+

In the QoS Mechanism Tokens subregistry, expert review is required. The new column is as follows:

+---------------+--------------+
| QoS Mechanism | Mux Category |
+---------------+--------------+
| rsvp | TRANSPORT |
| nsis | TRANSPORT |
+---------------+--------------+

In the SDP Capability Negotiation Option Tags subregistry, expert review is not required and the new column is as follows:

+------------+--------------+
| Option Tag | Mux Category |
+------------+--------------+
| cap-v0 | NORMAL |
| med-v0 | NORMAL |
| bcap-v0 | NORMAL |
| ccap-v0 | NORMAL |
| icap-v0 | NORMAL |
+------------+--------------+

In the Timestamp Reference Clock Source Parameters subregistry, expert review is required. The new column is as follows:

+----------+--------------+
| Name | Mux Category |
+----------+--------------+
| ntp | NORMAL |
| ptp | NORMAL |
| gps | NORMAL |
| gal | NORMAL |
| glonass | NORMAL |
| local | NORMAL |
| private | NORMAL |
+----------+--------------+

In the Media Clock Source Parameters subregistry, expert review is required. The new column is as follows:

+-----------+--------------+
| Name | Mux Category |
+-----------+--------------+
| sender | NORMAL |
| direct | NORMAL |
| IEEE1722 | NORMAL |
+-----------+--------------+

IANA understands that the nineteen actions above are the only ones 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 only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, draft-ietf-mmusic-sdp-mux-attributes@ietf.org, bo.burman@ericsson.com, "Bo Burman"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Framework for SDP Attributes when Multiplexing) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'A Framework for SDP Attributes when Multiplexing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. The last call is extended due to crossing
an IETF meeting, and due to the length of the draft. Please send
substantive comments to the ietf@ietf.org mailing lists by 2016-08-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 purpose of this specification is to provide a framework for
  analyzing the multiplexing characteristics of Session Description
  Protocol (SDP) attributes when SDP is used to negotiate the usage of
  single 5-tuple for sending and receiving media associated with
  multiple media descriptions.

  This specification also categorizes the existing SDP attributes based
  on the framework described herein.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ballot/


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

Hi,

Here is my AD evaluation of draft-ietf-mmusic-sdp-mux-attributes-12. I would like at least the substantive
section to be discussed before going to IETF last call.

Thanks!
Ben.
----------

# Substantive #

- This is very long and detailed. Are the authors and chairs comfortable
that all sections have had sufficient review?

-4.0: It would be helpful to add a paragraph describing how these semantic
groupings map to the categories.

-4.2: I recommend choosing a category name that is not a 2119 keyword.
  Maybe something like "not mux-able" or "unsafe"?

-4.3: Please don't use a 2119 keyword as part of the definition
of a category. This creates sort of a circular dependency; that is
attributes are in this category because they MUST be identical; but they
MUST be identical because they are in this category. I suggest describing
the category descriptively, and adding a separate sentence to say "Attributes
in the IDENTICAL category MUST be identical across all media descriptions."

-4.6:
>"This in turn MAY place constraints on what constitutes a valid
  configuration from
  a multiplexing point of view, e.g. because some attributes MUST be
  IDENTICAL (see Section 14 for further details)."

  It seems like it would make sense to state that last sentence
  more strongly. Does it make sense to say something along the lines
  of "inherited attributes MUST be coherent."?

-4.9: "For the purposes of implementations it is
  advised to consider "NOT RECOMMENDED" as the category when
  multiplexing these attributes."

  So why not have them in the NOT RECOMMENDED category, with
  an explanation that they have not been sufficiently analyzed?
  Or if you want to keep a separate category, you can say something
  like :"Attributes in the TBD category SHOULD NOT be multiplexed."

-5.8 and 5.9:
    The last paragraph of 5.8 seems redundant with section 5.9.

-5.8, last paragraph:

    "Hence multiplexing MUST NOT be performed even in this
    alternate scenario." seems to contradict the category selection of
    "NOT RECOMMENDED" (but see previous comment about not using 2119
    keywords in a category title.)

-5.14
  Do you really expect to see such an "early mechanism" be
  multiplexed?

-5.24, last paragraph: "it is recommended to consult the
  document defining the attribute."

  I assume one should _always_ refer to the specification of
  an SDP attribute before trying to mux it. But that doc is
  not going to explain muxing issues, is it?

-5.26:
  -"Support of this extension is OPTIONAL."
  Please don't use 2119 keywords to describe existing requirements
  from other docs, unless in direct quotes.

  -Note: As stated, this is untrue. MSRP has the built in ability
  to share multiple sessions across the same transport connection.
  But I think your point is that there is no specification about
  how to demux MSRP from among _other_ protocols.

  The MUST in the last sentence does not seem appropriate. You can't
  really create a 2119 level requirement for people to do work in
  the future. I suggest s/"MUST be revisited"/"could be revisited"

-5.28: Same comments as for 5.26.

- 5.39:
  I’m not a zrtp expert, but it seems like it might
  be more complicated than this. Section 8 of 6189 says
  “The a=zrtp-hash attribute  can only be included in the
  SDP at the media level since Hello messages sent in
  different media streams will have unique hashes.”
  I wonder if this shouldn't be “identical”?

-5.40:
  I'm surprised that the comedia attributes are not "transport"

-5.42:
  See previous comments about MUST level requirements for
  doing future work. (I think this recurs for some or all TBD
  sections.)

-5.45:
  6193 is an ISE stream RFC. Does anyone actually use
  in a context where muxing matters?

- 5.57:
  See comments from 5.26

-15.1:
  - Is there no need for a spec for any newly registered categories?
  - 2nd to last paragraph: "This seems vague for a MUST. Do you expect
    the registration of a new category to change the categories
    already assigned to existing SDP parameters? Is it possible
    that a new category only applies to some new SDP parameters?"
  - Last paragraph: 4566 procedures apply to what? The text just said
    new categories are first-come-first server. I don’t think
    4566 set policies for how to change mux categories.

-15.2.1:
  How do you expect the table to look after adding this RFC to the
  references? Will this RFC be added to the entries in the MUX
  column?

-16:
  - Do the assumptions for things like “fingerprint” and the zrtp
    hash not have security considerations since they force multiple
    media streams to share the same security associations?
    (Maybe that is covered by bundle?)
  - 2nd paragraph: There are more than one srtp keying mechanism—is
    this assumed true for all of them?



# Editorial #

- xml2rfc reports some outdated references. Are those intentional?

- The abstract is more detailed than needed. The point is to describe the
purpose of the draft. The second paragraph pretty much accomplishes that.

- Please include table numbers.

- 1:
  - First paragraph:
  s/"This would for e.g."/This would, for example,"
  s/"has made necessary to understand"/"has made it necessary to understand"
  - 2nd paragraph:
  "Generic future-proof framework" - This seems excessive--can we just call
  it a framework?

-3:
    - 1st paragraph, first sentence: Convoluted sentence. Can it be
    simplified?

-4:
    - first and second bullet example lists are each missing "and".

-4.2, first paragraph: Sentence fragment. (same for several category
  descriptions.)

-4.4, first sentence: Spurious comma.

-4.6, last paragraph: "In the above example, the category IDENTICAL is
  inherited for the cpar encapsulated rtcp-mux attribute."

  "For" doesn't seem like the right proposition. Is the category
  inherited "from" the cpar? "by" the cpar?

-5 and subsections: Is there any method to the ordering? They aren't
  in RFC order. It might make sense to group by the nature of the
  attributes, but if that is the case here it's not explained.

-5.4, note: "... due to inability in meeting
  the right resource reservations requested."

  I can't parse that clause. Does it mean "inability to meet the
  resource reservation request"? "Inability to determine the correct
  resource reservation request"?

-5.8, last paragraph:
  - "None of this is standardized yet and it wouldn’t work
  as explained. "

  Does this mean that it has been explained why it wouldn't work?
  Or do you mean the way it is explained wouldn't work?

-5.9:
  -s/"[RFC6773] document specifies"/"[RFC6773] specifies"
  - last paragraph: s/"can or cannot"/"may or may not"

-5.13, table:
  "Specific RTP extension document MUST be referred"

  I don’t understand what that means. If you mean to
  say “refer to specific document”, that shouldn’t use MUST.

-5.22, table: "document needs to be referred" (several repetitions)
  I'm not sure what this means. Should it say "Refer to the
  specific document"?

-5.27, table: If the "MUST be globally unique" requirement refers to
  and existing requirment from 4583, please avoid 2119 language.

-5.55: "... to be referred ..."
  I suggest "Refer to...."

-6.3: "not clearly defined offer/answer usage"
  I'm not sure what is meant here. (Also, why is this not TBD or NOT
  RECOMMENDED?)

-14.2.1, last paragraph:
  Do I understand this correctly to mean that the answerer can
  always fall back to a “common-to-all” config even if the offerer
  offered additional independent configs?

-14.3:
  s/"...extends capability..."/"...extends the capability..."

-14.3.1: "which MUST be followed here as well."
  If bundle-negotiation already requires identical pt values,
  isn’t this MUST redundant to that one?

14.3.2:
  I suspect that first MAY is a statement of fact, not a new
  requirement.

-15, paragraph starting with "The IANA is requested to...":
  This sentence seems to belong with the next paragraph.

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?

A Proposed Standard RFC is being requested. The document describes normative multiplexing behavior for media-level SDP attributes when multiplexing media for those "m=" lines on the same media transport. The title page indicates "Standards Track".

(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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

For scenarios where SDP is used to negotiate the usage of single 5-
tuple for sending and receiving media associated with multiple media
descriptions, it is required to understand the semantic implications
of the SDP attributes associated with the RTP Media Streams
multiplexed over a single underlying transport layer flow.

The purpose of this specification is to provide a framework for
analyzing the multiplexing characteristics of SDP attributes.  This
specification also categorizes the existing SDP attributes based on
the framework described herein.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

No.

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

The document was extensively reviewed and discussed by a large number of MMUSIC members (listed in Acknowledgements section).

Personnel

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

The Document Shepherd is Bo Burman.
The Responsible AD is Ben Campbell.

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

The document shepherd read the submitted version of the document fully, with specific focus on IANA aspects, and found no issues.

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

There are no concerns. The document got good review from many MMUSIC members and all comments were addressed.

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

Not applicable.

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

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

The author has confirmed that he does not know of any IPR disclosures that would be required.

(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 have been filed.

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

A large number of key people have commented on the draft in MMUSIC, and all comments are addressed in the current draft.

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

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mmusic-sdp-mux-attributes-12.txt

A few nits are identified, but all are intentional and should be OK:
* The supposedly non-RFC2606-compliant FQDNs are not FQDNs but references to existing 3GPP-defined SDP attributes.
* The use of "NOT RECOMMENDED" is intentionally not in the RFC 2119 boilerplate, because it is never used in regular RFC 2119 sense but instead a defined multiplex category defined in this document.
* Explicit reference to the obsoleted RFC 4091 instead of the replacing RFC 5245 is motivated by explicitly stating that the ANAT semantics from RFC4091 is obsoleted.

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

Not applicable.

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

This document normatively references ietf-mmusic-sdp-bundle-negotiation, which has a normative reference back to this document. The ietf-mmusic-sdp-bundle-negotiation document has no other normative references to Internet Drafts, and has concluded WGLC.

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

The document shepherd made an extensive review of the IANA section and its relation to and consistency with the document body. The IANA registry reference is correct, and the requirements for the new first-come first-serve "Multiplexing Categories" sub-registry is well described. The addition of the new "Mux Category" column to several existing IANA SDP attribute sub-registries is also well described.

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

None.

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

Not applicable.