Mark,
This is fine with me. My comment was essentially a question
as to whether or not IANA would be able to include references to WIP.
If - in your opinion - this is okay, then it's certainly okay with me.
As a general observation (independent of this ID/RFC), this is
yet another in an endless stream of evidentiary arguments as to why
the ID boiler plate SHOULD NOT include the usual statement about the
inappropriate use of an ID as a reference.
I refer - of course - to the last sentence in the third paragraph
of the "Status of this Memo" section of the ID boiler-plate that says:
'It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."'
--
Eric
--> -----Original Message-----
--> From: Mark Townsley [mailto:[EMAIL PROTECTED]
--> Sent: Wednesday, June 14, 2006 3:18 AM
--> To: [EMAIL PROTECTED]
--> Cc: 'Gray, Eric'; 'Vince Mammoliti'; Gen-ART@ietf.org
--> Subject: Re: draft-arberg-pppoe-iana-01.txt
-->
--> Peter Arberg wrote:
--> > Hi,
--> >
--> > thanks Eric for the review and the good change suggestions.
--> >
--> > I have updated the document with all your suggestions,
--> and attached
--> > it for reference.
--> >
--> > With regards to the informative references, Mark what do
--> you suggest ?
--> >
--> > Do we wait for [BERRY] and [ARBERG] to get RFC numbers
--> and then move
--> > them to normative references ?
--> > With regards to [CARREL] I do not think anyone is looking
--> at moving this
--> > draft forward, but it is implemented in BRAS equipment
--> today, and is in
--> > use in networks, so we somehow need to keep the reference.
--> >
--> Looking at this further, I have to disagree with Eric that the
--> references need to be Normative in order to appease IANA.
--> This is an
--> FCFS registry, it will be very likely that IANA will have
--> to deal with
--> non-RFC, and perhaps draft-only references. This is
--> commonly done, as an
--> example:
-->
--> http://www.iana.org/assignments/bgp-extended-communities
-->
--> Eric, if you insist we can take this up with IANA and the
--> RFC Editor to
--> see what the right thing to do here is, but I think that
--> keeping these
--> references as Informative will suffice.
-->
--> - Mark
--> > thanks,
--> > Peter
--> >
--> >
--> >> -----Original Message-----
--> >> From: Mark Townsley [mailto:[EMAIL PROTECTED]
--> >> Sent: 31. maj 2006 15:04
--> >> To: Gray, Eric
--> >> Cc: Peter Arberg; Vince Mammoliti; Gen-ART@ietf.org
--> >> Subject: Re: draft-arberg-pppoe-iana-01.txt
--> >>
--> >> Gray, Eric wrote:
--> >>
--> >> ==============================================================
--> >> =========
--> >>
--> >>> First, while I have to agree the three references listed as
--> >>>
--> >> Informative
--> >>
--> >>> are what I would imagine most people could agree to be just
--> >>>
--> >> that, it is
--> >>
--> >>> probable that IANA cannot create the registries indicated
--> >>>
--> >> until these
--> >>
--> >>> references are published, and possible that IANA will not
--> >>>
--> >> want this to
--> >>
--> >>> be published until they can create the corresponding
--> >>>
--> >> registries. This
--> >>
--> >>> means that these references are essentially Normative in
--> >>>
--> >> their effect
--> >>
--> >>> on publication of this draft.
--> >>>
--> >>> Is IANA going to be willing to allow publication of this
--> >>>
--> >> document as a
--> >>
--> >>> BCP without first creating the registries? Can IANA create
--> >>>
--> >> a registry
--> >>
--> >>> with references to WIP?
--> >>>
--> >>>
--> >>>
--> >> --------------------------------------------------------------
--> >> ---------
--> >>
--> >>>
--> >>>
--> >> Indeed you have uncovered a couple of bugs here, Thanks Eric.
--> >>
--> >> I went to check up on these three references. The [BERRY]
--> >> reference is
--> >> for a draft that was actually approved by the IESG back
--> in Jan, but
--> >> seems to have popped out of the RFC Editor's queue shortly
--> >> after. I had
--> >> not noticed and am following up.
--> >>
--> >> The [ARBERG] reference was just approved days ago, I
--> assume it is
--> >> advancing normally. Michelle (IANA) specifically acknowledged
--> >> the IANA
--> >> considerations section (which provides a cross-reference
--> to the iana
--> >> document) when this happened last week.
--> >>
--> >> With respect to the [CARREL] reference (PADN and PADM), no
--> >> one has asked
--> >> me to publish this, and I am not aware of its
--> advancement. The values
--> >> are FCFS, so technically a draft is not needed, but it would
--> >> be good to
--> >> know if anyone is going to advance this or not. Perhaps it
--> >> should not be
--> >> in the initial list? Authors, do we know if this is
--> >> implemented and in use?
--> >>
--> >> Thanks,
--> >>
--> >> - Mark
--> >>
--> >>
--> >>
--> ------------------------------------------------------------
--> ------------
--> >>
--> >>
--> >> Internet Draft
--> Peter Arberg
--> >>
--> Redback Networks
--> >> Intended status: Best Current Practice
--> >> Expiration Date: August 2006
--> Vince Mammoliti
--> >>
--> Cisco Systems
--> >>
--> >>
--> >>
--> February 2006
--> >>
--> >>
--> >>
--> >>
--> >>
--> >> IANA Considerations for PPP over Ethernet (PPPoE)
--> >>
--> >> draft-arberg-pppoe-iana-01.txt
--> >>
--> >>
--> >> Status of this Memo
--> >>
--> >> By submitting this Internet-Draft, each author
--> represents that any
--> >> applicable patent or other IPR claims of which he or
--> she is aware
--> >> have been or will be disclosed, and any of which he
--> or she becomes
--> >> aware will be disclosed, in accordance with Section 6
--> of 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/1id-abstracts.html
--> >>
--> >> The list of Internet-Draft Shadow Directories can be
--> accessed at
--> >> http://www.ietf.org/shadow.html.
--> >>
--> >> This Internet-Draft will expire on August 31, 2006.
--> >>
--> >> Copyright Notice
--> >>
--> >> Copyright (C) The Internet Society (2006).
--> >>
--> >>
--> >> Abstract
--> >>
--> >> This document describes the IANA considerations for
--> the PPP over
--> >> Ethernet (PPPoE) protocol.
--> >>
--> >>
--> >>
--> >>
--> >> Arberg Expires August 2006
--> [Page 1]
--> >> -->
--> >> Internet Draft draft-arberg-pppoe-iana-01.txt
--> February 2006
--> >>
--> >>
--> >> Table of Contents
--> >>
--> >> 1.
--> Introduction............................................... 2
--> >> 1.1
--> Terminology.............................................. 2
--> >> 1.2 Specification of
--> Requirements............................ 2
--> >> 2. IANA
--> Considerations........................................ 3
--> >> 2.1 Registration Policies for PPPoE TAG
--> Values............... 3
--> >> 2.2 Reserved PPPoE TAG
--> Values................................ 3
--> >> 2.3 Registration Policies for PPPoE Code
--> fields.............. 4
--> >> 2.4 Reserved PPPoE Code
--> fields............................... 4
--> >> 3. Security
--> Considerations.................................... 4
--> >> 4.
--> References................................................. 5
--> >> 4.1 Normative
--> References..................................... 5
--> >> 4.2 Informative
--> References................................... 5
--> >> Author's
--> Address........................................... 5
--> >> Full Copyright
--> Statement................................... 6
--> >> Intellectual Property
--> Statement............................ 6
--> >>
--> >>
--> >> 1. Introduction
--> >>
--> >> This document provides guidance to the Internet
--> Assigned Numbers
--> >> Authority (IANA) regarding the registration of values
--> related to
--> >> the PPP over Ethernet Protocol (PPPoE), defined in
--> [RFC2516], in
--> >> accordance with BCP 26, [RFC2434]. It also reserves PPPoE TAG
--> >> values as well as PPPoE packet Code fields which are
--> or have been
--> >> in use on the Internet.
--> >>
--> >>
--> >> 1.1 Terminology
--> >>
--> >> The following terms are used here with the meanings defined in
--> >> BCP 26: "name space", "registration".
--> >>
--> >> The following policies are used here with the
--> meanings defined in
--> >> BCP 26: "First Come First Served".
--> >>
--> >> 1.2 Specification of Requirements
--> >>
--> >> In this document, several words are used to signify
--> the requirements
--> >> of the specification. These words are often
--> capitalized. The key
--> >> words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
--> NOT", "SHOULD",
--> >> "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
--> in this document
--> >> are to be interpreted as described in [RFC2119].
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >> Arberg Expires August 2006
--> [Page 2]
--> >> -->
--> >> Internet Draft draft-arberg-pppoe-iana-01.txt
--> February 2006
--> >>
--> >>
--> >> 2. IANA Considerations
--> >>
--> >> The PPPoE protocol as defined in [RFC2516] defines
--> two name spaces
--> >> that requires registration, the PPPoE TAG and the
--> PPPoE Code field.
--> >>
--> >>
--> >> 2.1 Registration Policies for PPPoE TAG Values
--> >>
--> >> IANA shall set up a registry of "PPPoE TAG Values". These are
--> >> 16-bit values. PPPoE TAG values already in use are
--> specified as
--> >> reserved in this document, all other TAG values
--> between 0 and 65535
--> >> are to be assigned by IANA, using the "First Come
--> First Served"
--> >> policy defined in [RFC2434].
--> >>
--> >> A TAG-Name, and a point of contact or a specification
--> description
--> >> (if any exists) MUST be provided for any assignment from this
--> >> registry."
--> >>
--> >>
--> >> 2.2 Reserved PPPoE TAG Values
--> >>
--> >> TAG Value TAG Name
--> Reference
--> >> -------------- -------------------------
--> ---------
--> >> 0 0x0000 End-Of-List
--> [RFC2516]
--> >>
--> >> 257 0x0101 Service-Name
--> [RFC2516]
--> >> 258 0x0102 AC-Name
--> [RFC2516]
--> >> 259 0x0103 Host-Uniq
--> [RFC2516]
--> >> 260 0x0104 AC-Cookie
--> [RFC2516]
--> >> 261 0x0105 Vendor-Specific
--> [RFC2516]
--> >> 262 0x0106 Credits [BERRY]
--> >> 263 0x0107 Metrics [BERRY]
--> >> 264 0x0108 Sequence Number [BERRY]
--> >>
--> >> 272 0x0110 Relay-Session-Id
--> [RFC2516]
--> >> 273 0x0111 HURL [CARREL]
--> >> 274 0x0112 MOTM [CARREL]
--> >>
--> >> 288 0x0120 PPP-Max-Payload [ARBERG]
--> >> 289 0x0121 IP_Route_Add [CARREL]
--> >>
--> >> 513 0x0201 Service-Name-Error
--> [RFC2516]
--> >> 514 0x0202 AC-System-Error
--> [RFC2516]
--> >> 515 0x0203 Generic-Error
--> [RFC2516]
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >> Arberg Expires August 2006
--> [Page 3]
--> >> -->
--> >> Internet Draft draft-arberg-pppoe-iana-01.txt
--> February 2006
--> >>
--> >>
--> >> 2.3 Registration Policies for PPPoE Code fields
--> >>
--> >> IANA shall set up a registry of PPPoE Active Discovery Code
--> >> fields. These are 8-bit values. PPPoE Code fields
--> already in use
--> >> are specified as reserved in this document, all other
--> Code values
--> >> between 0 and 255 are to be assigned by IANA, using the
--> >> "First Come First Served" policy defined in [RFC2434].
--> >>
--> >> A PPPoE Active Discovery packet name and a point of
--> contact or a
--> >> specification description (if any exists) MUST be
--> provided for any
--> >> assignment from this registry."
--> >>
--> >>
--> >> 2.4 Reserved PPPoE Code fields
--> >>
--> >> Code Value PPPoE Packet Name
--> Reference
--> >> ---------- ---------------------------------------
--> ---------
--> >> 0 0x00 PPP Session Stage
--> [RFC2516]
--> >>
--> >> 7 0x07 PADO, Offer
--> [RFC2516]
--> >> 9 0x09 PADI, Initiation
--> [RFC2516]
--> >>
--> >> 10 0x0a PADG, Session-Grant [BERRY]
--> >> 11 0x0b PADC, Session-Credit Response [BERRY]
--> >> 12 0x0c PADQ, Quality [BERRY]
--> >>
--> >> 25 0x19 PADR, Request
--> [RFC2516]
--> >> 101 0x65 PADS, Session-confirmation
--> [RFC2516]
--> >>
--> >> 167 0xa7 PADT, Terminate
--> [RFC2516]
--> >>
--> >> 211 0xd3 PADM, Message [CARREL]
--> >> 212 0xd4 PADN, Network [CARREL]
--> >>
--> >>
--> >>
--> >> 3. Security Considerations
--> >>
--> >> This document focuses on IANA considerations for the
--> PPPoE protocol,
--> >> and as such should help remove the possibility for
--> the same PPPoE
--> >> code field and PPPoE TAG value being used for different
--> >> functionalities.
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >> Arberg Expires August 2006
--> [Page 4]
--> >> -->
--> >> Internet Draft draft-arberg-pppoe-iana-01.txt
--> February 2006
--> >>
--> >>
--> >> 4. References
--> >>
--> >> 4.1 Normative References
--> >>
--> >> [RFC2119] Bradner, S., "Key words for use in
--> RFCs to Indicate
--> >> Requirement Levels", BCP 14, RFC 2119,
--> March 1997.
--> >>
--> >> [RFC2434] Narten, T. and H. Alvestrand,
--> "Guidelines for Writing
--> >> an IANA Considerations Section in
--> RFCs", BCP 26, RFC
--> >> 2434, October 1998.
--> >>
--> >> [RFC2516] Mamakos L., Lidl K., Evarts J., Carrel
--> D., Simone D.,
--> >> Wheeler R., "A Method for Transmitting
--> PPP Over
--> >> Ethernet (PPPoE)", RFC 2516, February 1999
--> >>
--> >>
--> >> 4.2 Informative References
--> >>
--> >> [CARREL] Carrel D., Simone D., Ho C., Stoner
--> T., "Extensions
--> >> to a Method for Transmitting PPP Over Ethernet
--> >> (PPPoE)", work in progress.
--> >>
--> >> [BERRY] Berry B., Holgate H., "PPP Over
--> Ethernet (PPPoE)
--> >> Extensions for Credit Flow and Link Metrics",
--> >> work in progress.
--> >>
--> >> [ARBERG] Arberg P., Kourkouzelis D., Duckett
--> M., Anschutz T.,
--> >> Moisand J., "Accommodating an MTU/MRU
--> greater than
--> >> 1492 in PPPoE", work in progress.
--> >>
--> >>
--> >> Authors' Addresses
--> >>
--> >> Peter Arberg
--> >> Redback Networks, Inc.
--> >> 300 Holger Way
--> >> San Jose, CA 95134
--> >> USA
--> >> Email: [EMAIL PROTECTED]
--> >>
--> >> Vince Mammoliti
--> >> Cisco Systems, Inc.
--> >> 181 Bay Street, Suite 3400
--> >> Toronto, Ontario, M5J 2T3
--> >> Canada
--> >> EMail: [EMAIL PROTECTED]
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >> Arberg Expires August 2006
--> [Page 5]
--> >> -->
--> >> Internet Draft draft-arberg-pppoe-iana-01.txt
--> February 2006
--> >>
--> >>
--> >> Full Copyright Statement
--> >>
--> >> Copyright (C) The Internet Society (2005).
--> >>
--> >> This document is subject to the rights, licenses and
--> restrictions
--> >> contained in BCP 78, and except as set forth therein,
--> the authors
--> >> retain all their rights.
--> >>
--> >> This document and the information contained herein
--> are provided on an
--> >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
--> HE/SHE REPRESENTS
--> >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
--> THE INTERNET
--> >> ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
--> EXPRESS OR IMPLIED,
--> >> INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
--> >> INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
--> >> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
--> PARTICULAR PURPOSE.
--> >>
--> >>
--> >> Intellectual Property Statement
--> >>
--> >> The IETF takes no position regarding the validity or
--> scope of any
--> >> Intellectual Property Rights or other rights that
--> might be claimed to
--> >> pertain to the implementation or use of the
--> technology described in
--> >> this document or the extent to which any license
--> under such rights
--> >> might or might not be available; nor does it
--> represent that it has
--> >> made any independent effort to identify any such
--> rights. Information
--> >> on the procedures with respect to rights in RFC
--> documents can be
--> >> found in BCP 78 and BCP 79.
--> >>
--> >> Copies of IPR disclosures made to the IETF Secretariat and any
--> >> assurances of licenses to be made available, or the
--> result of an
--> >> attempt made to obtain a general license or
--> permission for the use of
--> >> such proprietary rights by implementers or users of this
--> >> specification can be obtained from the IETF on-line
--> IPR repository at
--> >> http://www.ietf.org/ipr.
--> >>
--> >> The IETF invites any interested party to bring to its
--> attention any
--> >> copyrights, patents or patent applications, or other
--> proprietary
--> >> rights that may cover technology that may be required
--> to implement
--> >> this standard. Please address the information to the
--> IETF at ietf-
--> >> [EMAIL PROTECTED]
--> >>
--> >>
--> >> Acknowledgement
--> >>
--> >> Funding for the RFC Editor function is currently
--> provided by the
--> >> Internet Society.
--> >>
--> >>
--> >>
--> >>
--> >>
--> >>
--> >> Arberg Expires August 2006
--> [Page 6]
-->
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
