One document matched: draft-arkko-pppext-bap-ianafix-02.xml

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

<rfc ipr="trust200902"
     docName="draft-arkko-pppext-bap-ianafix-02"
     category="bcp"
     updates="2125">

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

<front>

<title abbrev="BAP IANA Rules">IANA Allocation Guidelines for the PPP
Bandwidth Allocation Protocol (BAP)</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 fullname="James D. Carlson" initials="J."
                surname="Carlson">
        <organization>Workingcode</organization>
        <address>
            <email>carlsonj@workingcode.com</email>
            </address>
        </author>

        <author fullname="Amanda Baber" initials="A."
                surname="Baber">
        <organization>ICANN</organization>
        <address>
            <email>amanda.baber@icann.org</email>
            </address>
        </author>


<date month="September" year="2009" />

<keyword>IANA rules</keyword>
<keyword>PPP</keyword>
<keyword>Bandwidth Allocation Protocol</keyword>
<keyword>Bandwidth Allocation Control Protocol</keyword>
<keyword>BAP</keyword>
<keyword>BACP</keyword>

<abstract>

<t>This document specifies the IANA guidelines for allocating new
values in the PPP Bandwidth Allocation and Bandwidth Allocation
Control Protocols.
</t>

</abstract>

</front>
<middle>

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

<t>This document specifies the IANA guidelines
<xref target='RFC5226'/> for allocating new values for various fields
in the PPP Bandwidth Allocation Protocol (BAP) and Bandwidth
Allocation Control Protocol (BACP) <xref target='RFC2125'/>.  BACP is
the control protocol for BAP, and is used to manage the dynamic
bandwidth allocation of implementations supporting the PPP multilink
protocol <xref target="RFC1990"/>.
</t>

<t>The IANA guidelines are given in
<xref target="ianarules"/>. Previously, no IANA guidance existed for
such allocations either in <xref target="RFC2125"/> or
<xref target="RFC3818"/>. The purpose of this document is to allow
IANA to manage number assignments based on these guidelines in a
consistent manner. This document also points to
<xref target="RFC2153"/> which allows the construction of
vendor-specific packets and options. These mechanisms may also be used
for temporary experimental extensions, alleviating the need to
allocate specific experimental values in this document.
</t>

</section>

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

<t>The IANA is instructed to create the following registries.  For all
the registries, new values can be allocated through RFC Required
<xref target="RFC5226"/>.</t>

<t>IANA is instructed to create a registry for the BACP option
values. The initial contents of the registry should be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BACP Configuration Option Types
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Type     Configuration Option     Reference
----     --------------------     ---------
0        Vendor-Specific          [RFC2153]
1        Favored-Peer             [RFC2125]
2-255    Unassigned
</artwork>
</figure>

<t>IANA is also instructed to create a registry for the BAP Type field. The
initial contents of the registry should be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BAP Type
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Type     Datagram                 Reference
----     --------------------     ---------
0        Vendor-Specific          [RFC 2153]
1        Call-Request             [RFC 2125]
2        Call-Response            [RFC 2125]
3        Callback-Request         [RFC 2125]
4        Callback-Response        [RFC 2125]
5        Link-Drop-Query-Request  [RFC 2125]
6        Link-Drop-Query-Response [RFC 2125]
7        Call-Status-Indication   [RFC 2125]
8        Call-Status-Response     [RFC 2125]
9-255    Unassigned
</artwork>
</figure>

<t>IANA is also instructed to create a registry for the BAP Response Code field. The
initial contents of the registry should be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BAP Response Code
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Value    Response Code            Reference
----     --------------------     ---------
0        Request-Ack              [RFC 2125]
1        Request-Nak              [RFC 2125]
2        Request-Rej              [RFC 2125]
3        Request-Full-Nak         [RFC 2125]
4-255    Unassigned
</artwork>
</figure>

