From jari.arkko@piuha.net Thu Sep 3 00:37:03 2009 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64B93A6A47 for ; Thu, 3 Sep 2009 00:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTNooBIcWGw7 for ; Thu, 3 Sep 2009 00:37:03 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AB9493A6AB8 for ; Thu, 3 Sep 2009 00:37:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 64FB9D62CF for ; Thu, 3 Sep 2009 10:37:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy4Nu0dzc583 for ; Thu, 3 Sep 2009 10:37:16 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BBF52D6246 for ; Thu, 3 Sep 2009 10:37:16 +0300 (EEST) Message-ID: <4A9F722B.6070508@piuha.net> Date: Thu, 03 Sep 2009 10:37:15 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pppext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Pppext] small draft to update iana rules in PPP BAP/BACP X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 07:37:03 -0000 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 igoyret@alcatel-lucent.com Thu Sep 3 19:45:20 2009 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCE73A681E for ; Thu, 3 Sep 2009 19:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+nwDqUMlNAx for ; Thu, 3 Sep 2009 19:45:19 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1A06E3A63CB for ; Thu, 3 Sep 2009 19:45:19 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n8416JMR015342; Thu, 3 Sep 2009 20:06:19 -0500 (CDT) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [135.140.53.169]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n8416IFE001201; Thu, 3 Sep 2009 20:06:18 -0500 (CDT) Received: from igoyret-c1.alcatel-lucent.com (dhcp-135-140-27-183 [135.140.27.183]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id n8416H60007097; Thu, 3 Sep 2009 18:06:18 -0700 Message-Id: <200909040106.n8416H60007097@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Sep 2009 18:05:05 -0700 To: Jari Arkko From: Ignacio Goyret In-Reply-To: <4A9F722B.6070508@piuha.net> References: <4A9F722B.6070508@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: pppext@ietf.org Subject: Re: [Pppext] small draft to update iana rules in PPP BAP/BACP X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 02:45:20 -0000 At 10:37 AM 9/3/2009 +0300, Jari Arkko wrote: >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 :-) 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 esriniva@juniper.net Thu Sep 3 23:52:28 2009 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCB53A6866 for ; Thu, 3 Sep 2009 23:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIXLMWiUoVFK for ; Thu, 3 Sep 2009 23:52:27 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id AB79F3A6407 for ; Thu, 3 Sep 2009 23:52:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSqC492otgNSZUFm6zPmIpkcaYInGW6Id@postini.com; Thu, 03 Sep 2009 23:52:47 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 3 Sep 2009 23:49:25 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 23:49:25 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 23:49:25 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 23:49:23 -0700 Received: from svl-junos-pool72.juniper.net (svl-junos-pool72.juniper.net [172.17.30.192]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n846nNd03323; Thu, 3 Sep 2009 23:49:23 -0700 (PDT) (envelope-from esriniva@juniper.net) Received: from svl-junos-pool72.juniper.net (localhost.juniper.net [127.0.0.1]) by svl-junos-pool72.juniper.net (8.14.3/8.12.3) with ESMTP id n846nNmn027272; Thu, 3 Sep 2009 23:49:23 -0700 (PDT) (envelope-from esriniva@svl-junos-pool72.juniper.net) Received: (from esriniva@localhost) by svl-junos-pool72.juniper.net (8.14.3/8.12.3/Submit) id n846nN27027271; Thu, 3 Sep 2009 23:49:23 -0700 (PDT) Date: Thu, 3 Sep 2009 23:49:23 -0700 From: Eswaran Srinivasan To: Jari Arkko Message-ID: <20090904064923.GC22860@juniper.net> References: <4A9F722B.6070508@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4A9F722B.6070508@piuha.net> User-Agent: Mutt/1.4.2.3i X-OriginalArrivalTime: 04 Sep 2009 06:49:23.0947 (UTC) FILETIME=[D6869BB0:01CA2D2B] Cc: "pppext@ietf.org" Subject: Re: [Pppext] small draft to update iana rules in PPP BAP/BACP X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 06:52:28 -0000 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@piuha.net > > > James D. Carlson > Workingcode > > Email: carlsonj@workingcode.com > > > > > > > > > Arkko, et al. Expires March 7, 2010 [Page 6] > > Internet-Draft BAP IANA Rules September 2009 > > > Amanda Baber > ICANN > > Email: amanda.baber@icann.org > > Arkko, et al. Expires March 7, 2010 [Page 7] Thanks -- Eswaran Srinivasan esriniva@juniper.net 408-936-4915 From jari.arkko@piuha.net Fri Sep 4 01:57:06 2009 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BD73A68E8 for ; Fri, 4 Sep 2009 01:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxDhYBQY2XOl for ; Fri, 4 Sep 2009 01:57:06 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2FED13A6811 for ; Fri, 4 Sep 2009 01:57:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 40885D6337; Fri, 4 Sep 2009 11:57:25 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrcS7QJPw-uA; Fri, 4 Sep 2009 11:57:24 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B37DDD6261; Fri, 4 Sep 2009 11:57:24 +0300 (EEST) Message-ID: <4AA0D674.5000509@piuha.net> Date: Fri, 04 Sep 2009 11:57:24 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Eswaran Srinivasan References: <4A9F722B.6070508@piuha.net> <20090904064923.GC22860@juniper.net> In-Reply-To: <20090904064923.GC22860@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pppext@ietf.org" Subject: Re: [Pppext] small draft to update iana rules in PPP BAP/BACP X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 08:57:07 -0000 Eswaran, Thank you. I have made the suggested changes in my copy. Jari From william.allen.simpson@gmail.com Fri Sep 4 02:52:29 2009 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC073A69ED for ; Fri, 4 Sep 2009 02:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZXuKOt4QRFF for ; Fri, 4 Sep 2009 02:52:29 -0700 (PDT) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by core3.amsl.com (Postfix) with ESMTP id 12BAE3A69DC for ; Fri, 4 Sep 2009 02:52:28 -0700 (PDT) Received: by ywh42 with SMTP id 42so1236709ywh.30 for ; Fri, 04 Sep 2009 02:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=S7cyHnd6DU8qsNLoWTCBQ1Nuov258+YyWum+OpN1y4k=; b=E9Jy4v/XjGs8YPoIVouQhhxIL6hlxO71jcSQfq/Kq14BbtGkBWS6opX76efLSwb57C qCj5HjO5AbrcKpjk6Cv56D7zZoyxBD8hxrB/pbhOmrgkdcIXGPdSV7ejQ2MRbEzCcNBz 7bG8g0b1Ledx1yOt5KEI54/NJtCQdCizYyzRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=YfnTgJIeKYbu+35SKZskHp32Aq5UxPAu1qS1kRMdXteak/M0KF1bDjnXNiOSvzr7Z2 Lv8RZ6p/D6U2n9JoudBam32AQlzvsoUKkvvZDaEZ5iuDf/51h5LDsTj3goG/+t2xVYN4 9sKHKkcyMQbR8S+RYB5OpU+JorpRI9RDwnME8= Received: by 10.100.75.15 with SMTP id x15mr12190390ana.58.1252057783511; Fri, 04 Sep 2009 02:49:43 -0700 (PDT) Received: from Wastrel.local (c-68-42-73-61.hsd1.mi.comcast.net [68.42.73.61]) by mx.google.com with ESMTPS id d24sm2098932and.6.2009.09.04.02.49.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Sep 2009 02:49:42 -0700 (PDT) Message-ID: <4AA0E2B4.2000500@gmail.com> Date: Fri, 04 Sep 2009 05:49:40 -0400 From: William Allen Simpson User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "pppext@ietf.org" References: <4A9F722B.6070508@piuha.net> <20090904064923.GC22860@juniper.net> <4AA0D674.5000509@piuha.net> In-Reply-To: <4AA0D674.5000509@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] small draft to update iana rules in PPP BAP/BACP X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 09:52:30 -0000 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@piuha.net Sat Sep 5 02:41:37 2009 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C6A3A6820 for ; Sat, 5 Sep 2009 02:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdgAbY+hNtqp for ; Sat, 5 Sep 2009 02:41:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E886B3A67FE for ; Sat, 5 Sep 2009 02:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 70CFAD6270; Sat, 5 Sep 2009 12:41:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBNxqLjpO9TF; Sat, 5 Sep 2009 12:41:56 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A0B60D6246; Sat, 5 Sep 2009 12:41:56 +0300 (EEST) Message-ID: <4AA23263.20907@piuha.net> Date: Sat, 05 Sep 2009 12:41:55 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ignacio Goyret References: <4A9F722B.6070508@piuha.net> <200909040106.n8416H60007097@cliff.eng.ascend.com> In-Reply-To: <200909040106.n8416H60007097@cliff.eng.ascend.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org Subject: Re: [Pppext] small draft to update iana rules in PPP BAP/BACP X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 09:41:37 -0000 Ignacio, Thanks for your review: > 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. > Yes -- I changed this in my copy of the draft. > 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. > Sounds reasonable. I have made some changes to make these clearer. Jari From jari.arkko@piuha.net Sat Sep 5 02:47:44 2009 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F483A6817 for ; Sat, 5 Sep 2009 02:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzT0LAv72cDk for ; Sat, 5 Sep 2009 02:47:43 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 668A33A67FE for ; Sat, 5 Sep 2009 02:47:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8EAEED6270; Sat, 5 Sep 2009 12:48:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7-v+6eddNl9; Sat, 5 Sep 2009 12:48:02 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 11729D6246; Sat, 5 Sep 2009 12:48:02 +0300 (EEST) Message-ID: <4AA233D1.5030902@piuha.net> Date: Sat, 05 Sep 2009 12:48:01 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: William Allen Simpson References: <4A9F722B.6070508@piuha.net> <20090904064923.GC22860@juniper.net> <4AA0D674.5000509@piuha.net> <4AA0E2B4.2000500@gmail.com> In-Reply-To: <4AA0E2B4.2000500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pppext@ietf.org" Subject: Re: [Pppext] small draft to update iana rules in PPP BAP/BACP X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 09:47:44 -0000 Bill, > 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. 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. . > Should BAP be the only one missing its allocations, then maybe just > update > 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