[dhcwg] Mirja Kühlewind's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT)

["Mirja Kuehlewind" <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dhc-dhcpv6-failover-protocol-04: 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-dhcpv6-failover-protocol/



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

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