<t>IANA is also instructed to create a registry for the BAP Datagram Option Type field. The
initial contents of the registry should be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BAP Datagram Option Type 
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Type     Datagram Option          Reference
----     --------------------     ---------
0        Vendor-Specific          [RFC 2153]
1        Link-Type                [RFC 2125]
2        Phone-Delta              [RFC 2125]
3        No-Phone-Number-Needed   [RFC 2125]
4        Reason                   [RFC 2125]
5        Link-Discriminator       [RFC 2125]
6        Call-Status              [RFC 2125]
7-255    Unassigned               
</artwork>
</figure>

<t>IANA is also instructed to create a registry for the BAP Link Type field. The
initial contents of the registry should be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BAP Link Type
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Bit      Link Type                   Reference
----     --------------------        ---------
0        ISDN                        [RFC 2125]
1        X.25                        [RFC 2125]
2        analog                      [RFC 2125]
3        switched digital (non-ISDN) [RFC 2125]
4        ISDN data over voice        [RFC 2125]
5-7      Unassigned
</artwork>
</figure>

<t>Note the order of bits in this field as specified in Section 6.1 of
<xref target="RFC2125"/>: bit 0 of the Link Type field corresponds to
bit 39 of the Link-Type BAP Option. Also note that bits 5-7 were
originally marked reserved <xref target="RFC2125"/>, but this RFC
makes them in principle available for allocation. New allocations are
discouraged, however, as it would be difficult to assess the impacts
new bits might have on interoperability with existing
implementations.</t>

<t>IANA is also instructed to create a registry for the BAP
Phone-Delta Sub-Option Type field. The initial contents of the registry should
be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BAP Phone-Delta Sub-Option Type
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Type     Sub-Option               Reference
----     --------------------     ---------
0        Vendor-Specific          [RFC 2153]
1        Unique-Digits            [RFC 2125]
2        Subscriber-Number        [RFC 2125]
3        Phone-Number-Sub-Address [RFC 2125]
4-255    Unassigned
</artwork>
</figure>

<t>IANA is also instructed to create a registry for the BAP Call Status field. The
initial contents of the registry should be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BAP Call Status
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Value    Call Status              Reference
-----    --------------------     ---------
0        Success                  [RFC 2125]
1-254    Q.931 values             [RFC 2125] [ITU.Q931.1993]
255      Non-specific failure     [RFC 2125]
</artwork>
</figure>

<t>IANA is also instructed to create a registry for the BAP Call Action field. The
initial contents of the registry should be as follows:</t>
<figure>
<artwork>
Registry Name: PPP BAP Call Action
Reference: [RFC2125 and XXX THIS RFC]
Registration Procedures: RFC Required

Value    Action                   Reference
-----    --------------------     ---------
0        No retry                 [RFC 2125]
1        Retry                    [RFC 2125]
2-255    Unassigned
</artwork>
</figure>

</section>

<section title='Security Considerations'>

<t>This specification does not change the security properties of BAP
or BACP.</t>

<t>However, a few words are necessary about the use of vendor-specific
extensions. Obviously, the use of vendor-specific extensions affects
interoperability. General purpose extensions would be better defined
as standard extensions. Similarly, if vendor-specific extensions are
used to test temporary experimental designs, guidance given in
<xref target="RFC3692"/> should be followed to avoid potentially
harmful side-effects.</t>

</section>

<section title="Acknowledgments">

<t>The lack of any registration procedures has come up in IANA's
review of existing registries and RFCs.</t>

</section>

</middle>
<back>

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

<references title="Informative References">
      <?rfc include="reference.RFC.1990.xml"?>
      <?rfc include="reference.RFC.3818.xml"?>
      <?rfc include="reference.ITU.Q931.1993.xml"?>
</references>

<section title="Changes from the Original RFCs">

<t>This document specifies only the IANA rules associated with various
fields in BAP and BACP, and does not change the operation of the
protocols themselves.</t>

</section>

<section title="Acknowledgments">

<t>The authors would like to thank Carlos Pignataro, Eswaran
Srinivasan, Ignacio Goyret, and Bill Simpson for feedback.</t>

</section>

</back>
</rfc>