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

Mirja Kühlewind via Datatracker <noreply@ietf.org> Mon, 05 August 2019 14:55 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnssd@ietf.org
Delivered-To: dnssd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF913120230; Mon, 5 Aug 2019 07:55:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dnssd-push@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnssd-chairs@ietf.org, tjw.ietf@gmail.com, dnssd@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Message-ID: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com>
Date: Mon, 05 Aug 2019 07:55:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/xHdxU57vEtebJEH6gzx6jEvlePI>
Subject: [dnssd] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dnssd-push-23=3A_=28with_COMMENT=29?=
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2019 14:55:21 -0000

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:


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

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]