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

Tom Pusateri <pusateri@bangj.com> Tue, 02 July 2019 21:24 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 7FF2A1200E0; Tue, 2 Jul 2019 14:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hUcVFRiwQE7b; Tue, 2 Jul 2019 14:24:12 -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 60C321200D6; Tue, 2 Jul 2019 14:24:12 -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 72C5533B02; Tue, 2 Jul 2019 17:24:11 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3560.7\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <156175221593.21875.9525138908968318905@ietfa.amsl.com>
Date: Tue, 2 Jul 2019 17:24:10 -0400
Cc: gen-art@ietf.org, draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com>
References: <156175221593.21875.9525138908968318905@ietfa.amsl.com>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.3560.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/slrB_HPhYsE1zYsoEFgLLRc0ROA>
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: Tue, 02 Jul 2019 21:24:15 -0000


> On Jun 28, 2019, at 4:03 PM, Robert Sparks via Datatracker <noreply@ietf.org> wrote:
> 
> Issue:
> 
> The discussion of recursive resolvers in section 6.1 may need additional
> consideration. In particular, the recommendation to pass a received error code
> along to a client has, I think, some unintended consequences for the client. If
> the recursive server receives a NOTIMP, for example, passing that to the client
> tells the client the wrong thing about the server it is connected to. Perhaps
> it would be better for the recursive server to return SERVFAIL in this
> circumstance? (Similar to what it would do if it couldn't connect to the next
> server as described at the bottom of page 10).


The only time NOTIMP is returned is in the case where DSO stateful operations (over which DNS PUSH runs) is not supported. This error code is due to the fact that DSO uses a different Opcode than the standard Query/Response Opcode. DSO defines a new opcode. The effect of this is that NOTIMP is the correct response if a server doesn’t support the new Opcode.

Similarly, if DSO is supported but DNS Push TLV type is not supported, we return a new RCODE for DSO type not implemented DSOTYPENI.

These are both required by existing specifications.

If a client begins the connection with a DSO Keepalive to a resolver and the resolver accepts the connection, subsequent SUBSCRIBE operations that return NOTIMP will be obvious that the authoritative server does not support DSO.

However, if the client begins with a SUBSCRIBE and receives NOTIMP from the resolver, it’s not clear if the NOTIMP was originated by the resolver or the authoritative server.

Right now, we allow either DSO TLV to setup the state. In the case that the client begins with a SUBSCRIBE and the resolver returns NOTIMP, the client should attempt a connection with the authoritative server directly as described in 6.1. If the authoritative server returns NOTIMP, then PUSH notifications are not possible.

While we could be more explicit about every error case, I don’t think the document says anything wrong here.

Thanks,
Tom