Subject: [Gen-art] RE: draft-arberg-pppoe-iana-01.txt

From: "Peter Arberg" <[email-masked]>
Date: Tue, 13 Jun 2006 14:22:06 -0700

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.

thanks,
Peter

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]] 
> Sent: 31. maj 2006 15:04
> To: Gray, Eric
> Cc: Peter Arberg; Vince Mammoliti; [email-masked]
> 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
> 
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.

thanks,
Peter

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]] 
> Sent: 31. maj 2006 15:04
> To: Gray, Eric
> Cc: Peter Arberg; Vince Mammoliti; [email-masked]
> 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
> 
_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Jun 2006 09:18:19 +0200

> 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
>> ------------------------------------------------------------------------
>>
>>
>> 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-masked]
>>
>>    Vince Mammoliti
>>    Cisco Systems, Inc.
>>    181 Bay Street, Suite 3400
>>    Toronto, Ontario, M5J 2T3
>>    Canada
>>    EMail: [email-masked]
>>
>>
>>
>>
>>
>>
>> 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-masked].
>>
>>
>> Acknowledgement
>>
>>    Funding for the RFC Editor function is currently provided by the
>>    Internet Society.
>>
>>
>>
>>
>>
>>
>> Arberg                    Expires August 2006                   [Page 6]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jun 2006 14:17:47 +0200

If it's FCFS, it would be a violation of RFC 2234 to insist
on a normative reference, I think.

    Brian

Mark Townsley wrote:
>>> From: Mark Townsley [mailto:[email-masked]] Sent: 31. maj 2006 15:04
>>> To: Gray, 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.
>>>
>>> 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
>>>
>>>     
>>> Intended status: Best Current Practice Expiration Date: August 
>>> 2006                             Vince Mammoliti
>>>                                                            Cisco Systems
>>>
>>>
>>>                                                            February 2006
>>>
>>>
>>>
>>>
>>>
>>> between 0 and 255 are to be assigned by IANA, using the    "First 
>>> Come First Served" policy defined in [RFC2434].
>>>    This document focuses on IANA considerations for the PPPoE 
>>> protocol,    and as such should help remove the possibility for the 
>>> same PPPoE
>>>    [RFC2516]      Mamakos L., Lidl K., Evarts J., Carrel D., Simone 
>>> D.,                   Wheeler R., "A Method for Transmitting PPP Over 
>>>    [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

---

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Jun 2006 16:25:44 +0200

> on a normative reference, I think.
Sounds like Informative is the way to go here.
>> 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:
>>
>> 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
>>>
>>>  
>>>
>>>> but seems to have popped out of the RFC Editor's queue shortly 
>>>> after. I had not noticed and am following up.
>>>>
>>>> IANA considerations section (which provides a cross-reference to 
>>>> the iana document) when this happened last week.
>>>>
>>>> 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
>>>>
>>>>     
>>>>                                                         Redback 
>>>> Networks
>>>>                                                            Cisco 
>>>> Systems
>>>>                                                            February 
>>>> 2006
>>>>    The PPPoE protocol as defined in [RFC2516] defines two name 
>>>> spaces    that requires registration, the PPPoE TAG and the PPPoE 
>>>> Code field.
>>>>
>>>>
>>>>    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."
>>>>
>>>>
>>>> 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].
>>>>    specification description (if any exists) MUST be provided for 
>>>> any    assignment from this registry."
>>>>
>>>>
>>>> D.,                   Wheeler R., "A Method for Transmitting PPP 
>>>> Over                   Ethernet (PPPoE)", RFC 2516, February 1999
>>>>
>>>>
>>>>    [CARREL]       Carrel D., Simone D., Ho C., Stoner T., 
>>>> "Extensions                   to a Method for Transmitting PPP Over 
>>>> Ethernet                   (PPPoE)", work in progress.
>>>>

---

From: "Peter Arberg" <[email-masked]>
Date: Wed, 14 Jun 2006 11:33:32 -0700

Thank you for the help.

I have submitted ver. 02 of the draft just now, all changes
suggested by Eric is done and I have left the informative
references in place.

thanks,
Peter 

> Sent: 14. juni 2006 07:26
> To: Brian E Carpenter
> Cc: [email-masked]; 'Vince Mammoliti'; 'Gray, Eric'; 
> [email-masked]
> Subject: Re: [Gen-art] Re: draft-arberg-pppoe-iana-01.txt
> 
> Brian E Carpenter wrote:
> >>> With regards to [CARREL] I do not think anyone is looking 
> at moving 
> >>> this
> >>>> From: Mark Townsley [mailto:[email-masked]] Sent: 
> 31. maj 2006 
> >>>> 15:04
> >>>> To: Gray, Eric
> ---------- 
> >>>> Internet Draft                                           
> >>>> Arberg
> >>>>    Task Force (IETF), its areas, and its working groups. 
> Note that 
> >>>> other
> >>>>    Internet-Drafts are draft documents valid for a 
> maximum of six 
> >>>> months
> >>>>    and may be updated, replaced, or obsoleted by other 
> documents at 
> >>>> any
> >>>> > 
> >>>> 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
> >>>>    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 
> >>>> > 
> >>>> Internet Draft        draft-arberg-pppoe-iana-01.txt     
>   February 
> >>>> 2006
> >>>>
> >>>>
> >>>> 2. IANA Considerations
> >>>>
> >>>> > 
> >>>> Internet Draft        draft-arberg-pppoe-iana-01.txt     
>   February 
> >>>> 2006
> >>>>
> >>>>
> >>>> > 
> >>>> Internet Draft        draft-arberg-pppoe-iana-01.txt     
>   February 
> >>>> 2006
> >>>>
> >>>>
> >>>> 4. References
> >>>>
> >>>> 4.1 Normative References
> >>>>
> >>>> > 
> >>>> Internet Draft        draft-arberg-pppoe-iana-01.txt     
>   February 
> >>>> 2006
> >>>>
> >>>>
> >>>> Full Copyright Statement
> >>>>
> >>>>    This document and the information contained herein 
> are provided 
> >>>> on an
> >>>>    attempt made to obtain a general license or 
> permission for the 
> >>>> use of