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

"Jan Komissar (jkomissa)" <> Mon, 29 October 2018 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 755E8128BCC for <>; Mon, 29 Oct 2018 07:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zYd5ZvxZSjbU for <>; Mon, 29 Oct 2018 07:34:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C346130E29 for <>; Mon, 29 Oct 2018 07:34:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9234; q=dns/txt; s=iport; t=1540823693; x=1542033293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Cg79GSHlVGOffzuHExinUtaPW7Z4Xt1P1U8ozZ/Mb6w=; b=ig+WE+bQerjpIWl3QHdBH4XHqAxHENBGrkab//MQh8tdwfN5p4IFVVV7 ch/hsimLXjIn2L9STsluaYi2s2/NykX1UaAfIFORWCkYQ+7+xTwZ/TYsC y8qKySNvDxF++XCNyPkuI+fjfVeN5+CqRQrCcIojuuZvLoWjc9BiGsBkt 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAABYGddb/5BdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBggSBZSgKg2uUL4FoJZkaCwEBLIRAAhe?= =?us-ascii?q?DFSE3Cg0BAwEBAgEBAm0ohToBAQEBAgEdBhFFEAIBCBgCAgkdAgICMBUQAgQ?= =?us-ascii?q?OBYMhgXoIqB+BLooTgQuKXBeBQT+BEScME4JMhGiDGjGCJgKIWYIMg3uBRIR?= =?us-ascii?q?IiUlUCQKRAhiQR5Z1AhEUgSYzIoFVcBVlAYJBgiYXjhpvgSiJMASBKgGBHgE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.54,440,1534809600"; d="scan'208";a="470896067"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2018 14:34:52 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9TEYqF2031893 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Oct 2018 14:34:52 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 09:34:51 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 09:34:51 -0500
From: "Jan Komissar (jkomissa)" <>
To: Tom Pusateri <>
CC: Stuart Cheshire <>, Tim Wicinski <>, dnssd <>, David Schinazi <>, Ted Lemon <>
Thread-Topic: [dnssd] Working group last call for draft-ietf-dnssd-push
Date: Mon, 29 Oct 2018 14:34:51 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Oct 2018 14:34:56 -0000

Hi Tom,

Another thing I noticed: In the DSO spec (draft-ietf-dnsop-session-signal-16), in section 8.2  (p.51), there is a table indicating proper usage of the various TLVs in the spec with a recommendation to do the same for future TLV definitions. It might be good to add that to the Push Notification spec as well.



On 10/26/18, 9:15 PM, "Tom Pusateri" <> wrote:

    Thanks for the feedback! Comments inline.
    > On Oct 26, 2018, at 5:28 PM, Ted Lemon <> 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.