Hiya, On 06/01/16 21:49, sara wrote: > >> On 6 Jan 2016, at 20:57, Stephen Farrell >> <[email protected]> wrote: >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-dnsop-edns-tcp-keepalive-05: Discuss >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> Before I ballot yes on this I have a question to ask. >> Most likely the answer will be the obvious one and we'll be done, >> but I want to check and if the answer is not the obvious one then >> holding the discuss as we fix stuff would be correct I think. >> >> The question: how does this option play with DNS over DTLS? [1] >> >> The reason I ask is that there may be a need in that case for some >> similar option (or a TLS extension maybe) though for the DTLS >> session lifetime and not a TCP session lifetime. At present you are >> saying that this option is not it. And that's a fine answer but you >> could also have said that this could also be used for DTLS session >> lifetime handling. And that last might make sense for operational >> reasons (not sure really, but could be). >> >> [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 >> <https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03> > > Speaking for myself I don’t see this as the solution to managing DTLS > sessions, I think that would be better handled with a TLS extension.
Yes, that's the obvious answer, and a not bad answer. Did the dnsop WG (or dprive) consider the issue already? If yes, then I'll just clear and we're done. If not, I'm fine with being guided by the chairs and AD since linking these would be a bit odd (even if possibly useful), so will clear when one of 'em tells me. > > >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - intro: "However, TCP transport as currently deployed has >> expensive setup overhead." That seems a bit wrong as the 3-way h/s >> is an inherent part of TCP and isn't really specific to DNS with >> TCP trasnport not is it a deployment issue. I'd suggest just delete >> the sentence and merge the remaining part of tha para with the >> next. > > I think the implication here is “expensive setup overhead compared to > using UDP for DNS”, with the following paragraph going into the > details of that comparison. I would like to keep the sentence, but > suggest adding that proviso at the end to make it clearer. That's fine. > >> >> - 3.3.2: Oops:-) Typo there sorry, the one that puzzled me is at the end of 3.2.2 where it says " This holds true even if a previous edns-keepalive-option exchange occurred on the existing TCP connection." Sorry again:-) Cheers, S >> What's the last sentence of this section about? A case >> where a TCP session is handed over? Might be no harm saying why >> (via a reference to anything would be fine) > > Last sentence in 3.3.2 is: “The DNS server SHOULD send a > edns-tcp-keepalive option with a timeout of 0 if it deems its local > resources are too low to service more TCP keepalive sessions, or if > it wants clients to close currently open connections.” > > There is more discussion in section 3.4 including: > > “Based on TCP session resources servers may signal a TIMEOUT value > of 0 to request clients to close connections as soon as possible. > This is useful when server resources become very low or a denial-of- > service attack is detected and further maximises the shifting of > TIME_WAIT state to well-behaved clients.” > > So would it help to add “as discussed in the next section” to the end > of section 3.3.2? > > Regards > > Sara. > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
