[Reflections of the week-end.]

There have been some discussions
(<http://www.ietf.org/mail-archive/web/dnsop/current/msg13170.html> or
<http://www.ietf.org/mail-archive/web/dnsop/current/msg13203.html>) in
juanary on draft-ietf-dnsop-edns-tcp-keepalive and
draft-bellis-dnsop-connection-close. I've seen no discussion of their
interaction with draft-ietf-dnsop-5966bis. Basically, both
draft-ietf-dnsop-edns-tcp-keepalive and
draft-bellis-dnsop-connection-close try to improve signalling between
the DNS client and the server, while draft-ietf-dnsop-5966bis say that
clients and servers can do what they want with connections and the
other party should be ready to deal with it.

Since we always have to manage broken software and network glitches,
DNS programs will have to handle bad clients and servers, anyway. If
so, what is the point of having a better signalling? Is it worth the
cost (in implementation, and WG time)? Shouldn't we focus only on
5966bis and drop the two others?

Otherwise, three typos in
draft-ietf-dnsop-edns-tcp-keepalive-01:

* "truncacated" instead of truncated

* "that that specific TCP session" (too many thats)

* "indefinately" instead of indefinitely

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

Reply via email to