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

[Ted Lemon <[e-mail]>]

Thanks!  All good so far!  :)

On Fri, Oct 26, 2018 at 9:15 PM Tom Pusateri <[e-mail]> wrote:

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