From nobody Fri Aug 2 12:53:59 2019 Return-Path: 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 7A79412014F; Fri, 2 Aug 2019 12:53:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <156477563639.21007.9900842292278023537@ietfa.amsl.com> Date: Fri, 02 Aug 2019 12:53:56 -0700 Archived-At: Subject: [dnssd] Genart telechat review of draft-ietf-dnssd-push-23 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 02 Aug 2019 19:53:57 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dnssd-push-23 Reviewer: Robert Sparks Review Date: 2019-08-02 IETF LC End Date: None IESG Telechat date: 2019-08-08 Summary: Ready for publication as a Proposed Standard RFC Thanks for addressing all of the concerns in my previous review. From nobody Mon Aug 5 03:52:51 2019 Return-Path: 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 6B957120170; Mon, 5 Aug 2019 03:52:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-dnssd-push@ietf.org, Tim Wicinski , 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: Alexey Melnikov Message-ID: <156500236936.24594.14034383808328017805.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 03:52:49 -0700 Archived-At: Subject: [dnssd] Alexey Melnikov's Yes on draft-ietf-dnssd-push-23: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 05 Aug 2019 10:52:50 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dnssd-push-23: Yes 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: ---------------------------------------------------------------------- This comment is for RFC Editor: On page 21, HTML and text version has "TTL⩾0", which gets mangled in PDF version. From nobody Mon Aug 5 07:55:22 2019 Return-Path: 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?= To: "The IESG" Cc: draft-ietf-dnssd-push@ietf.org, Tim Wicinski , 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?= Message-ID: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 07:55:20 -0700 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 nobody Tue Aug 6 05:16:28 2019 Return-Path: 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 E40A512016C; Tue, 6 Aug 2019 05:16:19 -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 jJ-E4vWq2ID8; Tue, 6 Aug 2019 05:16:18 -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 8A8A61200CE; Tue, 6 Aug 2019 05:16:18 -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 71CDA318F2; Tue, 6 Aug 2019 08:16:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1565093777; bh=H5wJnvk5xXJuBb5sPKz8negmt075WBl5AiAwMZejvPI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MqfZWCePFC13JuzrRIOsVXT8uJaPNBDccTfI2PBhyX9HiorIcq5jP+pizNGe/J90r sEm7Jt0rQYivc6qxeMmNTgq+/+gxQkV3quUpUCAB9nL6SJQKKx4TA6d0KNnqeG+y3e 1YGextWhsj9hq6Ght9GVSqn2vY/v4KTwgJ6xTEQyCuwJMlbPiKehzKjsiUt5TVoZU9 D+EChlYl0HhqpX9k+FEAlkmyekGRNsiXmbH57TLg9OM9yAALG0ZfTIjweRKRexD9Lt HWmv2K8utP/Z0+8+gJ8pEZZpruiYsV4tSQfWQO+p+WtW9oWpJDGW2L+aIbLVfgR9AP OGlvac6QLgGLw== 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: <156500236936.24594.14034383808328017805.idtracker@ietfa.amsl.com> Date: Tue, 6 Aug 2019 08:16:17 -0400 Cc: The IESG , tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156500236936.24594.14034383808328017805.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3570.1) Archived-At: Subject: Re: [dnssd] Alexey Melnikov's Yes on draft-ietf-dnssd-push-23: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 12:16:20 -0000 > On Aug 5, 2019, at 6:52 AM, Alexey Melnikov via Datatracker = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-dnssd-push-23: Yes >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This comment is for RFC Editor: >=20 > On page 21, HTML and text version has "TTL=E2=A9=BE0", which gets = mangled in PDF version. >=20 I discussed this with the tools team and Henrik said it was a bug in the = TXT to PDF converter. This converter is being replaced with direct XML = to PDF in the near future and so I don=E2=80=99t think it will be fixed. Tom= From nobody Tue Aug 6 06:10:20 2019 Return-Path: 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 66F6D120189; Tue, 6 Aug 2019 06:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=kHyYBtb6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R1i5mvo4 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 SEfEkmEupbkM; Tue, 6 Aug 2019 06:10:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF7C120191; Tue, 6 Aug 2019 06:10:09 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8D7B221FE7; Tue, 6 Aug 2019 09:10:08 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Tue, 06 Aug 2019 09:10:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=w0XMb +1ue5lvL1Go0jz55hvJH54hSd+2XXB25WvTE7M=; b=kHyYBtb6eBw1IsMai0EPh 8X/zO3j//8qY6Za+CBX8RGxx21E16oGyK6bEfnBAZninvoNRb/14U9m+D2qu/RJ/ XtJ5UrDGUkFmLRBazBP/AOZ7ljedu9IQceJcGvxCizw4HMFYz7ZbJubA0TErqwMo FOgfFQ+DO1SK/XF4iiM9Zzt+OSD2wrhYkxUIqLLPn4ULJOYuXJ2t8huf2WzHPzT7 tXGXKXcdKKA6M1u362jE6XmtCWxEzauUHc3hcwHk93Bt0uHaYHdxdrdOKX81Oc8a LgDjNsHmu1rlM8VpBsbh6I/COjTnXpmWxWDbqRaRn2Ef05vJoCSiWmexEjEA+gUz A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=w0XMb+1ue5lvL1Go0jz55hvJH54hSd+2XXB25WvTE 7M=; b=R1i5mvo4ut1tU+NvYc+O70dmahEBXM+C51LII/8tXnAn0v4djRJ4MFaWH k4kIn9TRXQc/v9in6dzc3FErKUNitRqxXgQNKW42Vid+06id/VYsBhCS2JuckrDY RE61bL+x/jq3HX1Y6gtkqtYYL5LBoaWjIdJJ4TbrG9h6AnRA2wk2B8GOeIvEUZfy wdh4jekR+586OIiKQcHxOHj8w64oBLrYl7zo+zFYap4ECXz5g9C7gY2aQhUldgxJ M12ic3YVpa/d7I+hSjGt8pNC+x8lx1YGgzB+tWaaevPrwRLoZ9wcVNY7RcLyPGGB gkuVohYs+ckPwAEMRZML/kIyrDOwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddutddgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghs thhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 01BE0C200A5; Tue, 6 Aug 2019 09:10:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: <85a31324-0d5e-47a7-83d6-fd25a88ec4b8@www.fastmail.com> In-Reply-To: References: <156500236936.24594.14034383808328017805.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2019 14:09:56 +0100 From: "Alexey Melnikov" To: "Tom Pusateri" Cc: "The IESG" , "Tim Wicinski" , dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dnssd] =?utf-8?q?Alexey_Melnikov=27s_Yes_on_draft-ietf-dnssd-pu?= =?utf-8?q?sh-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 13:10:12 -0000 On Tue, Aug 6, 2019, at 1:16 PM, Tom Pusateri wrote: >=20 > > On Aug 5, 2019, at 6:52 AM, Alexey Melnikov via Datatracker wrote: > >=20 > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-dnssd-push-23: Yes > >=20 > >=20 > > --------------------------------------------------------------------= -- > > COMMENT: > > --------------------------------------------------------------------= -- > >=20 > > This comment is for RFC Editor: > >=20 > > On page 21, HTML and text version has "TTL=E2=A9=BE0", which gets ma= ngled in PDF version. > >=20 >=20 > I discussed this with the tools team and Henrik said it was a bug in=20= > the TXT to PDF converter. This converter is being replaced with direct= =20 > XML to PDF in the near future and so I don=E2=80=99t think it will be = fixed. That is fine. I just want for the responsible AD and WG to be aware, in = case you decide to change the document to work around. From nobody Tue Aug 6 08:07:29 2019 Return-Path: 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 04EFB1201D5; Tue, 6 Aug 2019 08:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WjOLyjsQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=miKtPLJY 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 D8C1rl0le53Y; Tue, 6 Aug 2019 08:07:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D97412018A; Tue, 6 Aug 2019 08:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2090; q=dns/txt; s=iport; t=1565104039; x=1566313639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zQ9ucdRKMt7QNCob4q7C25dsOZPcA6RbdXJIsQASf2o=; b=WjOLyjsQC527t5kKR+DFQQgRa7mjSPkh5l3X9RQWqltCckWQQYeelOUa XF/xs75ASOyj/rvHVjp3DluTGdM+zHj1e/yEWjwMkNPrSxN0kwt+RQ3vl 6qrs4POwWV4TeaDrlobP85mZnQH1bilN+hasIjJzX56f/K4WYV5OBePIG A=; IronPort-PHdr: =?us-ascii?q?9a23=3AYEohLxa2cc+j1mIXmd0I50P/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavncT08F8dPfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAADplkld/5ldJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBRFADbVUgBAsqhB6DRwOEUoZfgjYll1uBLoE?= =?us-ascii?q?kA1QJAQEBDAEBGAsKAgEBhD8CF4InIzQJDgEEAQEEAQECAQZthScMhUsBAQE?= =?us-ascii?q?DAQEQEREMAQEsCwEPAgEIDgoCAiYCAgIlCxUQAgQBDQUigwABgWoDHQECDKB?= =?us-ascii?q?YAoE4iGBxgTKCegEBBYUPGIITAwaBDCgBi2IXgUA/gTgME4JMPoJhAQGBeIJ?= =?us-ascii?q?0MoImjDQtgXgxnCIJAoIckC6DcxuYLI1Jl3ICBAIEBQIOAQEFgVA4gVhwFTs?= =?us-ascii?q?qAYJBgkIMF4NOhRSFP3KBKY0rAQE?= X-IronPort-AV: E=Sophos;i="5.64,353,1559520000"; d="scan'208";a="615279841" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Aug 2019 15:07:18 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x76F7Ipd013873 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2019 15:07:18 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 10:07:17 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 10:07:16 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 6 Aug 2019 11:07:16 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fNBhOXtG+ZuPsa4mmgWt/VKffKt/rRxurrwj0b88IGHAJ8Whq62OSfxUR5YnguPWrNpMnsih7filwD9eXIzLsb72e8YyveGmRSmcBR26bqo5fgnAsc3kHU1jfmbs4evX6yNnV3guzRg6vda6MqXQwcSd29nAekQqsG3Yeq2ZMGyC2EYitpMQb2m0luSQ0jACXxpxFJ8bK8fkgL6eT4rwAxdqGfbtjvJYxliuOvNaHVTSQt/u+eMtR3gpVYKNUcnEVnnYtVNqZVlMc+/CNGhK8HOmgiVzHnLAxqUs7cWa07+fxh2mxITzGZ/NkbDzXfBh/TsdfdV7CJWIVIFUr+5v+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zQ9ucdRKMt7QNCob4q7C25dsOZPcA6RbdXJIsQASf2o=; b=JM4SZQXr5sCsb3+QPW6r6GB1hhLyxRtqAMURtMrP8sjQF8ZY6hSlQoDieZMioLsqYVAV0bHDKO8IDo5brEK5lnblVi9oFzCZU57i+BDQ+HS48Sf2RA3B2y427TU4eQUPon1qqbQFZbbRpoSooErsyO8GYgbOgq1rKphkNYbIjriADyRofzXUa45Y6ybX4Ufe2gEkbH+cAPYab1YuyLSC3VYbPv8LkcTThNBKxpWv/rCJ8hxgFy/tiGiMLWmLAWlZnQgTEsUI3atrIBm2nYXxrMsKflJYyL6Vks1tm4tIpKHmgq2HYG/oko6G8IQYrMUrPlmyDcvT2U3u0OkpGslhpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zQ9ucdRKMt7QNCob4q7C25dsOZPcA6RbdXJIsQASf2o=; b=miKtPLJYs4o5q0tvzeuSMNC4IN677k1JWWs6godfEpdTTbEG1jqB2NJYL9C+D47KDA2ZGfVCdZtgoB03bKP4nc6nbQURgpw7luVSJcWANNcPv4pSmT+ZCld/BpOLAJtUbkRTNvsOXGhcm+hKW11RBMvkdNaB1lZ5VSE0r63b5ec= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4381.namprd11.prod.outlook.com (52.135.37.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.20; Tue, 6 Aug 2019 15:07:15 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c%7]) with mapi id 15.20.2136.018; Tue, 6 Aug 2019 15:07:15 +0000 From: "Eric Vyncke (evyncke)" To: Alexey Melnikov , Tom Pusateri CC: Tim Wicinski , "draft-ietf-dnssd-push@ietf.org" , "dnssd@ietf.org" , "dnssd-chairs@ietf.org" , The IESG Thread-Topic: [dnssd] Alexey Melnikov's Yes on draft-ietf-dnssd-push-23: (with COMMENT) Thread-Index: AQHVTFhdfUXj5PVhwU6oQtzdzFOVY6buWhgA Date: Tue, 6 Aug 2019 15:07:15 +0000 Message-ID: <59359702-536C-46E0-B76D-F0894F0587CD@cisco.com> References: <156500236936.24594.14034383808328017805.idtracker@ietfa.amsl.com> <85a31324-0d5e-47a7-83d6-fd25a88ec4b8@www.fastmail.com> In-Reply-To: <85a31324-0d5e-47a7-83d6-fd25a88ec4b8@www.fastmail.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:c3b:1410:deb2:43c9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ad0e31d-5adf-43f2-ca63-08d71a7fc45b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4381; x-ms-traffictypediagnostic: MN2PR11MB4381: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(199004)(189003)(8676002)(68736007)(2616005)(476003)(81156014)(486006)(256004)(6436002)(11346002)(46003)(6306002)(64756008)(66476007)(66556008)(102836004)(66946007)(76116006)(91956017)(36756003)(66446008)(446003)(186003)(6116002)(6486002)(6512007)(4326008)(305945005)(81166006)(86362001)(99286004)(6246003)(25786009)(76176011)(110136005)(54906003)(316002)(71200400001)(71190400001)(7736002)(8936002)(478600001)(53936002)(966005)(14454004)(6506007)(229853002)(58126008)(2906002)(53546011)(5660300002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4381; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: y+8Udx/1+Yc7uLPR5Btd6Rn0Hh/H4q5R/ZwYNl9oBIjsPyz411txDc9ppOB1ETGje6C3YbxwbFCk+7+oO66fFtFEX8XsF0jwXkAu6Dllv1aU0gFkj/vVvxVcN2vPN80Af3OMnXfCY8rHQfuek0zt76kJn+1GI9ktrDul0Z0ILV4anVZF5IgtIpJHzJJOX55CZeB44zHvM9B0IAFYCeWr1DMEUMvyObQC2lslwHaBmJ6sBUhF8tFTrzLvroytXIHrcyLShMqz166eHuN5sFaqFfLY2bshuQyc/MhXS+vBOv8K5YuX4K20CdN7tqJs2i3KPfUJQPWNW8QgfAWJQSXbKfPh37coCKK/M+ZKPE0mIYM9g7gM7ZML6n9tiZ315M35bKOJfh2WVTpXZzbWJI+D2Xnb71zmDdtvKhL+Ulm2d3I= Content-Type: text/plain; charset="utf-8" Content-ID: <9D02FFBCB94D33499DB8A9DE9163795B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8ad0e31d-5adf-43f2-ca63-08d71a7fc45b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2019 15:07:15.2573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4381 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [dnssd] Alexey Melnikov's Yes on draft-ietf-dnssd-push-23: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:07:22 -0000 VG9tLA0KDQpDYW4geW91IHNpbXBseSBjaGFuZ2UgdGhlIHRleHQgaW4gdGhlIFhNTCBNRCBzb3Vy Y2UgZmlsZSBpbnRvIFRUTCA+PSAwIChpLmUgdXNpbmcgQy9TUUwgc3ludGF4IGFuZCBwdXR0aW5n IHNwYWNlIGFyb3VuZCBpdD8sIGlmIHRoaXMgaXQgbm90IGVub3VnaCwgdGhlbiB1c2UgJ2dyZWF0 ZXIgb3IgZXF1YWwnKQ0KDQpUaGFuayB5b3UNCg0KLcOpcmljDQoNCu+7v09uIDA2LzA4LzIwMTks IDE1OjEwLCAiZG5zc2Qgb24gYmVoYWxmIG9mIEFsZXhleSBNZWxuaWtvdiIgPGRuc3NkLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFhbWVsbmlrb3ZAZmFzdG1haWwuZm0+IHdyb3RlOg0K DQogICAgT24gVHVlLCBBdWcgNiwgMjAxOSwgYXQgMToxNiBQTSwgVG9tIFB1c2F0ZXJpIHdyb3Rl Og0KICAgID4gDQogICAgPiA+IE9uIEF1ZyA1LCAyMDE5LCBhdCA2OjUyIEFNLCBBbGV4ZXkgTWVs bmlrb3YgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCiAgICA+ID4g DQogICAgPiA+IEFsZXhleSBNZWxuaWtvdiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv dCBwb3NpdGlvbiBmb3INCiAgICA+ID4gZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTIzOiBZZXMNCiAg ICA+ID4gDQogICAgPiA+IA0KICAgID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiA+IENPTU1FTlQ6 DQogICAgPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+ID4gDQogICAgPiA+IFRoaXMgY29tbWVudCBp cyBmb3IgUkZDIEVkaXRvcjoNCiAgICA+ID4gDQogICAgPiA+IE9uIHBhZ2UgMjEsIEhUTUwgYW5k IHRleHQgdmVyc2lvbiBoYXMgIlRUTOKpvjAiLCB3aGljaCBnZXRzIG1hbmdsZWQgaW4gUERGIHZl cnNpb24uDQogICAgPiA+IA0KICAgID4gDQogICAgPiBJIGRpc2N1c3NlZCB0aGlzIHdpdGggdGhl IHRvb2xzIHRlYW0gYW5kIEhlbnJpayBzYWlkIGl0IHdhcyBhIGJ1ZyBpbiANCiAgICA+IHRoZSBU WFQgdG8gUERGIGNvbnZlcnRlci4gVGhpcyBjb252ZXJ0ZXIgaXMgYmVpbmcgcmVwbGFjZWQgd2l0 aCBkaXJlY3QgDQogICAgPiBYTUwgdG8gUERGIGluIHRoZSBuZWFyIGZ1dHVyZSBhbmQgc28gSSBk b27igJl0IHRoaW5rIGl0IHdpbGwgYmUgZml4ZWQuDQogICAgDQogICAgVGhhdCBpcyBmaW5lLiBJ IGp1c3Qgd2FudCBmb3IgdGhlIHJlc3BvbnNpYmxlIEFEIGFuZCBXRyB0byBiZSBhd2FyZSwgaW4g Y2FzZSB5b3UgZGVjaWRlIHRvIGNoYW5nZSB0aGUgZG9jdW1lbnQgdG8gd29yayBhcm91bmQuDQog ICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBkbnNzZCBtYWlsaW5nIGxpc3QNCiAgICBkbnNzZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2QNCiAgICANCg0K From nobody Tue Aug 6 08:11:41 2019 Return-Path: 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 E78791203BA; Tue, 6 Aug 2019 08:11:29 -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 bAU8Znw54oDz; Tue, 6 Aug 2019 08:11:28 -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 ABF6E120242; Tue, 6 Aug 2019 08:11:23 -0700 (PDT) Received: from [192.168.1.89] (66-190-152-116.dhcp.hckr.nc.charter.com [66.190.152.116]) (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 B79A53193E; Tue, 6 Aug 2019 11:11:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1565104282; bh=JzvLqY7KTjGGaqX2pvsvO70Ub9LQ72In712ayr2iHp8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fhn+IPwdtN5uo8UcmPDx43Ea8AwAXJB1N3FGdhh1oyxQaWnszz7dwc7PTR2lye/ws 8z78t/cT8Pb6rdKpIVMHXgVWMwP2SZVBX3E4Jsx3L4XKPp/2PgsoavEsTUKwVnGcPx idI7AD8Gc956B+sADt3gOKsZgDSxa1yk84HBwQdvUNpW1Ymv5PGn2H0fLHq92DbN4I FwJkfmi+DlV9fVdeHrZfL6wPRtanBj2nt5GzXQk/XvsZbxDZkWkjkYI5ggUkDzuJM9 Rrc898eXuF7yFSOlQIazRSQN159IwNU0AHrbcxsL7W0z1aoUGqrpASVVZJMALunS+3 pbhLIW3M1XPyA== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPad Mail (16G77) In-Reply-To: <59359702-536C-46E0-B76D-F0894F0587CD@cisco.com> Date: Tue, 6 Aug 2019 11:11:21 -0400 Cc: Alexey Melnikov , Tim Wicinski , "draft-ietf-dnssd-push@ietf.org" , "dnssd@ietf.org" , "dnssd-chairs@ietf.org" , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <1324FC0B-3EE7-4A62-B1E0-219C2B2617ED@bangj.com> References: <156500236936.24594.14034383808328017805.idtracker@ietfa.amsl.com> <85a31324-0d5e-47a7-83d6-fd25a88ec4b8@www.fastmail.com> <59359702-536C-46E0-B76D-F0894F0587CD@cisco.com> To: "Eric Vyncke (evyncke)" Archived-At: Subject: Re: [dnssd] Alexey Melnikov's Yes on draft-ietf-dnssd-push-23: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:11:34 -0000 That=E2=80=99s how it was until the last draft when Stuart introduced the UT= F-8 character. Tom > On Aug 6, 2019, at 11:07 AM, Eric Vyncke (evyncke) wro= te: >=20 > Tom, >=20 > Can you simply change the text in the XML MD source file into TTL >=3D 0 (= i.e using C/SQL syntax and putting space around it?, if this it not enough, t= hen use 'greater or equal') >=20 > Thank you >=20 > -=C3=A9ric >=20 > =EF=BB=BFOn 06/08/2019, 15:10, "dnssd on behalf of Alexey Melnikov" wrote: >=20 >> On Tue, Aug 6, 2019, at 1:16 PM, Tom Pusateri wrote: >>=20 >>> On Aug 5, 2019, at 6:52 AM, Alexey Melnikov via Datatracker wrote: >>>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-dnssd-push-23: Yes >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> This comment is for RFC Editor: >>>=20 >>> On page 21, HTML and text version has "TTL=E2=A9=BE0", which gets mangle= d in PDF version. >>>=20 >>=20 >> I discussed this with the tools team and Henrik said it was a bug in=20 >> the TXT to PDF converter. This converter is being replaced with direct=20= >> XML to PDF in the near future and so I don=E2=80=99t think it will be fix= ed. >=20 > That is fine. I just want for the responsible AD and WG to be aware, in= case you decide to change the document to work around. >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 >=20 From nobody Tue Aug 6 12:10:18 2019 Return-Path: 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 8AE5A120059; Tue, 6 Aug 2019 12:10:09 -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 w_3t09Fu2qC2; Tue, 6 Aug 2019 12:10:08 -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 0982A12003F; Tue, 6 Aug 2019 12:10:08 -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 0A396319B5; Tue, 6 Aug 2019 15:10:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1565118607; bh=H4ClmZWaTwG+5UJ2Jemk2BDyYDl2kmvrtWiLnEHxhCQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ioBE+3wsNN8KcfvP+EOJsyp3TeXLLN8518mmZfE7db7S5zmEJsoPeAbOQfTfEVLwB 0dcpteaDDMLih8tzx+Eq0+tebRZFEEGNka7YtZkqgZMzrr5yYLeWE9VLZZhg0sKYCi hB6dHN8w4rKZyrVLj0q6tsrDpBYY/NcxzJ1i5SXveVLF0/RiqOJuKpaTteinPTqjSs dXlutfoimz4hU0Gvln3JdQH144J9z+MFvyPauadeH72jKtgOsU5eyfE4ThLSxyhqOr SQYB03JAB9HG3BjvbSiPNk/EtLfEYdfSSfoN7KWf8kSdvBeLTsPxGazj19DjkRIZmd T1kKlRyKuhndg== 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: <59359702-536C-46E0-B76D-F0894F0587CD@cisco.com> Date: Tue, 6 Aug 2019 15:10:06 -0400 Cc: Alexey Melnikov , Tim Wicinski , "draft-ietf-dnssd-push@ietf.org" , "dnssd@ietf.org" , "dnssd-chairs@ietf.org" , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <556A53A5-8C2C-4332-ACB2-FC057B48E225@bangj.com> References: <156500236936.24594.14034383808328017805.idtracker@ietfa.amsl.com> <85a31324-0d5e-47a7-83d6-fd25a88ec4b8@www.fastmail.com> <59359702-536C-46E0-B76D-F0894F0587CD@cisco.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.3570.1) Archived-At: Subject: Re: [dnssd] Alexey Melnikov's Yes on draft-ietf-dnssd-push-23: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 19:10:10 -0000 I=E2=80=99ve reverted this back to ASCII =E2=80=9C>=3D=E2=80=9C. Looking = at RFC 7997, it doesn=E2=80=99t seem to permit UTF-8 for the purpose of = maths. I think RFC 7997 should be updated to include mathematical = symbols. But that=E2=80=99s for another day. Thanks, Tom > On Aug 6, 2019, at 11:07 AM, Eric Vyncke (evyncke) = wrote: >=20 > Tom, >=20 > Can you simply change the text in the XML MD source file into TTL >=3D = 0 (i.e using C/SQL syntax and putting space around it?, if this it not = enough, then use 'greater or equal') >=20 > Thank you >=20 > -=C3=A9ric >=20 > =EF=BB=BFOn 06/08/2019, 15:10, "dnssd on behalf of Alexey Melnikov" = wrote: >=20 > On Tue, Aug 6, 2019, at 1:16 PM, Tom Pusateri wrote: >>=20 >>> On Aug 5, 2019, at 6:52 AM, Alexey Melnikov via Datatracker = wrote: >>>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-dnssd-push-23: Yes >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> This comment is for RFC Editor: >>>=20 >>> On page 21, HTML and text version has "TTL=E2=A9=BE0", which gets = mangled in PDF version. >>>=20 >>=20 >> I discussed this with the tools team and Henrik said it was a bug in=20= >> the TXT to PDF converter. This converter is being replaced with = direct=20 >> XML to PDF in the near future and so I don=E2=80=99t think it will be = fixed. >=20 > That is fine. I just want for the responsible AD and WG to be = aware, in case you decide to change the document to work around. >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 >=20 From nobody Tue Aug 6 14:46:29 2019 Return-Path: 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 A2BC7120047; Tue, 6 Aug 2019 14:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 m6J6LvouoznY; Tue, 6 Aug 2019 14:46:25 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95D0120033; Tue, 6 Aug 2019 14:46:24 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x76LkJO2006908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Aug 2019 17:46:22 -0400 Date: Tue, 6 Aug 2019 16:46:19 -0500 From: Benjamin Kaduk To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: The IESG , tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org Message-ID: <20190806214618.GN59807@kduck.mit.edu> References: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [dnssd] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 21:46:27 -0000 On Mon, Aug 05, 2019 at 07:55:20AM -0700, Mirja Khlewind via Datatracker wrote: > > 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? 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 nobody Tue Aug 6 15:02:21 2019 Return-Path: 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 In-Reply-To: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com> Date: Tue, 6 Aug 2019 18:02:09 -0400 Cc: The IESG , tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com> 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-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." 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=C3=BChlewind via Datatracker = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dnssd-push-23: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this well-written document! >=20 > 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. >=20 > Other, smaller comments: >=20 > 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=E2=80=99ve made the second MUST NOT lower case. >=20 > 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. >=20 > 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. >=20 > 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=E2=80=99s preference for short references. Tom From nobody Tue Aug 6 15:03:04 2019 Return-Path: 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 6826712008B; Tue, 6 Aug 2019 15:03:03 -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 imZfKWeo5wxT; Tue, 6 Aug 2019 15:03:02 -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 DF39312006E; Tue, 6 Aug 2019 15:03:01 -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 02686319F0; Tue, 6 Aug 2019 18:03:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1565128981; bh=6jncNcz82EVAfUO+zWsFcL3v6oWCllhIxVGBwoZPRWo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Ed76fTBKo4a/OR6UWASE36jhddHXOjxYmERHxB0eyush6Y3XuYpHQisYPPPK8y1r1 UhsnvGUseR+cvjfgl5IJ1i9L9t/dihhQmd8Zp7J9oi3wwQEVqEG6Rcl6GfG4BPRPQc WyHlCkJD7I7oSPTKqMsntUcL0TwrL2rNV9a8X7tbck/terOaLIRMVvnlJrKwfoUsGi W7N1+m/E9Uj3UCwg1nO0w5JC1JoPT8BwRz2pChoHTkMsmgEPU2U2ffR7e7RD1slYPf EYzjEcmimFuI4Dv1RurqMBq8mVHey92D1ipKyC4LAJIiYqavZlZ+kticvLPLPwhAES ECpcjBqg+UQJQ== 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: <20190806214618.GN59807@kduck.mit.edu> Date: Tue, 6 Aug 2019 18:03:00 -0400 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , The IESG , tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com> <20190806214618.GN59807@kduck.mit.edu> To: Benjamin Kaduk 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-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 22:03:04 -0000 > On Aug 6, 2019, at 5:46 PM, Benjamin Kaduk wrote: >=20 > On Mon, Aug 05, 2019 at 07:55:20AM -0700, Mirja K=C3=BChlewind via = Datatracker wrote: >>=20 >> 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? >=20 > 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.) >=20 > -Ben Yes, thanks for the background. This was a misunderstanding on my part = and I will remove the resumption clause. Tom= From nobody Wed Aug 7 11:07:11 2019 Return-Path: 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 069751202E1; Wed, 7 Aug 2019 11:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=pOAHnhiw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bqmdAn4L 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 VWUz8lYcmJqC; Wed, 7 Aug 2019 11:07:01 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2138A12068D; Wed, 7 Aug 2019 11:07:01 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5E95921F14; Wed, 7 Aug 2019 14:07:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 07 Aug 2019 14:07:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=6 qVYd3FRZAuEKOb23+pATuo6cPS2wm2HGPcKUau0VmA=; b=pOAHnhiwXy7KEKSvr Aq7D0gxTMk6Uh04wHkVU9rLH91wrTbgVfpsBlmRMmyrWVb2o7QXP6HB7eE4kntex tHQEY7NiEesvHYat4gIS57v8wsoYKeAmDgGQJxWRxFiMRUtft0iqcIclzQ0Bjjk9 C1TzHrvwInM8mWTUIP0XBVZE5bR3SDh/mD5nrZBa4jBEv76mb5K9XTHFRQ5QJTdd fd41hoCTzA99+OEVANqkjB0ryYWmXtkF5/1z537Z0hEBW9kXnmI+8doy0aFpDpy/ QDcz28rxoSGu/bYEfSBa9phlIZgKD4L2CeLniE0+IrQmnEy3zM+j+CWYAzZoT6wA mPRQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=6qVYd3FRZAuEKOb23+pATuo6cPS2wm2HGPcKUau0V mA=; b=bqmdAn4LV35BTR2p4xVyOUx1QFa4QlNSb+5eNL8SqS+tCxYVv7G2wJQxg i3N1sXmIj/RiBF/4FEdN7eJfVZGgFVb1rSa+o9PI3OSfLY1NwlYwx76YOf3bs0O8 HdV/3/paPEk4GopkfKNP4hC5PtT24zwfN/qTb7CINgRoSevYfkBsej5ex3uUTvtj UY2xSe+TL3jHnvV1UvSjTIO8x4dM2vTjaWG3iX3SrTi/ClW21oY2ZbgqA2VbZJM0 XbzapX3bHQeR6wSnE8w0gG+aFz2HJ2f0lm+WXtWf4F8NL8ZOEL+RoSTX7WtWN65D 4s+xYPMkcFgN2YK59TwR6rWlYXRBA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduvddguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekleenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E4E1380086; Wed, 7 Aug 2019 14:06:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156477563639.21007.9900842292278023537@ietfa.amsl.com> Date: Wed, 7 Aug 2019 14:06:58 -0400 Cc: General Area Review Team , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C3A426F-11E5-49E7-AAD9-9AA2324BAEF2@cooperw.in> References: <156477563639.21007.9900842292278023537@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] [Gen-art] Genart telechat review of draft-ietf-dnssd-push-23 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 18:07:03 -0000 Robert, thanks for your review. Tom, Ted, thanks for your responses. I = entered a No Objection ballot. Alissa > On Aug 2, 2019, at 3:53 PM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-dnssd-push-23 > Reviewer: Robert Sparks > Review Date: 2019-08-02 > IETF LC End Date: None > IESG Telechat date: 2019-08-08 >=20 > Summary: Ready for publication as a Proposed Standard RFC >=20 > Thanks for addressing all of the concerns in my previous review. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Aug 7 17:42:35 2019 Return-Path: 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 952A512008A; Wed, 7 Aug 2019 17:42:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-dnssd-push@ietf.org, Tim Wicinski , dnssd-chairs@ietf.org, tjw.ietf@gmail.com, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156522494653.8446.16442543893834173010.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 17:42:26 -0700 Archived-At: Subject: [dnssd] Roman Danyliw's No Objection on draft-ietf-dnssd-push-23: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 08 Aug 2019 00:42:27 -0000 Roman Danyliw 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: ---------------------------------------------------------------------- Reference Nits: -- Section 6.2.1. Please add a citation for “US-ASCII” -- Section 6.5. Please add a citation for “apple dns_sd.h API” Editorial Nits: -- Section 2. Editorial. s/poor imitations/imitation/ -- Section 6. Typo. s/the the/the/ From nobody Wed Aug 7 19:01:53 2019 Return-Path: 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 809ED120033; Wed, 7 Aug 2019 19:01:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156522971144.8361.11337962264982871105@ietfa.amsl.com> Date: Wed, 07 Aug 2019 19:01:51 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-24.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 08 Aug 2019 02:01:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-24.txt Pages : 41 Date : 2019-08-07 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-24 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 7 20:13:56 2019 Return-Path: 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 51231120033; Wed, 7 Aug 2019 20:13:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-dnssd-push@ietf.org, Tim Wicinski , dnssd-chairs@ietf.org, tjw.ietf@gmail.com, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156523403427.8333.17262158545335272634.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 20:13:54 -0700 Archived-At: Subject: [dnssd] Barry Leiba's Yes on draft-ietf-dnssd-push-24: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 08 Aug 2019 03:13:54 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dnssd-push-24: Yes 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: ---------------------------------------------------------------------- — Section 6.7 — When a client terminates an individual subscription (via UNSUBSCRIBE) or all subscriptions on that DSO session (by ending the session) it is signaling to the server that it is longer interested in receiving those particular updates. 
Typo: It shoud be “it is no longer interested”. From nobody Thu Aug 8 07:22:11 2019 Return-Path: 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 9922312006D; Thu, 8 Aug 2019 07:22:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dnssd-push@ietf.org, Tim Wicinski , dnssd-chairs@ietf.org, tjw.ietf@gmail.com, dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156527413058.7542.141771034158195549.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2019 07:22:10 -0700 Archived-At: Subject: [dnssd] Benjamin Kaduk's No Objection on draft-ietf-dnssd-push-24: (with COMMENT) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 08 Aug 2019 14:22:11 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dnssd-push-24: 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! What are the privacy considerations to zone content owners (e.g., machine owners listed in a zone) about the availability of near-realtime information tracking their changes? Can we have a discussion of padding policy to attempt to preserve the privacy of push transactions? Section 1.2 Do we need to give a reference for the BSD Sockets API? (I honestly forget what we did for other documents referencing it.) Section 3 Perhaps we should put quotation marks around statements taken from RFC 8490 (so as to avoid the appearance that we are duplicating normative requirements made in that document). Section 5 server in this protocol specification. Additional security measures such as client authentication during TLS negotiation MAY also be employed to increase the trust relationship between client and server. Do we want to say anything about the validation procedures for that client authentication, maybe RFC 6125 with a DNS-ID check, or would that be too restrictive? Section 6.1 In many contexts, the recursive resolver will be able to handle Push Notifications for all names that the client may need to follow. Use of VPN tunnels and split-view DNS can create some additional complexity in the client software here; the techniques to handle VPN tunnels and split-view DNS for DNS Push Notifications are the same as those already used to handle this for normal DNS queries. Is there a good reference discussing these techniques? Section 6.2.1 The MESSAGE ID field MUST be set to a unique value, that the client is not using for any other active operation on this DSO session. For Isn't this already mandated by 8490? (Hmm, the interaction of TLS early data's replayability and MESSAGE ID uniqueness might require some thought. But the MESSAGE ID uniqueness is within a DSO session, not global, so that may not make a difference.) Section 6.3.1 The other header fields MUST be set as described in the DSO spec- ification [RFC8490]. The DNS OPCODE field contains the OPCODE value for DNS Stateful Operations (6). The four count fields MUST be zero, and the corresponding four sections MUST be empty (i.e., absent). We may not need the 2119 terms for the requirements duplicated from 8490. For collective remove notifications, if CLASS is not 255 (ANY) and TYPE is not 255 (ANY) then for the given name this deletes all records of the specified type in the specified class. (et seq) What does it mean to "delete a record", from the recipient's point of view? (How does the server communicate that the RRset's contents have changed to a completely disjoint value -- delete plus add?) a SUBSCRIBE request, subject to the usual established DNS case- insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE request was not ANY (255) then the TYPE of the record must match the TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE nit: we switch from using the indefinite article to the definite article with "SUBSCRIBE request", which is a bit jarring since we don't give a great indication of what distinguishes the definite case. Section 6.5 It's not entirely clear to me that we need quite this much detail about discovery proxy operations, in order to motivate RECONFIRM. If we're going to talka bout Apple's dns_sd.h API (which I have somewhat mixed feelings about to begin with), we should have a reference for it. Section 7.1 Deployment recommendations on the appropriate key lengths and cypher suites are beyond the scope of this document. Please refer to TLS Recommendations [RFC7525] for the best current practices. Keep in Please cite this as BCP 195. Section 7.4 servers. The server may keep TLS state with Session IDs [RFC8446] or operate in stateless mode by sending a Session Ticket [RFC5077] to 5077 was made obsolete by 8446; from the practical side of tings there is no wire-visible distinction between stateful session IDs and stateless session tickets. Section 10.2 I think RFC 7858 needs to be normative. Likewise, RFC 8310. From nobody Mon Aug 12 16:32:49 2019 Return-Path: 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 909E3120018; Mon, 12 Aug 2019 16:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pitdALb4ulZb; Mon, 12 Aug 2019 16:32:43 -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 7EAFA12000E; Mon, 12 Aug 2019 16:32:43 -0700 (PDT) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 41F3F32206; Mon, 12 Aug 2019 19:32:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1565652762; bh=RVGoTPCmQX97I1Q64dog1TpphfzGID/k66IqcR1JOKQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=UM5TBaTHZgOY1EO7SQSPsQ3kZSbo5sWQKd0/A/JbqBUlY3Zo/SG7YQP9y/oNVIyCt GbOJu95OE3FxtQyPlkEYuiDjbOUwz4oY8b5ckFUP9mZqG5EHbzx8mh5aYEL7wHiYp7 3WJz2sAaca74pNe9zJcCB9PBgTk+Ych7wHptGsqc6B6j9tAzHXoIXK5LQ92HrHcMO/ fAUgojIRV4ReK3bApxYuPcYr958PMpkD0DHibOHvW1JO3TkvYxEZuIOmI4s7tddSVD NG2QLRjXyDgImWYtsqznUoBymVh2p4bcvlp+XitBQdbzNuWMdOMXMM9uhi3LVAPDfK ElTiL/L2eY//g== From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EEBE48C4-33D7-44B1-9DC1-679897161490" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3570.1\)) Date: Mon, 12 Aug 2019 19:32:41 -0400 In-Reply-To: <156527413058.7542.141771034158195549.idtracker@ietfa.amsl.com> Cc: The IESG , tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org To: Benjamin Kaduk References: <156527413058.7542.141771034158195549.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3570.1) Archived-At: Subject: Re: [dnssd] Benjamin Kaduk's No Objection on draft-ietf-dnssd-push-24: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 23:32:46 -0000 --Apple-Mail=_EEBE48C4-33D7-44B1-9DC1-679897161490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Comments below. > On Aug 8, 2019, at 10:22 AM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dnssd-push-24: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this well-written document! >=20 > What are the privacy considerations to zone content owners (e.g., > machine owners listed in a zone) about the availability of = near-realtime > information tracking their changes? With the primary case of service discovery, this information is already = available today as link-local multicast announcements. And many unicast = DNS servers already have policy controls that would apply to = subscriptions as well. We=E2=80=99re not really creating any new = exposure. >=20 > Can we have a discussion of padding policy to attempt to preserve the > privacy of push transactions? Analysis of message size is a component of traffic analysis. I can add a = paragraph about this and reference the Padding TLV as discussed in RFC = 8490. >=20 > Section 1.2 >=20 > Do we need to give a reference for the BSD Sockets API? (I honestly > forget what we did for other documents referencing it.) RFCs 8547, 8490, 8095, 7663, 7640, & 7242 are the most recent to = reference the BSD socket api. Of these, only RFC 8095 reference the = POSIX Base Specifications which probably isn=E2=80=99t useful since no = one is going to go read the POSIX docs but instead read operating system = docs. None of the other RFCs in this list provide a reference. I would = like to skip this. >=20 > Section 3 >=20 > Perhaps we should put quotation marks around statements taken from RFC > 8490 (so as to avoid the appearance that we are duplicating normative > requirements made in that document). Need more specifics. If referring to: Generally, as described in the DNS Stateful Operations specification [RFC8490], a client must not keep a DSO session to a server open indefinitely if it has no subscriptions (or other operations) active on that session. A client MAY close a DSO session immediately it becomes idle, and then if needed in the future, open a new session when required. Alternatively, a client MAY speculatively keep an idle DSO 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]. then changing =E2=80=9CMAY" to =E2=80=9Cmay" could resolve this issue. >=20 > Section 5 >=20 > server in this protocol specification. Additional security measures > such as client authentication during TLS negotiation MAY also be > employed to increase the trust relationship between client and > server. >=20 > Do we want to say anything about the validation procedures for that > client authentication, maybe RFC 6125 with a DNS-ID check, or would = that > be too restrictive? This does not include client certificates, DANE, or out of band = mechanisms. 6125 is helpful but only describes one approach. >=20 > Section 6.1 >=20 > In many contexts, the recursive resolver will be able to handle Push > Notifications for all names that the client may need to follow. Use > of VPN tunnels and split-view DNS can create some additional > complexity in the client software here; the techniques to handle VPN > tunnels and split-view DNS for DNS Push Notifications are the same = as > those already used to handle this for normal DNS queries. >=20 > Is there a good reference discussing these techniques? I can reference RFC 8499 which defines split DNS. > Section 6.2.1 >=20 > The MESSAGE ID field MUST be set to a unique value, that the client > is not using for any other active operation on this DSO session. = For >=20 > Isn't this already mandated by 8490? Are you asking us to change =E2=80=9CMUST=E2=80=9D to =E2=80=9Cmust=E2=80=9D= ? I haven=E2=80=99t heard it suggested before that you can only use 2119 = terms once. >=20 > (Hmm, the interaction of TLS early data's replayability and MESSAGE ID > uniqueness might require some thought. But the MESSAGE ID uniqueness = is > within a DSO session, not global, so that may not make a difference.) Yes, early data isn=E2=80=99t a concern because a new DSO session means = all new subscriptions and new MESSAGE ID space. >=20 > Section 6.3.1 >=20 > The other header fields MUST be set as described in the DSO spec- > ification [RFC8490]. The DNS OPCODE field contains the OPCODE value > for DNS Stateful Operations (6). The four count fields MUST be = zero, > and the corresponding four sections MUST be empty (i.e., absent). >=20 > We may not need the 2119 terms for the requirements duplicated from > 8490. Are you asking us to change =E2=80=9CMUST=E2=80=9D to =E2=80=9Cmust=E2=80=9D= here too? >=20 > For collective remove notifications, if CLASS is not 255 (ANY) and > TYPE is not 255 (ANY) then for the given name this deletes all > records of the specified type in the specified class. >=20 > (et seq) What does it mean to "delete a record", from the recipient's > point of view? (How does the server communicate that the RRset's > contents have changed to a completely disjoint value -- delete plus = add?) To =E2=80=9Cdelete a record=E2=80=9D means the record is being removed = from the zone. That could be because the service is no longer offered or = the host has been decommissioned. In mDNS (RFC 6762), an announcement = with TTL 0 is used to signal a delete. This could trigger a PUSH = notification deleting the record. A received DNS UPDATE message could = also trigger a PUSH notification deleting a record. If the name of a DNS service changes then, yes, the old service is = deleted and the new service is added (although the delete doesn=E2=80=99t = have to come before the add). >=20 > a SUBSCRIBE request, subject to the usual established DNS case- > insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE > request was not ANY (255) then the TYPE of the record must match the > TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE >=20 > nit: we switch from using the indefinite article to the definite = article > with "SUBSCRIBE request", which is a bit jarring since we don't give a > great indication of what distinguishes the definite case. I will change =E2=80=9Ca SUBSCRIBE request,=E2=80=9D to =E2=80=9Cthe = SUBSCRIBE request,=E2=80=9D >=20 > Section 6.5 >=20 > It's not entirely clear to me that we need quite this much detail = about > discovery proxy operations, in order to motivate RECONFIRM. >=20 > If we're going to talka bout Apple's dns_sd.h API (which I have = somewhat > mixed feelings about to begin with), we should have a reference for = it. Do you prefer something like = https://opensource.apple.com/source/mDNSResponder/mDNSResponder-878.70.2/m= DNSShared/dns_sd.h.auto.html = or = https://github.com/IETF-Hackathon/mDNSResponder/blob/master/mDNSResponder/= mDNSShared/dns_sd.h = >=20 > Section 7.1 >=20 > Deployment recommendations on the appropriate key lengths and cypher > suites are beyond the scope of this document. Please refer to TLS > Recommendations [RFC7525] for the best current practices. Keep in >=20 > Please cite this as BCP 195. Ok. >=20 > Section 7.4 >=20 > servers. The server may keep TLS state with Session IDs [RFC8446] = or > operate in stateless mode by sending a Session Ticket [RFC5077] to >=20 > 5077 was made obsolete by 8446; from the practical side of tings there > is no wire-visible distinction between stateful session IDs and > stateless session tickets. Ok. I can change this to: TLS Session Resumption [RFC8446] is permissible on DNS Push = Notification servers. However, closing the TLS connection terminates the DSO = session. >=20 > Section 10.2 >=20 > I think RFC 7858 needs to be normative. >=20 > Likewise, RFC 8310. Ok. Thanks for the detailed review! Tom --Apple-Mail=_EEBE48C4-33D7-44B1-9DC1-679897161490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Comments below.

