I made all of these suggested changes on github except for the Section 3 “same server instance” pandora’s box.
The authors can discuss how they want to change this one or leave it for later. If I don’t hear anything in a day or two, I’ll push out another version. Thanks, Tom > On Jun 2, 2018, at 11:08 AM, Warren Kumari <[email protected]> wrote: > > 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 > <http://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 > > <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
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
