Hi there, Thank you for writing this document, I found it clear and well written.
I do have a few comments that I’d like addressed before I start IETF LC — addressing these now will avoid issues later in the process. The majority of these are nits, but one is more of a (very easily addressed) substantive / editorial / process issue. Firstly the "substantive" issue: Throughout the document you say things like: "This document defines a new DNS OPCODE, DSO (tentatively 6),..." Can you please go through and change this to something like ([TBA1], tentatively 6)? I realize that that isn't quite as readable for "normal" reading, but this is sufficiently close to the end of the process that the IANA will read it soon and I don't want any occurrences to be missed. An exmaple of where this could have been an issue is in the table on page 16. If some number other than 11 were assigned for DSOTYPENI it might not get caught here. Sorry for the process wonkery. Nits / questions: Section 3. Terminology 1: "The term has no relationship to the "session layer" of the OSI "seven-layer model" popularized in the 1980s." -- I don't really get the purpose of the phrase "popularized in the 1980s." - it feels like it breaks the flow and feels like it will simply distract people into side arguments about if it was the 80's or 90's when this was "popularized". Note that this is truly a minor nit. Section 3. Terminology 2: "This document uses the term "same server instance" as follows: o In cases where a server is specified or configured using an IP address and TCP port number, two different configurations are referring to the same server instance if they contain the same IP address and TCP port number." Because you opened this Pandora's box -- in many Anycast deployments this isn't really true -- if you make a TCP connection to linkedin.com on port 80 (or 8.8.8.8 on 53) you are likely to hit the same "server instance" for a while, but at some point routing will change and you may hit some completely other location (and server). In many cases this will be sticky over long timeframes (a good slidedeck is the https://www.slideshare.net/shawnzandi/how-linkedin-used-tcp-anycast-to-make-the-site-faster ). Anyway, since you mention IP:PORT-> "same server instance" you might want to toss in some weasel words that the protocol does deal with this case (by falling over and reconnecting). "The term "long-lived operations" refers to operations such as Push Notification subscriptions [I-D.ietf-dnssd-push], Discovery Relay interface subscriptions [I-D.ietf-dnssd-mdns-relay], and other future long-lived DNS operations that choose to use DSO as their basis, that establish state that persists beyond the lifetime of a traditional brief request/response transaction." This sentence is somewhat hard to read - I *think* the repeated use of "that" in "... that choose to use DSO as their basis, that establish.." is part of the issue. Not sure if it can be simplified? "Section 5.1.3. Middlebox Considerations" The second paragraph of this section makes me slightly uncomfortable. I understand why it is here, but the tone of it sounds supportive of DSO-aware middleboxes being created. This might just be my personal bias (and so feel free to ignore it), but I'd think that on the whole we'd prefer that middleboxes don't monkey with DSO traffic. If they *do*, definitely there should be advice on how not to get it wrong, but the tone of this sounds more supportive / permissive than I (personally) would have expected. Section 5.2.2. DSO Data "Similarly, after an mDNS Relay client..." I think that this is the first use of mDNS - please expand the acronym. Section 5.4. DSO Response Generation "Possible mitigations for this problem include:..." This doesn't mention the mitigation of "just padding the packet until it is a full sized segment". While anti-social, it is a mitigation (trading increased bandwidth for performance). Having now finished writing these up, I realize that while I'd *prefer* a new version before starting IETF LC, I'm also fine with kicking it off with the current text and the (minor) fixes can be addressed after IETF LC / with the RFC Ed. Please let me know how you'd like to proceed. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
