Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-07

I think it would help to explain the rationale for having both secure and insecure modes supported.

In sections 7.2, 8.1, and 9, this is a bit of a strange layering of normative requirements:

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

If you were going to use normative language here I think this would more appropriately be a MUST, but I would actually recommend something along the lines of "The recommendations in [RFC7525] apply" since the recommendations contained therein vary in their normative strength. Perhaps the security ADs have a preferred formulation, I'm not sure.

Ben has anything I might say nailed quite well; thanks.

Thanks for addressing my DISCUSS points and comments!

I previously had no comments after reading the draft and think it may help to explain why, even though I did see the option for an insecure mode.

DHCP is *typically* used on local networks.  Admins have other controls they can use and I hope they aren't too worried about
their LANs physical security... they can use switches to separate out traffic - no one uses hubs anymore and they should control the equipment and wires.  Additionally, I was thinking that this was IPv4 and was long decided, as well as the discussions that already took place with Stephen for similar text in the IPv6 equivalent.  Since there was an option for a secure mode it could be used in other circumstances like an ISP's DHCP service to customers edge routers or any circumstance where a secure mode is warranted (and that's already stated in the Security Considerations). Security involves risk management decisions for operators and organizations and that has to be okay sometimes.  Since there is an option to use a secure mode (with details on how to do that) when needed, my feeling was the current text is enough given other security controls and the option that could be dependent on the environment.

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?

I think I recognise almost all of the security/privacy text we
ended up with for the dhcpv6 equivalent - thanks for getting all
that right!

For Alissa and Ben - I'd be happier too if only secure mode
existed here, but there was an argument (which I've forgotten)
as to why we needed the insecure one - I think it boiled down to
doing it on the same machine or that they'd do it no matter what
the RFC says. (But I may be mis-remembering.) So while I agree
with your points on that, I'm not sure we're (i.e. we as IESG)
right to fight the battle again over this one when they're
making this the same as the dhcpv6 one we already approved.
Anyway, if you do fight the battle over and win, we should
probably ensure any resulting edits also get done to the dhcpv6
equivalent spec which is with the RFC editor still.