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

From: Brian Haberman <[email-masked]>
Date: Fri, 21 Aug 2015 13:22:54 -0400

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

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 24 Aug 2015 16:54:34 -0400

Brian,

Thank you for the review!

I have submitted draft-ietf-dhc-dhcpv4-axtive-leasequery-05.txt in
response to changes that I made resulting from your review.

Indented below you will find my detailed explanation of changes that
I made (or did not make):

> written without them and the same point will be made.
	
	Fixed this, and referenced Section 8.1 where the normative
	statements exist.
> will help with comprehension.
	
	This resulted from the varied history of the drafts,
	with the DHCPv4 draft actually being the first written and
	the DHCPv6 draft a modification of that DHCPv4 draft.

	I have brought the DHCPv4 draft into as close alignment as
	possible to the DHCPv6 draft in this regard.  "IPv4 address
	bindings" does not appear anymore in the DHCPv4 draft, and 
	the usage of "IPv4 address" has moved (in many cases) to 
	"IPv4 binding" or simply "binding" in the same way as the 
	DHCPv6 draft.  This resulted in many small changes.

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

	Fixed this to be messages.

>   [RFC5460] will be able to deal with the message held inside of the

	As Bernie pointed out, this was removed in the past due to
	DHC WG review, and I see no reason to put it back in.  Nor
	do I see any reason to remove it from the DHCPv6 draft.  
	While it is true, it is largely unimportant.
> statements that aren't normative should be re-worded to avoid confusion.

	I brought this draft into alignment with the DHCPv6 draft,
	which I think solves this problem.  If you had something else
	in mind, please let me know.
>   message's OPTION_LQ_START_TIME option.

	This is explained by paragraph 4 in Section 7.4.1 (as Bernie
	also noted), and as such I don't see that there is any reason
	to add this additional paragraph.
> processing as section 8.5 of the DHCPv6 version of the draft?

	What an interesting question!  As it turns out, both the
	DHCPv6 Active Leasequery draft and the DHCPv4 Active
	Leasequery draft refer to their corresponding Bulk Leasequery
	drafts.  The DHCPv6 Bulk Leasequery draft [RFC5460] does not
	ever discuss time in this way, so the DHCPv6 Active Leasequery
	draft had to have this paragraph inserted in it.  On the other
	hand, the DHCPv4 Bulk Leasequery draft [RFC6926] (which was
	written later than its DHCPv6 counterpart) *does* have this 
	paragraph in it, and so the DHCPv4 Active Leasequery draft 
	does not have to have this paragraph since it says:

   Thus, the handling of time, clock skew, data source, and other items
   discussed in the Bulk Leasequery specification [RFC6926] are to be
   followed when implementing Active Leasequery...

> signaling an error prior to closing the connection?

	Good catch!  Yes, the mutual authentication sentence slipped by
	me, and definitely needs to be in there.  

	Regarding the signaling an error prior to closing the
	connection, I believe you are referring to the DHCPv6 section
	on Rejecting Connections, which does not appear in the DHCPv4
	draft.  This is largely because the DHCPv4 protocol doesn't
	have a particularly great way to send a rejection message.
	DHCPv6 sends replies to just about everything, good or bad,
	and has this convenient REPLY message, but DHCPv4 doesn't have
	a message to send for a sort of generic rejection.  So we just
	close the connection (which signals the same thing).

	Thanks -- Kim