Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1810712B00D for ; Mon, 22 Aug 2016 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.458 X-Spam-Level: X-Spam-Status: No, score=-5.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnP1-kYRobgQ for ; Mon, 22 Aug 2016 01:39:25 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1954612B00A for ; Mon, 22 Aug 2016 01:39:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EgAgADubpX/xUHmMZeGgEBAQGCWCEtV?= =?us-ascii?q?nwHhUaHYJ4cjC6BPUAjgW+ECwKBRTgUAQEBAQEBAQEBA1snQQ4BggM5BgcuAQE?= =?us-ascii?q?BAQEBASMCDyAPEgEBGQEBAQEDDAYbTBACAQgNBAIBAQEBCxYBBgchERQJCAEBB?= =?us-ascii?q?AENBQgTB4d1AxcBDaJZlhQNhA4BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiyETIJ?= =?us-ascii?q?DgWABAR0eBw8Igm6CLwWUAYUTNAGGH4Y6AYQxhFyDJ4VghmmBToQIg3geNoFXg?= =?us-ascii?q?iNwAQEBggqDODcBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EgAgADubpX/xUHmMZeGgEBAQGCWCEtVnwHhUaHYJ4cjC6?= =?us-ascii?q?BPUAjgW+ECwKBRTgUAQEBAQEBAQEBA1snQQ4BggM5BgcuAQEBAQEBASMCDyAPE?= =?us-ascii?q?gEBGQEBAQEDDAYbTBACAQgNBAIBAQEBCxYBBgchERQJCAEBBAENBQgTB4d1Axc?= =?us-ascii?q?BDaJZlhQNhA4BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiyETIJDgWABAR0eBw8Ig?= =?us-ascii?q?m6CLwWUAYUTNAGGH4Y6AYQxhFyDJ4VghmmBToQIg3geNoFXgiNwAQEBggqDODc?= =?us-ascii?q?BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,559,1464667200"; d="scan'208,217";a="202145050" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Aug 2016 04:39:21 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 22 Aug 2016 04:39:20 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0294.000; Mon, 22 Aug 2016 04:39:18 -0400 From: "Romascanu, Dan (Dan)" To: "Suhas Nandakumar (snandaku)" , "General Area Review Team" Thread-Topic: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13 Thread-Index: AdHxjh6Ih2VdKT4hSpGkdjOAj1xYSgH6Nh8hALY0bsA= Date: Mon, 22 Aug 2016 08:39:17 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7E274D6E@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA752668EC@AZ-FFEXMB04.global.avaya.com> <1471544958618.96373@cisco.com> In-Reply-To: <1471544958618.96373@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA7E274D6EAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mmusic-sdp-mux-attributes.all@tools.ietf.org" , "dromasca@gmail.com" Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 08:39:28 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA7E274D6EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Suhas, Thank you for your answer. Please see in-text. Please start using dromasca@gmail.com as my pref= erred mail address. I will be retiring in two weeks (but continuing the IET= F activities) and my Avaya address will soon become inactive. Regards, Dan From: Suhas Nandakumar (snandaku) [mailto:snandaku@cisco.com] Sent: Thursday, August 18, 2016 9:29 PM To: Romascanu, Dan (Dan); General Area Review Team Cc: draft-ietf-mmusic-sdp-mux-attributes.all@tools.ietf.org; Suhas Nandakum= ar (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 g= ot back from vacation) Please see inline for responses to concerns raised (with [[Suhas]] Markings= ) Cheers Suhas Nandakumar ________________________________ From: Romascanu, Dan (Dan) > Sent: Monday, August 8, 2016 9:01 AM To: General Area Review Team Cc: draft-ietf-mmusic-sdp-mux-attributes.all@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 t= he IETF Chair. Please treat these comments just like any other last call c= omments. 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 anal= yzing the multiplexing characteristics of the SDP attributes and classifyin= g 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 su= b-registries. What is not clear to me is what is the process by which new a= ttribute values are to be added. The sub-registries in 15.2.x - can new val= ues 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 reg= istration 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 f= uture extensions a) Adding a new Multiplexing category The process here is to have a new specification that explains the new Mu= ltiplexing category and its purpose in the SDP Attribute multiplexing as de= fined 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 speci= fy 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 detail= s 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 r= egistry. please let me know if we need to add more clarifications on any of the abov= e 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 attribu= te 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. Act= ually 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 Medi= a level) DR: any of the two proposed solutions would work. Option 2 is fine if you p= refer it. The only positive thing about Option 2 is that the changes are minimal. Ple= ase 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/d= emultiplexing fax protocols flows over a single 5-tuple. Once such a speci= fication is available, the multiplexing category assignments for the attrib= utes in this section could be revisited.' Assuming the missing specificatio= n will be publicly available sometime in the future - how will this informa= tion 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 mult= iplexing 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 defin= ed multiplexing category value to various subregistries defined at "Session= Description Protocol (SDP) Parameters" For the attributes marked as "TBD" category, the introductory paragraph me= ntions 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 upda= te the "Mux Category" of a given SDP attribute from "TBD" to whatever is ap= propriate. Thus an update to the current draft is not needed but a new futu= re 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 specifi= cation. Nits/editorial comments: 1. In the table at 5.6 - repetition 'section Section' [[Suhas]] -- Thanks for catching this. Will fix in the next version. --_000_9904FB1B0159DA42B0B887B7FA8119CA7E274D6EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Suhas,

 

