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) <droma...@avaya.com> Sent: Monday, August 8, 2016 9:01 AM To: General Area Review Team Cc: draft-ietf-mmusic-sdp-mux-attributes....@tools.ietf.org 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 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 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) 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. Nits/editorial comments: 1. In the table at 5.6 – repetition ‘section Section’ [[Suhas]] -- Thanks for catching this. Will fix in the next version.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
