[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-session-signal-19: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-session-signal-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for address my discuss!

------------------------
These are old comments for the record:

1) sec 3: I really find it a bit strange that there is normative language about
error handling (as well as in the "same service instance" definition part) in
the terminology section. Maybe move those paragraphs somewhere else...? Also
the part about "long-lived operations" and messages types provides far more
information than just terminology and I would recommend to also move it into an
own section or maybe just have it as part of the intro.

2) Maybe call section 5 "Protocol specification" instead of "Protocol
details"...?

3) Sec 5.1: "DSO messages MUST be carried in only protocols and in environments
   where a session may be established according to the definition given
   above in the Terminology section (Section 3)."
I don't get this. Which part of section 3? Given section 3 is on terminology
and this is a normative statement, I would recommend to spell out here
explicitly what is meant. Do you mean the protocol must be connection-oriented,
reliable, and providing in-order delivery? Any thing else? However, given that
you say two paragraphs onwards that this spec is only applicable for the use
with TCP and TLS/TCP, do you even need to specify these requirements
normatively?

4) sec 5.1 "It is a common
   convention that protocols specified to run over TLS are given IANA
   service type names ending in "-tls"."
Not sure this is true. Isn't it usually just an "s" at the end? Or with
registry are you talking about?

5) sec 5.1: "In some environments it may be known in advance by external means
   that both client and server support DSO, ..."
I guess the client and server also need to know if TLS is supported or not.
Maybe spell this out as well.

6) sec 5.1: "... therefore either
   client or server may be the initiator of a message."
Maybe s/initiator of a message/initiator of a message exchange/

7) sec 5.1.2: "Having initiated a connection to a server, possibly using zero
round-
   trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send
   multiple response-requiring DSO request messages to the server in
   succession without having to wait for a response to the first request
   message to confirm successful establishment of a DSO session."
Why is the ability to send more than one request related to TCP Fast
Open/TLS1.3 0-RTT? These are two independent mechanisms to speed up processing.
Mentioning TCP Fast Open/TLS1.3 0-RTT here is rather confusing. Respectively I
also don't think that the sentence: "Similarly, DSO supports zero round-trip
operation." is describing quite the same.

8) Further please provide references to TCP Fast Open and TLS1.3 and maybe
rephrase this paragraph to use normative language: "Caution must be taken to
ensure that DSO messages sent before the
   first round-trip is completed are idempotent, or are otherwise immune
   to any problems that could be result from the inadvertent replay that
   can occur with zero round-trip operation."
Maybe just:
"DSO messages sent with TLS1.3 0-RTT before the TLS handshake is completed or
in TCP SYN data with use of TCP Fast Open MUST be idempotent." However, this is
actually already required by TLS1.3 and TFO, so there is after all no need to
just rephrase this requirement here (at least not normatively). I think it
would be more useful for every DSO message type to specify if it can be sent in
0-RTT or not and require this for specification of future TLVs.

9) sec 5.1.3: "In cases where a DSO session is terminated on one side of a
   middlebox, and then some session is opened on the other side of the
   middlebox in order to satisfy requests sent over the first DSO
   session, any such session MUST be treated as a separate session."
This sentence seems a bit non-sensical, which probably isn't great for a
normative sentence. If a session is terminated and open of the other end,
doesn't that mean that you have two sessions?

10) sec 5.1.3: "A middlebox that is not doing a strict pass-through will have
no way to
   know on which connection to forward a DSO message, and therefore will
   not be able to behave incorrectly."
I'm not sure I understand this sentence. Can you clarify?

11) As already briefly mentioned by Ben, there is quite some redundant text in
sec 5 (with 5.2) for handling of message IDs and TLVs. Given this text is
normative, I would really recommend to only specify it clearly once. Please
also check the rest of the doc further things that are specified normatively
multiple times. It usually makes it must clearer to specify it only once, at
least normatively, at the appropriate position in the doc.

12) sec 5.3.1: "When a DSO unacknowledged message is unsuccessful for some
reason, .." What does unsuccessful mean here? Can you clarify?

13) sec 6.5.2: "A corporate DNS server that knows it is serving only clients on
the
   internal network, with no intervening NAT gateways or firewalls, can
   impose a higher keepalive interval, because frequent keepalive
   traffic is not required."
I guess in this scenario it is probably most appropriate to not send any
keep-alives…

14) sec 6.6: "   o  The server application software terminates unexpectedly
(perhaps
      due to a bug that makes it crash)."
This bullet point does not really make sense to me because at that time when
the app is crashed there is no way for the server anymore to perform any
actions.

15) sec 7.1: "When a client is sending its second and subsequent Keepalive DSO
   requests to the server, the client SHOULD continue to request its
   preferred values each time. "
I don't understand the SHOULD here.. what else should be client put in these
field instead...?

16) sec 7.1.2: "Once a DSO Session has been established, if either
   client or server receives a DNS message over the DSO Session that
   contains an EDNS(0) TCP Keepalive option, this is a fatal error and
   the receiver of the EDNS(0) TCP Keepalive option MUST forcibly abort
   the connection immediately."
This is normatively specified multiple time (3?) in the doc. Please consider to
only specify it once where most appropriate (probably section 7.1.2)

16) sec 7.1: "The Keepalive TLV is not used as an Additional TLV."
This is redundant with the normative sentence in the next paragraph. Maybe just
remove this sentence...?

17) +1 to Ben's discuss regarding the reconnection of clients. A TCP RST can be
sent for many reasons and waiting for an hour seems not appropriate. I would
rather recommend to log an error and directly try to reconnect.