One document matched: draft-arkko-pana-iana-02.xml

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

<rfc ipr="trust200902"
     docName="draft-arkko-pana-iana-02"
     category="std"
     updates="5191">

<?rfc toc="no"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>

<front>

<title abbrev="PANA IANA Rules">IANA Rules for PANA (Protocol for Carrying Authentication for Network Access)</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="A" surname="Yegin" fullname="Alper Yegin">
<organization>Samsung</organization>
<address>
<postal>
<city>Istanbul</city>
<country>Turkey</country>
</postal>
<email>alper.yegin@yegin.org</email>
</address>
</author>

<date month="February" year="2010" />

<keyword>IANA rules</keyword>
<keyword>PANA</keyword>

<abstract>

<t>This document relaxes the IANA rules for the Protocol for Carrying
Authentication for Network Access (PANA).</t>
</abstract>

</front>
<middle>

<section anchor="intro" title="Introduction">

<t>This document relaxes the IANA rules for the Protocol for Carrying
Authentication for Network Access (PANA)
<xref target="RFC5191"/>. Rules for the following protocol fields, all
defined in <xref target="RFC5191"/>, are affected:

<list style="symbols">
<t>Message Type</t>
<t>Message Flags</t>
<t>Attribute-Value Pair (AVP) Flags</t>
<t>Result-Code AVP Value</t>
<t>Termination-Cause AVP Value</t>
</list></t>

<t>The rationale for this update is that there can be situations where
it makes sense to grant an allocation under special circumstances. At
the time of writing this, one such allocation is currently in the
approval process at the IETF. By changing the current IANA rules to
allow also for IESG Approval <xref target="RFC5226"/>, it becomes
possible for the Internet Engineering Steering Group (IESG) to
consider an allocation request, even if it does not fulfill the
default rule. For instance, an experimental protocol extension could
perhaps deserve an allocation from a field of reserved bits, as long
as a sufficient number of bits still remains for other purposes, and
the PANA community is happy with such an allocation.</t>

</section>

<section anchor="ianarules" title="IANA Considerations">

<t>IANA is requested to updated the registries related to PANA Message
Types, Message Flags, AVP Flags, Result-Code AVP Values, and
Termination-Cause AVP Values as specified below. All other PANA IANA
registries are to remain unchanged.</t>

<section anchor="mt" title="Message Type">

<t>The Message Type namespace is used to identify PANA messages.
Message Type 0 is not used and is not assigned by IANA.  The range of
values 1 - 65,519 are for permanent, standard message types, allocated
by IETF Review or IESG approval <xref target="RFC5226"/>. Previously,
the rule for this range was allocation by IETF Review only.
<xref target="RFC5191"/> defined the range of values 1 - 4.  The same
Message Type is used for both the request and the answer messages,
except for type 1.  The Request bit distinguishes requests from
answers.</t>

<t>The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 -
0xffff) are reserved for experimental messages.  As these codes are
only for experimental and testing purposes, no guarantee is made for
interoperability between the communicating PANA Client (PaC) and PANA
Authentication Agent (PAA) using experimental commands, as outlined in
<xref target="RFC3692"/>.</t>

</section>

<section title="Message Flags">

<t>There are 16 bits in the Flags field of the PANA message header.
Section 6.2 of <xref target="RFC5191"/> assigned bit 0 ('R'), 1 ('S'),
2 ('C'), 3 ('A'), 4 ('P'), and 5 ('I'). Allocations from the remaining
free bits in the PANA header Flag field are done via Standards Action
or IESG Approval <xref target="RFC5226"/>.
Previously,
the rule for these bits was allocation by Standards Action only.</t>

</section>

<section title="AVP Flags">

<t>There are 16 bits in the AVP Flags field of the AVP header, defined
in Section 6.3 of <xref target="RFC5191"/>. That RFC also assigned bit
0 ('V'). The remaining bits are assigned via a Standards Action or
IESG Approval <xref target="RFC5226"/>.
Previously,
the rule for these bits was allocation by Standards Action only.</t>

</section>

<section title="Result-Code AVP Values">

<t>As defined in Section 8.7 of <xref target="RFC5191"/>, the
Result-Code AVP (AVP Code 7) defines the values 0-2.</t>

<t>All remaining values are available for assignment via IETF
Review or IESG Approval <xref target="RFC5226"/>.
Previously,
the rule for these bits was allocation by IETF Review only.</t>

</section>

<section title="Termination-Cause AVP Values">

<t>As defined in Section 8.9 of <xref target="RFC5191"/>, the
Termination-Cause AVP (AVP Code 9) defines the values 1, 4, and
8.</t>

<t>All remaining values are available for assignment via IETF Review
or IESG Approval <xref target="RFC5226"/>.  Previously, the rule for
these bits was allocation by IETF Review only.</t>

</section>

</section>

<section title='Security Considerations'>

<t>This specification does not change the security properties of
PANA.</t>

<t>However, a few words are necessary about the use of the
experimental code points defined in <xref target="mt"/>. Potentially
harmful side-effects from the use of the experimental values needs to
be carefully evaluated before deploying any experiment across networks
that the owner of the experiment does not entirely control. Guidance
given in <xref target="RFC3692"/> about the use of experimental values
needs to be followed.</t>

</section>

</middle>
<back>

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

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

<section title="Changes from RFC 5191">

<t>This document changes the IANA rules for the Message Type, Message
Flags, AVP Flags, Result-Code AVP Value, and Termination-Cause AVP
Value.</t>

</section>

<section title="Acknowledgments">

<t>The authors would like to thank Yoshihiro Ohba, Ralph Droms, Magnus Westerlund, and Alfred Hoenes for
reviews and comments on this topic.</t>

</section>

</back>
</rfc>