[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
