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

Adam Roach <adam@nostrum.com> Wed, 24 July 2019 12:45 UTC

Return-Path: <adam@nostrum.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 09D9212032A for <mmusic@ietfa.amsl.com>; Wed, 24 Jul 2019 05:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 5yautmHw6UL8 for <mmusic@ietfa.amsl.com>; Wed, 24 Jul 2019 05:45:51 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E8D120164 for <mmusic@ietf.org>; Wed, 24 Jul 2019 05:45:51 -0700 (PDT)
Received: from Orochi.local ([196.52.21.205]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6OCjjP2096368 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Jul 2019 07:45:47 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563972350; bh=v4Nmi+mngzZPYeJPRFMsuLWSEETaHwWaBGTVxQsiJok=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=pVWqak8I/D88ZrmxYpSaFhLQpcgn65ZlQ6HgN/5IbPdb1G/LeENNnhFpwfsW/Q22f AbhAbmYudr5pn275LiRwNS/FmZs2RhTJhnlQmgyLaSEqgcJvyWoIA4ZZmRlDTMl8DZ nB8hfSSc/tKP2ukqI+TpwhYuiLZMBjLaH3WwZk8U=
X-Authentication-Warning: raven.nostrum.com: Host [196.52.21.205] claimed to be Orochi.local
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, 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>
From: Adam Roach <adam@nostrum.com>
Message-ID: <e3baf0e3-831b-7286-fbb4-c76758e12c7a@nostrum.com>
Date: Wed, 24 Jul 2019 08:45:45 -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: <da24d89f-79cc-3fcc-aaad-4753cc552b3b@alum.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/0Ua3yk60CYaPH2oe7_yXnIFqYcA>
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: Wed, 24 Jul 2019 12:45:55 -0000

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