I-D Action:draft-arkko-rfc2780-proto-update-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IANA Allocation Guidelines for the Protocol Field
	Author(s)       : J. Arkko, S. Bradner
	Filename        : draft-arkko-rfc2780-proto-update-00.txt
	Pages           : 5
	Date            : 2007-11-05

This document revises the IANA guidelines for allocating new Protocol
field values in IPv4, as well as new Next Header field values in
IPv6.  It modifies the rules specified in RFC 2780 by removing the
Expert Review option.1.  Introduction

This document revises the IANA guidelines for allocating new Protocol
field values in IPv4.  The same guidelines will also apply for IPv6
Next Header values.

Previously, RFC 2780 allowed such allocations to happen through IESG
Approval, Standards action, or Expert Review processes
[RFC2780, RFC2434].  The Expert Review process was specified to be
used only in the case where a non-disclosure agreement was involved:

IANA allocates values from the IPv4 Protocol name space following

an Expert Review, IESG Approval or Standards Action process.  The

Expert Review process should only be used in those special cases

where non- disclosure information is involved.  In these cases the

expert(s) should be designated by the IESG.

The need for the Standards Action rule is obvious as the IETF keeps
developing new protocols.  It is equally obvious that there is a need
to allow experimental allocations in this space, see RFC 4727
[RFC4727] for an example.  Similarly, there are cases when it makes
sense to allocate values out of this space for other non- Standards
Track or non-IETF uses.  However, the size of the field is 256
values, and 55% of these were in use at the time this document was
written.  As a result, a sanity check is needed to ensure that
allocations are not made needlessly.  RFC 2780 specifies the IESG
Approval rule to take care of these sanity checks for the non-
Standards Track cases.  The judgment call can take into account the
existence of a stable protocol specification, constituency that wants
to use it, need to avoid duplicated allocations for the same purpose,
whether protocol number allocation is the right solution for this
problem as opposed to, say, a TCP port, and so on.

However, we now believe that the non-disclosure agreement option is
not appropriate for allocations in this space.  Traditionally, non-
disclosure agreements have been used by the IANA when a company was
developing a proprietary protocol and did not want to disclose new
areas of research or future products.  The protocol space is limited
enough that we no longer believe that it is reasonable to use of the
resource for such proprietary protocols.  Thus, we believe that
allocations should only be made using the IESG Approval or Standards
Action processes when there are public specifications that can be
reviewed.

As a result, this document revises the RFC 2780 rules by removing the
option for Expert Review for the IPv4 Protocol and IPv6 Next Header
fields.  This document takes no position on the allocation of other
parameters with non-disclosure agreements, as those parameters may
require different policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arkko-rfc2780-proto-update-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-arkko-rfc2780-proto-update-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-arkko-rfc2780-proto-update-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.