[Gen-art] Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13

["Romascanu, Dan (Dan)" <[e-mail]>]

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'