Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

[Ted Lemon <[e-mail]>]

On Jul 11, 2019, at 5:46 PM, Tom Pusateri <[e-mail]> wrote:
> 1. CLIENT receives SUBSCRIBE from server
> 2. SERVER receives duplicate SUBSCRIBE
> 3. CLIENT receives PUSH with no change notifications
> 4. CLIENT receives PUSH notification with ‘collective remove’ TTL and non-zero RDLEN
> 5. CLIENT receives PUSH notification with DNS message length larger than 16k
> 6. CLIENT receives UNSUBSCRIBE from SERVER
> 
> In cases 1, 3, 4, 5, and 6, the CLIENT will likely mark the SERVER as buggy, close the connection and not try to reconnect for a period of time or use another SERVER if available. A RETRY DELAY isn’t applicable and the CLIENT can close the connection either with a TCP RST or a TLS close_notify. The consensus seems to be to send a TCP RST in this case.
> 
> In case 2, the SERVER should send a RETRY DELAY TLV and then send a TLS close_notify or it could wait for the CLIENT to close_notify or RST but the SERVER shouldn’t RST because it wants the CLIENT to get the RETRY DELAY.
> 
> There are also cases where the server sends a RETRY DELAY TLV because of a SUBSCRIBE error and the CLIENT is supposed to close the connection. However, if the CLIENT does not close the connection, the SERVER may choose to close it in which case it should close with TLS close_notify to make sure the RETRY DELAY is received.
> 
> I think it would be better for the CLIENT to try to send a TLS close_notify after receiving a RETRY DELAY so it can resume later especially in the cases when a SUBSCRIBE fails.

Given David’s points, I don’t think there’s any reason to send a RETRY DELAY in case 2.   It should be handled the same as the other “protocol error” cases.  Can you think of a reason why case 2 is different, other than that it’s the one case where it’s possible to send a RETRY DELAY?  Bear in mind that it is a protocol error for the client to send a duplicate subscribe: it means that the client’s internal state is not being tracked correctly.   So it’s not a recoverable error.  We don’t want the client to reconnect.

Additionally, as you’ve pointed out, although the server could send the client a RETRY DELAY, if the client isn’t following the spec in one context there’s no particular reason to expect it to follow the spec in another.   Requiring the server to have special heuristics to follow in the case of broken clients seems to be creating an unreasonable burden.