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

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

Hi Suhas,

Thank you for your answer. Please see in-text.

Please start using [e-mail]<mailto:[e-mail]> as my preferred mail address. I will be retiring in two weeks (but continuing the IETF activities) and my Avaya address will soon become inactive.

Regards,

Dan


From: Suhas Nandakumar (snandaku) [mailto:[e-mail]]
Sent: Thursday, August 18, 2016 9:29 PM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: [e-mail]; Suhas Nandakumar (snandaku)
Subject: Re: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13


Hello Dan



 Many thanks for your review. Apologies for the delayed response ( I just got back from vacation)



Please see inline for responses to concerns raised (with [[Suhas]] Markings)





Cheers

Suhas Nandakumar

________________________________
From: Romascanu, Dan (Dan) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, August 8, 2016 9:01 AM
To: General Area Review Team
Cc: [e-mail]<mailto:[e-mail]>
Subject: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13


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<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=CwMF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=PcQwHEKZLeS5MO2yvCwLJ4Fw9Hwy3yLx9o4SH0yYZdw&s=yqb8cDj2OZ4NM4x6XD935ttCnC_-FK75_uOi0j0ZgDU&e=>



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.



[[Suhas]] - Section 15.XXX defines the following ways of dealing with the future extensions



a) Adding a new Multiplexing category

   The process here is to have a new specification that explains the new Multiplexing category and its purpose in the SDP Attribute multiplexing as defined in Section 15.1



b) Adding a new SDP attribute to any of the sub-registries

    Any future specifications that defines new SDP attributes must analyze the multiplexing characteristics for the newly defined attribute and  specify the appropriate "Mux Category" for the same as well.



c) Updating the category assignments  (Say from TBD to something different)

     This needs a new specification with the updated category. (more details below)



Section 15.2 and its sub-sections defines how the Mux Category for the SDP attributes analyzed in the current draft are added to SDP Parameters IANA registry.



please let me know if we need to add more clarifications on any of the above



DR: thanks, makes sense, but some clarification text would be necessary. My understanding is that the policy to update all the above is 'Specification Required'. This needs to be explicitly stated.



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.



[[Suhas]] - Good point Dan. I see 2 options to progress.



   Option 1 - Same as your suggestion of going with S+M

   Option 2 - Clarify the use of 'B' in Section 5's introductory paragraph as
*         B - Both ( implies attribute applies to both the Session and Media level)

DR: any of the two proposed solutions would work. Option 2 is fine if you prefer it.



The only positive thing about Option 2 is that the changes are minimal. Please advice.



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



[[Suhas]] -- Section 15 defines the following for adding a totally new multiplexing category

"Further entries can be registered on a first-come first-serve basis. Each registration needs to indicate the multiplexing category value to be added to the "Multiplexing Categories" subregistry as defined in this section.

Such a registration MUST also indicate the applicability of the newly defined multiplexing category value to various subregistries defined at "Session Description Protocol (SDP) Parameters"





For the attributes marked as "TBD" category,  the introductory paragraph mentions the following



" Future specifications can change the "TBD" entries to the correct value."



So the plan  of action would be a new specification will be defined to update the "Mux Category" of a given SDP attribute from "TBD" to whatever is appropriate. Thus an update to the current draft is not needed but a new future specification is required for such updates.



DR: good, same comment as at the first (major) issue applies - adding some explanatory text would clarify for future readers and users of this specification.







Nits/editorial comments:

1.       In the table at 5.6 - repetition 'section Section'

[[Suhas]] -- Thanks for catching this. Will fix in the next version.