[dhcwg] Spencer Dawkins' No Objection on draft-ietf-dhc-dhcpv4-active-leasequery-06: (with COMMENT)

["Spencer Dawkins" <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-dhc-dhcpv4-active-leasequery-06: No Objection

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/



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

Thank you for including a lot of TCP-awareness in this specification.

I had a few questions, but nothing at Discuss level. If you have
questions about my questions, please ask, of course.

In this text, 

   A requestor attempts to establish a TCP connection to a DHCPv4 Server
   in order to initiate a Leasequery exchange.  If the attempt fails,
   the Requestor MAY retry.
   
you might want to give some guidance about reasonable intervals to wait
before retrying, randomizing retry intervals, and/or backing off retry
intervals to some conservative maximum value. This isn't a
general-purpose client-server protocol, and you understand the use case
better than I do (and I wouldn't try to offer defaults), so please just
consider whether this would be helpful.

In this text,

   In any of the first three possibilities, the DHCPv4 server can be
   assumed to not support TLS.  In this case, the requestor MUST close
   the connection.
   
is the assumption that all three possibilities would happen again if you
retried the attempt with the same server? I wondered especially about the
second possibility (server side TCP connection close, as a possible
load-shedding strategy to reject a connection request that might work at
another time).

In this text,

   The Requestor attempts to read a DHCPv4 leasequery reply message from
   the TCP connection.  If the stream of replies becomes blocked, the
   Requestor SHOULD terminate the connection after
   ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
   to do so.
   
I'm not sure what "becomes blocked" means from the Requestor's
perspective. I'm guessing the following paragraph, describing interaction
with DHCPLEASEQUERYSTATUS, is the clue I'm missing, but if so, reversing
the order of the paragraphs, and tying that more tightly ("becomes
blocked, with no DHCPLEASEQUERYSTATUS messaging", or whatever the clue
I'm missing is), would likely be clearer.

I have pretty much the same question about the corresponding text for the
server side in 8.1,

   If the TCP connection becomes blocked while the server is accepting a
   connection or reading a query, it SHOULD terminate the connection
   after a BULK_LQ_DATA_TIMEOUT.  We make this recommendation to allow
   servers to control the period of time they are willing to wait before
   abandoning an inactive connection, independent of the TCP
   implementations they may be using.
   
and in 8.2,

   If the connection becomes blocked while the server is attempting to
   send reply messages, the server SHOULD terminate the TCP connection
   after ACTIVE_LQ_SEND_TIMEOUT.  This timeout governs how long the
   DHCPv4 server is prepared to wait for the requestor to read and
   process enough information to unblock the TCP connection.  The
   default is two minutes, which means that if more than two minutes
   goes by without the requestor reading enough information to unblock
   the TCP connection, the DHCPv4 server SHOULD close the TCP
   connection.
   
This text 

8.3.  Multiple or Parallel Queries

   Every Active Leasequery request MUST be made on a single TCP
   connection where there is no other request active at the time the
   request is made.  Note that this is different than what was allowed
   in [RFC6926] section 7.7 for Bulk Leasequery requests.
   
and the following two paragraphs are good, but I didn't see any
corresponding description of whether parallel queries were allowed on a
single TCP connection in Section 7, for Requestor behavior, and the
Requestor would be the entity that does this wrong, wouldn't it? Or did I
miss it?

I've seen some use cases described in IESG evaluation e-mail that sounds
like the Requestor and DHCPv4 server are close enough for a human to
touch both at the same time, but Kathleen commented that some ISPs
provide DHCP service to customer edge routers. Is it worth saying
anything about firewalls and NATs treating TCP differently? Or would even
those cases be part of a trusted network path, so no firewalls or NATs?