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

Ted Lemon <> Thu, 04 July 2019 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D6AE1200B6 for <>; Thu, 4 Jul 2019 12:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EI8wx1qD4PBn for <>; Thu, 4 Jul 2019 12:54:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA783120188 for <>; Thu, 4 Jul 2019 12:54:07 -0700 (PDT)
Received: by with SMTP id w17so5900538qto.10 for <>; Thu, 04 Jul 2019 12:54:07 -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=JJHTVdctnQUMJAV1RrFA9LKeiGlK+7sbi1FyyYj0aUc=; b=xl7GCVJ1J8ap8QGtEgf7GTdlt0sdaoxCL8wIZbbsCUH7Zfb2VPcjTlA13n5gG5GbJ7 maotUwBlBLqGapGCM2VpWOBl9XufWOVndmX6/3WPsuzGoXDw6rgL/qRunwD0eKMURa5o NmGVFaV9UPtMj+2QiYS4rZtONNEdbzhHofLS2rEfm8l/NodB2ADlm89QJjFnS8aONG6g RjyJg1j9EV6Q8Mrm6UmAdw1GCVx+u5gYJZGXN1c+0TTmsMqCKZepf7nyOQ9foyw79mzv 31qSJZsUYzTmZSFzWseyjhr42pgUDQVnhntmc+oA/2mIkQq30XL8Qp2FJv92kSSYsIwG NRKA==
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=JJHTVdctnQUMJAV1RrFA9LKeiGlK+7sbi1FyyYj0aUc=; b=HY7cVlCHdhoKjY4ednxvDB0ljhVnL/hCcQHkB5QERhsz43M1vGBPJIgqU2jAeClBQe Nzo5k1uFs9zR6483RidOstSgaOCdoPqID1APwzrPPndnuB6nIj7oypdJXzJPb6WD+puJ Hkhoql7dpDj6+J3NkTDSgc4ncotpQ2ZA1+i7JDVltWGj/Skm+DkCsf09wbnPsP+ij79g b8jaEt3NwlfFe6HAkcrlOCxJBsTjGptAhUQpuNvl4AHLWYAv0cSprEliH8RySVfPnqmk jfilJSA+XwR6wVrBSrFBkUAwoCB4imNJWQGZspgWX3c0+S7aUOdVJujkq0nW6ZdoqQfI NTIQ==
X-Gm-Message-State: APjAAAW2g9L5IKbZO5YjwR6TAD4tSdSJkGhuYjdF3FQc4Kgt/mp5g0/G c2jkjGMYuMNpxn0g3S7Io67D/Q==
X-Google-Smtp-Source: APXvYqxtcxH9ujZVWR6gs7JUaVr+q4IzAILovRPjNGALj/feFilRjyZiy4cGJ1+IVPztH90rz6999A==
X-Received: by 2002:ac8:3636:: with SMTP id m51mr36557837qtb.102.1562270046830; Thu, 04 Jul 2019 12:54:06 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:14d2:b425:853d:12fe? ([2001:470:c1a2:1:14d2:b425:853d:12fe]) by with ESMTPSA id n5sm3040379qta.29.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 12:54:06 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_001132AE-C0BE-49C2-971B-22D3612A314F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 04 Jul 2019 15:54:04 -0400
In-Reply-To: <>
Cc:,, IETF <>,, 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, 04 Jul 2019 19:54:11 -0000

On Jul 4, 2019, at 3:32 PM, Tom Pusateri <> wrote:
> I was trying to give the client enough information to determine WHY it failed. If we determine this isn’t important, we can just let the client try to figure it out but it will be more work for the client.

The client is a computer program, not a person, so there is no chance that it will be able to figure out what went wrong! :)

Seriously, though, what’s the strategy the client should follow in this case?  I think we generally say “try again in an hour” but I’m not sure if we said that explicitly here or just in the DSO document.

> It’s likely that resolvers aren’t going to support this before authoritative servers are and clients will quickly learn their resolver isn’t capable and go directly to the authoritative for some period of time.

I think that how resolver support for this will work is an open question right now, which will probably have to be addressed in a follow-on document.  At present, the implementation I’ve done doesn’t even attempt the local resolver, because I couldn’t figure out how to implement that.  I’m assuming that in most cases there’s no particular benefit to using the local resolver, because the auth server will also be local.