Re: [MMUSIC] IANA registration of SDP attributes

Christian Groves <Christian.Groves@nteczone.com> Tue, 29 March 2016 05:28 UTC

Return-Path: <Christian.Groves@nteczone.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 E1A2812D0FB for <mmusic@ietfa.amsl.com>; Mon, 28 Mar 2016 22:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 m1FCs2h8azwu for <mmusic@ietfa.amsl.com>; Mon, 28 Mar 2016 22:28:26 -0700 (PDT)
Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 A06D712D0C0 for <mmusic@ietf.org>; Mon, 28 Mar 2016 22:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=uJEsnh5Xu4HqskWmZdYXKGOX3An00snwAj/ma21R7BQ=; b=GlNY8LePVTZzo+Z/Y8QLZrU+ux Mq+BuPcIYS7eZdaM8aPlmSwUp74Dqb0rUgbO+YcXfRTZ8xuU80w3zzyPC7XliCwq5687tNsY+/NqB qV0LTWJzAbGeoVBf6eZKIbjj4oXll3y7pxqDNkQyByWS7qPHOSVgbmIODgawNqEa6L/Y2O+2oRrlI Gc1uxN2QAHYnhldka0Bki7wXcvEOeMbsIgI+XvDsGMzZhxB3jg6g8/K1qWCJd1O0GWqsnQiUu20To lL92WVdy5oKjU8vagfJuRrj+7drgRZYOeFnWH/OHCjX6JwDDABgavuspy4Ga1lgHTvpO5XgOeh85S ox8WrusA==;
Received: from ppp118-209-160-233.lns20.mel8.internode.on.net ([118.209.160.233]:51951 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from <Christian.Groves@nteczone.com>) id 1akmCV-003QrZ-ET for mmusic@ietf.org; Tue, 29 Mar 2016 16:28:23 +1100
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>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <56FA126E.30003@nteczone.com>
Date: Tue, 29 Mar 2016 16:28:14 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56F311CA.4090606@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh03.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/2WM7mRp6TWj4Ipb2X2-aKM51foE>
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 05:28:29 -0000

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?

[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?

>
> 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.
[CNG] This is the big issue. It will mean an effort to bring the 
registry up to the current state and more effort to ensure that it 
remains current. It probably comes down to whether people see the 
registry as a simple tool to register unique names or something more.
>
> 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.)
[CNG] Yes
>
> 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.
[CNG] Agree
>
>
>     Thanks,
>     Paul
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>