The Line-Identification Option
RFC 6788
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Adrian Farrel; former steering group member) Yes
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; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Barry Leiba; former steering group member) (was Discuss) No Objection
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.
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
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.
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
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?
(Stephen Farrell; former steering group member) No Objection
- 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
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection
I agree with Pete's DISCUSS.