Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-session-signal-00.txt

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

Hi Ray,

Here¹s some comments on this draft.

1. Introduction
Even if EDNS(0) currently has "per-message² semantics, I¹m not sure that
it would be wrong to extend it to have per-session semantics when used in
a Session Signaling message.

3.1 Message Format
I am not comfortable with a message format that is not backwards
compatible. Current packet logging code expects all DNS data to be in RR
format, even the EDNS(0) OPT RR. Keeping the Session Signaling in RR
format would make it easier to use existing logging and capturing code.
(How would tcpdump handle a DNS packet with the Session Signaling OpCode
in the current format?)

3.2 Message Handling
While it does make sense that Session Signaling requests are processed in
order, I don¹t think it necessarily makes sense for SS messages to be
³sequencing points.² Since DNS queries may take a long time, a SS message
would block the client from performing any other queries while one
outstanding query is very slow. It could be up to the client if it wants
to wait for all outstanding responses before issuing a SS request.

4.2.1 Terminate
I think the reconnect delay makes sense when you don¹t have anycast or
load-balancing, but still have multiple servers identified by multiple SRV
records. The reconnect delay would then force a client to look for another
server. It also makes sense when a server is trying to shed load and wants
to stop terminated clients from reconnecting immediately.

4.2.2 Idle Timeout

There should be a way for a client to reset the server¹s idle timeout
counter by sending a Session Keepalive message indicating that it¹s still
operational. In cases like DNS Push Notification
(draft-ietf-dnssd-push-08.txt) the client isn¹t idle because it has no
work for the server, but it is waiting for an update from the server that
may or may not come.

DNS Push Notification also specifies that a server should wait 1.5 times
the idle timeout before terminating a client to avoid race conditions
around the timeout expiration. It may be useful to adopt the same practice
here.

Regards,

Jan Komissar


On 7/6/16, 6:24 PM, "DNSOP on behalf of Ray Bellis"
<[e-mail] on behalf of [e-mail]> wrote:

>I've just submitted this draft, which resulted from discussions in
>Buenos Aires related to issues with using EDNS for persistent signalling
>(c.f. RFC 7828), and also from an overlap with draft-ietf-dnssd-push and
>its (mis-)use of the edns-tcp-keepalive option.
>
>The intention here is to split out session-related stateful options from
>the dnssd-push draft into a more generic specification.
>
>Please note that the question of whether to use an alternate message
>format for this OpCode (as it is currently specified) or whether to
>shoe-horn the options into an RR lookalike (per EDNS) is still a matter
>of some debate between the authors.  With no consensus amongst us I felt
>if important that the WG be able to weigh in on that debate.
>
>Ray
>
>-------- Forwarded Message --------
>Subject: New Version Notification for
>draft-bellis-dnsop-session-signal-00.txt
>
>A new version of I-D, draft-bellis-dnsop-session-signal-00.txt
>has been successfully submitted by Ray Bellis and posted to the
>IETF repository.
>
>Name:		draft-bellis-dnsop-session-signal
>Revision:	00
>Title:		DNS Session Signaling
>Document date:	2016-07-06
>Group:		Individual Submission
>Pages:		10
>URL:
>https://www.ietf.org/internet-drafts/draft-bellis-dnsop-session-signal-00.
>txt
>Status:
>https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/
>Htmlized:
>https://tools.ietf.org/html/draft-bellis-dnsop-session-signal-00
>
>
>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
>   handle feature negotiation and to manage session timeouts and
>   termination.
>
>_______________________________________________
>DNSOP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsop