Re: [Pppext] small draft to update iana rules in PPP BAP/BACP
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pppext] small draft to update iana rules in PPP BAP/BACP
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: jari.arkko at piuha.net
>
>
> James D. Carlson
> Workingcode
>
> Email: carlsonj at workingcode.com
>
>
>
>
>
>
>
>
> Arkko, et al. Expires March 7, 2010 [Page 6]
>
> Internet-Draft BAP IANA Rules September 2009
>
>
> Amanda Baber
> ICANN
>
> Email: amanda.baber at icann.org
>
> Arkko, et al. Expires March 7, 2010 [Page 7]
Thanks
--
Eswaran Srinivasan
esriniva at juniper.net
408-936-4915
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