Thank you for your ans= wer. Please see in-text.

 

Please start using dromasca@gmail.com as my preferred mail address. I will be retiring in = two weeks (but continuing the IETF activities) and my Avaya address will so= on become inactive.

 

Regards,

 

Dan<= /p>

 

 

From: Suhas Na= ndakumar (snandaku) [mailto:snandaku@cisco.com]
Sent: Thursday, August 18, 2016 9:29 PM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-mmusic-sdp-mux-attributes.all@tools.ietf.org; Suhas N= andakumar (snandaku)
Subject: Re: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attribut= es-13

 

Hello Dan

 

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

 

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

 

 

Cheers

Suhas Nandakumar

From: Romascanu, Dan (Dan) <dromasca@avaya.com>
Sent: Monday, August 8, 2016 9:01 AM
To: General Area Review Team
Cc: draft-ietf-mmusic-sdp-mux-attributes.all@tools.ietf.org
Subject: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-1= 3

 = ;

I am the assigned G= en-ART reviewer for this draft. The General Area Review Team (Gen-ART) revi= ews 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 informatio= n, please see the FAQ at

 

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

 

Document: draft-iet= f-mmusic-sdp-mux-attributes-13

Reviewer: Dan Romas= canu

Review Date: 8/8/16=

IETF LC End Date: 8= /10/16

IESG Telechat date:= not known

 

Summary:=

 

Ready with issues.<= o:p>

 

Major issues:<= /o:p>

= 1. &= nbsp;     My understanding is that this document= undertakes the task of analyzing the multiplexing characteristics of the S= DP 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 m= akes sense, in case it does not, please explain why.

=  

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

=  

= a) Adding a new Multiplexing category

=    The process here is to have a ne= w 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 s= ub-registries

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

=  

= c) Updating the category assignments  (S= ay from TBD to something different)

=      This needs a new specific= ation 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 cla= rifications on any of the above

=  

DR: thanks, m= akes sense, but some clarification text would be necessary. My understandin= g is that the policy to update all the above is ‘Specification Requir= ed’. This needs to be explicitly stated.

 

Minor issues:<= /o:p>

1. &nbs= p;     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 thi= rd possible level SR – Source Level. Actually S + M would probably be more clear.<= /o:p>

=  

= [[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 

·       &= nbsp; 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 i= s that the changes are minimal. Please advice.<= /p>

=  

= 2. &= nbsp;     Section 5.54 includes a note referring= to the TBD content. ‘As per section 9.1 of [I-D.ietf-mmusic-sdp-bund= le-negotiation],  there exists no publicly available specification tha= t 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 qu= estion 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 fir= st-come first-serve basis. Each registration needs to indicate the multiplexing category value to be added to the "Multiplexing Cate= gories" subregistry as defined in this section.

Such a registration MUST also indicate the appli= cability of the newly defined multiplexing category value to various subreg= istries defined at "Session Description Protocol (SDP) Parameters"

 

 

For the attributes marked as &q= uot;TBD" category,  the introductory paragraph mentions the follo= wing

 

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

 

So the plan  of action wou= ld be a new specification will be defined to update the "Mux Cate= gory" of a given SDP attribute from "TBD" to whatever is app= ropriate. Thus an update to the current draft is not needed but a new future specifi= cation is required for such updates.=

 

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

&nbs= p;

=  

 

Nits/editorial comm= ents:

= 1. &= nbsp;     In the table at 5.6 – repetition= ‘section Section’

= [[Suhas]] -- Thanks for catching this. Will f= ix in the next version.

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA7E274D6EAZFFEXMB04globa_--