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

[Tom Pusateri <[e-mail]>]

> On Jul 11, 2019, at 2:20 PM, Tom Pusateri <[e-mail]> wrote:
> 
> But I think it would be helpful to outline the actual errors that could occur on either end and verify this works in every case. Sending as much information to the other side as possible is helpful for determining bugs. TCP RST signaling doesn’t convey much information.
> 
> Tom


Here are all the places a TCP RST was suggested in -20. These are all likely BUGS.

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.

Tom