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

Tom Pusateri <> Thu, 11 July 2019 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CE3F120041; Thu, 11 Jul 2019 16:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vFnDTZlxc4Kc; Thu, 11 Jul 2019 16:03:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D29212016B; Thu, 11 Jul 2019 16:03:20 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9EC20347D5; Thu, 11 Jul 2019 19:03:18 -0400 (EDT)
From: Tom Pusateri <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_46CCAA12-F964-465A-83C1-5E7129210CDC"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\))
Date: Thu, 11 Jul 2019 19:03:17 -0400
In-Reply-To: <>
Cc: Stuart Cheshire <>, Eric Rescorla <>, DNSSD <>,, David Schinazi <>, Robert Sparks <>
To: Ted Lemon <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3564)
Archived-At: <>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jul 2019 23:03:23 -0000

> On Jul 11, 2019, at 6:58 PM, Ted Lemon <> wrote:
> On Jul 11, 2019, at 5:46 PM, Tom Pusateri < <>> 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
>> 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.

The SERVER may want to conserve resources from broken clients. The RETRY DELAY is for the SERVER’s protection and it’s thoughtfully informing the CLIENT how long it has to wait before the SERVER will accept a connection from it. It doesn’t matter if the CLIENT agrees or not or whether the CLIENT follows the spec or not.