Re: [MMUSIC] IANA registration of SDP attributes

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 23 March 2016 21:59 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 E652212D506 for <mmusic@ietfa.amsl.com>; Wed, 23 Mar 2016 14:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 vOx0XhDk4vfO for <mmusic@ietfa.amsl.com>; Wed, 23 Mar 2016 14:59:40 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 7613712D188 for <mmusic@ietf.org>; Wed, 23 Mar 2016 14:59:40 -0700 (PDT)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by comcast with SMTP id iqoValszqMjYpiqoVaLKMm; Wed, 23 Mar 2016 21:59:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458770379; bh=btb50X74qX7vHuqFLmyRYewPSpwY1n5UX/I5GoSNyFQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=HLEY8FPCDsOZTpqH1357DW9rdo2KvMr80Zg5FYz6obtb9NhrgO9j6cl7QKiVMbNYL l3ss3OmQKvY1LzzkN39bH1eU3J0oJi2P11vZ913dQ4ryeqS/JC7GXXrBUcA75qhYIA 0ic4T6aMnze4U508DS4riT8KkMA++6o64GmZukdEjdVHVNwYcb+29/15Bc85ZM+P5u jHNS2YdCqcmI5wTxCp5L33sRjsax9h3sHVbkW3SHLlbs21BCKvnD14pUirtm+uo4cO jTWHKuvjv66luN+bp1c/ldNN9PVZxNqAQbCg8tICzbYiHORQ6Z1zXln1+WHizUdMo1 FKDN98l/ruiHg==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id ZZze1s00R3KdFy101Zzesu; Wed, 23 Mar 2016 21:59:39 +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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56F311CA.4090606@alum.mit.edu>
Date: Wed, 23 Mar 2016 17:59:38 -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: <56F198C9.3080604@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/rBDgQYBEhzVwnMMoLK7UzTX_Oko>
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: Wed, 23 Mar 2016 21:59:42 -0000

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.

The other thing, that this thread has been discussing, is that this only 
covers definitions of new attributes.

What it doesn't cover are *new* usages of existing attributes. What 
isn't covered are cases that *revise* the definition of an existing 
attribute. For instance, the IANA registry entries for the 'setup' and 
'connection' attributes only reference RFC4145. (For use with TCP.) But 
these attributes are also used in contexts (with proto values) not 
covered by that RFC. For instance, RFC4572 defines a new proto TCP/TLS, 
and reuses 'setup' and 'connection'. The semantics are mostly the same, 
but additional behavior triggered by these is added on. Perhaps the 
registry entries for these attributes should also reference this RFC. In 
principle, in cases where it matters this behavior can be discovered by 
looking up the references for the TCP/TLS proto. But if you are 
particularly interested in what the setup attribute is doing then it 
might not occur to you to look there.

In that case, the relationship to the original definition is pretty 
clear, since it is still TLS over TCP. It is less clear when used with a 
protocol entirely distinct from TCP. For instance we have active drafts 
draft-ietf-mmusic-sctp-sdp and draft-ietf-mmusic-dtls-sdp. These both 
reuse 'setup', and sctp-sdp reuses 'connection', while dtls-sdp has 
chosen an alternative to 'connection'. They also layer on additional 
behavior. And dtls-sdp also forbids use of some of the values defined in 
4145 for setup.

IMO it would be good if the registry for 'setup' referenced all of 
these, and that for 'connection' referenced these with the exception of 
dtls-sdp that doesn't use it. This is because these are extending the 
semantics of the attributes.

But it seems less critical as long as these other documents are 
otherwise discoverable from actual uses. (Such as checking the 
references for the proto value in the m-line associated with these uses.)

But IMO it would be essential if the syntax of the attribute is revised.

As you can see, I am a bit ambivalent on this. That is why I think it 
needs discussion.

	Thanks,
	Paul