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

[Eswaran Srinivasan <[e-mail]>]

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: [e-mail]
>
>
>    James D. Carlson
>    Workingcode
>
>    Email: [e-mail]
>
>
>
>
>
>
>
>
> Arkko, et al.             Expires March 7, 2010                 [Page 6]
>
> Internet-Draft               BAP IANA Rules               September 2009
>
>
>    Amanda Baber
>    ICANN
>
>    Email: [e-mail]
>
> Arkko, et al.             Expires March 7, 2010                 [Page 7]

Thanks
--
Eswaran Srinivasan
[e-mail]
408-936-4915