Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.txt - Respond by Oct 13, 2014

["Bernie Volz (volz)" <[e-mail]>]

Below are my review comments. I think with these applied, the document should be able to move forward (I support this work and do feel it should be able to advance) - however, given the lack of response for this Working Group Last Call, it may need another. For those that support this work but have not yet commented, you have until the end of (your) day, Oct 13.

** General

-          Minor: There are many contractions in this document (can't, it's, ...). While these will be fixed by the RFC editor, best to clean them up. I think the general goal is to avoid these (cannot, it is, ...). Of course, leave any possessive words.
** Section 2

-          Very minor: For "PE router: Provider Edge Router" wonder why not

-           just "provider edge router" as for CPE (i.e., check case).
** Section 3

-          Figure 1 title - I guess "simple" this isn't, but not sure what else to call it. Perhaps "Smaller hierarchical Network"?

-          After Figure 2, the paragraph starts with "This diagram" ... which is this referring to? Perhaps both (These diagrams?) "This diagram" is also used in the next paragraph (top of page 6).

-          3rd paragraph on page 6: - "In DHCPv6 that is also possible is case[s]". Also, in this sentence, can we replace the "it" at the end of the sentence - use "unicast"?

-          Next sentence, "In such case[s,] once the ... to contact [the] server".

-          General comment on this paragraph, is the unicast decision here really worth it? Would be a lot simpler to just say "In DHCPv6, it is possible for the server to indicate to the client that it may unicast packets under appropriate conditions (see RFC 3315, such as Section 22.12)."

-          Next paragraph, perhaps best to avoid "on-link"? How about "that it knows is [on the] link to which the client is connected:".

-          And in the last sentence of this paragraph, the is missing ... "and select the appropriate subnet".

-          The discussion about interface-id on bottom of page 6/top of page 7 is a bit incorrect in that an interface-id may always be included - it is not just included it the link-address is not set. Also, a server could ignore a link-address and use the interface-id. I'm also wondering if this entire interface-id discussion is worth it since this isn't really what this draft is mostly about? Again, may be worth just to point out that other techniques can be used by a server to select the prefixes from which to assign address/delegate prefixes? (Technically I'm not sure 22.18 of 3315 permits this - the text just says "Servers MAY use the Interface-ID for parameter assignment policies." But I am less concerned about this as I don't think it matters what special purpose servers may do/permit.

-          I also believe the text regarding LDRA is incorrect - "in addition to receiving an IPv6 address that is on-link for the link"? Huh? The LDRA relay sets the link-address to the "Unspecified_Address" (there is the peer-address, but that is a link-local address and is the same as for non-LDRAs).

-          Page 7, start of first full paragraph - "For completeless" should b "For completeness".

-          At the bottom of page 7, the paragraph beings "In all cases, then, the DHCP server will a link-identifying IP address" ... I think the earlier text missed the case where there is no relay? In that case, the server would likely use the address of the interface on which the request packet was received?

-          I'm also not sure what the value (at least for this work) of introducing RFC 6977 is - as that deals with relay-agent to server communication.

-          Also, it seems the DHCPv4 case wasn't really covered here. GIADDR isn't mentioned until section 6??
** Section 4

-          For the JSON notation, is it worth to provide some kind of reference? There is RFC 7159 that defines this format.
** Section 5

-          The first 2 paragraphs should probably start with "[A] relay agent ...".

-          Minor - perhaps add v6/v4 - "link-local multicast [v6] or broadcasts [v4]"?

-          Last paragraph/sentence, change "legal" to "a valid"? (If you leave legal, a should be added before it.)
** Section 6

-          First paragraph, 1st sentence add a comma between "case, shown".

-          2nd sentence - "Not that in [this] configuration"?

-          2nd paragraph, "[The] server will send the response".

-          3rd paragraph, "Depending on the configuration[,] that can be [a] server's".

-          Also, "32 levels of encapsulation if [the packet] traveled".
** Section 7

-          "In this example"? Which? I think this is for Figure 2? So, "In Figure 2,".
** Section 9

-          2nd paragraph, "of certains optons" should be "of certain options".


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Monday, September 29, 2014 10:36 AM
To: [e-mail]
Subject: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.txt - Respond by Oct 13, 2014


Hi all,



This message starts the DHC working group last call to advance "Customizing DHCP Configuration on the Basis of Network Topology", draft-ietf-dhc-topo-conf-03, document as an Informational RFC. The authors believe that this version is ready.



The draft is available here:

http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-03



Please send your comments by October 13th, 2014. If you do not feel this document should advance, please state your reasons why.



There are no IPR claims reported at this time.



Bernie Volz is the assigned shepherd for this document.



- Tomek & Bernie