Hi Kim, Thanks for addressing my issues! I am happy with your suggested modifications :)
Regards, Christer -----Original Message----- From: Kim Kinnear [mailto:[email protected]] Sent: 10 September 2015 21:45 To: Christer Holmberg <[email protected]> Cc: Kim Kinnear <[email protected]>; [email protected]; [email protected] 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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
