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

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-dhcpv4-active-leasequery-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Do you really want to discourage implementations that only support secure
mode? Is there a reason not to make secure mode MTI?

Do I understand correctly that insecure mode makes no attempt to
authorize requestors? If so, that should probably be mentioned in the
security considerations. (I note that 6926 had some words about access
control in the security considerations, but if this draft has the
equivalent, I missed it.)

The fact that insecure mode at the server does not allow a requester to
upgrade to secure mode seems brittle.  That is, it's easy to configure
things where the server and requester simply cannot talk.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alissa's discuss questioning why this allows the insecure
mode at all.

The draft could use a general pass to clean up the use of 2119 keywords.
There are a lot of redundant normative statements between sections, and
within sections. There are  2119 keywords in places that really don't
need them--you don't need a MUST or a SHOULD to just describe the basic
workings of a protocol. They should be saved for places where an
implementer has a decision to make, or is likely to do the wrong thing.
I've captured some examples, but I know I didn't get them all.

-- 3: "server SHOULD provide a mechanism to control which data is
allowed"

Why not MUST?

  "with the exception that
   a server responding to an Active Leasequery request SHOULD be able to
   be configured to prevent specific data items from being included in
   the response to the requestor even if they were requested by
   inclusion in the dhcp-parameter-request-list option."

Redundant with previous. (Also, why not MUST)?

-- 7.1: "If the attempt fails,
   the Requestor MAY retry."

How many times? How often?

-- 7.2:  "A requestor SHOULD be able to operate in either insecure or
secure
   mode.  This MAY be a feature that is administratively controlled."

Why only MAY?

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

Why not MUST? Or more to the point, why does this need a 2119
keyword--it's simply how the protocol works?

  "The recommendations in [RFC7525] SHOULD be followed when negotiating
   this connection."

Why not MUST? (Or as Alissa commented, why not "The recommendations in
[RFC7525] apply")

  "the requestor SHOULD initiate the
   exchange of the messages involved in a TLS handshake "

Why not MUST? When might it not do so?

  "If the handshake exchange does not yield a functioning TLS
   connection, then the requester MUST close the TCP connection."

Is the requester allows to attempt a new connection in insecure mode?

-- 7.3: "The DHCPv4 request MUST have an
   xid (transaction-id) unique on the connection on which it is sent."

Redundant with previous statement.

  "the requester SHOULD place this
   highest base-time value into a query-start-time option"

Why does this need to be a 2119 keyword? It seems like the requester can
do this if it cares about catch-up data, otherwise skip it. (as indicated
by the next paragraph)

-- 7.4: "
  "Note that a DHCPACTIVELEASEQUERY request specifically requests the
   DHCPv4 server to create a long-lived connection "

I thought the Requester created the connections.

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

Why are the SHOULDs not MUSTs? When might one send additional messages,
or not close the connection?

-- 7.4.1: "The requester MUST NOT assume that every individual state
change..."

Redundant with previous statement.

-- 8.1:

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

Why not MUST? When might a server chose not to ignore them?

  "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."

Why not MUST? When might it do something different?

-- 8.1.1:

Why not MUST?

-- 8.4:

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

This seems to contradict previous normative statements. But I suspect you
mean something to the effect of "The server MAY end communication by
sending a DHCPLEASEQUERYSTATUS and them immediately closing the TCP
connection."

-- 9:

The section seems to have a lot of redundant 2119 keywords.


*** Editorial: 

-- 7.3:, paragraph starting with "Note that until all the recent
data..."

This paragraph would make more sense after the explanation of base-time
in the following paragraph.

-- 8.2:

  "The DHCPv4 server SHOULD, but is not required to, keep track of a
   limited amount of previous binding activity"

I suggest " ... limit the amount of previous binding activity it keeps
track of..."