Re: [MMUSIC] Alissa Cooper's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with DISCUSS and COMMENT)

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 09 August 2019 21: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 44D081200B8; Fri, 9 Aug 2019 14:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 74XH4NmVrEsZ; Fri, 9 Aug 2019 14:31:54 -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 09F82120077; Fri, 9 Aug 2019 14:31:53 -0700 (PDT)
Received: from Kokiri.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 x79LViUm024375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2019 17:31:44 -0400
To: Adam Roach <adam@nostrum.com>, Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>
Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-rfc4566bis@ietf.org, mmusic@ietf.org
References: <155907213212.25802.10923362703417281306.idtracker@ietfa.amsl.com> <da24d89f-79cc-3fcc-aaad-4753cc552b3b@alum.mit.edu> <e3baf0e3-831b-7286-fbb4-c76758e12c7a@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <dc79777e-a989-1e44-6471-e20efc1bd670@alum.mit.edu>
Date: Fri, 09 Aug 2019 17:31:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <e3baf0e3-831b-7286-fbb4-c76758e12c7a@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/o20ue7X-peEk_ccKlzJZRNz23_Q>
Subject: Re: [MMUSIC] Alissa Cooper's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with DISCUSS and COMMENT)
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: Fri, 09 Aug 2019 21:31:57 -0000

Alissa & Adam,

Regarding the specification of fields to be included in IANA registries:

I just submitted -37. It now is explicit about both what must be 
specified in the document and what of that is to be included in the 
registries.

	Thanks,
	Paul

On 7/24/19 8:45 AM, Adam Roach wrote:
> On 6/3/19 10:36, Paul Kyzivat wrote:
>> Alissa,
>>
>> On 5/28/19 3:35 PM, Alissa Cooper via Datatracker wrote:
>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> Section 8.2.8:
>>>
>>> "In the RFC specifications that register new values for SDP "media",
>>>     "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the
>>>     authors MUST include the following information for IANA to place in
>>>     the appropriate registry:"
>>>
>>> It doesn't look like all the fields that are listed after this text 
>>> actually
>>> appear in the registries. For some of these I don't see why the 
>>> information
>>> would be put into the registries (e.g., contact name, contact email 
>>> address,
>>> since those appear in the RFCs themselves). I think this needs to be 
>>> clarified.
>>
>> OK. There are two things going on here: the information that must be 
>> provided when registering a new value, and then which of those items 
>> need to appear in the registry. The distinction isn't clear.
>>
>> For items where the registration requirements are less that "document 
>> required" the information must be in the registry since there is no 
>> place else for it to appear. But when a document is required then in 
>> principle the name of the item and a reference to the document is all 
>> that is *necessary* in the registry, and any additional information is 
>> for convenience of access.
>>
>> I've found that this distinction often isn't clearly made, especially 
>> in older stuff.
>>
>> I can look into this further for all the SDP registries. 
> 
> 
> Paul --
> 
> I see that there are some changes in -36 around this text ("IANA will 
> populate its registries with some or all of these values"). This isn't 
> really clear enough for IANA to know what to do. Could you produce a new 
> version that is explicit regarding which of these collected fields are 
> published? (e.g.: "IANA will populate its registries with the parameter 
> name, the parameter type, and the document reference.")
> 
> Thanks.
> 
> /a
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic