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

Ted Lemon <> Fri, 12 July 2019 00:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC956120155 for <>; Thu, 11 Jul 2019 17:32:34 -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 N7gTkR5KZisQ for <>; Thu, 11 Jul 2019 17:32:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EDFD12009C for <>; Thu, 11 Jul 2019 17:32:32 -0700 (PDT)
Received: by with SMTP id l9so6407924qtu.6 for <>; Thu, 11 Jul 2019 17:32:32 -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=zFef4VNLqwF/7AA40P2uB2eiNiZqLBOIX9F0iyRFHO4=; b=TPo7nHD8h/KwBBeCDLxFzqe+PftabXezHtM/dDBdvPzc0tKLYdEE9qg0Rph8EgYsjr IelS55zb5w6ccBnqasi1oeiDbuUmV1go5bxQ1e+2du2Oy0GQ9g03Fl9LLfeBbG2WY0+y FkQL5KpKowFIW5Nk2JR0vK4j8HlyL/STmYbVhUJ8YOQp1/iAo1gGGbglAcIa4NcSTjMn z1jZkHkoyeElYyd7qay5T9Mov+F04Eo/H83BQkGU2T3IldkY8/rWM/hcjBQ4DuXqPfnY paNXkjyPe51VrfNtf9rKh4i6xqN8vYbCN+Ei6gPr0AwzicFA+Na1XvUQiKVj5DaNGLAN NQ0Q==
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=zFef4VNLqwF/7AA40P2uB2eiNiZqLBOIX9F0iyRFHO4=; b=H6EIwz4JT7C4Av0MuwbtJ0Q8hzE8E/iQmAdbL8Qc4TCZ3JAZDynwIq2CunAg1AhIzz O1e/ZviPso4bCwy1wKHCginKADk0kyN+tSTEhiDGiIwq2+AtS9Qea4Sy7+mC65xSpSGS b+xWN3ex53s4bskxxt1ULbkBPmp+STZ2iy1mYH6X3TUo8u9Kvr9wZWlsDlmoa7YAH3SA gfm1rZBrQLipkRCCMyJCZNTm9K+4+lzf453XMZCgPjt+4n7tvG9nlujnpoGm3IhGpSm4 x9iI6jaoigyDdOYFcyHxpQ6yC8cv5kxVGsuwpAEz7n2ozEJciQbIQYEeodrrJ7ZUVcxx Tw5Q==
X-Gm-Message-State: APjAAAXjfKA4tWtaQFxIYtQawfLRSe7z5X7+VDSwGZjK1kv4HNPpAOP2 dEEfeT7Q9F3bYt3RrfCtOtw/6A==
X-Google-Smtp-Source: APXvYqzF7PpTiM/8oDlXwD2V9XP7xK191GROEOjptsEeGFruhxEHHPNf2R53IKb1yVq/J085McfoUw==
X-Received: by 2002:a0c:ad6f:: with SMTP id v44mr4344994qvc.40.1562891551474; Thu, 11 Jul 2019 17:32:31 -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 f25sm3362893qta.81.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 17:32:30 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_987AC539-3ED2-4967-AA6E-1FE30766332E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 11 Jul 2019 20:32:26 -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: Fri, 12 Jul 2019 00:32:35 -0000

On Jul 11, 2019, at 7:39 PM, Tom Pusateri <> wrote:
> There is no back to back reconnect in the #2 case. The server shouldn’t accept the connection after sending a RETRY DELAY to this client. The client may ignore the RETRY DELAY but this doesn’t matter. It’s only a courtesy that the SERVER tells the client how long it has to wait.

I don’t know how the server refuses connections on a per-client basis.   We certainly don’t describe how to do that in the DSO RFC.  Practically speaking, unless the server is maintaining a list of all the clients that connect to it, it has no idea that client X that it just dropped is client Y that just connected.   Even if it does maintain such a list, it would be unusual for that to allow it to actually drop the connection immediately.   And supposing it does, that might just make the client reconnect a bit faster.   That is, if the SYN gets an RST in response, the client will just get -1 from connect() and call connect() again unless it has some kind of backoff strategy.