Subject: [Pppext] small draft to update iana rules in PPP BAP/BACP

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Sep 2009 10:37:15 +0300

IANA is going through all the registries and RFCs, and occasionally 
finds registries that are broken or missing or for which there are no 
published allocation guidelines. They recently detected that registries 
related to RFC 2125 (BAP/BACP) are missing. Its not clear to me whether 
BAP has much relevance left at this stage, but this still seemed like a 
bug, at least the registries should correctly reflect the existing RFCs. 
As a result, I wanted to write a draft that updates the IANA status for 
these registries:

http://www.ietf.org/id/draft-arkko-pppext-bap-ianafix-00.txt

Comments appreciated. I promise that at least this draft is shorter and 
simpler than most others :-)

Also, this might be a convenient opportunity to update other PPP IANA 
registries, if someone knows of existing problems or missing allocation 
guidelines in the PPP protocol set, let us know.

Jari

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 03 Sep 2009 18:05:05 -0700

At 10:37 AM 9/3/2009 +0300, Jari Arkko wrote:

>Comments appreciated. I promise that at least this draft is shorter and simpler than most others :-)

Hi Jari,
Just a couple of minor comments on the "PPP BAP Link Type" option.
It may be useful to IANA to mention that this is actually
a bit field and that each entry defines one bit.

Although RFC2125 allows defining more bits for this field,
the interoperability of such a choice would probably be questionable.
May be the text should include some sort of discouragement to
adding more bits beyond the defined ones.

Finally, the bit positions are opposite of the usual: bit 0 is
actually the low order bit. This is very confusing, but this is
also how it is in the original RFC. Too bad it wasn't fixed
back then.

Cheers,-Ignacio

---

From: Eswaran Srinivasan <[email-masked]>
Date: Thu, 3 Sep 2009 23:49:23 -0700

Hi Jari,

The document looks great to me in general.  Please look for Eswaran>
for some comments.

