Re: [DNSOP] I-D Action: draft-bellis-dnsop-session-signal-01.txt

["Jan Komissar (jkomissa)" <[e-mail]>]

Hi,

Here's my comments to version 1 of this draft.

3.1 Message Format

I'm a little hesitant about going to the 4-octet header. Are we certain
that most existing DNS servers will respond with NOTIMP rather than
FORMERR upon receipt of a ses-sig message? Some servers may not even
respond to packets smaller than 12 octets (DNS header size). I would
prefer using the full DNS header, even if it wastes 8 octets.

I do like the simplification of only allowing one TLV per message.

3.2 Message Handling

I'm still uncertain about ses-sig messages being "sequencing points" (see
my comments to version 00 of this draft). In addition, where do server
initiated messages, such as DNS Push Notification updates, fit into this?

4.2.1 Start Session

I like using the Start Session TLV as a no-op/I'm still here message.

4.2.2 Terminate Session

The current DNS Push Notification draft specifies different Reconnect
Delays in different cases. Maybe there should be suggestions for multiple
delay values, depending on the kinds of reasons for termination (server
shutdown, server restart, different kinds of client errors). Out maybe
just mentioning that as a valid option.

4.2.3. Idle Timeout

I'm not sure of the usefulness of querying for the timeout value, the
client should already have received it if one applies. However, I see no
harm in that feature.

5. IANA Considerations

Nits: Should it be "IANA is directed.."?

Regards,

Jan Komissar



On 7/21/16, 12:48 PM, "DNSOP on behalf of [e-mail]"
<[e-mail] on behalf of [e-mail]> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Domain Name System Operations of the
>IETF.
>
>        Title           : DNS Session Signaling
>        Authors         : Ray Bellis
>                          Stuart Cheshire
>                          John Dickinson
>                          Sara Dickinson
>                          Allison Mankin
>                          Tom Pusateri
>	Filename        : draft-bellis-dnsop-session-signal-01.txt
>	Pages           : 11
>	Date            : 2016-07-21
>
>Abstract:
>   The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly
>   defined to only have "per-message" semantics.  This document defines
>   a new Session Signaling OpCode used to carry persistent "per-session"
>   type-length-values (TLVs), and defines an initial set of TLVs used to
>   manage session timeouts and termination.