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

Ted Lemon <mellon@fugue.com> Thu, 04 July 2019 18:13 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122E1120143 for <dnssd@ietfa.amsl.com>; Thu, 4 Jul 2019 11:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLRQL0xqdJ3t for <dnssd@ietfa.amsl.com>; Thu, 4 Jul 2019 11:13:25 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A114120159 for <dnssd@ietf.org>; Thu, 4 Jul 2019 11:13:22 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id v22so6115104qkj.8 for <dnssd@ietf.org>; Thu, 04 Jul 2019 11:13:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5yXs/2EZLbNUZ763/11/SaFYPLjepWGHWS24gg/nd4k=; b=nFMi2EsLUvfzUSD5t57WEvZ6TDWxw48PZJ5XmX28WcCoCN515mcFCsu9RV/PwHcauZ eqkQ+DI9kHlxrP7eg+pSAV5knldPQ1ZBGdIMJ7sNdPvlrxLaXDKQBVRU8FfFU0IzMER8 Ob1CeZBZW3qkSLeutXJG6QtoIm9uKlwmlImxRr++sTgLIEcxMMlKk+lB4i613tPFuB5O xA89RaAu/I1TT4pg3IQzDimfPdtosCwiUUnwD2sFpYkJx86I/jrO+wHRSVgy98L39e6V BJ+kTj38Wz0engFj9Wca5GmGOAiQF01MAxaPXlIIK1qpPUVmjbn12xqwPAgNqCrvj+pI 6nhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5yXs/2EZLbNUZ763/11/SaFYPLjepWGHWS24gg/nd4k=; b=Ii3i7GvhEEpbW1n+7IV8SEy0GRIwsq/mR3nB3m8A0BDxZxPNfyE7wspxwktCROZkX5 0ALpKG3c3ikiUmCsLPYIY+AZgKwNgbU0NtKzxdKA1zUg2HXixIvHhGtQi0vjFEvgSVV3 6eZhXt0DyueP6t++vdiM4JYRqYvvn1cBe0QHI0rVAKIWvMo1IY3ppk0OGzgz6PQ0qYxh DNicex+ZkSEQVi3w6vOyEQIuwbZfh8llxd0gvkGVCgDxP1AMiIPYwq7xb6crsFD5ELq/ eDo/grnyiNpEIT5TuYuzJhs30LEIpNWc57EWJP3lAAQhGu6zMTUAX9i/KH9DMQLhAbRv QRjA==
X-Gm-Message-State: APjAAAW6m8IGmKp+ZBCtJ8KIe+/BoUjFhgpmybsnJPXvi/wSOyvQo9D0 3zAD2rNUXCp6+2LNaL+40rtXrg==
X-Google-Smtp-Source: APXvYqyQOP+mVVoSn6ocwHMJVptijj13sRd72CBlGc1CplRcG0rvu4vHf9/ZLKjHEjPMvv2rmYRbNQ==
X-Received: by 2002:ae9:f809:: with SMTP id x9mr2959960qkh.86.1562264000950; Thu, 04 Jul 2019 11:13:20 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:14d2:b425:853d:12fe? ([2001:470:c1a2:1:14d2:b425:853d:12fe]) by smtp.gmail.com with ESMTPSA id h4sm2710075qkk.39.2019.07.04.11.13.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 11:13:20 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <B5F53B32-452B-466C-832C-D31DD2D75C75@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E55E8C5-D8D8-4EC6-8C68-9BAEC871F6A6"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 4 Jul 2019 14:13:16 -0400
In-Reply-To: <AA6C3215-EA6A-4777-B615-819CB0F78662@bangj.com>
Cc: Robert Sparks <rjsparks@nostrum.com>, draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, dnssd@ietf.org, IETF <ietf@ietf.org>
To: Tom Pusateri <pusateri@bangj.com>
References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <a1812b4c-d443-fd36-ed51-bf054170efe6@nostrum.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> <AA6C3215-EA6A-4777-B615-819CB0F78662@bangj.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/cUCY-MVGRPzuAd3c0ojXOuTYjIA>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 18:13:27 -0000

On Jul 4, 2019, at 12:52 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> 1. The client should only send SUBSCRIBE to set up the DSO session if it has gone through the discovery process and wants to talk to the authoritative directly. If it wants to try to subscribe to push notifications through a resolver, then it should use KEEPALIVE first to establish the DSO connection with the resolver.

This creates a new semantic connection between KEEPALIVE and SUBSCRIBE.  This means that DSO implementations now have to track more state.  I don’t think there’s a benefit to doing this.  Why do you think it’s necessary?

> 2. If the resolver supports SUBSCRIBE but the authoritative doesn’t, the resolver should not send DSONI back to the client because the client can’t tell the difference between the resolver not supporting SUBSCRIBE and the authoritative not supporting SUBSCRIBE. In this case, the resolver should return SERVFAIL. This should inform the client that the authoritative doesn’t support SUBSCRIBE. If there are multiple authoritative servers supporting _dns-push._tcp, the resolver may want to try all of them before returning SERVFAIL.

There’s no need to mention DSONI here.  Just say what the right behavior is.  If you mention DSONI here, someone might read this to suggest that in some case DSONI would make sense.

SERVFAIL just means that the server is unable to support the requested behavior. It doesn’t signal why. Unless there’s something the client would do differently, I don’t think it’s necessary for the client to know why the request failed.