On Mon, Oct 5, 2015 at 1:08 PM, Tim WIcinski <tjw.i...@gmail.com> wrote:

> 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.

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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to