Subject: [RTG-DIR] RtgDir review: draft-ietf-6man-lineid-05.txt

From: David Sinicrope <[email-masked]>
Date: Thu, 21 Jun 2012 02:53:27 -0400

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-6man-lineid-05.txt
Reviewer: David Sinicrope
Review Date: 14 June 2012
IETF LC End Date: 18 June 2012
Intended Status: Experimental

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

 *   Overall the draft is nearly ready for publication, but there are a few things that, if clarified, would help the reader in understanding the draft.  I am happy to discuss the comments with the draft editors.

Major Issues:

 *   No major issues found.

Minor Issues:

 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"