On Aug 8, 2019, at 10:22 AM, = Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:

Benjamin Kaduk has entered the following ballot position = for
draft-ietf-dnssd-push-24: 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.htmlfor 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!

What are the privacy = considerations to zone content owners (e.g.,
machine = owners listed in a zone) about the availability of near-realtime
information tracking their changes?

With the = primary case of service discovery, this information is already available = today as link-local multicast announcements. And many unicast DNS = servers already have policy controls that would apply to subscriptions = as well. We=E2=80=99re not really creating any new = exposure.


Can we have a = discussion of padding policy to attempt to preserve the
privacy of push transactions?

Analysis = of message size is a component of traffic analysis. I can add a = paragraph about this and reference the Padding TLV as discussed in RFC = 8490.


Section 1.2

Do we need to give a reference for the BSD Sockets API? =   (I honestly
forget what we did for other = documents referencing it.)
RFCs 8547, 8490, 8095, 7663, 7640, & 7242 are the = most recent to reference the BSD socket api. Of these, only RFC 8095 = reference the POSIX Base Specifications which probably isn=E2=80=99t = useful since no one is going to go read the POSIX docs but instead read = operating system docs. None of the other RFCs in this list provide a = reference. I would like to skip this.


Section 3

Perhaps we should put = quotation marks around statements taken from RFC
8490 (so = as to avoid the appearance that we are duplicating normative
requirements made in that document).

