Subject: [DNSOP] draft-ietf-dnsop-session-signal: session establishment

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 27 Jan 2018 18:16:09 -0800

Greetings. The -05 draft still has a complexity that I can can be easily 
fixed. In a few places, it says that a session can be established by the 
client sending a response-requiring DSO request message. For example, 
from section 4.1:
    A DSO Session is established over a connection by the client sending
    a DSO request message of a kind that requires a response, such as 
the
    DSO Keepalive TLV (see Section 6.1), and receiving a response, with
    matching MESSAGE ID, and RCODE set to NOERROR (0), indicating that
    the DSO request was successful.

This logic requires a client to survey all the kinds of requests it 
knows to find one appropriate for establishing the session. It also 
requires the server to have to check the first message for any kind of 
response-requiring request message.

Why not just say that the session MUST be established by the client 
sending a Keepalive message? That message must be understood by all 
parties, and both the values in it have defaults listed in the draft. A 
client who has not real preference for the inactivity timeout or 
keepalive interval can just use the defaults; a client with a stronger 
opinion can start the session with what it wants.

This change would simplify the draft in a bunch of places by making the 
protocol more definitive.

--Paul Hoffman

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 29 Jan 2018 11:38:15 -0800

On 27 Jan 2018, at 18:16, Paul Hoffman <[email-masked]> wrote:

> Greetings. The -05 draft still has a complexity that I can can be easily fixed. In a few places, it says that a session can be established by the client sending a response-requiring DSO request message. For example, from section 4.1:
>   a DSO request message of a kind that requires a response, such as the
> This logic requires a client to survey all the kinds of requests it knows to find one appropriate for establishing the session. It also requires the server to have to check the first message for any kind of response-requiring request message.

The intent was not that client software would make a run-time decision about how to initiate a DSO session.

The intent was that a client *implementer* would make a design-time decision about how to initiate a DSO session. And, of course, “I’ll send a Keepalive request,” is a perfectly good design-time answer to that question.

On the server side, the routine that generates and/or sends DSO response messages just needs to set a Boolean flag saying, “no-error response sent” (or, equivalently, “DSO session established”) when it sends a no-error DSO response.

For implementations of only the base DSO spec (not extensions that build on DSO), the only response-requiring DSO request message is Keepalive, so it degenerates to the simple scenario you proposed -- a DSO session MUST be established by the client sending a Keepalive message.

The reason we left the flexibility in the specification was to avoid putting unnecessary constraints on future uses of DSO that we haven’t anticipated yet.

Stuart Cheshire