Re: [MMUSIC] IANA registration of SDP attributes

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 29 March 2016 18:17 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 0518612E240 for <mmusic@ietfa.amsl.com>; Tue, 29 Mar 2016 11:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.874
X-Spam-Level:
X-Spam-Status: No, score=0.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=2.099, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 V12IkE4cI3sl for <mmusic@ietfa.amsl.com>; Tue, 29 Mar 2016 11:17:33 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [69.252.207.34]) (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 8795812DB36 for <mmusic@ietf.org>; Tue, 29 Mar 2016 10:49:34 -0700 (PDT)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by comcast with SMTP id kxkhaGEd023jlkxkoauI99; Tue, 29 Mar 2016 17:48:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459273714; bh=l1/kdGp2j0cEMFG8/v1opfXahkJnasVjKN8XNmsDXZI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=vnNNTyAfr2EbpWTOEiMHNEAYouhIedQCRfNHv+S6Rs77yJtIUItM36BIBFjCDeGcS m78VwThizW+8YAwSe1jQ3MJPnrtXXeKK0Tyx07G6fK1C3Es0zblKMgM5+q7YRkG3ix emEZ2T0fD20V9/mvdnFRiBBglBmtOLDlU+vzsDpg1fy3NO4GlxKrXlHDDk89fwMjcN 0+A0vqn5CghQlKea4SqH6eyc92uUlhk7f6Bvd5SUgXMmoFEepXePOZA6+4iGj4kgWc dUzHZHC+7OZF04nB0SzeJBdGTAhfdIzC+YO6uSo8v2yCxJ3MD8qewugYINovKrJJKs JGqMTJgOwIc/A==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id btoa1s0013KdFy101toacr; Tue, 29 Mar 2016 17:48:34 +0000
To: mmusic@ietf.org
References: <56E1C193.1050308@alum.mit.edu> <56E2EF31.2020808@alcatel-lucent.com> <56E2F67D.7060005@alum.mit.edu> <56EE0AA1.3030502@nteczone.com> <56EEE286.5090505@alum.mit.edu> <56F09E03.5020200@nteczone.com> <56F198C9.3080604@cisco.com> <56F311CA.4090606@alum.mit.edu> <56FA126E.30003@nteczone.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56FABFF0.6060809@alum.mit.edu>
Date: Tue, 29 Mar 2016 13:48:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <56FA126E.30003@nteczone.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/yUHrDA2R6Vc5i4DvE2nPQPRLzww>
Subject: Re: [MMUSIC] IANA registration of SDP attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 29 Mar 2016 18:17:37 -0000

On 3/29/16 1:28 AM, Christian Groves wrote:
> Hello Paul,
>
> Please see below.
>
> Regards, Christian
>
> On 24/03/2016 8:59 AM, Paul Kyzivat wrote:
>> On 3/22/16 3:11 PM, Flemming Andreasen wrote:
>>
>>> Do we have a volunteer to drive the discussion there ?
>>
>> OK. I'll volunteer.
>>
>> The starting point for this discussion is the current text of section
>> 8.2.4 of rfc4566bis-16.
>>
>> Looking at that, one thing leaps out at me:
>>
>> There is a long list of "stuff" that must be provided when defining a
>> new attribute. IMO it is all *good* stuff, that should be provided.
>> But it also strikes me that it will be difficult for IANA to evaluate
>> the adequacy of this stuff itself. So we might want to require an
>> expert review as a gate to registration.
> [CNG] What's the role of the SDP directorate in relation to this? I
> guess they would check any RFC defined attributes but that non-RFCs
> would also need to be checked? How much of this should be visible on the
> IANA registry page?

The SDP directorate will only be invoked for ietf documents. The policy 
for attributes is Specification Required, so it might be a document from 
another SDO, ore even no SDO. In those cases there would be no SDP 
directorate review.

After refreshing my memory about the definition of Specification 
Required, I see that it implies Expert Review. (Flemming is currently 
listed as the expert.) That may be good enough, though we might want to 
beef up the requirements in section 8.2.4 of 4566bis.

The hard part is seeing to any new actions when *existing* attributes 
are used in new ways. For that I think the SDP Directorate is all we 
have to check for that sort of thing. I wonder if there ought to be a 
checklist of things for SDP Directorate reviews.

And of course *that* also will only work for IETF documents. If somebody 
outside the IETF defines a new use for an existing attribute then we 
have no mechanism to notice that and trigger an update to the registry.

> [CNG] Also in 8.2.4 there's bullet points for "Attribute Name" and "An
> ABNF definition..." both these mention ABNF definitions. What's the
> distinction?

You are referring to:

    o  Attribute value: The name of an ABNF syntax rule defining the
       syntax of the value.  Absence of a rule name indicates that the
       attribute takes no value.  Enclosing the rule name in "[" and "]"
       indicates that a value is optional.
...
    o  An ABNF definition of the attribute value rule.  The rule MUST NOT
       match anything that is not also matched by <att-value>.  The rule
       name MUST NOT be defined as an Incremental Alternative to <att-
       value>.

The first of those is the *name* of an ABNF rule. The 2nd is the 
*definition* of that rule.

I split it up that way in order to avoid including an ABNF rule for the 
whole attribute (including the "a=") because that has been a problem.

	Thanks,
	Paul