Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 11 April 2019 16:31 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B0D1202EF for <mmusic@ietfa.amsl.com>; Thu, 11 Apr 2019 09:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 5o3P0QKeMEYJ for <mmusic@ietfa.amsl.com>; Thu, 11 Apr 2019 09:31:46 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 F41BB1203B6 for <mmusic@ietf.org>; Thu, 11 Apr 2019 09:31:45 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3BGVhYa005323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Thu, 11 Apr 2019 12:31:44 -0400
To: mmusic@ietf.org
References: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <8f2f339c-8174-b9b1-8204-78d5ee665574@alum.mit.edu>
Date: Thu, 11 Apr 2019 12:31:43 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/4DRL41w4mSqOD1YPBSBtWGL8aFc>
Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 16:31:48 -0000

On 4/11/19 6:34 AM, Roni Even (A) wrote:
> Hi,
> 
> I got the following comment from IANA:
> 
> Third, Section 9.3 of the current document appears to request the 
> creation of a new registry in the Session Description Protocol (SDP) 
> Parameters registry located at:
> 
> https://www.iana.org/assignments/sdp-parameters/
> 
> IANA Question --> The new registry might be modeled upon the existing 
> att-field (. . . level) registries but instead be a registry for 
> att-field (dcsa level). Is this correct? Would the new registry have the 
> same characteristics as other att-field registries on the registry page? 
> Could the draft be revised to explicitly create the registry, if this is 
> correct? Are there any initial registrations in this new registry?
> 
> My response was
> 
> We are not asking for a new registry,  see 
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-33#section-8.5 
> for  the Reorganization of the att-field Registries.  I now think that 
> this third action is not really needed since it is now defined in 
> rfc4566bis section 8.5 and 8.4
> 
> So I suggest to remove section 9.3 and add to the end of section section 
> 5.2.1

ISTM we actually got a little ahead of ourselves in 4566bis by 
mentioning dcsa and msrp-usage-datachannel.

While 4566bis reorganizes the attribute registries so that we don't need 
a new registry for dcsa, is is draft-ietf-mmusic-data-channel-sdpneg 
that defines the dcsa usage level. The publication of it should result 
in addition of a reference to it in the attribute registry. So I think 
we need an IANA action just to accomplish that.

And maybe the references to dcsa and msrp-usage-data-channel should be 
removed from 4566bis if it isn't too late to do so.

I don't find section 5.2.1 to be an appropriate place for this kind of 
information.

	Thanks,
	Paul

> A data channel specific usage of a subprotocol attribute is expected to 
> be specified
> 
>     in the same document that registers the subprotocol's identifier for
> 
>     data channel usage.
> 
>          SDP attributes that are only defined for use at the
> 
>     dcsa usage level, SHALL use the dcsa usage level when registering the
> 
>     attribute.  If existing media attributes are used in a datachannel
> 
>     subprotocol specific way, then a new dcsa usage level
> 
>     MUST be defined for the existing media attribute.  Where the SDP
> 
>    attribute is applicable to a particular subprotocol/s this SHALL also
> 
>     be registered by indicating the applicable subprotocol identifiers
> 
>     (see 
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section-8.5) 
> along with the dcsa usage level.
> 
> Roni Even
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>