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

Christian Groves <Christian.Groves@nteczone.com> Fri, 11 October 2013 00:17 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 5D96E21F8FDC for <mmusic@ietfa.amsl.com>; Thu, 10 Oct 2013 17:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 O+1Gqcrd4LE6 for <mmusic@ietfa.amsl.com>; Thu, 10 Oct 2013 17:17:41 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id C888621F99F8 for <mmusic@ietf.org>; Thu, 10 Oct 2013 17:17:38 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApQBANhCV1J20Xsy/2dsb2JhbAANTIM/wU9LgTaDGQEBAQMBAQEBGhsbGAMKBgcECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYd8EqZ0HJMqBI1+gVAGhB0DrT+BXQ
Received: from ppp118-209-123-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.123.50]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2013 10:47:37 +1030
Message-ID: <52574393.7010504@nteczone.com>
Date: Fri, 11 Oct 2013 11:17:23 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
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> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu>
In-Reply-To: <5257269D.6080600@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Fri, 11 Oct 2013 00:17:42 -0000

Hello Paul,

On 11/10/2013 9:13 AM, Paul Kyzivat wrote:
> On 10/9/13 6:47 PM, DRAGE, Keith (Keith) wrote:
>> We don't need an RFC to do it. We existed for years without an IANA 
>> registration section but still had IANA registrations.
>>
>> My understanding of the current rule is that they need to exist, and 
>> give instructions on how to write them. This is to make their job 
>> easier and their output more efficient. There is nothing that says 
>> that IANA cannot address issues regarding missing material from 
>> reading the rest of the RFC. After all, the entire RFC has IETF 
>> consensus.
>
> Repeating what I just posted in another thread:
>
> Just request it *how*?
[CNG] Email? Surely if one of the MMUSIC chairs sends an email 
highlighting the situation that the original registrations were missed 
and point to the agreed standards tracks RFCs this can be considered. 
IANA works with experts all the time to manage these pages. If I find an 
error in the registry I'm responsible for its just a matter of sending 
an email indicating what the issue is.

> If IANA receives an email asking them to make a change, they won't be 
> doing their job unless they consult the existing registry and check 
> the rules for changes/additions. If the rules call for an rfc and a 
> specific template, then they need an rfc with that template filled out.
[CNG] I think we need to recognise that what we are trying to do is fix 
an error not do a brand new registration.

> Note that these templates often carry information that isn't captured 
> in the registry itself - depending on the registry reference to the 
> document.
>
>     Thanks,
>     Paul
>
>> Keith
>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On 
>>> Behalf
>>> Of Paul Kyzivat
>>> Sent: 09 October 2013 23:29
>>> To: Flemming Andreasen
>>> Cc: mmusic@ietf.org
>>> Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 
>>> values
>>>
>>> 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
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>