One document matched: draft-arkko-rfc2780-proto-update-00.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="full3978" docName="draft-arkko-rfc2780-proto-update-00" category="std" updates="2780">
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<front>

<title abbrev="Protocol Field IANA Rules">IANA Allocation Guidelines for the Protocol Field</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street />
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>

<date month="November" year="2007" />

<keyword>IANA rules</keyword>
<keyword>IPv4</keyword>
<keyword>IPv6</keyword>
<keyword>Protocol field</keyword>
<keyword>Next header field</keyword>

<abstract>

<t>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.
</t>

</abstract>

</front>
<middle>

<section title="Introduction">

<t>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.</t>

<t>Previously, RFC 2780 allowed such allocations to happen through
IESG Approval, Standards action, or Expert Review processes <xref
target="RFC2780"/><xref target="RFC2434"/>. The Expert Review process
was specified to be used only in the case where a non-disclosure
agreement was involved:</t>

<list style="empty">

<t>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.</t>

</list>

<t>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 <xref
target="RFC4727">RFC 4727</xref> 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.</t>

<t>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.</t>

<t>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.</t>

</section>

<section title="IANA Considerations">

<t>This document replaces the current rule in section 4.3 with the
following:</t>

<list style='empty'>
     <t>IANA allocates values from the IPv4 Protocol name space following
     an IESG Approval or Standards Action process.</t>
</list>

<t>This document makes no change to the rule for the IPv6 Next Header
field in Section 5.3 but notes that the rule in section 4.3 that is
referred to is the revised one without the Expert Review option.</t>

</section>

<section title='Security Considerations'>
<t>This specification does not change the security properties
of the affected protocols.</t>
</section>

<section title="Acknowledgments">

<t>Issues with the original RFC 2780 rules were uncovered in
discussions of the IETF - IANA team. The team also provided background
information on the practical difficulties encountered with
non-disclosure agreements.  The authors would like to thank Thomas
Narten, Bill Fenner, and Michelle Cotton in particular.</t>

</section>

</middle>
<back>

<references title="Normative References">
      <?rfc include="reference.RFC.2434.xml"?>
      <?rfc include="reference.RFC.2780.xml"?>
</references>

<references title="Informative References">
      <?rfc include="reference.RFC.4727.xml"?>
</references>

</back>
</rfc>