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

From: Tom Pusateri <[email-masked]>
Date: Sat, 20 Oct 2018 07:48:51 -0400

This last call deadline is approaching and there hasn’t been much feedback. That is probably due to the fact that we’ve been through last call before. 

But in order to be thorough, even if you responded before, if you think this document is ready, please just send a short affirmation before the 22 October deadline. 

Thanks,
Tom

> On Sep 29, 2018, at 8:26 PM, David Schinazi <[email-masked]> wrote:
> 
> Hi everyone,
> 
> This email starts a three-week working group last call for draft-ietf-dnssd-push. The call will run until October 22nd.
> Please review this draft and send comments to the list, even if only to say you support the draft.
> 
> The authors have let us know that the draft was updated to reflect the final changes in DNS Stateful Operations (draft-ietf-dnsop-session-signal) which was submitted to the IESG for publication. If we get enough support on the list for this document, we will be able to progress it alongside the Discovery Proxy (draft-ietf-dnssd-hybrid).
> 
> The chairs would also like to hear about implementation experience.
> 
> Thanks,
> David

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Mon, 22 Oct 2018 13:59:30 +0000

I approve.

Jan.

From: dnssd <[email-masked]> on behalf of Tom Pusateri <[email-masked]>
Date: Saturday, October 20, 2018 at 7:49 AM
To: David Schinazi <[email-masked]>
Cc: Stuart Cheshire <[email-masked]>, Tim Wicinski <[email-masked]>, dnssd <[email-masked]>
Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push

Thanks,
Tom

On Sep 29, 2018, at 8:26 PM, David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Hi everyone,

This email starts a three-week working group last call for draft-ietf-dnssd-push<https://tools.ietf.org/html/draft-ietf-dnssd-push>. The call will run until October 22nd.
Please review this draft and send comments to the list, even if only to say you support the draft.

