IANA Considerations for PPP over Ethernet (PPPoE)
draft-arberg-pppoe-iana-03

[Ballot discuss]
I would like to understand why the IANA registry is not "Specification Required". It seems like one would want the IETF to at least by notified about changes being made to it.

The carrel reference does not seem to exist (or refers to a ID that expired in 2000) and should be removed along with the associated registration.

[Ballot discuss]
The policies described in Sections 2.1 and 2.3 do not fit completely with the way "Frist Come First Served" policy is defined in Section 2 of RFC 2434.

RFC 2434 says:

First Come First Served - Anyone can obtain an assigned number, so
          long as they provide a point of contact and a brief
          description of what the value would be used for.

My reading is that providing a description is not optional, something must always exist in the hands of a supplicant, and the following changes need to be made

in 2.1:

OLD:

  A TAG name and a point of contact or a specification description (if any 
  exists) MUST be provided for any assignment from this registry.

NEW:

  A TAG name and a point of contact and a specification description (e.g.
  reference document if one exists) MUST be provided for any assignment
  from this registry.

in 2.3:

OLD:

  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.

NEW:

  A PPPoE Active Discovery packet name and a point of contact and a 
  specification description (e.g. reference document if one exists) MUST be
  provided for any assignment from this registry.

[Ballot comment]
Section 1.2, paragraph 1:

>    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].

        "These words are often capitalized" - often? Not always?

[Ballot comment]
I can't find the the carrel reference, but it it is not already past IESG approval, I think it might be better for it to do the IANA registration for it. I suspect that it is past approval so put this as a comment.

[Ballot discuss]
I'm expect to clear this discuss with no change to the document... I would like to understand why the IANA registry is not "Specification Required". Given the importance and widespread use of PPPoE, it seems like one would want the IETF to at least by notified about changes being made to it.

IANA Last Call Comment :

Uppon approval of this document, the IANA will make the following assignments
in a new registry located at
http://www.iana.org/assignments/pppoe-tag-registry

Value
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]


Furthermore, Uppon approval of this document, the IANA will make the following
assignments
in a new registry located at
http://www.iana.org/assignments/pppoe-codes-registry

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]

We understand the above to be the only IANA Actions for this document.

PROTO

-------- Original Message --------
Subject: Re: draft-arberg-pppoe-iana-01.txt
Date: Wed, 24 May 2006 07:30:48 -0400
From: James Carlson
To: Mark Townsley
References: <44740617.8060103@cisco.com>



> Have you done a WG LC?

Yes.  It was called on December 23rd, 2005, and was complete on
January 13th, 2006.

> May I have a proto questionnaire?

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes, I've reviewed it.  Yes, it's ready to be forwarded to the
IESG.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

Yes it has had adequate review, and I have no concerns about
the review.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No concerns.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The list was largely silent on the document, and it does
represent the explicit work of a few individuals rather than
the "whole" WG, however the effect of the document
(establishing an IANA registry for code points already
specified in Informational RFCs) is fairly trivial and no
serious comment was expected or encountered over a lengthy
review period.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The document conforms to that checklist.

The document does have two other minor nits.  The boilerplate
copyright notice for BCP 78 says 2005 instead of 2006, and the
RFC 2119 boilerplate in section 1.2 is non-standard and should
be swapped for the standard language.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

Yes, the references are split.  No normative ID references.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

This document provides for an IANA registry of PPPoE TAG and
Code fields.  Known existing usages are reserved, and a "first
come first served" policy is established for future codes.

        *    Working Group Summary

The PPPEXT working group reviewed the document and there are
no known concerns with the work.  PPPoE itself is not a
standard protocol (L2TP and DHCP are standards-track
alternatives), and future extensions are thus not encouraged.
However, the new registry will help prevent possible conflicts
that may develop before the standards-based solutions are
adopted by PPPoE users.

        *    Protocol Quality

This document does not specify any protocol.  The registry
established reflects current practice within the community.

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

Already did.  That's above in the answer to 1.i.  Honest.

  1.k) Note:

        *    The relevant information for the technical summary can
            frequently be found in the abstract and/or introduction of
            the document.  If not, this may be an indication that there
            are deficiencies in the abstract or introduction.

        *    For the Working Group Summary: Was there anything in WG
            process that is worth noting? For example, was there
            controversy about particular points, decisions where
            consensus was particularly rough, etc.

        *    For the protocol quality, useful information includes:

            +    Are there existing implementations of the protocol?

            +    Have a significant number of vendors indicated they
                  plan to implement the specification?

            +    Are there any reviewers that merit special mention as
                  having done a thorough review (i.e., that resulted in
                  important changes or a conclusion that the document
                  had no substantive issues)?

No special notes here.

--
James Carlson, KISS Network                   
Sun Microsystems / 1 Network Drive        71.232W  Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757  42.496N  Fax +1 781 442 1677