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

Tom Pusateri <pusateri@bangj.com> Thu, 04 July 2019 20:09 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 5A2F512029C; Thu, 4 Jul 2019 13:09:13 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 yCtpADPg0ZAe; Thu, 4 Jul 2019 13:09:11 -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 F00FD120223; Thu, 4 Jul 2019 13:09:10 -0700 (PDT)
Received: from [172.16.10.123] (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 EA3C233D96; Thu, 4 Jul 2019 16:09:09 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-44B26C82-FA46-489D-AA61-E5F239E6C399
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <pusateri@bangj.com>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <CCEFAA9A-6198-491D-B966-9C32E0D354AB@fugue.com>
Date: Thu, 4 Jul 2019 16:09:09 -0400
Cc: dnssd@ietf.org, draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, IETF <ietf@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Content-Transfer-Encoding: 7bit
Message-Id: <B1BBEB30-8A3D-416F-B89D-FBAF033A6B4A@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> <B5F53B32-452B-466C-832C-D31DD2D75C75@fugue.com> <8ED0A4DA-3398-4CC8-8896-E126D82D6A31@bangj.com> <CCEFAA9A-6198-491D-B966-9C32E0D354AB@fugue.com>
To: Ted Lemon <mellon@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/vDy1svwswQI560ZtinYHPWVGmg8>
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 20:09:15 -0000

Maybe we could have a conference call and hash this out. Anyone is welcome. 

I’m ok with removing resolver support for now to simplify this and tackle resolvers in another document. But if there’s a good solution we’re all happy with, we can fix it now. 

Tom

> On Jul 4, 2019, at 3:54 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
>> On Jul 4, 2019, at 3:32 PM, Tom Pusateri <pusateri@bangj.com> 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.
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd