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.

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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to