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

Tom Pusateri <pusateri@bangj.com> Tue, 06 August 2019 22:02 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3C12008B; Tue, 6 Aug 2019 15:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bangj.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGNKV5EtV_qg; Tue, 6 Aug 2019 15:02:11 -0700 (PDT)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C6112006E; Tue, 6 Aug 2019 15:02:11 -0700 (PDT)
Received: from [172.16.25.146] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 084AD319ED; Tue, 6 Aug 2019 18:02:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; 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 <pusateri@bangj.com>
In-Reply-To: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com>
Date: Tue, 6 Aug 2019 18:02:09 -0400
Cc: The IESG <iesg@ietf.org>, tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE742BFF-AD92-4617-A014-3005A73EA982@bangj.com>
References: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3570.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ms1XITOaOkLFKBPO4ZW78MgFV48>
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-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 06 Aug 2019 22:02:14 -0000


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

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.

Tom