Re: [dnssd] Working group last call for draft-ietf-dnssd-push

Tom Pusateri <pusateri@bangj.com> Sat, 27 October 2018 01:15 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 D77AC130DD1 for <dnssd@ietfa.amsl.com>; Fri, 26 Oct 2018 18:15:52 -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 tVn2vMsFwWUB for <dnssd@ietfa.amsl.com>; Fri, 26 Oct 2018 18:15:50 -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 7A7BB1294D0 for <dnssd@ietf.org>; Fri, 26 Oct 2018 18:15:50 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (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 DBA99225A1; Fri, 26 Oct 2018 21:15:47 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <CAPt1N1m1d5Vj1ueC17ksfP7j9+23s0ATtxUwrTnCwmjqEQgtUQ@mail.gmail.com>
Date: Fri, 26 Oct 2018 21:15:46 -0400
Cc: "Jan Komissar (jkomissa)" <jkomissa@cisco.com>, Stuart Cheshire <cheshire@apple.com>, Tim Wicinski <tjw.ietf@gmail.com>, dnssd <dnssd@ietf.org>, David Schinazi <dschinazi@apple.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com>
References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> <DD18BDD4-FFDF-43BC-97E1-8BB846F15702@bangj.com> <C4802C62-E94C-48AE-867F-9A4743A4AEA2@cisco.com> <CAPt1N1m1d5Vj1ueC17ksfP7j9+23s0ATtxUwrTnCwmjqEQgtUQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/h4bPDSOjpI419Ch_4o70DiZp_8k>
Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push
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: Sat, 27 Oct 2018 01:15:53 -0000

Thanks for the feedback! Comments inline.

> On Oct 26, 2018, at 5:28 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> I'm in favor of advancing the document.   I have a few editorial comments:
> 
> On Page 6:
> 
>    For example, if a user presses the "Print"
>    button on their smartphone, and then leaves the phone showing the
>    printer discovery screen until the phone goes to sleep, then the
>    printer discovery screen should be automatically dismissed as the
>    device goes to sleep.  If the user does still intend to print, this
>    will require them to press the "Print" button again when they wake
>    their phone up.
> 
> 
> I don't think this is the right advice to give—it's not necessary to dismiss the UI.   It always surprises me when a context switch results in something in the UI changing without me changing it.    The less surprising behavior would be to simply stop doing these queries while the dialog isn't showing.   The dialog isn't showing when the phone is asleep.   So maybe this text would accomplish the same purpose without recommending a particular UI flow?
> 
> For example, if a user presses the "Print" button on their smartphone, and then leaves the phone showing the printer discovery screen until the phone goes to sleep, or switches
> to a different app, then the push subscription should (SHOULD?) be discontinued. When the phone wakes up,
> or the user switches back to the application that is showing the print
> dialog, the subscription could be reinstated, perhaps after a brief wait
> to allow the user to dismiss the dialog if they no longer intend to print.

I agree that too much implementation info here is not needed. How about:

(a) A subscription should only be active when there is a valid reason to need live data (for example, an on-screen display is currently showing the results to the user) and the subscription SHOULD be cancelled as soon as the need for that data ends (for example, when the user dismisses that display). Implementations may want to implement idle timeouts, so that if the user ceases interacting with the device, the subscription is cancelled.

> Section 3 says:
> 
> Standard DNS Queries MAY be sent over a DNS Push Notification connection, provided that these are queries for names falling within the server's zone (the <zone> in the "_dns-push-tls._tcp.<zone>" SRV record). The RD (Recursion Desired) bit MUST be zero. If a query is received with the RD bit set, matching records for names falling within the server's zones should be returned with the RA (Recursion Available) bit clear. If the query is for a name not in the server's zone, an error with RCODE NOTAUTH (Not Authoritative) should be 
>    returned.
> 
> Why is this?   What if this is a hybrid authoritative/caching resolver?   Also, later on we do actually specify that this can work with the local resolver.   ISTM you could say this instead and capture what is necessary:
> 
>    Standard DNS Queries MAY be sent over a DNS Push Notification
>    connection.   For any zone for which the server is authoritative, it
> 
>    MUST respond authoritatively for queries on names falling within
>    that zone (e.g., the <zone> in the "_dns-push-tls._tcp.<zone>" SRV
>    record) both for DNS Push Notification queries and for normal DNS
> 
>    queries.   For names for which the server is acting as a caching
>    resolver, e.g. when the server is the local resolver, for any query
>    for which it supports DNS Push Notifications, it MUST also support
>    standard queries.

That sounds better. I think the idea of subscriptions to a local resolver came along later and this part didn’t get updated.

> 
> Section 4 says:
> 
>    In keeping with the more recent precedent, DNS Push Notification is
>    defined only for TCP.  DNS Push Notification clients MUST use DNS
>    Stateful Operations (DSO) [
> DSO] running over TLS over TCP [RFC7858].
> 
> But section 7 says:
> 
>    The Strict Privacy Usage Profile for DNS over TLS is strongly
>    recommended for DNS Push Notifications as defined in "Usage Profiles
>    for DNS over TLS and DNS over DTLS" [
> RFC8310].
> 
> Which is it?   :)

Ok, I intended to go strict only since it was a new protocol. Here is the new text in Section 7:

The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS Push Notifications as defined in "Usage Profiles for DNS over TLS and DNS over DTLS". Cleartext connections for DNS Push Notifications are not permissible. Since this is a new protocol, transistion mechanisms using the Opportunistic Privacy profile are deemed unnecessary.

> 
> Section 5 says:
> 
>    Token bucket rate limiting schemes are also effective
>    in providing fairness by a server across numerous client requests.
> 
> 
> [Citation Needed]
> 
> Is there any reason to say this?

No. Probably better to remove it.

> 
>    DNS Push Notification clients and servers MUST support DSO, but (as
>    stated in the DSO specification [
> DSO
> ]) the server SHOULD NOT issue
>    any DSO messages until after the client has first initiated an
>    acknowledged DSO message of its own.  A single server can support DNS
>    Queries, DNS Updates, and DNS Push Notifications (using DSO) on the
>    same TCP port, and until the client has sent at least one DSO
>    message, the server does not know what kind of client has connected
>    to it.  Once the client has indicated willingness to use DSO by
>    sending one of its own, either side of the session may then initiate
>    further DSO messages at any time.
> 
> 
> It's just reiterating what the DNS Stateful Operations document says, and what was said previously about updates and so on.   Less text better?

I agree.

Ok, that’s as far as I got tonight. More tomorrow.

Thanks!

Tom