Re: [DNSOP] Comments on draft-ietf-dnsop-session-signal-06

[Stuart Cheshire <[e-mail]>]

On 5 Mar 2018, at 14:56, Paul Hoffman <[e-mail]> wrote:

> This draft is much clearer about DSO unacknowledged messages, which really helps understanding the protocol. Also, thank you for switching from "octet" to "byte". :-)

Thanks for your feedback Paul.

> A few other comments:
> 
>   In this document the term "session" is used exclusively as described
>   above, and is in no way related to the anachronistic term "session"
>   as used in the obsolete "seven-layer model" that shaped the design of
>   the failed OSI protocols of the 1980s.
> 
> Judgmental language seems unneeded here.

Just a test to check if anyone was actually reading the draft :-)

It is now changed to this:

   In this document the term "session" is used exclusively as described
   above.  The term has no relationship to the "session layer" of the
   OSI "seven-layer model" popularized in the 1980s.

>   Note that for clients that implement only the DSO-TYPEs defined in
>   this base specification, sending a DSO Keepalive TLV is the only DSO
>   request message they have available to initiate a DSO Session.  Even
>   for clients that do implement other future DSO-TYPEs, for simplicity
>   they MAY elect to always send an initial DSO Keepalive request
>   message as their way of initiating a DSO Session.
> 
> It is unclear whether this is meant to place a restriction on future protocols that define new DSO-TYPEs. Assuming that it is, it might be clearer to say so explicitly.

I have updated the text as follows:

   <<Same text as above>>  A future
   definition of a new response-requiring DSO-TYPE gives implementers
   the option of using that new DSO-TYPE if they wish, but does not
   change the fact that sending a DSO Keepalive TLV remains a valid way
   of initiating a DSO Session.

> The second paragraph of Section 5.6.1 give an example that is much more detailed, and possibly conflicting with the (apparently normative) table in Section 4.2.1.
> 
>   |    9 | NOTAUTH   | Not Authoritative (TLV-dependent)              |
> 
>   An RCODE value of NOTAUTH indicates
>   that the server has been reconfigured and is no longer able to
>   perform one or more of the functions currently being performed on
>   this DSO Session because it no longer has authority over the names in
>   question.
> 
> The table entry says nothing about the server being reconfigured, nor about "no longer able" as compared to "was never able”.

You are right. This part of the document was not sufficiently thorough. I also realized it was unclear about what to do when there is more than one reason for the server wanting to end the session. I have updated the text as shown below:

6.2.1.  Retry Delay TLV used as a Primary TLV

   When sent from server to client, the Retry Delay TLV is used as the
   Primary TLV in an unacknowledged message.  It is used by a server to
   instruct a client to close the DSO Session and underlying connection,
   and not to reconnect for the indicated time interval.

   In this case it applies to the DSO Session as a whole, and the client
   MUST begin closing the DSO Session, as described in Section 5.6.1.
   The RCODE in the message header SHOULD indicate the principal reason
   for the termination:

   o  NOERROR indicates a routine shutdown or restart.

   o  FORMERR indicates that the client requests are too badly malformed
      for the session to continue.

   o  SERVFAIL indicates that the server is overloaded due to resource
      exhaustion and needs to shed load.

   o  REFUSED indicates that the server has been reconfigured, and at
      this time it is now unable to perform one or more of the long-
      lived client operations that were previously being performed on
      this DSO Session.

   o  NOTAUTH indicates that the server has been reconfigured and at
      this time it is now unable to perform one or more of the long-
      lived client operations that were previously being performed on
      this DSO Session because it does not have authority over the names
      in question (for example, a DNS Push Notification server could be
      reconfigured such that is is no longer accepting DNS Push
      Notification requests for one or more of the currently subscribed
      names).

   This document specifies only these RCODE values for Retry Delay
   message.  Servers sending Retry Delay messages SHOULD use one of
   these values.  However, future circumstances may create situations
   where other RCODE values are appropriate in Retry Delay messages, so
   clients MUST be prepared to accept Retry Delay messages with any
   RCODE value.

   In some cases, when a server sends a Retry Delay message to a client,
   there may be more than one reason for the server wanting to end the
   session.  Possibly the configuration could have been changed such
   that some long-lived client operations can no longer be continued due
   to policy (REFUSED), and other long-lived client operations can no
   longer be performed due to the server no longer being authoritative
   for those names (NOTAUTH).  In such cases the server MAY use any of
   the applicable RCODE values, or RCODE=NOERROR (routine shutdown or
   restart).

   Note that the selection of RCODE value in a Retry Delay message is
   not critical, since the RCODE value is generally used only for
   information purposes, such as writing to a log file for future human
   analysis regarding the nature of the disconnection.  Generally
   clients do not modify their behavior depending on the RCODE value.
   The RETRY DELAY in the message tells the client how long it should
   wait before attempting a new connection to this server instance.

   For clients that do in some way modify their behavior depending on
   the RCODE value, they should treat unknown RCODE values the same as
   RCODE=NOERROR (routine shutdown or restart).

   A Retry Delay message from server to client is an unacknowledged
   message; the MESSAGE ID MUST be set to zero in the outgoing message
   and the client MUST NOT send a response.

   A client MUST NOT send a Retry Delay DSO request message or DSO
   unacknowledged message to a server.  If a server receives a DNS
   request message (i.e., QR=0) where the Primary TLV is the Retry Delay
   TLV, this is a fatal error and the server MUST forcibly abort the
   connection immediately.

The updated draft is available at: <https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-07>

Stuart Cheshire