Subject: [dhcwg] Fred Templin review of draft-ietf-dhc-rfc3315bis-05

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Aug 2016 14:46:03 +0000

Here are my overall review comments for this draft. I will post the high
points for discussion in subsequent messages to the list.

I support progressing this document for publication pending resolution
of these comments.

Thanks - Fred
[email-masked]

---

1) Introduction, paragraph 5, change: "DHCPv6 can also provide only
   other configuration options" to: "DHCPv6 can also be used to
   provide only other configuration options".

2) Section 1.2, the sentences: "[RFC3315] suggested that future work
   might be to extend DHCPv6 to carry IPv4 address and configuration
   information. However, the current consensus of the IETF is that
   DHCPv4 should be used rather than DHCPv6 when conveying IPv4
   configuration information to nodes." This text is at odds with the
   AERO spec, where DHCPv6 is used to carry IPv4 configuration info in
   environments where DHCPv4 mechanisms cannot be applied. Suggestion
   is to remain silent on this subject and remove these two sentences,
   then leave it for other documents to define mechanisms for carrying
   IPv4 information in DHCPv6 messages.

3) Section 4.2, suggested reword for the definition of "lease":
   "A contract representing an address assigned by the DHCP server
   to the client or a delegated prefix assigned by the delegating
   router to the requesting router."

4) Section 4.2, definition of "requesting router" - change to:
   "A node that acts as a DHCP client and requests prefix delegations."

5) Section 5, second paragraph, reword as: "This document assumes that
   the client and all DHCP servers that are reachable via a specific
   interface belong to a single provisioning domain."

6) Section 5.2, first sentence, s/[RFC2462]/[RFC4862]

7) Section 5.2, second sentence, reword as: "It is appropriate for
   situations where stateless address autoconfiguration alone is
   insufficient or impractical, e.g, beacuse of network policy,
   additional requirments such as dynamic updates to the DNS,
   client-specific requirements, etc."

8) Section 5.2, sentence beginning "Typically clients request", change
   "domain server addresses" to "DNS server addresses".

9) (no comment)

10) Section 12.1, the paragraph beginning: "Any address assigned by a
    server that is based on an EUI-64 identifier MUST" - does this
    alternative still match with operational experience? I.e., do
    real-world DHCPv6 servers create EUI-64 based IA_NAs? If not,
    this paragraph could be removed.

11) Should the order of Sections 12.2 and 12.3 be reversed? I.e.,
    talk about IA_NA first, then IA_TA and then IA_PD. In other
    words, talk about all address assignent methods first before
    talking about prefix delegation.

12) Section 13.1, the sentence "This method of bounding burstiness
    also guarantees that the long-term transmission rate will not
    exceed." is a sentence fragment that needs to be resolved before
    the period. Suggestion is to merge it with the following line as
    "This method of bounding burstiness also guarantees that the
    long-term transmission rate will not exceed a Trasmission Rate
    Limit (TRT)."

13) Section 13.2, second paragraph, this is the only place in the
    document that "renew" and "rebind" are used w/o capitalization.
    Should change to "Renew" and "Rebind".

14) Section 17, the sentence beginning: "In particular, if the
    client had some valid bindings and has chosen...". Remove
    this sentence. Reason - it should be OK for the client to
    receive bindings from multiple servers if it has some way to
    keep track of which bindings it received from which servers.

15) Section 17.1.5, add a trailing sentence to this section:
    "The client MAY send a Rebind message if its link-layer
    address(es) have changed, e.g., to update any cached
    link-layer address information."

16) Section 17.1.10.1, final paragraph, delete this paragraph
    since the client should be able to associate with multiple
    servers if it wants to.

17) Section 17.1.11, the sentence: "How does this mechanism work
    in the face of duplicated or retransmitted Reconfigure messages?"
    It seems odd to see this text phrased in the form of a question,
    which is then immediately answered in the rest of the paragraph.
    Simply deleting this question will shorten the paragraph while
    still retaining its integrity.

18) Section 17.1.12, add the following as a new last item in the
    bulleted list:

  o The requesting router's link-layer address(es) change.

19) Section 18.1.1, the sentence: "That is not recommended as it
   requires additional information to be provided in the server
   configuration." - suggest deleting this sentence. There may be
   many deployments that rely on this kind of configuration where
   a "not recommended" qualification does not apply.

20) Section 19, this whole Section needs to either import
    'draft-ietf-dhc-sedhcpv6' or simply say that a new DHCP
    authentication mechanism will be specified in a future
    document.

21) Section 20.11 again should mention 'draft-ietf-dhc-sedhcpv6'
    or simply say that a new DHCP authentication mechanism will
    be specified in a future document.

22) Section 21, same comment as for 20) and 21) above.