[dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv4-active-leasequery

[Brian Haberman <[e-mail]>]

All,
     I have completed my AD evaluation of
draft-ietf-dhc-dhcpv4-active-leasequery as a part of the publication
process.  Please let me know if you have questions/concerns with the
following comments.  Some of these comments address perceived
consistency questions between this draft and the recently approved
DHCPv6 active lease query draft.

1. The inclusion of normative statements (i.e., 2119 keywords) in the
Introduction is worrisome. The statements with 2119 keywords can be
written without them and the same point will be made.

2. There seems to be some inconsistency within the document (and between
this draft and the DHCPv6 version) with the use of "IPv4 addresses",
"IPv4 bindings", and "IPv4 address bindings". Consistent terminology
will help with comprehension.

3. Should Section 4 be talking about the content of packets or the
content of messages?

4. The following paragraph appears in section 6.1 of the DHCPv6 version
of this function.  Should it also appear in section 5.1 of this draft?

   The intent in using the same format is that code which currently
   knows how to deal with a message returned from DHCPv6 Bulk Leasequery
   [RFC5460] will be able to deal with the message held inside of the
   TCP framing.

5. Section 7.2 has some inconsistent capitalization of 2119 keywords.
The normative statements should use consistent capitalization. Those
statements that aren't normative should be re-worded to avoid confusion.

6. The following paragraph appears in section 8.4 of the DHCPv6 version
of this function.  Should it also appear in section 7.4 of this draft?

   The updates sent by the DHCPv6 server during the catch-up phase are
   not in the order that the lease state data was updated.  Therefore,
   the OPTION_LQ_BASE_TIME option from messages during this phase MUST
   NOT be saved and used to compute the subsequent ACTIVELEASEQUERY
   message's OPTION_LQ_START_TIME option.

7. Should this draft have an equivalent discussion on time value
processing as section 8.5 of the DHCPv6 version of the draft?

8. Should section 8.1 have some discussion of mutual authentication or
signaling an error prior to closing the connection?

Regards,
Brian