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

[Kim Kinnear <[e-mail]>]

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):

On Aug 21, 2015, at 1:22 PM, Brian Haberman <[e-mail]> wrote:

> 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.
	
	Fixed this, and referenced Section 8.1 where the normative
	statements exist.
> 
> 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.
	
	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
> content of messages?

	Fixed this to be 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.

	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.
> 
> 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.

	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.
> 
> 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.

	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.
> 
> 7. Should this draft have an equivalent discussion on time value
> 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...

> 
> 8. Should section 8.1 have some discussion of mutual authentication or
> 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
> 
> Regards,
> Brian
>