Need more specifics. If referring to:

   Generally, as described in = the DNS Stateful Operations specification
  =  [RFC8490], a client must not keep a DSO session to a server = open
   indefinitely if it has no subscriptions = (or other operations) active
   on that session. =  A client MAY close a DSO session immediately it
 =  becomes idle, and then if needed in the future, open a new = session
   when required.  Alternatively, a = client MAY speculatively keep an
   idle DSO = 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].

then changing =E2=80=9CMAY" to =E2=80=9Cm= ay" could resolve this issue.


Section 5

=   server in this protocol specification.  Additional = security measures
  such as client = authentication during TLS negotiation MAY also be
=   employed to increase the trust relationship between client = and
  server.

Do = we want to say anything about the validation procedures for that
client authentication, maybe RFC 6125 with a DNS-ID check, or = would that
be too restrictive?

This does = not include client certificates, DANE, or out of band mechanisms. 6125 = is helpful but only describes one approach.


Section 6.1

=   In many contexts, the recursive resolver will be able to = handle Push
  Notifications for all names that = the client may need to follow.  Use
  of = VPN tunnels and split-view DNS can create some additional
=   complexity in the client software here; the techniques to = handle VPN
  tunnels and split-view DNS for DNS = Push Notifications are the same as
  those = already used to handle this for normal DNS queries.