> Network Working Group                                           J. Arkko
> Internet-Draft                                                  Ericsson
> Updates: 2125 (if approved)                                   J. Carlson
> Intended status: BCP                                         Workingcode
> Expires: March 7, 2010                                          A. Baber
>                                                                    ICANN
>                                                        September 3, 2009
>
>
>   IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol
>                                  (BAP)
>                    draft-arkko-pppext-bap-ianafix-00
>
> Status of this Memo
>
>    This Internet-Draft is submitted to IETF in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on March 7, 2010.
>
> Copyright Notice
>
>    Copyright (c) 2009 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents in effect on the date of
>    publication of this document (http://trustee.ietf.org/license-info).
>    Please review these documents carefully, as they describe your rights
>    and restrictions with respect to this document.
>
>
>
>
>
> Arkko, et al.             Expires March 7, 2010                 [Page 1]
>
> Internet-Draft               BAP IANA Rules               September 2009
>
>
> Abstract
>
>    This document specifies the IANA guidelines for allocating new values
>    in the PPP Bandwidth Allocation and Bandwidth Allocation Control
>    Protocols.
>
>
> 1.  Introduction
>
>    This document specifies the IANA guidelines [RFC5226] for allocating
>    new values for various fields in the PPP Bandwidth Allocation
>    Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP)
>    [RFC2125].  BACP is the control protocol for BAP, and is used to
>    manage the dynamic bandwidth allocation of implementations supporting
>    the PPP multilink protocol [RFC1990].
>
>    The IANA guidelines are given in Section 2.  Previously, no IANA
>    guidance existed for such allocations either in [RFC2125] or
>    [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 [RFC2153] which allows the construction
>    of vendor-specific packets and options.
>
>
> 2.  IANA Considerations
>
>    The IANA is instructed to create the following registries.  For all
>    the registries, new values can be allocated through RFC Required
>    [RFC5226].
>
>    IANA is instructed to create a registry for the BACP option values.
>    The initial contents of the registry should be as follows:
>
>    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
>
>    IANA is also instructed to create a registry for the BAP Type field.
>    The initial contents of the registry should be as follows:
>
>
>
>
>
>
> Arkko, et al.             Expires March 7, 2010                 [Page 2]
>
> Internet-Draft               BAP IANA Rules               September 2009
>
>
>    Registry Name: PPP BAP Type
>    Reference: [RFC2125 and XXX THIS RFC]
>    Registration Procedures: RFC Required
>
>    Type     Configuration Option  Reference
>    ----     --------------------  ---------

Eswaran> Please fix the alignment and sorry for the nit pick.

>    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
>
>    IANA is also instructed to create a registry for the BAP Response
>    Code field.  The initial contents of the registry should be as
>    follows:
>
>    Registry Name: PPP BAP Response Code
>    Reference: [RFC2125 and XXX THIS RFC]
>    Registration Procedures: RFC Required
>
>    Type     Configuration Option     Reference
>    ----     --------------------     ---------

Eswaran> I guess the title being "Value, Response Code" will be better
         than "Type, Configuration Option".

>    0        Request-Ack              [RFC 2125]
>    1        Request-Nak              [RFC 2125]
>    2        Request-Rej              [RFC 2125]
>    3        Request-Full-Nak         [RFC 2125]
>    4-255    Unassigned
>
>    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:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Arkko, et al.             Expires March 7, 2010                 [Page 3]
>
> Internet-Draft               BAP IANA Rules               September 2009
>
>
>    Registry Name: PPP BAP Datagram Option Type
>    Reference: [RFC2125 and XXX THIS RFC]
>    Registration Procedures: RFC Required
>
>    Type     Configuration 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
>
>    IANA is also instructed to create a registry for the BAP Link Type
>    field.  The initial contents of the registry should be as follows:
>
>    Registry Name: PPP BAP Link Type
>    Reference: [RFC2125 and XXX THIS RFC]
>    Registration Procedures: RFC Required
>
>    Type     Configuration Option        Reference
>    ----     --------------------        ---------

Eswaran> I guess the title being "Bit, Link Type" will be better
         than "Type, Configuration Option".

>    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
>
>    Note that values 5-7 were originally marked reserved [RFC2125], but
>    this RFC makes them available for allocation.
>
>    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:
>
>    Registry Name: PPP BAP Phone-Delta Sub-Option Type
>    Reference: [RFC2125 and XXX THIS RFC]
>    Registration Procedures: RFC Required
>
>    Type     Configuration Option     Reference
>    ----     --------------------     ---------

Eswaran> I guess the title being "Value, Sub-Option Type" will be better
         than "Type, Configuration Option".

>    0        Vendor-Specific          [RFC 2153]
>    1        Unique-Digits            [RFC 2125]
>    2        Subscriber-Number        [RFC 2125]
>    3        Phone-Number-Sub-Address [RFC 2125]
>
>
>
> Arkko, et al.             Expires March 7, 2010                 [Page 4]
>
> Internet-Draft               BAP IANA Rules               September 2009
>
>
>    4-255    Unassigned
>
>    IANA is also instructed to create a registry for the BAP Call Status
>    field.  The initial contents of the registry should be as follows:
>
>    Registry Name: PPP BAP Call Status
>    Reference: [RFC2125 and XXX THIS RFC]
>    Registration Procedures: RFC Required
>
>    Type     Configuration Option     Reference
>    ----     --------------------     ---------

Eswaran> I guess the title being "Value, Call Status" will be better
         than "Type, Configuration Option".

>    0        Success                  [RFC 2125]
>    1-254    Q.931 values             [RFC 2125] [ITU.Q931.1993]
>    255      Other                    [RFC 2125]

Eswaran> The RFC 2125 says that the call status code 255 is for
         "Non-specific failure".  Should we mention it this way
         instead of "Other"?

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

Eswaran> I guess the title being "Value, Action" will be better
         than "Type, Configuration Option".

>    0        No retry                 [RFC 2125]
>    1        Retry                    [RFC 2125]
>    2-255    Unassigned
>
>
> 3.  Security Considerations
>
>    This specification does not change the security properties of BAP or
>    BACP.
>
>
> 4.  Acknowledgments
>
>    The lack of any registration procedures has come up in IANA's review
>    of existing registries and RFCs.
>
>
> 5.  References
>
> 5.1.  Normative References
>
>    [RFC2125]  Richards, C. and K. Smith, "The PPP Bandwidth Allocation
>               Protocol (BAP) The PPP Bandwidth Allocation Control
>               Protocol (BACP)", RFC 2125, March 1997.
>
>
>
> Arkko, et al.             Expires March 7, 2010                 [Page 5]
>
> Internet-Draft               BAP IANA Rules               September 2009
>
>
>    [RFC2153]  Simpson, W. and K. Fox, "PPP Vendor Extensions", RFC 2153,
>               May 1997.
>
>    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
>               May 2008.
>
> 5.2.  Informative References
>
>    [RFC1990]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
>               Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
>               August 1996.
>
>    [RFC3818]  Schryver, V., "IANA Considerations for the Point-to-Point
>               Protocol (PPP)", BCP 88, RFC 3818, June 2004.
>
>    [ITU.Q931.1993]
>               International Telecommunications Union, "ISDN user-network
>               interface layer 3 specification for basic call control",
>               ITU-T Recommendation Q.931, May 1993.
>
>
> Appendix A.  Changes from the Original RFCs
>
>    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.
>
>
> Authors' Addresses
>
>    Jari Arkko
>    Ericsson
>    Jorvas  02420
>    Finland
>
>    Email: [email-masked]
>
>
>    James D. Carlson
>    Workingcode
>
>    Email: [email-masked]
>
>
>
>
>
>
>
>
> Arkko, et al.             Expires March 7, 2010                 [Page 6]
>
> Internet-Draft               BAP IANA Rules               September 2009
>
>
>    Amanda Baber
>    ICANN
>
>    Email: [email-masked]
>
> Arkko, et al.             Expires March 7, 2010                 [Page 7]

Thanks
--
Eswaran Srinivasan
[email-masked]
408-936-4915

---

From: Jari Arkko <[email-masked]>
Date: Fri, 04 Sep 2009 11:57:24 +0300

Eswaran,

Thank you. I have made the suggested changes in my copy.

Jari

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 04 Sep 2009 05:49:40 -0400

My preference would be to rename:

Updated IANA Allocation Guidelines for PPP documents

And rigorously walk through every PPP-related RFC, looking for missing
or inconsistent IANA information.

Should BAP be the only one missing its allocations, then maybe just update
IANA without bothering to write yet another RFC....

---

From: Jari Arkko <[email-masked]>
Date: Sat, 05 Sep 2009 12:41:55 +0300

Ignacio,

> a bit field and that each entry defines one bit.

Yes -- I changed this in my copy of the draft.

> also how it is in the original RFC. Too bad it wasn't fixed

Sounds reasonable. I have made some changes to make these clearer.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 05 Sep 2009 12:48:01 +0300

Bill,

> or inconsistent IANA information.

Are you volunteering? :-) I'm asking serioulsy, because I think we 
should do a walkthrough and find out what other missing information 
there might be.
.
> IANA without bothering to write yet another RFC....

I know this RFC is a borderline case in terms of real-world usefulness. 
I do believe, however, that the registries need to be kept up to date 
and correct even for older protocols. And my personal preference is to 
issue significant registry updates only through RFCs. Most of the effort 
in writing this draft has gone into getting the various registries 
correct (whether they should or should not contain 0 - vendor specific, 
for instance. It took a while for me and James to get that right. This 
needs to be done anyway, and I guess I'm still hoping that the remaining 
IETF publication process for simple RFCs is a very efficient one :-) Or 
at least it has been for some of the past RFCs that we have written on 
similar IANA updates.

Jari