"designated expert" to advise it in assignment matters.  That is, the
   IANA forwards the requests it receives to a specific point-of-contact
   (one or a small number of individuals) and acts upon the returned
   recommendation from the designated expert. The designated expert can
   initiate and coordinate as wide a review of an assignment request as
   may be necessary to evaluate it properly.

   Designated experts are appointed by the relevant Area Director of the
   IESG. They are typically named at the time a document that creates a
   new numbering space is published as an RFC, but as experts originally
   appointed may later become unavailable, the relevant Area Director
   will appoint replacements if necessary.

   Any decisions made by the designated expert can be appealed using the
   normal IETF appeals process as outlined in Section 6.5 of [IETF-
   PROCESS]. Since the designated experts are appointed by the IESG,
   they may be removed by the IESG.









 
RFC 2434           Guidelines for IANA Considerations       October 1998


   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).










 
RFC 2434           Guidelines for IANA Considerations       October 1998


      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]