Is there a good reference discussing these techniques?

I can = reference RFC 8499 which defines split DNS.

Section 6.2.1

  The = MESSAGE ID field MUST be set to a unique value, that the client
  is not using for any other active operation on = this DSO session.  For

Isn't this = already mandated by 8490?

Are you asking us to change =E2=80=9CMUST=E2=80=9D to = =E2=80=9Cmust=E2=80=9D? I haven=E2=80=99t heard it suggested before that = you can only use 2119 terms once.


(Hmm, the interaction of TLS early data's replayability and = MESSAGE ID
uniqueness might require some thought. =  But the MESSAGE ID uniqueness is
within a DSO = session, not global, so that may not make a difference.)

Yes, early = data isn=E2=80=99t a concern because a new DSO session means all new = subscriptions and new MESSAGE ID space.


Section 6.3.1

=   The other header fields MUST be set as described in the DSO = spec-
  ification [RFC8490].  The DNS = OPCODE field contains the OPCODE value
  for = DNS Stateful Operations (6).  The four count fields MUST be = zero,
  and the corresponding four sections = MUST be empty (i.e., absent).

We may not = need the 2119 terms for the requirements duplicated from
8490.

Are you asking us to change =E2=80=9CMUST=E2=80=9D to = =E2=80=9Cmust=E2=80=9D here too?


