Draft:  draft-arberg-pppoe-iana-01.txt
Reviewer: Gray, Eric [Eric.Gray@marconi.com]
Review Date: Wednesday 6/14/2006 9:17 AM CST
IETF Telechat Date: 6/22/2006

Summary:  The draft version sent with agreed changes satisfies the minor
comments provided below during LC.  This draft will be completely
ready for submission to the RFC Editor for publishing as
a BCP RFC - as soon as Mark Townsley is satisfied with
the resolution of the reference issues...


------------------------------------------------------------------------

Review Date: Wednesday 5/31/2006 2:57 PM
IETF LC Date: 6/21/2006

Summary: this draft is almost ready for publication as a Best Common 
Practices RFC.
 
It is short (6 pages), and clearly written.  I have observation(s), 
or question(s), about the effect of certain kinds of references on 
BCP publication.  I also have some very minor comments about specific 
text (mostly NITs).

=======================================================================

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?

-----------------------------------------------------------------------

NITs
===
I suggest replacing the Terminology section with the following (between
"====" bars):

=======================================================================
   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".
=======================================================================

You do not actually use the terms "assigned value", "Private Use", 
"Expert Review", "Specification Required", "IETF Consensus" or 
"Standards Action"...

-----------------------------------------------------------------------

In section 2 ("IANA Considerations"), first line of text, change 
"two name space" to "two name spaces".

-----------------------------------------------------------------------

Section 2.1 ("Recommended Registration Policies for PPPoE TAG Values")
- you might leave out "Recommended" as (assuming publication of this
document) this document will define the registration policy until some
other document redefines it.  Saying that "a point of contact MUST be 
provided" - for instance - is inconsistent with a "recommendation."

To tighten up the wording, the first paragraph in this section should
start with "IANA SHALL ..." (as opposed to "IANA needs to ...").

Also, is it acceptable to provide a reference in lieue of a point of 
contact?  It should be acceptable - especially given the following 
three observations:

1) a referenced document is likely to be more portable and useful
   in the long term than a point of contact,
2) most likely a referenced document will contain (or otherwise
   provide) contact information that is at least as likely to be
   useful, and
3) your own registry entries contain only referenced documents (in
   lieue of point of contact information).

I suggest rewording the last two paragraphs (prior to section 2.2)
something like this:

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

-----------------------------------------------------------------------

For section 2.3 - similar to the above for section 2.1 (removing 
"Recommended", re-wording, etc.)

-----------------------------------------------------------------------

Section numbering is funky in section 4/4.1 - I recommend having a
"References" section (section 4) and sub-sections 4.1 and 4.2 for
normative/informative (assuming both remain)...