Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 09 October 2013 22:28 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 4FF0E21E81E7 for <mmusic@ietfa.amsl.com>; Wed, 9 Oct 2013 15:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.228
X-Spam-Level:
X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ65AQzeWKcl for <mmusic@ietfa.amsl.com>; Wed, 9 Oct 2013 15:28:40 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 193AD21E819C for <mmusic@ietf.org>; Wed, 9 Oct 2013 15:28:31 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id b0HX1m0010xGWP854AUXnz; Wed, 09 Oct 2013 22:28:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id bAUX1m00W3ZTu2S3YAUXMD; Wed, 09 Oct 2013 22:28:31 +0000
Message-ID: <5255D88E.1050600@alum.mit.edu>
Date: Wed, 09 Oct 2013 18:28:30 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com>
In-Reply-To: <5255C3A7.6000104@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381357711; bh=p4++TnVErXTLGTihnBZyd4vbV/cJSxgRSXQbAxETbpI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hOSeJtISn5bJvpQT+viI8VOnv0kRKxXKps9n9mZZz9FDivRwADF5MBsbucDTUbfvp HNViukRmC3ADJshiEDnU5OoQd5yRDtRbQVXA8QXT95PlAMWTtfF4gEplBm0FEZ08JW 8/0wCwq9zL229zREuNVLzOZUNVkFtLEfaGDLUUOyx6SWG7bUqLwNhFkJtNL1rP3O8h pOxLiXRIFQ8mcoFeAr1bNmbVE7l1LMXulKjoI7tR0/k/ZmckKnvUkNHKm1LJAYp7ou cyNwUMvbRWE7UVD45FUBPd0mpvXqmxgqRfA+eroF0mmmuVI7OKAfF6EebF/+Wtoo1V kBGuZZxmMyAWw==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 09 Oct 2013 22:28:46 -0000

On 10/9/13 4:59 PM, Flemming Andreasen wrote:
>
> On 10/9/13 12:19 PM, Paul Kyzivat wrote:
>> On 10/7/13 6:46 PM, Christian Groves wrote:
>>> Hello Paul,
>>>
>>> Is a process needed to create an errata? Wouldn't the fact that they
>>> appear in standards track RFCs be enough to include them in the SDP
>>> registry based on the SDP directorates (i.e. expert review)
>>> recommendation? I agree its not ideal that these older RFCs didn't
>>> include an IANA considerations section but I think that rather than
>>> spending lots of cycles on this that the SDP directorate could just
>>> request IANA to register them to avoid any future overlap issues.
>>
>> Unfortunately there are rules. The rules for a particular IANA
>> registry are defined when the registry is created. If you check in the
>> registry, it points to RFC4566. Section 8.2.4 of RFC4566 says that
>> additions to this registry must follow the "Specification Required"
>> policy defined in RFC2434. And the specification must include a
>> particular set of information. (That would typically be in an IANA
>> considerations section.)
>>
>> At the moment all we have is RFC3108, and it doesn't have an IANA
>> considerations section at all. It certainly doesn't give the info
>> needed for an addition to that registry.
>>
>> IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I
>> think we will need a new RFC that does it. This should probably be an
>> update to 3108. An errata is perhaps a formal way to trigger that.
>>
> Having previously communicated with one of the RFC 3108 authors on this,
> I would ask for leniency here, not least considering that RFC 3108
> predates RFC 4566. In other words, I'd argue that we should simply add
> the missing registrations.

I wasn't trying to be pejorative - just commenting on what seems 
required to fix it.

We just need *some* RFC to do it. It could be 4566bis. But if it isn't 
one that explicitly updates 3108, then we should take care to instruct 
IANA to make the registry point to 3108.

	Thanks,
	Paul