=   For collective remove notifications, if CLASS is not 255 = (ANY) and
  TYPE is not 255 (ANY) then for the = given name this deletes all
  records of the = specified type in the specified class.

(et = seq) What does it mean to "delete a record", from the recipient's
point of view?  (How does the server communicate that = the RRset's
contents have changed to a completely disjoint = value -- delete plus add?)
To =E2=80=9Cdelete a record=E2=80=9D means the record = is being removed from the zone. That could be because the service is no = longer offered or the host has been decommissioned. In mDNS (RFC 6762), = an announcement with TTL 0 is used to signal a delete. This could = trigger a PUSH notification deleting the record. A received DNS UPDATE = message could also trigger a PUSH notification deleting a = record.

If the name of a DNS service = changes then, yes, the old service is deleted and the new service is = added (although the delete doesn=E2=80=99t have to come before the = add).


  a SUBSCRIBE = request, subject to the usual established DNS case-
=   insensitivity for US-ASCII letters.  If the TYPE in the = SUBSCRIBE
  request was not ANY (255) then the = TYPE of the record must match the
  TYPE given = in the SUBSCRIBE request.  If the CLASS in the SUBSCRIBE

nit: we switch from using the indefinite = article to the definite article
with "SUBSCRIBE request", = which is a bit jarring since we don't give a
great = indication of what distinguishes the definite case.

I will = change =E2=80=9Ca SUBSCRIBE request,=E2=80=9D to =E2=80=9Cthe SUBSCRIBE = request,=E2=80=9D


Section 6.5

It's not entirely clear to me that we need = quite this much detail about
discovery proxy operations, = in order to motivate RECONFIRM.

If we're = going to talka bout Apple's dns_sd.h API (which I have somewhat
mixed feelings about to begin with), we should have a = reference for it.

Do you prefer something like

https://opensource.apple.com/source/mDNSResponder/mDNSResponder= -878.70.2/mDNSShared/dns_sd.h.auto.html


