Subject: [Sip] INFO Framework: IANA Registry

From: Eric Burger <[email-masked]>
Date: Wed, 19 Nov 2008 18:46:53 -0600

There was some discussion as to whether the registry for Info Packages  
should be Specification Required, Expert Review, or First Come First  
Served.

Specification Required today means that the specification requires  
expert review.

Expert Review means someone needs to give a cursory review of the  
registration application.

First Come First Served means what it says: send a note to IANA, and  
get a registration (with some basic review).

We can also have two trees, one Specification Required and one  
Private. This has been proven to be an interoperability and marketing  
nightmare, but I will put it out there for completeness.

I would offer we go with First Come First Served.  We can have a field  
for a reference, giving us the best of the specification required (you  
can look up what a published specification is) and Private (if you are  
creating a private Info Package, you do not have to specify anything  
other than the package name).

Please Vote:
[ ] First Come First Served with pointer to optional specification
[ ] First Come First Served
[ ] Specification Required
[ ] Expert Review
[ ] Two trees: Specification Required and Private

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Burger <[email-masked]>
Date: Wed, 19 Nov 2008 19:12:17 -0600

By the way, the reference for IANA Considerations is now RFC 5226. To  
whit:

       Private Use - For private or local use only, with the type and
             purpose defined by the local site.  No attempt is made to
             prevent multiple sites from using the same value in
             different (and incompatible) ways.  There is no need for
             IANA to review such assignments (since IANA does not record
             them) and assignments are not generally useful for broad
             interoperability.  It is the responsibility of the sites
             making use of the Private Use range to ensure that no
             conflicts occur (within the intended scope of use).

       First Come First Served - Assignments are made to anyone on a
             first come, first served basis.  There is no substantive
             review of the request, other than to ensure that it is
             well-formed and doesn't duplicate an existing assignment.
             However, requests must include a minimal amount of clerical
             information, such as a point of contact (including an email
             address) and a brief description of how the value will be
             used.  Additional information specific to the type of value
             requested may also need to be provided, as defined by the
             namespace.  For numbers, the exact value is generally
             assigned by IANA; with names, specific text strings can
             usually be requested.

       Expert Review (or Designated Expert) - approval by a Designated
             Expert is required.  The required documentation and review
             criteria for use by the Designated Expert should be  
provided
             when defining the registry.  For example, see Sections 6  
and
             7.2 in [RFC3748].

       Specification Required - Values and their meanings must be
             documented in a permanent and readily available public
             specification, in sufficient detail so that  
interoperability
             between independent implementations is possible.  When  
used,
             Specification Required also implies use of a Designated
             Expert, who will review the public specification and
             evaluate whether it is sufficiently clear to allow
             interoperable implementations.  The intention behind
             "permanent and readily available" is that a document can
             reasonably be expected to be findable and retrievable long
             after IANA assignment of the requested value.  Publication
             of an RFC is an ideal means of achieving this requirement,
             but Specification Required is intended to also cover the
             case of a document published outside of the RFC path.  For
             RFC publication, the normal RFC review process is expected
             to provide the necessary review for interoperability,  
though
             the Designated Expert may be a particularly well-qualified
             person to perform such a review.

On Nov 19, 2008, at 6:46 PM, Eric Burger wrote:

> There was some discussion as to whether the registry for Info  
> Packages should be Specification Required, Expert Review, or First  
> Come First Served.
>
> Private. This has been proven to be an interoperability and  
> marketing nightmare, but I will put it out there for completeness.
>
>
> I would offer we go with First Come First Served.  We can have a  
> field for a reference, giving us the best of the specification  
> required (you can look up what a published specification is) and  
> Private (if you are creating a private Info Package, you do not have  
> to specify anything other than the package name).
>
> Please Vote:

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Nov 2008 01:01:16 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Burger
> Sent: 20 November 2008 00:47
> To: SIP List
> Subject: [Sip] INFO Framework: IANA Registry
> 
> Packages  
> marketing  
> [X] First Come First Served with pointer to optional specification

John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Nov 2008 20:16:19 -0500

Eric Burger wrote:

> We can also have two trees, one Specification Required and one Private. 
> This has been proven to be an interoperability and marketing nightmare, 
> but I will put it out there for completeness.

Can you say more? Why would it be more of a nightmare than FCFS?

> [X] Two trees: Specification Required and Private

IMO this is better than FCFS with pointer because it gives a higher 
degree of legitimacy to those with specifications, which provides an 
incentive to get that.

But I will make FCFS w/opt spec my 2nd choice.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Wed, 19 Nov 2008 19:52:37 -0600

The nightmare is the proliferation of X-mumble (e-mail), P-mumble  
(SIP), g.mumble, etc., especially when the experiment becomes standard.

I'd much rather have a registration that looks like:

Package Name     Contact                            Reference
keypress         SIP Work Group <[email-masked]>      RFCYYYY
coolpackage      Proprietary Co <[email-masked]>   none

(where RFCYYYY is some standards track RFC)

And then, someday we get

coolpackage      Proprietary Co <[email-masked]>   RFCZZZZ

(where RFCZZZZ is some Informational RFC or link to a stable document)

The multiple tree way gives us X-coolpackage at best and  
com.example.coolpackage at worst, which might make foobar.com not want  
to advertise example.com.  Plus the package name give us a hint to  
what it does...

On Nov 19, 2008, at 7:16 PM, Paul Kyzivat wrote:

>> Private (if you are creating a private Info Package, you do not  
>> have to specify anything other than the package name).
>> Please Vote:

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 02:56:15 +0100

Agreed
 
I do not see separate mileage in separate vendor trees. They only work
to me if we can grandfather some package off another package.
 
Keith

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Burger
	Sent: Thursday, November 20, 2008 1:53 AM
	To: Paul Kyzivat
	Cc: SIP List
	Subject: Re: [Sip] INFO Framework: IANA Registry

	The nightmare is the proliferation of X-mumble (e-mail),
P-mumble (SIP), g.mumble, etc., especially when the experiment becomes
standard. 

	

	And then, someday we get

	(where RFCZZZZ is some Informational RFC or link to a stable
document)

	
	The multiple tree way gives us X-coolpackage at best and
com.example.coolpackage at worst, which might make foobar.com not want
to advertise example.com.  Plus the package name give us a hint to what
it does...

	

		
		Eric Burger wrote:

			We can also have two trees, one Specification
Required and one Private. This has been proven to be an interoperability
and marketing nightmare, but I will put it out there for completeness.

		Can you say more? Why would it be more of a nightmare
than FCFS?

			I would offer we go with First Come First
Served.  We can have a field for a reference, giving us the best of the
specification required (you can look up what a published specification
is) and Private (if you are creating a private Info Package, you do not
have to specify anything other than the package name).

			Please Vote:

			[ ] First Come First Served with pointer to
optional specification

			[ ] Expert Review

			[X] Two trees: Specification Required and
Private

		IMO this is better than FCFS with pointer because it
gives a higher degree of legitimacy to those with specifications, which
provides an incentive to get that.

		Thanks,
		Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Nov 2008 20:59:49 -0500

OK, I agree.

Eric Burger wrote:
> The nightmare is the proliferation of X-mumble (e-mail), P-mumble (SIP), 
> g.mumble, etc., especially when the experiment becomes standard.
> 
> keypress         SIP Work Group <[email-masked] <mailto:[email-masked]>>     
>  RFCYYYY
> coolpackage      Proprietary Co <[email-masked] 
> <mailto:[email-masked]>>   none
> 
> coolpackage      Proprietary Co <[email-masked] 
> <mailto:[email-masked]>>   RFCZZZZ
>