Re: [dhcwg] Review of draft-ietf-dhc-topo-conf-01

Hi all,
I think this work is very helpful and well documented. Here are some minor
comments on this draft.

1. In section 2, the xml missed <list></list> tag.

2. Page 5 paragraph 4, "In either case ..."

Which cases? This sentence only discusses DHCPv4, and DHCPv6 is discussed
in the next paragraph.
Since the next paragraph mentioned dhcpv6 options, it's better to mention
option 82 in this paragraph.

3. In page 6 paragraph 2, "and in some cases which layer 2 link the client
is connected to"

Which paragraph discussed this (L2 link)? I don't get it.

4. In section 3, paragraphs in page 5 and page 6 have no pointer to the two
figures (and are not explaining the figures),
so I suggest to put them in separate sections or subsections.

5. In section 4 Figure 3, replace the 10.0.x/24 prefix with RFC5737 prefix.
(not sure about this, it's quite minor)

6. In section 5, "Relay agent can be run on a host connected to two links."

It can, but one link is enough for a host besides the cascade case.
There're some words in section 9, but I'd like some words in section 5 too.

7. In section 8, "When changes are made to the DNS server, these changes are
    immediately and automatically adopted by the DHCP server."

Wouldn't the changes be adopted by the DHCP server when the next DHCP query
(that requests the corresponding address) comes,
not "immediately"? Although there's no much difference...

Best Regards,
Cong Liu

2014-03-29 22:22 GMT+08:00 Bernie Volz (volz) <volz@cisco.com>:

>  Below are some comments I had sent to Tomek a while back ... I think some
> (or all) of these might have already been noted by others.
>
>
>
> I also believe it is worth mentioning RFC 3257, Link Selection sub-option
> for the Relay Agent Information Option for DHCPv4 - as using these avoids
> the overloading of giaddr to be both the "location" of the client and the
> relay address.
>
>
>
> ---
>
>
>
> Section 10.  Mutliple subnets on the same link
>
>
>
> Multiple is misspelled in section title.
>
>
>
> Section 4, figure is labeled as both Figure 2 and Figure 3?
>
>
>
>    {"prefixes":
>
>      {"10.0.0.0/24": {"options": {"routers": ["10.0.0.1"]}
>
>               "on-link": ["a"]}}
>
>       "10.0.1.0/24": {"options": {"routers": ["10.0.1.1"}}
>
>               "on-link": ["b"]}
>
>       "10.0.2.0/24": {"options": {"routers": ["10.0.2.1"}}
>
>               "on-link": ["f"]}
>
>       "10.0.3.0/24": {"options": {"routers": ["10.0.3.1"}}
>
>               "on-link": ["g"]}}
>
>
>
>
>
>    Figure 2
>
>
>
>                                  Figure 3
>
>
>
> I also think the text which follows this figure should refer to figure 2,
> not 3.
>
>
>
> Actually the problem is that this should be Figure 3, not 2. And the later
> "Figure 3" (Section 7) should be Figure 4.
>
>
>
> (As a side issue, I wonder whether for v4 example the "prefixes" would be
> better as "subnet"? Also,
>
>
>
> - Bernie
>
>
>
> *From:* dhcwg [mailto:dhcwg-bounces@ietf.org] *On Behalf Of *Qi Sun
> *Sent:* Wednesday, March 26, 2014 7:47 AM
> *To:* <dhcwg@ietf.org>
> *Subject:* Re: [dhcwg] Review of draft-ietf-dhc-topo-conf-01
>
>
>
> Dear all,
>
>
>
> I volunteered to review the document. The document is well written and
> easy to review. I have some comments in addition to Simon and Sheng's.
>
>
>
> 1. Sec 2, Terminology:
>
>    an IP address with a scope of use wider than the local link.
>
>
>
> [Qi] Is this the definition for "Link-identifying IP address"?
>
>
>
>   provider edge router.  The provider router closest to the customer.
>
>
>
> [Qi] Suggest:
>
> Provider Edge router (PE router): ...
>
>
>
>   customer premise equipment device.  Typically a router belonging to
>
>   the customer that connects directly to the provider link.
>
>
>
> [Qi] Suggest:
>
> Customer Premise Equipment device (CPE device): ...
>
>
>
> 2. Sec 3, on Page 6
>
>    In either case, the DHCP server is able to obtain an IP address that
>
>   it knows is on-link for the link to which the DHCP client is
>
>   connected: either the DHCPv4 client's routable IPv4 address, or the
>
>   relay agent's IP address on the link to which the client is
>
>    connected.
>
>
>
> [Qi] The word "obtain" here is confusing: it seems the DHCP server obtains
> an IP address for its own configuration. Obviously not.
>
>
>
> 3. The 1st paragraph on Page 7
>
>    DHCPv6 also has support for more finely grained link identification,
>
>   using Lightweight DHCPv6 Relay Agents [RFC6221<http://tools.ietf.org/html/rfc6221>]
> (LDRA).  In this
>
>   case, in addition to receiving an IPv6 address that is on-link for
>
>   the link to which the client is connected, the DHCPv6 server also
>
>   receives an Interface Identifier option from the relay agent that can
>
>   be used to more precisely identify the client's location on the
>
>    network.
>
>
>
> [Qi] IMHO, the word "receive" here is also confusing, as "obtain" in the
> previous note.
>
>
>
> 4. Section 5
>
>    Relay agent is a DHCP software that may be run on any IP node.
>
>   Although it is typically run on a a router, it doesn't have to be
>
>   one.  Relay agent can be run on a host connected to two links.  That
>
>   case is presented in Figure 2.  There is router B that is connected
>
>   to links D and E. At the same time there is also a host that is
>
>   connected to the same links.  The relay agent software is running on
>
>    that host.  That is uncommon, but legal configuration.
>
>
>
> s/on a a router/on a router/
>
> BTW, where is the host that connects to the same links with the router B
> in Figure 2?
>
>
>
> Thanks for writing this.
>
>
>
> Best Regards,
>
> Qi
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>