or

https://github.com/IETF-Hackathon/mDNSResponder/blob/master/mDN= SResponder/mDNSShared/dns_sd.h



Section 7.1

=   Deployment recommendations on the appropriate key lengths = and cypher
  suites are beyond the scope of = this document.  Please refer to TLS
=   Recommendations [RFC7525] for the best current practices. =  Keep in

Please cite this as BCP = 195.

Ok.


Section 7.4

  servers.  The server may = keep TLS state with Session IDs [RFC8446] or
=   operate in stateless mode by sending a Session Ticket = [RFC5077] to

5077 was made obsolete by = 8446; from the practical side of tings there
is no = wire-visible distinction between stateful session IDs and
stateless session tickets.

Ok. I can change this to:

   TLS = Session Resumption [RFC8446] is permissible on DNS Push = Notification
   servers.  However, = closing the TLS connection terminates the DSO session.



Section 10.2

I = think RFC 7858 needs to be normative.

Likewise, RFC 8310.

Ok.

Thanks for the = detailed review!

Tom


= --Apple-Mail=_EEBE48C4-33D7-44B1-9DC1-679897161490-- From nobody Wed Aug 14 17:50:29 2019 Return-Path: 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 6D363120901; Wed, 14 Aug 2019 17:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 qAPqM7t9lzE1; Wed, 14 Aug 2019 17:50:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354FB120919; Wed, 14 Aug 2019 17:50:23 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7F0oFAb026886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 20:50:18 -0400 Date: Wed, 14 Aug 2019 19:50:14 -0500 From: Benjamin Kaduk To: Tom Pusateri Cc: The IESG , tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org Message-ID: <20190815005014.GE88236@kduck.mit.edu> References: <156527413058.7542.141771034158195549.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [dnssd] Benjamin Kaduk's No Objection on draft-ietf-dnssd-push-24: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 00:50:28 -0000 On Mon, Aug 12, 2019 at 07:32:41PM -0400, Tom Pusateri wrote: > Comments below. > > > On Aug 8, 2019, at 10:22 AM, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dnssd-push-24: 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! > > > > What are the privacy considerations to zone content owners (e.g., > > machine owners listed in a zone) about the availability of near-realtime > > information tracking their changes? > > With the primary case of service discovery, this information is already available today as link-local multicast announcements. And many unicast DNS servers already have policy controls that would apply to subscriptions as well. We’re not really creating any new exposure. It sounds like it, yes, but thanks for checking. > > > > Can we have a discussion of padding policy to attempt to preserve the > > privacy of push transactions? > > Analysis of message size is a component of traffic analysis. I can add a paragraph about this and reference the Padding TLV as discussed in RFC 8490. Thanks! > > > > Section 1.2 > > > > Do we need to give a reference for the BSD Sockets API? (I honestly > > forget what we did for other documents referencing it.) > > RFCs 8547, 8490, 8095, 7663, 7640, & 7242 are the most recent to reference the BSD socket api. Of these, only RFC 8095 reference the POSIX Base Specifications which probably isn’t useful since no one is going to go read the POSIX docs but instead read operating system docs. None of the other RFCs in this list provide a reference. I would like to skip this. Skipping it seems like a good plan; thanks for checking the prior art. > > > > Section 3 > > > > Perhaps we should put quotation marks around statements taken from RFC > > 8490 (so as to avoid the appearance that we are duplicating normative > > requirements made in that document). > > Need more specifics. If referring to: > > Generally, as described in the DNS Stateful Operations specification > [RFC8490], a client must not keep a DSO session to a server open > indefinitely if it has no subscriptions (or other operations) active > on that session. A client MAY close a DSO session immediately it > becomes idle, and then if needed in the future, open a new session > when required. Alternatively, a client MAY speculatively keep an > idle DSO 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]. > > then changing “MAY" to “may" could resolve this issue. I think that was what I was thinking of, yes, and the proposed resolution sounds good. > > > > Section 5 > > > > server in this protocol specification. Additional security measures > > such as client authentication during TLS negotiation MAY also be > > employed to increase the trust relationship between client and > > server. > > > > Do we want to say anything about the validation procedures for that > > client authentication, maybe RFC 6125 with a DNS-ID check, or would that > > be too restrictive? > > This does not include client certificates, DANE, or out of band mechanisms. 6125 is helpful but only describes one approach. I guess it's pretty unclear to me what the normative value of the "MAY" is if this is totally up to deployment preferences (but I definitely support having all of those as options!). So perhaps we could consider an alternate tack, like "In some deployments the trust relationship between client and server might be further strengthened, such as via TLS client authentication, but since the trust relationship is a local deployment matter, the details of such authentication are also a matter for local configuration". (But probably with fewer words, if possible.) > > > > Section 6.1 > > > > In many contexts, the recursive resolver will be able to handle Push > > Notifications for all names that the client may need to follow. Use > > of VPN tunnels and split-view DNS can create some additional > > complexity in the client software here; the techniques to handle VPN > > tunnels and split-view DNS for DNS Push Notifications are the same as > > those already used to handle this for normal DNS queries. > > > > Is there a good reference discussing these techniques? > > I can reference RFC 8499 which defines split DNS. > > > Section 6.2.1 > > > > The MESSAGE ID field MUST be set to a unique value, that the client > > is not using for any other active operation on this DSO session. For > > > > Isn't this already mandated by 8490? > > Are you asking us to change “MUST” to “must”? I haven’t heard it suggested before that you can only use 2119 terms once. It's not a hard rule, but the cost/benefit of having them get out of sync tends to skew towards only using them once. In this case, the reader may want to know whether this is a new requiremnet for push vs. something that they get for free with a stock DSO implementation, for example. > > > > (Hmm, the interaction of TLS early data's replayability and MESSAGE ID > > uniqueness might require some thought. But the MESSAGE ID uniqueness is > > within a DSO session, not global, so that may not make a difference.) > > Yes, early data isn’t a concern because a new DSO session means all new subscriptions and new MESSAGE ID space. > > > > > Section 6.3.1 > > > > The other header fields MUST be set as described in the DSO spec- > > ification [RFC8490]. The DNS OPCODE field contains the OPCODE value > > for DNS Stateful Operations (6). The four count fields MUST be zero, > > and the corresponding four sections MUST be empty (i.e., absent). > > > > We may not need the 2119 terms for the requirements duplicated from > > 8490. > > Are you asking us to change “MUST” to “must” here too? Slightly weaker than asking to change, but the same story, yes. > > > > For collective remove notifications, if CLASS is not 255 (ANY) and > > TYPE is not 255 (ANY) then for the given name this deletes all > > records of the specified type in the specified class. > > > > (et seq) What does it mean to "delete a record", from the recipient's > > point of view? (How does the server communicate that the RRset's > > contents have changed to a completely disjoint value -- delete plus add?) > > To “delete a record” means the record is being removed from the zone. That could be because the service is no longer offered or the host has been decommissioned. In mDNS (RFC 6762), an announcement with TTL 0 is used to signal a delete. This could trigger a PUSH notification deleting the record. A received DNS UPDATE message could also trigger a PUSH notification deleting a record. > > If the name of a DNS service changes then, yes, the old service is deleted and the new service is added (although the delete doesn’t have to come before the add). Okay, thanks for confirming. > > > > a SUBSCRIBE request, subject to the usual established DNS case- > > insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE > > request was not ANY (255) then the TYPE of the record must match the > > TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE > > > > nit: we switch from using the indefinite article to the definite article > > with "SUBSCRIBE request", which is a bit jarring since we don't give a > > great indication of what distinguishes the definite case. > > I will change “a SUBSCRIBE request,” to “the SUBSCRIBE request,” > > > > > Section 6.5 > > > > It's not entirely clear to me that we need quite this much detail about > > discovery proxy operations, in order to motivate RECONFIRM. > > > > If we're going to talka bout Apple's dns_sd.h API (which I have somewhat > > mixed feelings about to begin with), we should have a reference for it. > > Do you prefer something like > > https://opensource.apple.com/source/mDNSResponder/mDNSResponder-878.70.2/mDNSShared/dns_sd.h.auto.html > > > or > > https://github.com/IETF-Hackathon/mDNSResponder/blob/master/mDNSResponder/mDNSShared/dns_sd.h Hmm, not an easy choice, but probably the apple.com one. (Using a specific commit hash rather than the 'master' symbolic ref would make the github one potentially more archival/stable, but in this case I think the authority of Apple is preferred.) > > > > > Section 7.1 > > > > Deployment recommendations on the appropriate key lengths and cypher > > suites are beyond the scope of this document. Please refer to TLS > > Recommendations [RFC7525] for the best current practices. Keep in > > > > Please cite this as BCP 195. > > Ok. > > > > > Section 7.4 > > > > servers. The server may keep TLS state with Session IDs [RFC8446] or > > operate in stateless mode by sending a Session Ticket [RFC5077] to > > > > 5077 was made obsolete by 8446; from the practical side of tings there > > is no wire-visible distinction between stateful session IDs and > > stateless session tickets. > > Ok. I can change this to: > > TLS Session Resumption [RFC8446] is permissible on DNS Push Notification > servers. However, closing the TLS connection terminates the DSO session. Thanks! > > > > > Section 10.2 > > > > I think RFC 7858 needs to be normative. > > > > Likewise, RFC 8310. > > Ok. > > Thanks for the detailed review! You're welcome! -Ben From nobody Fri Aug 23 19:58:52 2019 Return-Path: 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 D3A60120047; Fri, 23 Aug 2019 19:58:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dnssd@ietf.org, dnssd-chairs@ietf.org, evyncke@cisco.com, bs7652@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156661552981.25070.12256219645480508027.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2019 19:58:49 -0700 Archived-At: Subject: [dnssd] dnssd - New Meeting Session Request for IETF 106 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Sat, 24 Aug 2019 02:58:50 -0000 A new meeting session request has just been submitted by Barbara Stark, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Barbara Stark Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: dnsop doh dprive homenet quic tls babel intarea httpbis 6man v6ops Technology Overlap: mls core anima People who must be present: Stephen Farrell Eric Vyncke Barbara Stark David Schinazi Resources Requested: Special Requests: dnssd and homenet would like to do a single joint 2 hour meeting. We'll figure out how to divide the time. --------------------------------------------------------- From nobody Sat Aug 24 12:37:09 2019 Return-Path: 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 2585C120073 for ; Sat, 24 Aug 2019 12:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 MCZlz31lRxi7 for ; Sat, 24 Aug 2019 12:37:06 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C32012006E for ; Sat, 24 Aug 2019 12:37:06 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id k13so14418279qtm.12 for ; Sat, 24 Aug 2019 12:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ZiepYK9A8cyaidC/sWGA+eYjXTpnrbCTFZtHt0NkVh4=; b=cunHBL4HRVImIQLp0MVyi7PupSS4NpbSWKPhyXNw0nQ+tCtriiL2eQWnTIUVa9q4t/ 0+jM+PHNBXRM6u4HbJHgAaZvctLxdrwO13iUlXQQJSfeIZg/2SjliU4UEt0mIQJYBamt tewAD3qardv/5oj/mGiHZcoltWcLKME58vFFmVbcpGUPyUptq10HSdQcURratQ1A1OLK Zx5zHTt9eCE5ci2KrbydIk7/aqOa5cuztwtP+9qS8P2N9OyLlHIUcmRCWSbNglVereyb QLvf8bKcPo9YB/NUkr0Gv5s7R5OAcH4CFm6algiL75NFwNr0TdEPJatkYmZzOC/Fwd3L d3EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=ZiepYK9A8cyaidC/sWGA+eYjXTpnrbCTFZtHt0NkVh4=; b=rwgsohSQT1Y2o0Suks+F+bE2G5114R9kzcYBV2w0StcDk0yePBRtUZoKGt6eMvC6Ar KeL39hY3I1NiAFEETUKpUtgBQE1+kUHikp4O1fw0L2xzV05WZcI2lxhBMpT3f4Ym5DRH E8RzKeTS1ENysWg3I0y1wOOasQOJS+vJgaP6xzx5dhr+Rwf78yV/T2WwphvfWi+nOVnt pXTFcBwBtWPGA0a5DaGDDsETUQVNtZHwZENF+DUxZgRqf1hGQObCEkXMw+V+A5heUvbw NfDdbgkLcV2qSA29rN4wFWu0ryOd5lM2GTO8wmMJLMiPcVwygr/AmHTNcycMM6u9JjNW m5ww== X-Gm-Message-State: APjAAAW+xOEG2gDO9H0GZ8ESLR8Cz2WX8TC5CrQLTY3Ztwry6YLMC1uj 0uF/TytdbKjHCFormeIf6Qa+7OqLqDK9Rw== X-Google-Smtp-Source: APXvYqyXT4XE6jtfsgQdSlbpfZczBkdwOUsjKJ+sCeeQU2xKHLfdX29fgem9qSQvjSgGxq2StCy/hg== X-Received: by 2002:aed:3621:: with SMTP id e30mr10848549qtb.283.1566675425165; Sat, 24 Aug 2019 12:37:05 -0700 (PDT) Received: from [10.0.100.59] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id 18sm3426169qkh.77.2019.08.24.12.37.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Aug 2019 12:37:04 -0700 (PDT) From: Ted Lemon Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) Message-Id: <022060C3-45D1-4D36-8AC9-C582E4C29479@fugue.com> Date: Sat, 24 Aug 2019 15:37:03 -0400 To: DNSSD X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: [dnssd] SRP deletes? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 19:37:08 -0000 I=E2=80=99ve been hacking on an SRP mDNS proxy, and I realized that we = didn=E2=80=99t actually specify a mechanism whereby a service can delete = itself when it goes away. This means that once an advertisement is = present, it will be present until it expires. This isn=E2=80=99t how regular mDNS works: with regular mDNS, if the = service isn=E2=80=99t there anymore, it=E2=80=99s not advertised = anymore, and indeed if there is a clean shutdown, mDNSResponder will = send a =E2=80=9Cgoodbye=E2=80=9D packet to let any consumers of the = service know that it=E2=80=99s not there anymore. I don=E2=80=99t = really know how often it will be the case that there will be a clean = shutdown in an SRP client, but it seems to me that it=E2=80=99s probably = correct to specify this. What do people think about this? Also, at present one of the characteristics of FCFS naming is that KEY = records are kept longer than other records, so that the name can be held = even when the service is not available. So I=E2=80=99m thinking that a = service delete would generally leave the KEY record alone. From nobody Sat Aug 24 16:41:57 2019 Return-Path: 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 1993F1200D6 for ; Sat, 24 Aug 2019 16:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NzKw2sYo9B2E for ; Sat, 24 Aug 2019 16:41:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C98120074 for ; Sat, 24 Aug 2019 16:41:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 27F7738191; Sat, 24 Aug 2019 19:40:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5FA5D14; Sat, 24 Aug 2019 19:41:51 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: DNSSD In-Reply-To: <022060C3-45D1-4D36-8AC9-C582E4C29479@fugue.com> References: <022060C3-45D1-4D36-8AC9-C582E4C29479@fugue.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [dnssd] SRP deletes? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 23:41:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > I=E2=80=99ve been hacking on an SRP mDNS proxy, and I realized that w= e didn=E2=80=99t > actually specify a mechanism whereby a service can delete itself when > it goes away. This means that once an advertisement is present, it > will be present until it expires. If it's not a cool/useful name, then perhaps, who cares? > This isn=E2=80=99t how regular mDNS works: with regular mDNS, if the = service > isn=E2=80=99t there anymore, it=E2=80=99s not advertised anymore, and= indeed if there > is a clean shutdown, mDNSResponder will send a =E2=80=9Cgoodbye=E2=80= =9D packet to let > any consumers of the service know that it=E2=80=99s not there anymore= . I > don=E2=80=99t really know how often it will be the case that there wi= ll be a > clean shutdown in an SRP client, but it seems to me that it=E2=80=99s= probably > correct to specify this. It seems that deleting an entry comes with more security risk that creating them. But, we have DNSSEC signatures, so it shouldn't be much of a problem. > What do people think about this? > Also, at present one of the characteristics of FCFS naming is that KEY > records are kept longer than other records, so that the name can be > held even when the service is not available. So I=E2=80=99m thinkin= g that a > service delete would generally leave the KEY record alone. So, delete removes the name, but not the KEY RR, so the name can be reclaim= ed much easier, and nobody else can take the name until it expires. Are there two forms of delete then? One of which deletes the KEY RR so that it can be claimed by another. Consider replacing the "printer". If not that, then is there a mechanim where the new "printer" can put itself in line to claim "printer" when the old holder expires. Until then, it is printer-02 or some such? The point is to facilitate the user who wants it called "printer", but the old device is not quite gone yet. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1hyz8ACgkQgItw+93Q 3WUR5wf/QpKQt4XMQqB1UX+nudBLkrpKJzcbPqeYdfwYvsiJIw/HsI6Pu0+4Ipkc XYaF0b+jMXUbm8xXCpEqErmz7b76uz3itavf/5S9cNBcfiMmfpMUCxN1dBGmtqju tcnHWwW2TrEniPiEJgXTmuiefAhGf8OM67LfdG71+xozAx7gVjL0Rh8ybkHbEQTx qo0gJXmNLkCQ8XOkdEa5qZzxO06t+VZ6HfHD/t3KYt9p31NnvEi/qDYD2hL7oCyU OJRNBXipZgRfe2LvniYHErdm/zZObOEp054ynpJwFFhpuBSIM47pXK2WfcBHBE23 H8p0W18gdLJYQ3i1WXIxesWn3e5ZfA== =b6kY -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 24 16:59:00 2019 Return-Path: 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 6D707120074 for ; Sat, 24 Aug 2019 16:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 bOsdFJEuO3Gj for ; Sat, 24 Aug 2019 16:58:57 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0B8120025 for ; Sat, 24 Aug 2019 16:58:57 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id l9so14758577qtu.6 for ; Sat, 24 Aug 2019 16:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Js1iRHQfwORGZy1TwXUgo+lZrYlRn4jHeN9h76LG3sU=; b=OETu7nAbf/AK2A7OoQYeW+brI+C/SJqeUSngJoWce2ECCMzEP0ujqFvs8NYj3Kxprj YPz+bPcoOnbBwFZr9WLgcWh3uNlFgn9s+FZTKOLlNAaau28rzGOf5X+Ov8GCVaPTq91W tGlWQcpGF4nbKpnO5hiIj7mmZ5LW7tN1x84cbVyVxv2uYgdcA5cd7lPutCBtfyQTaHY+ i3qAIBB4xOIjvmZd6uPHwlmPHGLdqNRs9W4ccTez4X3a7rbyPu/sLYYJJsx44+E0Fc+U 0VnYr10a2iS4zBJEOsEvdvIMclP4UhWja5HjXKn6a/qDhbMKtLmPgg0XnzBrobvEudf5 +i7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Js1iRHQfwORGZy1TwXUgo+lZrYlRn4jHeN9h76LG3sU=; b=GHupot6Uat+2WlHJrdj2afC6Wq9Qqq4xDkvTnwKskUK138Gw/SzN70oAUDjdENZ9i0 GGzDBBjfqWDcrTV3CBw5s6AuAt1XbYaqeGhJ6ubN6RpqaZgoR4sM4FauuIrJUaRhfABm P5iokP63LIZj4OTw1MY52xBohYuz46ytHJGTK9OeH6r4KPeFUF5Mj9CSEdN8xiyzdw4x h0fc3FvPGB5lqNBgbeh3EOLa/VZ0J1IWCd9kI452OdJ2yE56bFXWS2wN6pytSBtNu5G1 TESMrNT0PnD+gIDKQ93mNf35/Wtmgue3f1dtvSq1wSO4seCXkHFPSGsoBjZHv+unvmbz PxRw== X-Gm-Message-State: APjAAAV2PgWffuwb3Efilb6GTPQ4uIWN/NTWdkpia7UFVVZXCMnwTaOr SbMkFq5q46GAMESNezYsK0FkeRCO15A= X-Google-Smtp-Source: APXvYqzX4pTpiMgBoPYrgOmkn6qtmsspHKWqDA2YKHViVggzWpb8nhLVNplBtLoDj/D4ui90ILvzPQ== X-Received: by 2002:ac8:128b:: with SMTP id y11mr11649556qti.229.1566691136129; Sat, 24 Aug 2019 16:58:56 -0700 (PDT) Received: from ?IPv6:2600:380:5963:13a:cc46:955f:e649:f66a? ([2600:380:5963:13a:cc46:955f:e649:f66a]) by smtp.gmail.com with ESMTPSA id c74sm3819357qke.128.2019.08.24.16.58.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Aug 2019 16:58:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sat, 24 Aug 2019 19:58:54 -0400 Message-Id: <5B1EC8BE-7492-4D3D-AF58-142378E63AAE@fugue.com> References: <13320.1566690111@localhost> Cc: DNSSD In-Reply-To: <13320.1566690111@localhost> To: Michael Richardson X-Mailer: iPhone Mail (17A574) Archived-At: Subject: Re: [dnssd] SRP deletes? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 23:58:59 -0000 I think there=E2=80=99s no need for a delete key operation. The main point i= s that we don=E2=80=99t want services to show up in dialogs if they aren=E2=80= =99t present.=20 Sent from my iPhone > On Aug 24, 2019, at 19:41, Michael Richardson wrot= e: >=20 > =EF=BB=BF > Ted Lemon wrote: >> I=E2=80=99ve been hacking on an SRP mDNS proxy, and I realized that we di= dn=E2=80=99t >> actually specify a mechanism whereby a service can delete itself when >> it goes away. This means that once an advertisement is present, it >> will be present until it expires. >=20 > If it's not a cool/useful name, then perhaps, who cares? >=20 >> This isn=E2=80=99t how regular mDNS works: with regular mDNS, if the serv= ice >> isn=E2=80=99t there anymore, it=E2=80=99s not advertised anymore, and ind= eed if there >> is a clean shutdown, mDNSResponder will send a =E2=80=9Cgoodbye=E2=80=9D p= acket to let >> any consumers of the service know that it=E2=80=99s not there anymore. I= >> don=E2=80=99t really know how often it will be the case that there will b= e a >> clean shutdown in an SRP client, but it seems to me that it=E2=80=99s pro= bably >> correct to specify this. >=20 > It seems that deleting an entry comes with more security risk that creatin= g > them. But, we have DNSSEC signatures, so it shouldn't be much of a proble= m. >=20 >> What do people think about this? >=20 >> Also, at present one of the characteristics of FCFS naming is that KEY >> records are kept longer than other records, so that the name can be >> held even when the service is not available. So I=E2=80=99m thinking th= at a >> service delete would generally leave the KEY record alone. >=20 > So, delete removes the name, but not the KEY RR, so the name can be reclai= med > much easier, and nobody else can take the name until it expires. >=20 > Are there two forms of delete then? One of which deletes the KEY RR so th= at > it can be claimed by another. Consider replacing the "printer". >=20 > If not that, then is there a mechanim where the new "printer" can put itse= lf > in line to claim "printer" when the old holder expires. Until then, it is > printer-02 or some such? The point is to facilitate the user who wants it= > called "printer", but the old device is not quite gone yet. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Sun Aug 25 17:46:20 2019 Return-Path: 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 84F25120020 for ; Sun, 25 Aug 2019 17:46:18 -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 QZxaOUvF5MMa for ; Sun, 25 Aug 2019 17:46:16 -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 89E4812001E for ; Sun, 25 Aug 2019 17:46:16 -0700 (PDT) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 1796533332; Sun, 25 Aug 2019 20:46:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1566780375; bh=vbHIc/uTIdJsU3S9jOzSthsVO7BvRnCwFDcG0Maab60=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ckWutN4DbNuqSvc5WeG3BFK+q0OVbFGb2LSOtAiq8KKzIkIw9+gEEIvUIjgVVW9cS +MYYep2toc/Mc26qw4O7sX70oTEUIZEtaqoy5ClZRdw52RP+LdxTvGmq1C6Uh8ItKU unclFOJwXKsviw1WZ3BPan5b3BRVGBHPNFDmv0hvc/COCQELskUY+v0K5SWhmKKb4R fWGukbxK21b8e6bzzJgG+BfaBmH2q5Sye5bFJkHRyChtBcooAxOXkb/f2D23sSc+xT 4He/no7Jiq+gcrT6F4TJTa8JJVhHLhUrCExbO+NznjoGi9FW/LLNXHdXJ6G1nFnoBH Uq0Sucapr4Z4Q== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) From: Tom Pusateri In-Reply-To: <5B1EC8BE-7492-4D3D-AF58-142378E63AAE@fugue.com> Date: Sun, 25 Aug 2019 20:46:14 -0400 Cc: Michael Richardson , DNSSD Content-Transfer-Encoding: quoted-printable Message-Id: <03C30161-2520-4A6F-A52F-18034D2141A0@bangj.com> References: <13320.1566690111@localhost> <5B1EC8BE-7492-4D3D-AF58-142378E63AAE@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: Re: [dnssd] SRP deletes? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 00:46:19 -0000 Eventually, the records (whether directly or through an SRP Proxy) get = into an authoritative DNS server. If you want special behavior in = response to an RFC 2136 Update at the authoritative, then you=E2=80=99ll = need to specify that. Otherwise, the KEY can be deleted along with any = of the other records. Tom > On Aug 24, 2019, at 7:58 PM, Ted Lemon wrote: >=20 > I think there=E2=80=99s no need for a delete key operation. The main = point is that we don=E2=80=99t want services to show up in dialogs if = they aren=E2=80=99t present.=20 >=20 > Sent from my iPhone >=20 >> On Aug 24, 2019, at 19:41, Michael Richardson = wrote: >>=20 >> =EF=BB=BF >> Ted Lemon wrote: >>> I=E2=80=99ve been hacking on an SRP mDNS proxy, and I realized that = we didn=E2=80=99t >>> actually specify a mechanism whereby a service can delete itself = when >>> it goes away. This means that once an advertisement is present, it >>> will be present until it expires. >>=20 >> If it's not a cool/useful name, then perhaps, who cares? >>=20 >>> This isn=E2=80=99t how regular mDNS works: with regular mDNS, if the = service >>> isn=E2=80=99t there anymore, it=E2=80=99s not advertised anymore, = and indeed if there >>> is a clean shutdown, mDNSResponder will send a =E2=80=9Cgoodbye=E2=80=9D= packet to let >>> any consumers of the service know that it=E2=80=99s not there = anymore. I >>> don=E2=80=99t really know how often it will be the case that there = will be a >>> clean shutdown in an SRP client, but it seems to me that it=E2=80=99s = probably >>> correct to specify this. >>=20 >> It seems that deleting an entry comes with more security risk that = creating >> them. But, we have DNSSEC signatures, so it shouldn't be much of a = problem. >>=20 >>> What do people think about this? >>=20 >>> Also, at present one of the characteristics of FCFS naming is that = KEY >>> records are kept longer than other records, so that the name can be >>> held even when the service is not available. So I=E2=80=99m = thinking that a >>> service delete would generally leave the KEY record alone. >>=20 >> So, delete removes the name, but not the KEY RR, so the name can be = reclaimed >> much easier, and nobody else can take the name until it expires. >>=20 >> Are there two forms of delete then? One of which deletes the KEY RR = so that >> it can be claimed by another. Consider replacing the "printer". >>=20 >> If not that, then is there a mechanim where the new "printer" can put = itself >> in line to claim "printer" when the old holder expires. Until then, = it is >> printer-02 or some such? The point is to facilitate the user who = wants it >> called "printer", but the old device is not quite gone yet. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Sun Aug 25 18:04:34 2019 Return-Path: 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 ED6CC1200A1 for ; Sun, 25 Aug 2019 18:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 QfOW8kJgGSrJ for ; Sun, 25 Aug 2019 18:04:31 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05A112001E for ; Sun, 25 Aug 2019 18:04:30 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id t12so16444806qtp.9 for ; Sun, 25 Aug 2019 18:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=26pE6rCdJvWdMKnsrIzpaRhKUN54Smg6F0BW+K7I7e8=; b=zl8QYfnY7KNrMxyS64nBYdLSRW6gv3+ErDtkr47XsxNMgsZDDDiClZV0Bcw51mv+4O iDeaQQPM9W6oyMLPsCKji85KSZfhMeGd3YAjhp0wgvuNdOHDDS3wUUNP61+iRlpM+X4i LFh6lLFGGVK7GNGKst4dQVURhJgbCFhAF7JV2tgjHUk/TYCzyphEy0xT11xlx5PmPl6x dmsWvqtnc0KiFDNY9qzXIVlTnybBfgSfIbYTH6PorEsqeBYPSEzg3PsUDoUEaSK5WOuc rq8/RafLf6zWWeBw1+EHQMTUMI+AcdVnfk9UpBTjdIL8s4dfGEIB/V354JinRr3nSXdL pPNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=26pE6rCdJvWdMKnsrIzpaRhKUN54Smg6F0BW+K7I7e8=; b=TUFD5kihoc20FYNbIB5CX8ua63XP8wetB6nUiOhgqy2ZswGG4oguoAshRuu82LLSx6 QJfWqAhM0p+RXVd7aEMeTLWjOPmu7NBExZ6N94nHMt6XqtvXdmfUMlnxFY/fwwvDWQ4k oRlMd2En6LMdQ1naGytT0ivF36tgwu7U2OqQNBruKyF6cckEh3zJjdzTHhdH4DOVeX8V Q7oBCj39Ve7fWMB/RSYX1zJTMdkItsdVJybHNQ2lUJPEDEVG/qRNs/h79MRsg1g/4VuA W2Eur/jeiuxa0HHiWqisNFo0fy71cmfPRjdJm3NJDyZqZ/oFAQAlEv2wNNlIpfvONtzf +ohA== X-Gm-Message-State: APjAAAVU0x9zKhbwVfXl5Xcj/E0HjuuWrQyFy+DrBm/TSt/neFqah6kx NCrbDVioG2w/NcUEOxwj8sWvhXbupawuUHM7 X-Google-Smtp-Source: APXvYqy4GsakpaPPOlMByQ0KFKV0z/9IeP8ftf+tZ0P1WvpXOdPB+1aa/TN7S0iaSmQ1JTpDosfOBQ== X-Received: by 2002:ac8:7b46:: with SMTP id m6mr15192072qtu.389.1566781469764; Sun, 25 Aug 2019 18:04:29 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id g14sm5452362qki.14.2019.08.25.18.04.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Aug 2019 18:04:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sun, 25 Aug 2019 21:04:27 -0400 Message-Id: <58E1C523-170A-486A-BC12-FC3DBB6E9306@fugue.com> References: <03C30161-2520-4A6F-A52F-18034D2141A0@bangj.com> Cc: Michael Richardson , DNSSD In-Reply-To: <03C30161-2520-4A6F-A52F-18034D2141A0@bangj.com> To: Tom Pusateri X-Mailer: iPhone Mail (17A574) Archived-At: Subject: Re: [dnssd] SRP deletes? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 01:04:33 -0000 On Aug 25, 2019, at 20:46, Tom Pusateri wrote: >=20 > =EF=BB=BFEventually, the records (whether directly or through an SRP Proxy= ) get into an authoritative DNS server. If you want special behavior in resp= onse to an RFC 2136 Update at the authoritative, then you=E2=80=99ll need to= specify that. Otherwise, the KEY can be deleted along with any of the other= records=20 Updates only ever get processed on the primary authoritative server. Updates= can delete some or all records. So we are free to choose the behavior we wa= nt. The question is, what behavior do we want? :)=