The authors have let us know that the draft was updated to reflect the final changes in DNS Stateful Operations (draft-ietf-dnsop-session-signal) which was submitted to the IESG for publication. If we get enough support on the list for this document, we will be able to progress it alongside the Discovery Proxy (draft-ietf-dnssd-hybrid<https://tools.ietf.org/html/draft-ietf-dnssd-hybrid>).

Thanks,
David

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Oct 2018 17:28:29 -0400

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.

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.

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
<https://tools.ietf.org/html/draft-ietf-dnssd-push-15#ref-DSO>]
running over TLS over TCP [RFC7858
<https://tools.ietf.org/html/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
<https://tools.ietf.org/html/rfc8310>].

Which is it?   :)

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?

   DNS Push Notification clients and servers MUST support DSO, but (as
   stated in the DSO specification [DSO
<https://tools.ietf.org/html/draft-ietf-dnssd-push-15#ref-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?

Section 6.1 says:

   The client begins by opening a DSO Session to its normal configured
   DNS recursive resolver and requesting a Push Notification
   subscription.  If this is successful, then the recursive resolver
   will make appropriate Push Notification subscriptions on the client's
   behalf, and the client will receive appropriate results.  If the
   recursive resolver does not support Push Notification subscriptions,
   then it will return an error code, and the client should proceed to
   discover the appropriate server for direct communication.  The client
   MUST also determine which TCP port on the server is listening for
   connections, which need not be (and often is not) the typical TCP
   port 53 used for conventional DNS, or TCP port 853 used for DNS over

   TLS [RFC7858 <https://tools.ietf.org/html/rfc7858>].

This is inconsistent with the earlier assertion that the server we are
talking to is an authoritative server.   How do we know what zone, if any,
the default resolver is authoritative for?   What if it can support some
push notifications we want, but for others we need to talk to the
authoritative server?   What about TLS?

I think this text was added based on a comment I made a while back; I think
that the behavior defined here may be okay, but there should be some
additional text:

   The client begins by opening a DSO Session to its normal configured
   DNS recursive resolver and requesting a Push Notification
   subscription.  This connection is made to the default DNS-over-TLS

   port.   If this connection is successful, then the recursive resolver
   will make appropriate Push Notification subscriptions on the client's
   behalf, and the client will receive appropriate results.

   In many contexts, the local recursive resolver will be able to handle

   push notifications for all zones that the client may need to follow.

   In other cases, the client may require Push Notifications from more

   than one zone, and those zones may be served by different servers.

   It is assumed here, therefore, that the client may need to maintain

   connections to more than one DNS Push server.

   In some cases,

   the recursive resolver may not be able to get answers for a particular

   zone.   In this case, rather than returning SERVFAIL, the resolver

   returns NOTAUTH.   This signals the client that queries for this zone

   can't be handled by the local caching resolver.   For that zone, the

   client SHOULD contact the zone's DNS Push server itself, even if

   all other DNS Push queries can be handled by the local resolver.

   This may be necessary in cases where the client is connected to a VPN,

   for example, or where the client has a pre-established trust relationship

   with the owner of the zone that allows the client, but not the local

   resolver, to successfully get answers for queries in that zone.

   If the
   recursive resolver does not support Push Notification subscriptions,
   then it will return an error code, DSONOTIMPL.   This occurs when the

   local resolver follows the procedure below and does not find an SRV

   record indicating support for DNS Push Notifications.

   In case of either failure, the client should proceed to
   discover the appropriate server for direct communication.  The client

   MUST also determine which TCP port on the server is listening for
   connections, which need not be (and often is not) the typical TCP
   port 53 used for conventional DNS, or TCP port 853 used for DNS over

   TLS [RFC7858 <https://tools.ietf.org/html/rfc7858>].

Later in 6.1:

   3.  If the requested SOA record does not exist, the client will get
       back a NOERROR/NODATA response or an NXDOMAIN/Name Error
       response.  In either case, the local resolver SHOULD include the
       SOA record for the zone of the requested name in the Authority
       Section.

That SHOULD is updating RFC1035, I think, although I realize that there's
text later claiming it doesn't.   How about "would normally"?   Given that
we specify how clients handle the exceptional case, there's no reason to
get fussy about this here.   BTW, we really ought to have a document that
describes this stuff, so that we can reference it.   It's a fairly common
operation.

At the bottom of Page 16 (the end of section 6.2.1) it might be good to add
some text acknowledging the recent deprecation of ANY queries, and
explicitly saying why they are not deprecated here.   This avoids the risk
of DNSOP experts tripping on this, although they will probably see the
utility.

The table in 6.2.2 is introduced by saying "Supported RCODEs are as
follows:" but then lists NXDOMAIN, for the purpose of explicitly
repeating that it is not supported.   Subsequent text also refers to
the table as if all the RCODEs are permitted.   This needs to be
fixed.   I would take NXDOMAIN out of the table and just be really
explicit about how it's not allowed.   6.5.2 has the same issue, with
the same cure.

Also in 6.2.2:

      For RCODE = 2 (SERVFAIL) the delay should be chosen according to
      the level of server overload and the anticipated duration of that
      overload.  By default, a value of one minute is RECOMMENDED.  If a
      more serious server failure occurs, the delay may be longer in
      accordance with the specific problem encountered.

In this case ideally there is more than one server, and the client can try
the next one in the list, rather than repeatedly connecting to the same
overloaded server.   Or are we assuming the client will look the server up
again, and that round-robining will take care of this?

Also in 6.2.2:

      This is a misconfiguration, since this server is listed in a
      "_dns-push-tls._tcp.<zone>" SRV record, but the server itself is
      not currently configured to support DNS Push Notifications for
      that zone.  Since it is possible that the misconfiguration may be
      repaired at any time, the retry delay should not be set too high.
      By default, a value of 5 minutes is RECOMMENDED.

Probably ought to say this:

      If the server being queried is not the local resolver, rhis is a

      misconfiguration, since this server is listed in a
      "_dns-push-tls._tcp.<zone>" SRV record, but the server itself is
      not currently configured to support DNS Push Notifications for
      that zone.  Since it is possible that the misconfiguration may be
      repaired at any time, the retry delay should not be set too high.
      By default, a value of 5 minutes is RECOMMENDED.

At the end of 6.3.1:

   The TTL of an added record is stored by the client and decremented as
   time passes, with the caveat that for as long as a relevant
   subscription is active, the TTL does not decrement below 1 second.
   For as long as a relevant subscription remains active, the client
   SHOULD assume that when a record goes away the server will notify it
   of that fact.  Consequently, a client does not have to poll to verify
   that the record is still there.  Once a subscription is cancelled
   (individually, or as a result of the DSO session being closed) record
   aging resumes and records are removed from the local cache when their

   TTL reaches zero.

There's a slight problem with this: if the caching resolver is doing these
queries on behalf of a client, then it shouldn't be decrementing the TTL.
 Also, if we haven't received an update from the server saying that the TTL
has a new value, then the TTL doesn't have a new value—it's still whatever
the server sent last time.   So it would actually be correct to never
decrement the TTL while a subscription is active.   So I would suggest:

   The TTL of an added record is stored by the client.   While the subscription

   is active, the TTL is not decremented, because a change to the TTL would

   produce a new update.

   For as long as a relevant subscription remains active, the client
   SHOULD assume that when a record goes away the server will notify it
   of that fact.  Consequently, a client does not have to poll to verify
   that the record is still there.  Once a subscription is cancelled
   (individually, or as a result of the DSO session being closed) record
   aging for records covered by the subscription resumes and records are

   removed from the local cache when their

   TTL reaches zero.

Section 7.4 talks about TLS session resumption and that subscriptions have
to be reinstantiated, but implies without stating explicitly that closing a
TLS session closes the DSO session.   It might be worth saying that
explicitly.   Something like:

   TLS Session Resumption is permissible on DNS Push Notification

   servers.  The server may keep TLS state with Session IDs [RFC5246
<https://tools.ietf.org/html/rfc5246>] or
   operate in stateless mode by sending a Session Ticket [RFC5077
<https://tools.ietf.org/html/rfc5077>] to
   the client for it to store.  However, closing the TLS connection

   terminates the  the DSO session.  When the TLS session is
   resumed, the DNS Push Notification server will not have any
   subscription state and will proceed as with any other new DSO
   session.  Use of TLS Session Resumption allows a new TLS connection
   to be set up more quickly, but the client will still have to recreate
   any desired subscriptions.

In section 8, you probably ought to use two tables rather than one.   Also,
I don't think you've given enough information for the service name
registration.

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 26 Oct 2018 21:15:46 -0400

Thanks for the feedback! Comments inline.

> On Oct 26, 2018, at 5:28 PM, Ted Lemon <[email-masked]> wrote:
> 
> 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,

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:
> 

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

>    Stateful Operations (DSO) [
> DSO] running over TLS over TCP [RFC7858].
> 
> But section 7 says:
> 
>    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.

> Is there any reason to say this?

No. Probably better to remove it.

> ]) the server SHOULD NOT issue
> 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Oct 2018 21:45:19 -0400

Thanks!  All good so far!  :)

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

> 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
> (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:
> >
> 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.
> >
> 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:
> >
> 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:
> >
> > 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.
>

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Mon, 29 Oct 2018 14:34:51 +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.

Thanks,

Jan.

On 10/26/18, 9:15 PM, "Tom Pusateri" <[email-masked]> wrote:

    

    

    

    
    
    I agree.

    Thanks!
    
    Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 29 Oct 2018 10:42:51 -0400

Yes, be glad to add this. 

Thanks!

Tom

> On Oct 29, 2018, at 10:34 AM, Jan Komissar (jkomissa) <[email-masked]> wrote:
> 
> Hi Tom,
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 29 Oct 2018 16:45:19 -0400

Continuing on… Comments inline.

>    TLS [RFC7858].
> This is inconsistent with the earlier assertion that the server we are talking to is an authoritative server.   How do we know what zone, if any, the default resolver is authoritative for?   What if it can support some push notifications we want, but for others we need to talk to the authoritative server?   What about TLS?
> 
> I think this text was added based on a comment I made a while back; I think that the behavior defined here may be okay, but there should be some additional text:
> 
>    connections to more than one DNS Push server..
> 
>    In some cases,
>    TLS [RFC7858].

Looks good. Adopted.

> That SHOULD is updating RFC1035, I think, although I realize that there's text later claiming it doesn't.   How about "would normally"?   Given that we specify how clients handle the exceptional case, there's no reason to get fussy about this here.   BTW, we really ought to have a document that describes this stuff, so that we can reference it.   It's a fairly common operation.

changed to “would normally”.

> 
> At the bottom of Page 16 (the end of section 6.2.1) it might be good to add some text acknowledging the recent deprecation of ANY queries, and explicitly saying why they are not deprecated here.   This avoids the risk of DNSOP experts tripping on this, although they will probably see the utility.

This is the only thing I didn’t change yet. Looking at https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-07 doesn’t exactly say it’s deprecated and our wording seems consistent with the options given. I don’t understand how this could trip up DNSOP experts.

> The table in 6.2.2 is introduced by saying "Supported RCODEs are as follows:" but then lists NXDOMAIN, for the purpose of explicitly repeating that it is not supported.   Subsequent text also refers to the table as if all the RCODEs are permitted.   This needs to be fixed.   I would take NXDOMAIN out of the table and just be really explicit about how it's not allowed.   6.5.2 has the same issue, with the same cure.

Fixed.

> 
> Also in 6.2.2:
> 
> For RCODE = 2 (SERVFAIL) the delay should be chosen according to the level of server overload and the anticipated duration of that overload. By default, a value of one minute is RECOMMENDED. If a more serious server failure occurs, the delay may be longer in accordance with the specific problem encountered.
> 
> In this case ideally there is more than one server, and the client can try the next one in the list, rather than repeatedly connecting to the same overloaded server.   Or are we assuming the client will look the server up again, and that round-robining will take care of this?

Clarified.

>       By default, a value of 5 minutes is RECOMMENDED.

Adopted.

> There's a slight problem with this: if the caching resolver is doing these queries on behalf of a client, then it shouldn't be decrementing the TTL.   Also, if we haven't received an update from the server saying that the TTL has a new value, then the TTL doesn't have a new value—it's still whatever the server sent last time.   So it would actually be correct to never decrement the TTL while a subscription is active.   So I would suggest:
> 

Sounds good.

> 
> Section 7.4 talks about TLS session resumption and that subscriptions have to be reinstantiated, but implies without stating explicitly that closing a TLS session closes the DSO session.   It might be worth saying that explicitly.   Something like:
> 
> ] or
> ] to

Done.

> 
> In section 8, you probably ought to use two tables rather than one.   Also, I don't think you've given enough information for the service name registration.

Split the table and added a “none" port for clarity.

Thanks again!

Tom

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Oct 2018 16:54:51 -0400

Awesome, thanks! :)

I think it's fine if we just wait to see what DNSOP says about ANY.

On Mon, Oct 29, 2018 at 4:45 PM Tom Pusateri <[email-masked]> wrote:

> > I think this text was added based on a comment I made a while back; I
> think that the behavior defined here may be okay, but there should be some
> additional text:
> >
> > That SHOULD is updating RFC1035, I think, although I realize that
> there's text later claiming it doesn't.   How about "would normally"?
>  Given that we specify how clients handle the exceptional case, there's no
> reason to get fussy about this here.   BTW, we really ought to have a
> document that describes this stuff, so that we can reference it.   It's a
> fairly common operation.
>
> > At the bottom of Page 16 (the end of section 6.2.1) it might be good to
> add some text acknowledging the recent deprecation of ANY queries, and
> This is the only thing I didn’t change yet. Looking at
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-07 doesn’t
> exactly say it’s deprecated and our wording seems consistent with the
> options given. I don’t understand how this could trip up DNSOP experts.
>
> follows:" but then lists NXDOMAIN, for the purpose of explicitly repeating
> that it is not supported.   Subsequent text also refers to the table as if
> all the RCODEs are permitted.   This needs to be fixed.   I would take
> NXDOMAIN out of the table and just be really explicit about how it's not
> allowed.   6.5.2 has the same issue, with the same cure.
>
> Fixed.
>
> >
> > Also in 6.2.2:
> >
> > For RCODE = 2 (SERVFAIL) the delay should be chosen according to the
> level of server overload and the anticipated duration of that overload. By
> default, a value of one minute is RECOMMENDED. If a more serious server
> failure occurs, the delay may be longer in accordance with the specific
> problem encountered.
> >
> > In this case ideally there is more than one server, and the client can
> try the next one in the list, rather than repeatedly connecting to the same
> > There's a slight problem with this: if the caching resolver is doing
> these queries on behalf of a client, then it shouldn't be decrementing the
> TTL.   Also, if we haven't received an update from the server saying that
> the TTL has a new value, then the TTL doesn't have a new value—it's still
> whatever the server sent last time.   So it would actually be correct to
> never decrement the TTL while a subscription is active.   So I would
> suggest:
> >
> > Section 7.4 talks about TLS session resumption and that subscriptions
> have to be reinstantiated, but implies without stating explicitly that
> closing a TLS session closes the DSO session.   It might be worth saying
> that explicitly.   Something like:
> >
> > In section 8, you probably ought to use two tables rather than one.
>  Also, I don't think you've given enough information for the service name
> registration.
>
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 29 Oct 2018 20:50:10 -0400

Ok this has been added. I will publish a new version as soon as submissions open up again.

6.6.  DNS Stateful Operations TLV Context Summary

   This document defines four new DSO TLVs.  As suggested in [DSO],
   Section 8.2, the valid contexts of these new TLV types are summarized
   below.

   The client TLV contexts are:

   C-P:  Client primary bidirectional TLV
   C-U:  Client primary unidirectional TLV
   C-A:  Client additional TLV
   CRP:  Client response primary TLV
   CRA:  Client response additional TLV

               +-------------+-----+-----+-----+-----+-----+
               |     Type    | C-P | C-U | C-A | CRP | CRA |
               +-------------+-----+-----+-----+-----+-----+
               |  SUBSCRIBE  |  X  |     |     |     |     |
               |     PUSH    |     |     |     |     |     |
               | UNSUBSCRIBE |  X  |     |     |     |     |
               |  RECONFIRM  |  X  |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+

                  Table 3: DSO TLV Client Context Summary

   The server TLV contexts are:

   S-P:  Server primary bidirectional TLV
   S-U:  Server primary unidirectional TLV
   S-A:  Server additional TLV
   SRP:  Server response primary TLV
   SRA:  Server response additional TLV

               +-------------+-----+-----+-----+-----+-----+
               |     Type    | S-P | S-U | S-A | SRP | SRA |
               +-------------+-----+-----+-----+-----+-----+
               |  SUBSCRIBE  |     |     |     |     |     |
               |     PUSH    |     |  X  |     |     |     |
               | UNSUBSCRIBE |     |     |     |     |     |
               |  RECONFIRM  |     |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+

                  Table 4: DSO TLV Server Context Summary

> On Oct 29, 2018, at 10:42 AM, Tom Pusateri <[email-masked]> wrote:
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 29 Oct 2018 22:13:23 -0400

Here’s an updated version after Ted pointed out a copy and paste error with Unsubscribe.

Thanks Ted!

Tom

   C-P:  Client primary TLV

               +-------------+-----+-----+-----+-----+-----+
               |   TLV Type  | C-P | C-U | C-A | CRP | CRA |
               +-------------+-----+-----+-----+-----+-----+
               |  SUBSCRIBE  |  X  |     |     |     |     |
               |     PUSH    |     |     |     |     |     |
               | UNSUBSCRIBE |     |  X  |     |     |     |
               |  RECONFIRM  |  X  |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+

   S-P:  Server primary TLV

               +-------------+-----+-----+-----+-----+-----+
               |   TLV Type  | S-P | S-U | S-A | SRP | SRA |
               +-------------+-----+-----+-----+-----+-----+
               |  SUBSCRIBE  |     |     |     |     |     |
               |     PUSH    |     |  X  |     |     |     |
               | UNSUBSCRIBE |     |     |     |     |     |
               |  RECONFIRM  |     |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+

> On Oct 29, 2018, at 8:50 PM, Tom Pusateri <[email-masked]> wrote:
>