Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

From: Tim WIcinski <[email-masked]>
Date: Mon, 5 Oct 2015 16:08:26 -0400

This starts a Working Group Last Call  
for draft-ietf-dnsop-edns-tcp-keepalive

Current versions of the draft is available here:

_https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/_

The chairs feel the authors have spent considerable time addressing 
questions and issues raised, and the current document has undergone some 
solid revision.  We would appreciate if the working group could review 
the draft and offer relevant comments. Also, if someone feels the 
document is *not* ready for publication, please speak out with your reasons.

This starts a two week Working Group Last Call process, and ends on 
  2015-10-19 at 21:00 UTC

thanks
tim

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Oct 2015 10:17:51 -0700

On Mon, Oct 5, 2015 at 1:08 PM, Tim WIcinski <[email-masked]> wrote:

> This starts a Working Group Last Call  for
> draft-ietf-dnsop-edns-tcp-keepalive

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/
>
> solid revision.  We would appreciate if the working group could review the
> draft and offer relevant comments. Also, if someone feels the document is
> *not* ready for publication, please speak out with your reasons.

I've read the 03 version of draft.  It's very well written and I've
not found any critical technical issues.  So I basically think it's
ready to ship.

I have a couple of minor comments, which the authors might want to
address/discuss before advancing the draft:

1. Section 3.2.1

   DNS clients MAY include the edns-tcp-keepalive option in the first
   query sent to a server using TCP transport to signal their desire to
   keep the connection open when idle.

  I wonder whether we want to explicitly say something about including
  the edns-tcp-keepalive option in subsequent queries on the same TCP
  connection.  Although such behavior isn't explicitly prohibited, the
  following part of Section 3.4 seems to rather expect such subsequent
  inclusion more commonly:

   Since servers must be faithful to this specification even on a
   persistent TCP connection it means that (following the initial
   exchange of timeouts) a server may not be presented with the
   opportunity to signal a change in the idle timeout associated with a
   connection if the client does not send any further requests
   containing EDNS0 OPT RRs.

  So it may be better to explicitly say, e.g., that clients MAY
  include the option in subsequent queries.  We might even want to use
  a stronger requirement like "the client SHOULD occasionally include
  the option in subsequent queries if it includes the option in the
  first query".

2. Section 3.2.2

   A DNS client that receives a response that includes the edns-tcp-
   keepalive option with a TIMEOUT value of 0 should send no more
   queries on that connection and initiate closing the connection as
   soon as it has received all outstanding responses.

  I wonder whether this 'should' may better be 'SHOULD'.  I personally
  don't have a strong opinion, but it seemed to be more consistent
  with other use of the RFC2119 keywords in this document.

And, one minor editorial nit: In Section 5

   [...]  When a Nameserver
   detects abusive behaviour, it SHOULD immediately close the TCP
   connection and free the resources used.

  Perhaps s/Nameserver/nameserver/?  Or, it might even be "DNS server"
  ('[Nn]ameserver' or 'name server' doesn't seem to be used anywhere
  else in the document).

--
JINMEI, Tatuya

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 14 Oct 2015 11:55:02 +0100

> On 7 Oct 2015, at 18:17, 神明達哉 <[email-masked]> wrote:
> 
> 

Hi,

Many thanks for the review.

>  connection.  
>  include the option in subsequent queries

Yes, this will definately improve the document. The following has been added to Section 3.2.1:

+   DNS clients MAY include the edns-tcp-keepalive option in subsequent
+   queries sent to a server using TCP transport to signal their
+   continued desire to keep the connection open when idle.

>  We might even want to use
>  first query”.

I’m not sure how prescriptive the document should be on this...

Would adding the following paragraph to Section 3.4 on TCP session management address you concerns?

    attractive than a mechanism that establishes default persistence and
    then uses a connection close signal (in a similar manner to HTTP 1.1
    [RFC7320]).
 
+   Clients might choose to send the edns-tcp-keepalive option regularly
+   during a TCP session to increase the chance of being notified should
+   the server modify the timeout associated with a session.  The
+   algorithm for choosing when to do this is out of scope of this
+   document and is left up to the implementor and/or operator.

>  I wonder whether this 'should' may better be 'SHOULD’.  

Good catch, this is now a SHOULD. 

