Subject: Re: IANA procedures for GSTN address elements registration

From: Graham Klyne <[email-masked]>
Date: Fri, 19 Mar 1999 13:22:10 +0000

At 23:11 18/03/99 +0100, Claudio Allocchio +39 040 3758523 wrote:
>Hallo,
>during this morning ietf FAX WG meeting we discussed the "IANA 
>Considerations" section contained into the draft-ietf-fax-fulladr-05.txt 
>document.

In RFC 2434, the following suggested options are presented:

   The following are example policies, some of which are in use today:

      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 and assignments are not generally useful for
           interoperability.

           Examples: Site-specific options in DHCP [DHCP] have
           significance only within a single site.  "X-foo:" header
           lines in email messages.

      Hierarchical allocation - Delegated managers can assign values
           provided they have been given control over that part of the
           name space.  IANA controls the higher levels of the namespace
           according to one of the other policies.

           Examples: DNS names, Object Identifiers

      First Come First Served - Anyone can obtain an assigned number, so
           long as they provide a point of contact and a brief
           description of what the value would be used for.  For
           numbers, the exact value is generally assigned by the IANA;
           with names, specific names are usually requested.

           Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP
           and UDP port numbers.

      Expert Review - approval by a Designated Expert is required.

      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible.

           Examples: SCSP [SCSP]

      IESG Approval - New assignments must be approved by the IESG, but
           there is no requirement that the request be documented in an
           RFC (though the IESG has discretion to request documents or
           other supporting materials on a case-by-case basis).

      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG. Typically, the IESG will seek
           input on prospective assignments from appropriate persons
           (e.g., a relevant Working Group if one exists).

           Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
           Family Identifiers [BGP4-EXT].

      Standards Action - Values are assigned only for Standards Track
           RFCs approved by the IESG.

           Examples: MIME top level types [MIME-REG]

>- We could state that any new IANA registration SHOULD be supplemented by a 
>Standard track RFC. This leaves the way open also to experimental RFCs 
>and eventually to externally defined specifications (like ITU ones).

I think this corresponds to "standards action" above.

>- We could state that any new IANA registration MUST be supplemented by
>a "fully specified and stable specification". This has the same 
>consequences as the above sentence, but is even more "open" to external 
>specification, including for example proprietary specification which 
>wishes to register c/o IANA their services.

I think thjis coresponds to "Specification Required".

>- We could state the any new IANA registration MAY be supplemented by a 
>"fully specified and stable specification". This is the less strict 
>requirement and leaves anybody free to register anything, without the 
>need of an accompanying document.

This seems to be another instance of "Specification Required".

In view of the fact that (I assume) RFC 2434 has been prepared with IANA's
position in mind, I think it would be appropriate to select from and
reference that document, rather than try to invent a new registration
criterion.

For "service selector", I think "IETF consensus" or "standards action" is
appropriate.  For address qualifiers, I think "specification required" is
appropriate.

#g

------------
Graham Klyne
([email-masked])

---

From: Claudio Allocchio +39 040 3758523 <[email-masked]>
Date: Fri, 19 Mar 1999 17:13:04 +0100

> appropriate.  For address qualifiers, I think "specification required" is

I think that we should choose the same level of "approval" both for 
service-selector and qualifiers, using as a minimum "specification 
required", then "IETF consensus" and as a top "standard action".

However it would be just for clarity with implementors... and Graham 
suggestion is also acceptable. 

Other comments? 

Claudio

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 21 Mar 1999 17:04:04 -0800

>required", then "IETF consensus" and as a top "standard action".

I agree that the same level should be used on both, and I think that level 
should be "specification required".

--Paul Hoffman, Director
--Internet Mail Consortium