[DNSOP] AD review of draft-ietf-dnsop-session-signal

[Warren Kumari <[e-mail]>]

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