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

[Kathleen Moriarty <[e-mail]>]

I'm chiming in a little late, but I agree with Ben on his mTI comment.
I had noticed that as well when reading the draft, but was mostly okay
with the language.  The draft didn't spell out MTI, but seemed to talk
more about MTU.  MTI for secure mode would be good.  I see the
security considerations section has an MTU focus.  Where is the
statement in the list of changes that resulted from Ben's discuss?
I'm not able to pick it out easily (might just be me).

Thanks,
Kathleen

I'm not sure the SHOULD statement is enough, but if he's okay to clear...

On Tue, Oct 6, 2015 at 1:39 PM, Kim Kinnear <[e-mail]> wrote:
>
> 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 them all.
>
> I've included an rfc diff with this email, and 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
>
>



-- 

Best regards,
Kathleen