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

[Jari Arkko <[e-mail]>]

Thank you Christer and Kim!

Jari

On 10 Sep 2015, at 21:53, Christer Holmberg <[e-mail]> wrote:

> 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
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art