Comments on draft-ietf-dnsop-session-signal-00 (Finally reading a document before all deadlines pass. See, Tim, I can be good.)
Overall, defining session layer semantics in the DNS is something significant. In my estimation, one of the DNS architecture's weakest points is the management of the transport layer (resulting in the ANY/DDoS fiascos), as much as the abuse seen is abuse of the transport, the DNS contributes via relying blindly on the transports. So, addressing this by applying a session layer is a promising step. Initially reading the document I was a little confused, and perhaps the document can address this. From what I know of sessions, they can exist independent of transport connections. So this line in section 3.1 threw me a bit: "A session begins when a client makes a new connection to a server." The phrase "a new connection" could mean, "a connection" or "a connection after some time passes (if the two have connected at all before)." A "new connection" - perhaps "establishes a connection"? And mentioning when a session ends would be helpful. I assume, after reading the document, that when a connection is closed, the session ends. (Is that so?) In that case all session management is discarded. The implication includes - if the server sheds load, the clients no longer are in sessions with the server (thus the timeout parameter diddling is lost too, if it was diddled). To help clarify, whether a session can cover multiple transport connections - in parallel or sequentially in time - should be addressed. (I'd hoped that the session could also manage UDP too. If not be managed over UDP, but include UDP transports within the session.) There is a sentence I can't figure out in section 3's beginning. ## Where a middle box (e.g. a DNS proxy, ## forwarder, or session multiplexer) is in the path the message MUST ## NOT be blindly forwarded in either direction by that middle box. I don't get that at all. I'm not sure what is meant by "blindly forwarded." And as a final request for clarification, the terms client and server are defined to be "in the usual DNS sense". (Joking, what's usual about DNS?) In the sense an authoritative server (for queries) can act like an AXFR client for zone updates, does client and server refer to the individual mechanisms and not the process. (What if a primary server uses TCP to ask questions of a secondary while also answering AXFR requests? As I say, what's "usual.")
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
