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

Ted Lemon <> Thu, 11 July 2019 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7114120041 for <>; Thu, 11 Jul 2019 15:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.603
X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ne3NiwIgL79H for <>; Thu, 11 Jul 2019 15:58:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97C0612017C for <>; Thu, 11 Jul 2019 15:58:21 -0700 (PDT)
Received: by with SMTP id k10so6254449qtq.1 for <>; Thu, 11 Jul 2019 15:58:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7csaWt9xzuB7S5/JT26e/r/xEcpwIal7vjH48cp1yaA=; b=LuO80knzWV++9iNxkzi5dGirHwbFNTxPxHuRn5yz5YPw72/7ceqvNFLDR5xldl1r+a De5gHOQt1nNSBj3VvNH811TyGrBMDNbckEIYsR/TbHkiiliQzYGGvLt3i18bmXTDgFCT sFgVSfXwqfD4bKZCdIU/syRlqvoqyvT99k2L0aCdy1W2sMPt/MDYjmi1o+YFC/+cv+jj K+oGUT4ZpN+k0V227AngER8CSVuENwmowBK0xSEf5FnyHhrY1ixiAgO8Y5zi4FQ/R4X8 Zq5pCuAFfrj9RT8nAU+zw/rjConKSdy+kE99hSczP+Dxd2UNg5rPDuI79wUj9P4cZTvu z1aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7csaWt9xzuB7S5/JT26e/r/xEcpwIal7vjH48cp1yaA=; b=GAkZHy9/1oyJ2NgExgnXa0rZZyOVn7dwm1NlGINCeGVgpww8UsaiQwX3DM82XObXum 5NB1a1gr21ey5d4hZ6YvryvzAo7/KJmnF0CSm6TsFCRCaEOkKy85l3CnbjnlVYHwIq8P nHLnE9eHHULrgFBHD1tn7Z6RU0ZEjH8hE3Ky2/dAQoKQr8JoBhPqihs/ubWeVz28Ha/w UZ37/7maoFw1Qx1c0lE6D68wn11RZELOpU3RIsRoNjfUGtoCZDhgKDwrLb54xDGFhFn3 D8JtZCYOh+AcU16HEwwycqXgnBtq5HjqBuHX19gZiixf8t6mwoo7mpRKpUfYcJChazmb gp1w==
X-Gm-Message-State: APjAAAWu8JKRbZhNdX+EO+6+j9zrmprWP8BsfrWVfAZRww/H4ScRcetb uunF1jvGSmFk36NybJ6cYBST0g==
X-Google-Smtp-Source: APXvYqzEri16aV5QY6MGHIt++pJR5fJNZjFqapMPxDTfAgOB2nKIsaP907rH6UBRx2hIo6ZKivCg6A==
X-Received: by 2002:ac8:2726:: with SMTP id g35mr3841333qtg.35.1562885900409; Thu, 11 Jul 2019 15:58:20 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by with ESMTPSA id a21sm2686362qka.113.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 15:58:19 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_27009587-3EFA-4BB8-B9E8-AE12591F85C2"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 11 Jul 2019 18:58:16 -0400
In-Reply-To: <>
Cc: Stuart Cheshire <>, Eric Rescorla <>, DNSSD <>,, David Schinazi <>, Robert Sparks <>
To: Tom Pusateri <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
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 22:58:26 -0000

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.