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

["Jan Komissar (jkomissa)" <[e-mail]>]

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.

Thanks,

Jan.

On 10/26/18, 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