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

Tom Pusateri <pusateri@bangj.com> Thu, 04 July 2019 19:32 UTC

Return-Path: <pusateri@bangj.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 EF9481201C5; Thu, 4 Jul 2019 12:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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=ham autolearn_force=no
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 sKQDwqBRnqFd; Thu, 4 Jul 2019 12:32:54 -0700 (PDT)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E331200B6; Thu, 4 Jul 2019 12:32:54 -0700 (PDT)
Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 460EB33D87; Thu, 4 Jul 2019 15:32:53 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <8ED0A4DA-3398-4CC8-8896-E126D82D6A31@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_12A1A3AA-CB83-4CAC-A31B-4DE43C1D6F6D"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\))
Date: Thu, 4 Jul 2019 15:32:52 -0400
In-Reply-To: <B5F53B32-452B-466C-832C-D31DD2D75C75@fugue.com>
Cc: draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, IETF <ietf@ietf.org>, dnssd@ietf.org, Robert Sparks <rjsparks@nostrum.com>
To: Ted Lemon <mellon@fugue.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> <B5F53B32-452B-466C-832C-D31DD2D75C75@fugue.com>
X-Mailer: Apple Mail (2.3564)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/a0hLmvmCg3aiH6WbfyBGqms2QEs>
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 19:32:57 -0000


> On Jul 4, 2019, at 2:13 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Jul 4, 2019, at 12:52 PM, Tom Pusateri <pusateri@bangj.com <mailto: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?
> 

Do I already have a session or not with my resolver is not a lot of extra state. Especially when it’s over TLS and you are likely to keep the session up for some time and then let it expire. This state is necessary regardless.

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.

>> 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.



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.

Tom