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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Fri, 11 October 2013 06:36 UTC

Return-Path: <keith.drage@alcatel-lucent.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 23F0521F9FF3 for <mmusic@ietfa.amsl.com>; Thu, 10 Oct 2013 23:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 hkm8APk-zvZj for <mmusic@ietfa.amsl.com>; Thu, 10 Oct 2013 23:35:54 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A73B921F9EAF for <mmusic@ietf.org>; Thu, 10 Oct 2013 23:35:54 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9B6ZmqO002956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Oct 2013 01:35:49 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9B6ZkBk022684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 08:35:46 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 11 Oct 2013 08:35:46 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] Updating SDP parameter registry with RFC3108 values
Thread-Index: AQHOxQuw3vE+5VfpPkSFvZv7z22ypZnugeoAgACFhgA=
Date: Fri, 11 Oct 2013 06:35:45 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0B6174@FR712WXCHMBA11.zeu.alcatel-lucent.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> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu>
In-Reply-To: <5257269D.6080600@alum.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <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: Fri, 11 Oct 2013 06:36:00 -0000

In regard to "how" just write an email or fill out the form on the IANA main page.

And it works in exactly the same way as when the material exists in the IANA considerations section but has not been correctly implemented by IANA. We don't have to go and write a new RFC in that case.

The IANA sections of RFCs are there to provide a convenient means for IANA to find the information they need, not the arbiter of whether the information can be included in a registry or not.

The arbiter of whether the information can be included in the registry or not is the registration policy of that registry. Even if the registration policy is RFC required, if it is somewhere else in the RFC, then IANA can still use that information. Regardless, all of this will take place in conjunction with the appropriate experts to ensure that a mistake does not occur. IANA consult on anything they are not sure of.

As for formatting of the information - we help them as much as possible with the IANA considerations section, but that is all it is "considerations". IANA have total flexibility in this area.

Keith

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] 
> Sent: 10 October 2013 23:14
> To: DRAGE, Keith (Keith)
> Cc: Flemming Andreasen; mmusic@ietf.org
> Subject: Re: [MMUSIC] Updating SDP parameter registry with 
> RFC3108 values
> 
> 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*?
> 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.
> 
> 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
> >
> 
>