On 5 Mar 2018, at 14:56, Paul Hoffman <paul.hoff...@vpnc.org> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
