The Line-Identification Option
RFC 6788

Note: This ballot was opened for revision 05 and is now closed.

(Ron Bonica) Yes

(Adrian Farrel) Yes

Comment (2012-07-05 for -05)
No email
send info
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"

(Brian Haberman) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2012-08-17 for -07)
No email
send info
1. (cleared)

2. (cleared)

3. (cleared)

4. Two questions about this text from section 6.2:

   If the Source Address field of the received IPv6 datagram
   was not the unspecified address, the Edge router MUST copy this
   address into the Destination Address field of the outer IPv6 datagram
   sent back towards the Access Node.  The link-layer destination
   address of the tunneled RA MUST be resolved using regular Neighbour
   Discovery procedures.  Otherwise, the destination address of the
   outer IPv6 datagram MUST be set to the well-known link-local scope
   All-BBF-Access-Nodes multicast address [to be allocated].

Is the "tunneled RA" the "outer IPv6 datagram"?

Does the "Otherwise" apply to the first "If" in the quoted text?

(update) I see that section 6.2 has been revised to clarify the
various cases.  In e-mail, you explained that "tunneled RA" is
equivalent to "outer IPv6 datagram".  While this is a non-blocking
comment, it would be good to be consistent in using one term or the
other throughout the document (I would suggest "outer IPv6 datagram"
as more precise and clear), or add a sentence explaining the two
phrases are equivalent.

5.(cleared)

6. (new, from previous Discuss point 2) The use of the word "uses"
clarifies that this option will only be carried in an RS in a tunnel.
It wouldn't hurt to add a sentence that explicitly expresses that
restriction, and specifies the behavior if an "untunneled" RS carrying
this option is received.

7. (new, from previous Discuss point 8)  I've cleared my Discuss
based on the text regarding MTU in rev -07.  I
suggest some minor word-smithing for that next text:

OLD:

   The edge router MUST ensure that it does not transmit tunneled RAs
   whose size is larger than the MTU of the link between the edge router
   and the AN. i.e.  The outer IPv6 datagram would require
   fragmentation.  This is required because the AN may not be capable of
   handling the reassembly of such fragmented datagrams.

NEW:

   The edge router MUST ensure that it does not transmit tunneled RAs
   whose size is larger than the MTU of the link between the edge
   router and the AN, which would require that the outer IPv6 datagram
   undergo fragmentation.  This limitation is imposed because the AN
   may not be capable of handling the reassembly of such fragmented
   datagrams.

(Wesley Eddy) No Objection

Comment (2012-07-05 for -05)
No email
send info
I agree with Pete's DISCUSS.

(Stephen Farrell) No Objection

Comment (2012-07-02 for -05)
No email
send info
- Just want to check, I'm fairly sure no change is needed but
just in case... Is there any way in which the LIO for one
subscriber can leak out so as to be visible to another 
subscriber?

- Wouldn't it be better to say that the LIO identifies the
subscriber premises or account rather than the subscriber?
That is, its not a person, being identified, e.g. the title of 
section 3 reads like there might be something privacy 
sensitive here, but I don't think there is really.

- Some fixes due to Dan Harkins' secdir review [1] comments
seem to be agreed by the authors. 

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03361.html

(Russ Housley) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2012-07-04 for -05)
No email
send info
Former DISCUSS points, now resolved [3 July]:

1. Suresh has confirmed that the NOT RECOMMENDED text in Section 2 is correctly meant in the 2119 sense, and shouldn't be MUST NOT.

2. Suresh has confirmed that the AN is not physically accessible to the subscriber, so securing the network beginning at that point and continuing out is sufficient.

========
Non-blocking comments;  no need to respond to these:

Authors:
Thank you for being very clear in the IANA Considerations.

*** A note to the document shepherd about the writeup:
You say, in responses to writeup questions (1) and (2), that there was a great deal of discussion and disagreement about this document in the WG:

> (1) Experimental as indicated in the header. This designation
> was reached after a long discussion in the working group.

> (2) Working Group Summary
> It was difficult reaching a consensus on this document, hence the two w.g. last
> calls. This approach was requested by the Broad Band Forum. The issues were
> resolved by some changes in the document and an agreement to have it be an
> experimental RFC.

It would have been helpful to have had more explanation (perhaps in the response to question (9)) of what the issues were, why they were considered difficult problems, and how that led to Experimental status rather than... what status was it intended for before?  A lot of discussion happened about why this is problematic or questionable, and how that got resolved, and ADs from other areas have to review it without any of that background.  These writeups aren't just meant to say "yes" and "no", and "yeh, there were issues."  This one is pretty perfunctory.

(Pete Resnick) (was Discuss) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2012-07-04 for -05)
No email
send info
Picking up on Stephen's point about referring the LIO referring to "subscriber premise."  The last sentence of s3 does use this term so maybe just sprinkling premise in s2/s3 title?