AD review: draft-ietf-6man-lineid

[Brian Haberman <[e-mail]>]

All,
      Here are my comments on the LineID draft.  It is in pretty good 
shape, but I would like these issues addressed before moving on to IESG 
Review/IETF Last Call...

Substantive
-----------

- Section 2 (paragraph 3) : This text talks about "the network" getting 
some information from the subscriber-originated RS messages.  Is it 
really the AN that gets this information or is it really the Edge 
Router?  What information is being lost when the subscriber-initiated RS 
messages stop?

- Section 2 (paragraph 5) : This paragraph states that this approach is 
"NOT RECOMMENDED for general deployments".  Do you really mean general 
deployments or is is better to say deployments not using the N:1 VLAN model?

- Section 5.1 : If the AN has an IPv6 address, why is its use in the 
encapsulating header only a SHOULD?

- Section 6.3 : How does the edge router know what prefixes to map to 
the LIO?  Should there be some specification that the RA transmitted 
must/should carry a PIO?

- Section 7 : I would suggest for the definition of the Option Length 
s/The value 0 is considered invalid/The value MUST be greater than 0/

- Section 7.1 : I have questions on the use of SHOULD NOT in the last 
two paragraphs. In what situation would two line IDs be considered equal 
if they do not match byte-by-byte?  To me, this can be changed to MUST 
NOT. I am not sure there is really any reason to say an intermediate 
system SHOULD NOT examine the Line ID.  There is no way to enforce that 
rule.  In what situation (or type of situation) would an intermediate 
system be allowed to modify the Line ID?

Editorial
---------

* Introduction
- s/traditionally/traditional/
- s/[RFC1661] based some networks/[RFC1661] based, some networks/
- s/network in context/network in the context/
- None of the figures are referenced in the text
- Expand GPON acronym on its first use

* Terminology
- The definition of AN uses the terms northbound and southbound. It 
would be useful to briefly define those (or use different terms).
- I would define RG before Edge Router so that there is no dangling use 
of the term RG before it is defined. Or you can expand RG in the 
definition...
- It may be useful to state whether the use of an RG is optional or not.
- The definition of RG is missing a term: "...similar to one specified 
in or a Layer...".

* Section 2
- s/VLAN deployment models line/VLAN deployment models, line/
- DHCP should be expanded on first use and a reference given.
- I would suggest providing a reference for SLAAC.
- s/this results on some/this results in some/
- s/Router Solicitations by initiating RSs/Router Solicitations (RSes) 
by initiating RSes/
- s/RSs/RSes/g
- There is a dangling "e.g." in the middle of the third paragraph.

* Section 3
- s/the end-device on the circuit the end-device is connected on/the 
end-device on the circuit/
- It would be useful to include a reference for DHCP relay agents.

* Section 4
- The acronym ND needs to be expanded or changed to RS/RA.
- Specify that it is the Hop Limit of the *inner* packet that must not 
be decremented.

* Section 5.1
- The section uses the term "insert" when talking about the creation of 
the encapsulating (outer) packet.  This makes me think of modifying an 
existing packet.  It would be clearer to state that the encapsulating 
packet includes/contains a destination options header.

* Section 5.2
- s/router advertisement/Router Advertisement/
- Rather than saying the AN will "multicast" the inner packet, would be 
sufficient to say it will "transmit" the inner packet?

* Section 6.1
- Last sentence is missing a period.

* Section 6.2
- s/this router advertisement(es./this router advertisement./
- s/All BBF Access Nodes/All-BBF-Access-Nodes/g

* Section 6.3
- Provide an informative reference for ANCP.

* Section 7
- s/an alignment requirement of (none)/no alignment requirements/

* Section 7.1
- The last sentence of the first paragraph is missing a period.

Regards,
Brian