Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv4-active-leasequery-05

[Christer Holmberg <[e-mail]>]

Hi Kim,

Thanks for addressing my issues! I am happy with your suggested modifications :)

Regards,

Christer

-----Original Message-----
From: Kim Kinnear [mailto:[e-mail]] 
Sent: 10 September 2015 21:45
To: Christer Holmberg <[e-mail]>
Cc: Kim Kinnear <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Gen-ART review of draft-ietf-dhc-dhcpv4-active-leasequery-05


Christer,

Thank you for the review.  My response to each of your issues appears inline, below.

On Sep 6, 2015, at 9:16 AM, Christer Holmberg <[e-mail]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> Document:                                   draft-ietf-dhc-dhcpv4-active-leasequery-05
> Reviewer:                                     Christer Holmberg
> Review Date:                               6 September 2015
> IETF LC End Date:                       8 September 2015
> IETF Telechat Date:                   N/A
> Summary:         The document is well written, but I have a few comments and issues I'd like the authors to address.                       
> Major Issues: None
> Minor Issues: None
> Editorial Issues:
>  
> General:
> -----------
> QGEN_1:
> The text says that the document updates RFC 6926, but it is a little unclear to figure out exactly what is updated.
> I think it would be good to have an explicit "Update to RFC 6926" section which explains exactly which parts are updated.

	I will create a new section, 8.1.1, entitled "Update to RFC 6926", which 
	will contain the following words:

   In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
   didn't discuss this situation explicitly), if the DHCPv4 server
   receives a DHCPv4 message containing a dhcp-message-type option with
   a value that is not supported over a TCP connection, it SHOULD close
   the TCP connection.

	And I will change the reference in the security section where this update
	is discussed from Section 8.1 to Section 8.1.1


>  
> QGEN_2:
> The draft talks about "secure mode" and "insecure mode" in a few places, and defined different procedures based on which mode is used.
> However, there is no generic definition for "secure mode" and "insecure mode". I wonder whether it would be useful to add some text somewhere, e.g. to section 2?

	I will add both of these to Section 2, Terminology:

   o "insecure mode"

     When operating in insecure mode, the TCP connection between the
     requestor and DHCPv4 server is not protected in any way.  In
     addition, the identity of the requestor is not validated by the
     server nor is the identity of the server validated by the
     requestor.

   o "secure mode"

     When operating in secure mode, the TCP connection between the
     requestor and the DHCPv4 server is protected by TLS [RFC5246].
     In addition, the requestor uses the certificates exchanged
     between it and the DHCPv4 server while setting up the TLS
     connection to validate the identity of the server.  The DHCPv4
     server also uses these certificates to validate the identity of
     the requestor.


>  
> Abstract:
> ------------
>  
> QA_1:
>  
> The text says:
>  
> "The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
>               extended with a Leasequery capability that allows a requestor to
>               request information about DHCPv4 bindings."
>  
> Please indicate in which specification (RFC?) this extension has been done.

	I will add a reference to RFC 4388 to the abstract.
>  
>  
> Section 1 (Introduction):
> ---------------------------------
>  
> Q1_1:
>  
> The text says:
>  
>               "Requirements exist for external entities to keep up to date on the
>               correspondence between DHCPv4 clients and their bindings."
>  
> Are these documented requirements, or generic requirements coming from the industry? Please clarify.

	These requirements are not documented in an RFC.  These requirements
	have come to us from users of DHCP servers in large service providers.

	In an attempt to clarify this paragraph, I will remove this sentence 
	and replace it with the one from the abstract, yielding this as the new
	paragraph:

   Continuous update of an external requestor with Leasequery data is
   sometimes desired.  These requestors need to keep up with the
   current binding activity of the DHCPv4 server.  Keeping up with
   these binding activities is termed "active" leasequery.

>  
>  
> Q1_2:
>  
> The text says:
>  
>               "This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it
>               specifies the DHCPv4 server should close the TCP connection if..."
>  
> Is "should" the correct wording? Section 8.4 contains both MAY, SHOULD and MUST procedures, and I am not quite sure which procedure(s) the text above refers.

	I will add a reference to the new Section 8.1.1 in the Introduction so
	that the reference is clear.

Regards -- Kim