>  ('[Nn]ameserver' or 'name server' doesn't seem to be used anywhere

This is now 'DNS server’ which is consistent with the rest of the document. 

Regards

Sara.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 14 Oct 2015 18:29:01 -0700

At Wed, 14 Oct 2015 11:55:02 +0100,

> +   continued desire to keep the connection open when idle.

I have no objection to this text per se, but the described reason why
the client might want to do this is different from what I intended.  I
was more concerned about the case where the client only includes the
option in the first query and the server can't send updated
notification.  And, in that sense,

> Would adding the following paragraph to Section 3.4 on TCP session management address you concerns?
[...]
> +   document and is left up to the implementor and/or operator.

while the text looks good to me, I thought it would be safer to use
some RFC2119 keyword here.  Combining these, what I would have
proposed is something like this:

   DNS clients MAY include the edns-tcp-keepalive option in the first
   query sent to a server using TCP transport to signal their desire
   to keep the connection open when idle.  If a client include the
   option in the first query, it SHOULD include the option regularly
   during a TCP session to increase the chance of being notified
   should the server modify the timeout associated with a session.
   The algorithm for specifically when to include the option in
   subsequent queries is out of scope of this document and is left up
   to the implementor and/or operator.

--
JINMEI, Tatuya

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 15 Oct 2015 16:32:40 +0100

> On 15 Oct 2015, at 02:29, 神明達哉 <[email-masked] <mailto:[email-masked]>> wrote:
> 

My hesitation here is that if it is a SHOULD, then I think the document would need a bit more detail regarding what ‘regularly’ means, rather than simply saying the precise behaviour is out of scope. I like to think that when something is specified as a SHOULD then it should be relatively easy to determine if an implementation is compliant with that requirement, and without specifying more detail here I don’t think that would be easy. Do you have any thoughts on that?  IIRC there were some discussions among the authors about this prior to the -02 version and we deliberately left this out because how to time these subsequent signals isn’t obvious. However maybe this isn’t really necessary and the above text is acceptable. 

A couple of details to consider:

1) If the client is regularly sending messages with an EDNS0 OPT RR, then the server can respond to these by adding the edns-tcp-keepalive option and there is no need for the client to specifically send the edns-tcp-keepalive option in the query.  See Section 3.3.2:

  A DNS server that receives a query sent using TCP transport that
  includes an OPT RR MAY include the edns-tcp-keepalive option in the
  response to signal the expected idle timeout on a connection.

2) Also, it is perfectly possible that a client opens a connection, sends a single message but does not have any further queries for that server before the timeout expires. I don’t think there is any desire to have clients send ‘fake’ heartbeat-like messages to check on the timeout during the idle period, so I think it would be useful to clarify that. 

The best wording I can come up with to try to cover this is:

If a client includes the edns-tcp-keepalive option in the first query, it SHOULD include an EDNS0 OPT RR periodically
in any further messages it sends during the TCP session. 
This will increase the chance of the client being notified should the server modify the timeout associated with a session.

Regards

Sara.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 15 Oct 2015 10:00:42 -0700

At Thu, 15 Oct 2015 16:32:40 +0100,
Sara Dickinson <[email-masked]> wrote:

> My hesitation here is that if it is a SHOULD, then I think the
> document would need a bit more detail regarding what ‘regularly’
> means, rather than simply saying the precise behaviour is out of
> scope. I like to think that when something is specified as a SHOULD
> then it should be relatively easy to determine if an implementation
> is compliant with that requirement, and without specifying more
> detail here I don’t think that would be easy. Do you have any
> thoughts on that?  IIRC there were some discussions among the
> authors about this prior to the -02 version and we deliberately left
> this out because how to time these subsequent signals isn’t
> obvious. However maybe this isn’t really necessary and the above
> text is acceptable.

I see your point.  But whether the updated notification from the
server works relies on whether the client includes an OPT RR in
subsequent queries, ambiguity on the latter can easily lead to
interoperability problem.  So I thought this should be at least
clearly documented and RFC2119 keywords are helpful exactly in such a
situation.  I personally do not think a SHOULD inevitably requires
more specific text about the frequency, although I see some others may
have a different opinion.

That said, I just realized I misunderstood one related part...

> 1) If the client is regularly sending messages with an EDNS0 OPT RR,
> then the server can respond to these by adding the
> edns-tcp-keepalive option and there is no need for the client to
> specifically send the edns-tcp-keepalive option in the query.

...I incorrectly thought the client needs to keep including the
edns-tcp-keepalive option.  I'm not sure if we can reasonably assume
clients generally include an EDNS OPT RR even if they have no other
particular reason to do so than the issue we're discussing here.  If
we can assume that, the text can be loosened.  But we probably cannot
rely on the current implementation behavior on this topic, so I think
it's safer to at least mention it explicitly in some way.

> This will increase the chance of the client being notified should the server modify the timeout associated with a session.

I'm fine with this.  Also, if the use of 'SHOULD' really triggers
controversy on whether to be more specific about "periodically", I'm
fine with avoiding an RFC2119 keyword, too.

--
JINMEI, Tatuya

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 16 Oct 2015 14:13:37 +0100

> On 15 Oct 2015, at 18:00, 神明達哉 <[email-masked]> wrote:
> 
> situation.

That’s reasonable and so I do think extra text helps here. 

> particular reason to do so than the issue we're discussing here.  
> If we can assume that, the text can be loosened.  But we probably cannot

I certainly agree that the EDNS0 spec is full of subtleties :-)

> fine with avoiding an RFC2119 keyword, too.

Fair enough - I’ll add the above text to the document and the wording can be downgraded if necessary!

Thanks for all the feedback.

Sara.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 27 Oct 2015 03:39:14 -0400

Hi

The WGLC ended on this, and there was strong consensus to move this 
document forward.  Thanks to all the folks who gave very constructive 
comments, and thanks to the authors for addressing all the issues raised 
during the process.  I'll be submitting this shortly.

tim

On 10/5/15 4:08 PM, Tim WIcinski wrote:
> __
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/>_https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/_
>