Last Call Review of draft-ietf-mmusic-sdp-mux-attributes-13
review-ietf-mmusic-sdp-mux-attributes-13-genart-lc-romascanu-2016-08-08-00

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-mmusic-sdp-mux-attributes-13

Reviewer: Dan Romascanu

Review Date: 8/8/16

IETF LC End Date: 8/10/16

IESG Telechat date: not known



Summary:



Ready with issues.



Major issues:

1.



My understanding is that this document undertakes the task of analyzing the
multiplexing characteristics of the SDP attributes and classifying them based
on this analysis. It also adds one new ‘Multiplexing Category’
 registry, a ‘Mux Category’ column and new attributes to a number of SDP
 sub-registries. What is not clear to me is what is the process by which new
 attribute values are to be added. The sub-registries in 15.2.x – can new
 values be added? Or new  sub-registries created because of the need to support
 a new protocol that defined SDP attributes? What is the policy and the
 registration process? I hope that my question makes sense, in case it does
 not, please explain why.



Minor issues:

1.



The use of B - ‘Both’ terminology used to indicate that an attribute is
specified S - Session Level and M - Medial Level (e.g. in Section 5) may be
confusing, as there is a third possible level SR - Source Level.
 Actually S + M would probably be more clear.

2.



Section 5.54 includes a note referring to the TBD content. ‘As per section 9.1
of [I-D.ietf-mmusic-sdp-bundle-negotiation],  there exists no publicly
available specification that defines procedures for multiplexing/demultiplexing
 fax protocols flows over a single 5-tuple.  Once such a specification is
 available, the multiplexing category assignments for the attributes in this
 section could be revisited.’ Assuming the missing specification will be
 publicly available sometime in the future – how will this information be
 added? Revise this RFC? The question applies to other TBD marked in the ‘Mux
 Category’ column of the tables in Section 5 (in 5.42, 5.44, …)



Nits/editorial comments:

1.



In the table at 5.6 – repetition ‘section Section’