Re: [Gen-art] [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: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1F5120143 for <gen-art@ietfa.amsl.com>; Thu, 4 Jul 2019 11:13:26 -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=ham 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 Wn6Suhkf3Drv for <gen-art@ietfa.amsl.com>; Thu, 4 Jul 2019 11:13:23 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 2A24212015B for <gen-art@ietf.org>; Thu, 4 Jul 2019 11:13:22 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id s22so6092530qkj.12 for <gen-art@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=hejglsYN+T1e4/e9/qvwIViCNjLPWznAeWJGjyWvxqqUptDRstFQ7NOsb2KdEQo6bV f1mDJl0qtpYWnz68aMnoVfuaHdjaVrTiDAnOWtV2K9pHw4I53dp65TuUcpr0vGG5Xvyi yCKEaOE9ss5COh451u6cyr6UHoooIY/TnNWQEKYg94MXLoNDghyh1jiQVd476R5WELMA mizX5ijcXMscDuvTj9+DjGHpGx7/vgiQnhBLHlQVprTipcTCkgwrrAynLDjDe/0+GBtu fdWHEnPXCt3FpS18i8ASH+KejTil/TOalZGH11l8V3pYTf/kcJtuF3hGIJulhpQc5035 KJEA==
X-Gm-Message-State: APjAAAWUmpGK9+SgC9ppsYJ3uucUNGUHnKZvCoFk1tcQe2AubV2s8cle riKrx5SBzfQ/ydakLHeoDKYKRg==
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, 04 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/gen-art/ViQrnvZ6fr7Sgp164lC4m6xBY0I>
Subject: Re: [Gen-art] [dnssd] Genart last call review of draft-ietf-dnssd-push-20
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 18:13:26 -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.