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

Tom Pusateri <> Tue, 06 August 2019 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DB3C12008B; Tue, 6 Aug 2019 15:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WGNKV5EtV_qg; Tue, 6 Aug 2019 15:02:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03C6112006E; Tue, 6 Aug 2019 15:02:11 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 084AD319ED; Tue, 6 Aug 2019 18:02:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201907; t=1565128930; bh=NHmrVj62rB2ymWla4LnAJprTpsHMySEJPUGQyfsLX1U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=l2XzDUDA2WELjF7FFsRmaDEIXK/WVbPT0L+G4XoU7RPEYGPXSyvMSvLWtRAkHj2UF ZT86B7w2WMgMVe24mPduzBoskt+6vzmU8v+LmEbc/QDXuBDDiEJm0FFWTwp5rHwdwr VthDdl66bOor9fNWK/yHDj7ez+7c24ZREofNEuegenuF1WmW70Z6JkEbnUA9D5sNfN doFE5rn9gfcqUXteeY3BopLNyZ0z8uVz7SalOE1NSNhyMIvni4DcWmPsYBdVvIMg2j 4l+0kswoFe1TOmsjbYL/d233yyX0s6Kx2IOXzB0plF/4FJYkZmQtxsvwub/KLcbBy7 vtGmDcvI8S0iw==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3570.1\))
From: Tom Pusateri <>
In-Reply-To: <>
Date: Tue, 6 Aug 2019 18:02:09 -0400
Cc: The IESG <>,,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>
X-Mailer: Apple Mail (2.3570.1)
Archived-At: <>
Subject: Re: [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-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Aug 2019 22:02:14 -0000

> On Aug 5, 2019, at 10:55 AM, Mirja Kühlewind via Datatracker <> wrote:
> 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
> 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
> 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.

Good catch. I’ve made the second MUST NOT 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.

Thanks. Updated.

> 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?

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

> 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...?

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.

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

Stuart’s preference for short references.