DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-06

Thanks for addressing my DISCUSS comment. I am clearing now under the assumption the proposed text will make it into the draft.

I have 2 questions that I would like to chat about and should be easy enough to resolve.

1. I know we've discussed in the past why there is no MUST for TLS and it having to do with DHCPv6 use on private networks or isolated.  Is there text in one of the more recent RFCs that covers this explanation that can be cited?  I'd like to make sure that's enough too.

2. The Security Considerations section says not to use Authentication from RFC3316.  SHould authentication instead be done within TLS or how will the session be authenticated.  Did I miss something?  I'm not finding the term authentication elsewhere in the draft and can infer things, but wanted to make sure since nothing is stated explicitly.

A few questions that are not fully clear to me and maybe need some additional explanation in the draft (or maybe it's just me...):

- It's not fully clear to me when a TCP connection is opened or closed. Are the two servers supposed to have one long-lived connection? And if that connection is terminated for any reason, should the primary server try to re-open immediately? And if a (new) connection is (re-)open do I always need to send a CONNECT first, or only if I didn't have any connection with this server before? And if the secondary server goes down and comes up in RECOVER state (sec 8.5.1.), should it open a TCP connection to the primary server, or will always the primary server be the one that opens the connection (and if so when will it do it)?

- Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD  is needed and how the server should know the right value. I guess you would want to calculate this based on the send buffer, however, not all message have the same size and as such I don't know how to calculate that. And is that really needed? If messages will not be accepted by the receiver-side server, the receive window will be zero and the socket on the sending side will be blocked; no additional message can be send. What will be different if the sender knows in advance when it could potentially happen (but also might not if the other end processes the messages quickly and there is no excessive loss).

- I support Ben's discuss about "secure mode" - a few
more details are needed, in particular how a pair
decide to use/not-use TLS - are there different ports
or a STARTTLS equivalent - I can't see that defined
here. (Is it inherited from RFC7653? If so, maybe you
need to say?)

- For the DNS update stuff - is there no need to use
TSIG secrets? If there is, how is that sync'd between
the pair of DHCP servers?  If it is sync'd then don't
you need to say that TLS is a MUST for such
connections? If there is no support for TSIG, is that
likely to work?