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

"Roni Even (A)" <roni.even@huawei.com> Thu, 11 April 2019 10:34 UTC

Return-Path: <roni.even@huawei.com>
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 6C09712004D; Thu, 11 Apr 2019 03:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 WWPKXxLIEuZ5; Thu, 11 Apr 2019 03:34:55 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 37A57120044; Thu, 11 Apr 2019 03:34:55 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 43252390BB843AA18E83; Thu, 11 Apr 2019 11:34:53 +0100 (IST)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 11:34:52 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 18:34:08 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
CC: "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
Thread-Index: AdTwT5OIKFVlXaa2S8ClvVSnITuzDg==
Date: Thu, 11 Apr 2019 10:34:08 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.102]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CDB681dggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/RGjKk_zxdyhhKuQEeak0AIwd-6g>
Subject: [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 10:34:57 -0000

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





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