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

[Stuart Cheshire <[e-mail]>]

On 27 Jan 2018, at 18:16, Paul Hoffman <[e-mail]> 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 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.

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