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

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

<rfc ipr="full3978" docName="draft-arkko-rfc2780-proto-update-02" 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="January" year="2008" />

<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 header. It modifies the rules specified
in RFC 2780 by removing the Expert Review option. The change will also
affect the allocation of Next Header field values in IPv6.
</t>

</abstract>

</front>
<middle>

<section title="Introduction">

<t>This document revises the IANA guidelines <xref target='RFC2780'/>
for allocating new Protocol field values in IPv4 header <xref
target='RFC0760'/>. The change will also be applicable for IPv6, as
the IANA guidelines for IPv6 Next Header values <xref
target="RFC2460"/> allocation refer to the IPv4 guidelines.</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 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 <xref target="RFC2780">RFC 2780 Section
4.3 rule</xref> 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 also an implicit change to the rule for the
IPv6 Next Header field in Section 5.3 of RFC 2780. That rule refers to
the rule in Section 4.3 of the same RFC. From now on this reference
should be understood to refer to the rule revised here, i.e., 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.0760.xml"?>
      <?rfc include="reference.RFC.2434.xml"?>
      <?rfc include="reference.RFC.2460.xml"?>
      <?rfc include="reference.RFC.2780.xml"?>
</references>

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

<section title="Changes from RFC 2780">

<t>Section 4.3 from RFC 2780 has been changed from:</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>to:</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>In addition, RFC 2780 Section 5.3 reference to IPv4 rules should be
understood to refer to the rule revised here, i.e., without the Expert
Review option.</t>

</section>

</back>
</rfc>