Subject: [dnssd] Mirja Kühlewind's No Objection on draft-ietf-dnssd-push-23: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 07:55:20 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnssd-push-23: 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-dnssd-push/

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

Thanks for this well-written document!

One small comment on the idle handling: The DSO idle timeout does not "apply"
as long as there is at least one active subscription. That mean the connection
can be idle for a long time if not change appears. Should this document say
something about use of keep-alives in this situation? RFC8490 specifies
keep-alives handling as well but it could be good to mention this explicitly in
this document as well. Further I was wondering if actually DSO keep-alives
should be used or if the lower layer TCP keep-alives would be more
efficient/appropriate.

Other, smaller comments:

1) Minor comment on normative language in section 3:
   "Generally, as described in the DNS Stateful Operations specification
   [RFC8490], a client must not keep a session to a server open
   indefinitely if it has no subscriptions (or other operations) active
   on that session.  A client MAY close a session as soon as it becomes
   idle, and then if needed in the future, open a new session when
   required.  Alternatively, a client MAY speculatively keep an idle
   session open for some time, subject to the constraint that it MUST
   NOT keep a session open that has been idle for more than the
   session's idle timeout (15 seconds by default) [RFC8490]."
I assume the first "must" is not normative because this is normatively
specified in RCC8490. However, if this is reason the last "MUST NOT" should
also be lower case.

2) Section 5: Tail Loss Probe (TLP) [I-D.dukkipati-tcpm-tcp-loss-probe]"
dukkipati-tcpm-tcp-loss-probe was merged into draft-ietf-tcpm-rack-05. Maybe
mention TCP RACK instead of TLP anyway.

3) Section 6.7:
   "If the session is forcibly closed at the TCP level by sending a RST
   from either end of the connection, data may be lost and TLS session
   resumption of this session will not be possible."
I would think that TLS session resumption might still be possible even if a RST
is received (as long as the TLS handshake was completed and the client received
a session ticket). Or what's the assumption here?

4) Section 6.8:
"The interval between successive DNS queries for the same name, type and
   class SHOULD be at least the minimum of: 900 seconds (15 minutes), or
   two seconds more than the TTL of the answer RRset."
Would it maybe make sense to specify also a hard limit, e.g. "MUST NOT be less
than 3 seconds (see RFC8085)", or would that maybe give a wrong impression that
3 seconds seems to be an acceptable value...?

5) One minor comment/question on the references:
And why is draft-ietf-dnssd-hybrid not cited by draft name but as [DisProx]
instead?

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Aug 2019 16:46:19 -0500

> a session ticket). Or what's the assumption here?

It's hard for me to be sure, but I note that previous versions of TLS
mandated that the session be invalidated on receipt of a TLS fatal alert,
after which other existing connections using that session could continue
but new ones would not be allowed to be established.  However, a TCP RST is
not a TLS fatal alert, so I don't think even a strict reading of RFC 5246
would imply this stated behavior, but I could see it being easy for someone
to have internalized "TLS connection error implies the session is no longer
resumable".  (Many implementations ignored this requirement, and it is
relaxed in RFC 8446 anyway.)

-Ben

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 6 Aug 2019 18:02:09 -0400

> On Aug 5, 2019, at 10:55 AM, Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> 

Good catch. I’ve made the second MUST NOT lower case.

> mention TCP RACK instead of TLP anyway.

Thanks. Updated.

> a session ticket). Or what's the assumption here?

Yeah, this was based on a misunderstanding. I will remove the resumption clause.

> 3 seconds seems to be an acceptable value...?

Since we do not know all the future use cases and therefore, TTLs of the answer RRsets, I would be hesitant to put a hard limit here. Maybe Stuart has more field experience to feel comfortable with a hard limit.

> And why is draft-ietf-dnssd-hybrid not cited by draft name but as [DisProx]

Stuart’s preference for short references.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 6 Aug 2019 18:03:00 -0400

> On Aug 6, 2019, at 5:46 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Yes, thanks for the background. This was a misunderstanding on my part and I will remove the resumption clause.

Tom