Subject: [Gen-art] Gen art last call and telechat review of draft-ietf-dnsext-dns-tcp-requirements-03

From: Avshalom Houri <[email-masked]>
Date: Fri, 11 Jun 2010 15:05:52 +0300

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dnsext-dns-tcp-requirements-03
Reviewer: Avshalom Houri
Review Date: 2010-06-11
IETF LC End Date: 2010-06-11
IESG Telechat date: 2010-06-17

Summary: The document is ready as a standard track RFC. See minor issue

Major issues: None

Minor issues:

Lines 246-250
   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
   query first, but MAY elect to send a TCP query instead if it has good
   reason to expect the response would be truncated if it were sent over
   UDP (with or without EDNS0) or for other operational reasons, in
   particular if it already has an open TCP connection to the server.

What should be the behavior here? Try TCP and then revert to UDP?
What should be the timeout for the TCP trial? Seems that this
needs a bit of clarification.

Nits/editorial comments:

Line 229
      so that the do not prevent large responses from a TCP-capable
->       so that they do not prevent large responses from a TCP-capable

thanks
avshalom

---

From: Avshalom Houri <[email-masked]>
Date: Mon, 14 Jun 2010 13:56:38 +0300

I am OK with this explanation. Maybe it can be added as an explanatory 
note to the draft.

tnx
avshalom

From:   Ray Bellis <[email-masked]>
To:     Avshalom Houri/Haifa/IBM@IBMIL
Cc:     General Area Review Team <[email-masked]>, "<[email-masked]>" 
<[email-masked]>
Date:   14/06/2010 01:44 PM
Subject:        Re: Gen art last call and telechat review of 
draft-ietf-dnsext-dns-tcp-requirements-03

> What should be the behavior here?  Try TCP and then revert to UDP? What 
should be the timeout for the TCP trial? Seems that this needs a bit of 
clarification. 

I'm unsure how to address this.

Can you please clarify what sort of timeouts you're thinking of?  Do you 
mean network level issues (e.g. blocked SYN) or simply those where the far 
end is slow to respond?

In the latter case no text should be necessary (IMHO).  This document 
doesn't change the protocol processing.  This particular section merely 
permits TCP first in _some_ cases, relaxing §6.1.3.2 of RFC 1123.

> ->       so that they do not prevent large responses from a TCP-capable 

Thanks - already reported and fixed :)

kind regards,

Ray

---

From: Ray Bellis <[email-masked]>
Date: Mon, 14 Jun 2010 10:44:11 +0000

> What should be the behavior here?  Try TCP and then revert to UDP? What should be the timeout for the TCP trial? Seems that this needs a bit of clarification. 

Can you please clarify what sort of timeouts you're thinking of?  Do you mean network level issues (e.g. blocked SYN) or simply those where the far end is slow to respond?

In the latter case no text should be necessary (IMHO).  This document doesn't change the protocol processing.  This particular section merely permits TCP first in _some_ cases, relaxing §6.1.3.2 of RFC 1123.

kind regards,

Ray

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 16 Jun 2010 10:14:28 +0800

Sorry to intrude (not my doc), but what I'm reading is making me think Ray's point, that the protocol processing doesn't change except for the order of transports you attempt, is true, but if you get a truncation indication using UDP, you know *when* to attempt TCP, and when you try TCP first, you don't actually know when to give up.

Have I got that right? If so ...

TCP connections will eventually reset if the attempt to establish a connection fails, but that's measured in terms of minutes, not seconds (I'm finding 75 seconds on a couple of web pages, but I was remembering that it was more persistent than that - implementations could have changed since the last time I looked). So if the application developer thinks a shorter interval before attempting UDP is appropriate, the application can always run a timer and give up sooner.

If that's "good enough", you can probably get away with pointing this out in the document.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Avshalom Houri 
  To: Ray Bellis 
  Cc: General Area Review Team ; <[email-masked]> 
  Sent: Monday, June 14, 2010 6:56 PM
  Subject: Re: [Gen-art] Gen art last call and telechat review ofdraft-ietf-dnsext-dns-tcp-requirements-03

  I am OK with this explanation. Maybe it can be added as an explanatory  note to the draft. 

  tnx
  avshalom

  From:        Ray Bellis <[email-masked]> 
  To:        Avshalom Houri/Haifa/IBM@IBMIL 
  Cc:        General Area Review Team <[email-masked]>, "<[email-masked]>"        <[email-masked]> 
  Date:        14/06/2010 01:44 PM 
  Subject:        Re: Gen art last call and telechat review of draft-ietf-dnsext-dns-tcp-requirements-03 

------------------------------------------------------------------------------

  kind regards,

  Ray

------------------------------------------------------------------------------

  _______________________________________________
  Gen-art mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/gen-art