Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv4-active-leasequery-06: (with DISCUSS and COMMENT)

[Kim Kinnear <[e-mail]>]

Ben, et. al.

I've submitted a new version of draft-ietf-dhc-dhcpv4-active-leasequery, 
with all of the changes to which I agreed during the review process.
I've replied to Ben's email since he had the most comments, but I
believe that I've covered all of the changes that we all discussed.

Below you will find a list of the changes that I have made along with
whose review prompted that change.

Thank you all for your reviews.

Regards -- Kim

-------------------------

1. Changed "recommendations in [RFC7525] SHOULD be followed" to
"recommendation in [RFC7525] apply".  Alissa Cooper

2. Added "Retries SHOULD NOT be more frequent than one every
ACTIVE_LQ_IDLE_TIMEOUT.  See Section 5.3." to the two places where
we say "... the Requestor MAY retry."  Ben Campbell, Spencer Dawkins

3. Added to Section 8.1:

"If a connection is to be rejected because of a limitation of the
number of open connections, the TCP connection itself should be
rejected, or the subsequent ACTIVELEASEQUERY message should be
rejected.  Capacity related rejections SHOULD NOT affect the response
to the DHCPTLS message." Spencer Dawkins

4. Moved the following paragraph to appear after a paragraph explaining
how the server needs to ensure that a constant (albeit light) stream
of messages flows from server to requestor:

"If the stream of replies becomes blocked with no messages being
received, the Requestor SHOULD terminate the connection after   
ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
to do so."  Spencer Dawkins

5.  Added the following paragraph to section 7.1, General Processing:

"Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection
at a time.  Parallel DHCPACTIVELEASEQUERY requests on the same TCP
are no allowed."  Spencer Dawkins

6. Added the following paragraph to section 9, Security Considerations:

"Operating in insecure mode (see Section 8.1) does not provide any
way to validate the authorization of requestors of a DHCPV4 Active
Leasequery request."  Ben Campbell

7. In section 7.2, Initiating a Connection, changed:

"When operating in insecure mode, the requestor SHOULD proceed to send
a DHCPACTIVELEASEQUERY request after the establishment of a TCP
connection."

to 

"When operating in insecure mode, the requestor sends a
DHCPACTIVELEASEQUERY request after the establishment of a TCP
connection."  Ben Campbell

8. In section 7.2, Initiating a Connection, changed:

"... the requestor SHOULD initiate the exchange ..."

to

"... the requestor initiates the exchange ..." Ben Campbell

9. In section 7.3, Forming an Active Leasequery, changed:

"... the requestor SHOULD place this highest base-time value into
a query-start-time option in the ..."

to 

"... the requestor should place this highest base-time value into
a query-start-time option in the ..." Ben Campbell

10. In section 7.3, Forming an Active Leasequery, changed:

"Note that a DHCPACTIVELEASEQUERY request specifically requests the
DHCPv4 server to create a long-lived connection which may not have
data transferring continuously during its lifetime."

to

"Note that the connection resulting from accepting a DHCPACTIVELEASEQUERY
request may be long-lived, and may not have data transferring
continuously during its lifetime." Ben Campbell

11. In section 7.4, Processing Active Replies, changed:

"This SHOULD be the last message on that connection, and once the
message has been transmitted, the server SHOULD close the connection."

to

"This MUST be the last message on that connection, and once the
message has been transmitted, the server MUST close the connection."
Ben Campbell

12. In section 8.1, Accepting Connections, added the following:

After:

"Any options appearing in a DHCPTLS message received by a DHCPv4  
server SHOULD be ignored." 

added:

"Any options appearing in a DHCPTLS message received by a DHCPv4  
server SHOULD be ignored.  This is a SHOULD instead of a MUST
in order to allow use of the DHCPTLS message in later documents,
possibly with the use of options, without requiring those documents
to update this document." Ben Campbell

13.  In section 8.1, changed the following:

"If for some reason the DHCPv4 server cannot or has been configured
to not support a TLS connection, then it SHOULD send a DHCPTLS
message with a dhcp-status-code of TLSConnectionRefused back to
the requestor."

to

"If for some reason the DHCPv4 server cannot or has been configured
to not support a TLS connection, then it sends a DHCPTLS
message with a dhcp-status-code of TLSConnectionRefused back to
the requestor."  Ben Campbell

14. In section 8.1.1, changed the following:

"In an update to the DHCPv4 Bulk Leasequery protocol <xref
target="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."

to

"In an update to the DHCPv4 Bulk Leasequery protocol <xref
target="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 MUST close the TCP connection."  Ben Campbell

15. In section 8.4, changed the following:

"The sever MAY close its end of the TCP connection after sending its
last message, a DHCPLEASEQUERYSTATUS message in response to a query."

to 

"The sever MAY may end communication by sending a DHCPLEASEQUERYSTATUS
message and then immediately closing the TCP connection." Ben Campbell

16. In section 7.3, moved the paragraph starting with:

"Note that until all of the recent data (catch-up data) has been ..."

after the subsquent paragraph. Ben Campbell

17. In section 8.2, replaced the paragraph beginning as follows:

"Note that until all of the recent data (catch-up data) has been ..."

with

"The DHCPv4 server SHOULD keep track of previous binding
activity.  It SHOULD limit the amount of previous binding activity it
keeps track of."  Ben Campbell

18. Addd this explanation to section 9, Security Considerations:

"Two modes of operation exist for this protocol, insecure mode and
secure mode.  These two modes exists because there are essentially
two models of use for this protocol.  In one model, the requestor
of an Active Leasequery is connected to the internet in an arbitrary
location, and the information transmitted needs to be protected
during transmission.  In addition, the identity of both requestor
and server need to be verified.  For this model of use, the secure
mode is appropriate.

The other model of use is where the requestor of the Active Leasequery
resides in a network element that is essentially "next to" the
element containing the DHCP server, and both of these elements are
inside a protected environment.  For this model, the insecure mode
is sufficient since there are other, more global, protections in
place to protect this information."

and placed references to it in section 7.2, Initiating a Connection
and section 8.1, Accepting Connections.

Alissa Cooper

19. Three situations where statements with normative language were used
which echoed other similar statements also using normative language were
changed to not use normative language.  References to the section of the
document where the normative language remains were added.  These
changes were made in sections 3, 7.1, and 7.4.1.  Ben Campbell