The Line-Identification Option
draft-ietf-6man-lineid-08

I am balloting "yes" but there are some minor comments from Dave
Sinicrope's Routing Directorate review. Please consider them 
before advancing the document for publication.

 1.  Section 1.1 Terminology & all related sections:  Throughout 
     several sections of the document the term "subscriber" is used.
     It is not defined in the Terminology.  It seems this is often
     used synonimously with End-device which is defined.  This is 
     particularly true of section 2. Applicability Statement.  
     Please define "subscriber" or substitute a defined term (e.g.,
     "end device") for "subscriber" throughout the document.

 2.  Section 1.1 Terminology & all related sections:  Throughout 
     several sections of the document the term "host" is used. While
     "host" is defined in the Terminology, it seems this is often 
     used synonimously with End-device where it would be better to
     use the latter term.  This is particularly true of section 2.
     Applicability Statement paras 3 and 5.  Please substitute "end
     device" for "host" throughout the document where this is 
     applicable.

 3.  Section 2. Applicability Statement: This section focuses on the
     limitations of the draft, but it should elaborate more on the 
     applicability and usefulness of the draft to support stateless
     auto configuration.

 4.  Section 2. Applicability Statement, para 3, last 2 sentences: 
     These statements make it appear that all broadband networks rely
     on the [end device] MAC address and that it is not recommended
     that this draft be used for networks that require the [end 
     device] MAC address, leading the reader to the possible conclusion
     that this draft has little use.  In practice some broadband 
     networks use the [end device] MAC address, but not all making the
     draft far more applicable than indicated.  Please qualify the 
     penultimate sentence of paragraph 3 "currently used in <"some"
     or "many"> Broadband networks"

 5.  Section 2 Applicability Statement: The document would benefit
     from a brief flow diagram showing the Router Solicitation & 
     Router Advertisement flows between the nodes shown in Figure 1.

 6.  Section 4 Basic Operation, last sentence:  The last sentence is
     not clear as to why a packet with a hop limit not set to 255 is
     discarded.  Please briefly elaborate (e.g., "because they appear
     to be more than a single hop away.")

 7.  Section 5.1 On receiving a Router Solicitation: Add a figure
     showing the construction of a tunneled Router Solicitation.  Add
     "See Figure X" within the paragraph to reference the figure.

 8.  Section 5.2.1 Identifying tunneled Router Advertisements: It is 
     unclear, at least initially, what is meant by "All BBF Access 
     Nodes".  Please clarify its use as done in section 6.2, noting
     that it is a well known, link-local scoped multicast address. 

 9.  Section 5.3 On detecting a subscriber circuit coming up, para 1,
     "When the access node": I believe what is meant by "When the 
     access node detects that a subscriber circuit has come up" is
     really "Each time the access node detects that a subscriber 
     circuit has come up".  "When the" could be misinterpreted as 
     meaning "the first time".  Please change "When the" to "Each 
     time" in this sentence.

 10. Section 6.1 On receiving a Tunneled Router Solicitation: It is
     not clear how the edge router recognizes a tunneled RS. Please
     briefly elaborate on how this datagram is identified by the 
     edge router.

 11. Section 6.1 On receiving a Tunneled Router Solicitation, "The
     link-layer destination address of the tunneled RA MUST".  There
     are two statements in this paragraph that start with this clause
     that seem to be contradictory.  Please reconcile and clarify.

 12. Section 6.3 Sending periodic unsolicited Router Advertisements:
     This section would benefit from a forward reference to section 8
     Garbage collection of unused prefixes to help the reader
     understand when and how the prefixes are eventually removed or
     cleared.

 13. Section 7 Line Identification Destination Option (LIO): Change
     "no alignment requirement." to "… no byte alignment 
     requirement."

 14. Section 7.1 Encoding of Line ID, para 3: It is not clear why
     compatibility with DHCP is needed as these are two independent
     protocols.  The section notes the derivation of the option from
     DHCP.  It seems to be implied that compatibility is kept to allow
     the same processing to be used.  If this is the case it should be
     stated.  If it is not the case, the rationale would help the
     reader understand better why compatibility must be kept and the 
     relation to the install base which would seem to need a software
     upgrade to support this draft.

Nits:

 1.  Section 2 Applicability Statement, para 3: This paragraph should
     be broken into two paragraphs as the latter sentences explain 
     limitations and recommendations of the draft itself while the 
     earlier sentences explain operation of Router Solicitation and
     Advertisement.

 2.  Section 5.1 On receiving a Router Solicitation:  Clarify the use
     of "the unspecified address", with a reference or context. (e.g.,
     "the unspecified address defined in RFC"

 3.  General: inconsistent use of capitalization on "Edge Router"/"edge
     router"/"Edge router"