From nobody Sat Jul 1 14:13:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F247129461; Sat, 1 Jul 2017 14:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0NCEFKOgbumA; Sat, 1 Jul 2017 14:13:09 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8B9126BFD; Sat, 1 Jul 2017 14:13:08 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v61KvH6N033745; Sat, 1 Jul 2017 22:57:17 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707012057.v61KvH6N033745@givry.fdupont.fr> From: Francis Dupont To: tjw ietf cc: dnsop , "dnsop-chairs@ietf.org" In-reply-to: Your message of Fri, 30 Jun 2017 13:24:10 +0200. Date: Sat, 01 Jul 2017 22:57:17 +0200 Archived-At: Subject: Re: [DNSOP] IETF 99: Call for agenda items, and draft cutoff reminder X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 21:13:10 -0000 As you should know now there are some security problems in different TSIG implementations. IMHO the source of the problem is in TSIG RFCs so it is likely we'll have to discuss about publishing one or two Erratas. So even with a formal request for time in the agenda I believe we should consider to keep 5/10 mn for at least a presentation about this. Regards Francis.Dupont@fdupont.fr PS: I expect more of the work to be done in this list (the problem impact is clearly operational). From nobody Sat Jul 1 14:40:44 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7F9126DED; Sat, 1 Jul 2017 14:40:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149894524329.526.18431408698564464455@ietfa.amsl.com> Date: Sat, 01 Jul 2017 14:40:43 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 21:40:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : DNS Terminology Authors : Paul Hoffman Andrew Sullivan Kazunori Fujiwara Filename : draft-ietf-dnsop-terminology-bis-06.txt Pages : 37 Date : 2017-07-01 Abstract: The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308 and RFC 3758. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-06 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 Sun Jul 2 14:33:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E2B129601 for ; Sun, 2 Jul 2017 14:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 1EEEk69Hptqv for ; Sun, 2 Jul 2017 14:33:35 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBE21275AB for ; Sun, 2 Jul 2017 14:33:35 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id E154012C168F; Sun, 2 Jul 2017 17:33:34 -0400 (EDT) Date: Sun, 2 Jul 2017 17:33:34 -0400 From: Robert Edmonds To: dnsop@ietf.org Message-ID: <20170702213334.dm5olfbvkpbxdq3m@mycre.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [DNSOP] [internet-drafts@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 21:33:37 -0000 Hi, I've written a proposal for adding capability signaling to the DNS protocol that may be of interest to this group. The git repository is here: https://github.com/edmonds/draft-edmonds-dnsop-capabilities. ----- Forwarded message from internet-drafts@ietf.org ----- Date: Sun, 02 Jul 2017 13:42:39 -0700 From: internet-drafts@ietf.org To: Robert Edmonds Subject: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt A new version of I-D, draft-edmonds-dnsop-capabilities-00.txt has been successfully submitted by Robert Edmonds and posted to the IETF repository. Name: draft-edmonds-dnsop-capabilities Revision: 00 Title: Signaling DNS Capabilities Document date: 2017-07-02 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-edmonds-dnsop-capabilities-00.txt Status: https://datatracker.ietf.org/doc/draft-edmonds-dnsop-capabilities/ Htmlized: https://tools.ietf.org/html/draft-edmonds-dnsop-capabilities-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-edmonds-dnsop-capabilities-00 Abstract: This document defines an Extension Mechanisms for DNS (EDNS0) option that allows DNS clients and servers to signal support for DNS protocol capabilities. Clients and servers that support this option can take advantage of new DNS protocol features when completing a transaction, and by caching the set of capabilities advertised by a DNS server, a DNS client can utilize any mutually supported DNS protocol capability in subsequent queries. 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. The IETF Secretariat ----- End forwarded message ----- -- Robert Edmonds From nobody Sun Jul 2 20:54:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FC51294C8 for ; Sun, 2 Jul 2017 20:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fhCkCn0EEzjM for ; Sun, 2 Jul 2017 20:54:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 3EBAB12708C for ; Sun, 2 Jul 2017 20:54:03 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id EA9B124AE09; Mon, 3 Jul 2017 03:53:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AD97C160041; Mon, 3 Jul 2017 03:53:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9B0D1160051; Mon, 3 Jul 2017 03:53:58 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xnYCkee60GoZ; Mon, 3 Jul 2017 03:53:58 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 56AF3160041; Mon, 3 Jul 2017 03:53:58 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DA71A7D6C89D; Mon, 3 Jul 2017 13:53:55 +1000 (AEST) To: Robert Edmonds Cc: dnsop@ietf.org From: Mark Andrews References: <20170702213334.dm5olfbvkpbxdq3m@mycre.ws> In-reply-to: Your message of "Sun, 02 Jul 2017 17:33:34 -0400." <20170702213334.dm5olfbvkpbxdq3m@mycre.ws> Date: Mon, 03 Jul 2017 13:53:55 +1000 Message-Id: <20170703035355.DA71A7D6C89D@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] [internet-drafts@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 03:54:05 -0000 There are three things that made it hard to deploy new features. 1) Firewall vendor shipping firewalls with ridiculously strict rules with zero evidence that they are needed. 2) Misimplementation of STD 13 and RFC 2671 by nameserver vendors. 3) Unknown EDNS option behaviour was not well defined by RFC 2671, this is addressed in RFC 6891. 1 and 2 made it impossible to do a clean update from RFC 2671 to RFC 6891 which tightened the unknown EDNS option behaviour. Proper implementation of RFC 2671 would have allowed the EDNS version 1 to be used to signal that RFC 6891 unknown option behaviour is required. I don't see how adding a capabilities option will help here when the primary problem is bad code. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jul 3 01:48:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474FF129B94 for ; Mon, 3 Jul 2017 01:48:22 -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, URIBL_BLOCKED=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 xWii1WndbD1k for ; Mon, 3 Jul 2017 01:48:20 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8297B127444 for ; Mon, 3 Jul 2017 01:48:20 -0700 (PDT) Received: from [10.242.2.15] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id BB09E1BCE3; Mon, 3 Jul 2017 10:48:17 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Mon, 03 Jul 2017 10:48:58 +0200 Message-ID: <2D02BDF5-FE9B-4E77-A561-5E0988AEBCF9@powerdns.com> In-Reply-To: <149894524329.526.18431408698564464455@ietfa.amsl.com> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 08:48:22 -0000 Hello, On 1 Jul 2017, at 23:40, internet-drafts@ietf.org wrote: > Abstract: > The DNS is defined in literally dozens of different RFCs. The > terminology used by implementers and developers of DNS protocols, and > by operators of DNS systems, has sometimes changed in the decades > since the DNS was first defined. This document gives current > definitions for many of the terms used in the DNS in a single > document. > > This document will be the successor to RFC 7719, and thus will > obsolete RFC 7719. It will also update RFC 2308 and RFC 3758. s/3758/3757/ Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Jul 3 02:08:35 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CD612F092; Mon, 3 Jul 2017 02:08:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149907291397.4998.8059630450980375262@ietfa.amsl.com> Date: Mon, 03 Jul 2017 02:08:34 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:08:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : C-DNS: A DNS Packet Capture Format Authors : John Dickinson Jim Hague Sara Dickinson Terry Manderson John Bond Filename : draft-ietf-dnsop-dns-capture-format-03.txt Pages : 49 Date : 2017-07-03 Abstract: This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic monitoring applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-03 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-03 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 Mon Jul 3 02:11:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68657131480 for ; Mon, 3 Jul 2017 02:11:35 -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_PASS=-0.001, URIBL_BLOCKED=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 CHu6ynHP27gK for ; Mon, 3 Jul 2017 02:11:33 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C44712EC15 for ; Mon, 3 Jul 2017 02:11:29 -0700 (PDT) Received: from [2001:b98:204:102:fff1::f145] (port=63819 helo=[192.168.64.1]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dRxOA-0005u0-LY for dnsop@ietf.org; Mon, 03 Jul 2017 10:11:27 +0100 From: "John Dickinson" To: dnsop@ietf.org Date: Mon, 03 Jul 2017 10:11:24 +0100 Message-ID: <555FCD98-C509-4D9A-ADDB-9621623E109E@sinodun.com> In-Reply-To: <149907291397.4998.8059630450980375262@ietfa.amsl.com> References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_8B81B260-C908-4C11-BCD9-7CD715EE616C_="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.6r5347) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:11:35 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_8B81B260-C908-4C11-BCD9-7CD715EE616C_= Content-Type: text/plain On 3 Jul 2017, at 10:08, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : C-DNS: A DNS Packet Capture Format > Authors : John Dickinson > Jim Hague > Sara Dickinson > Terry Manderson > John Bond > Filename : draft-ietf-dnsop-dns-capture-format-03.txt > Pages : 49 > Date : 2017-07-03 > Hi, This new version just adds an Implementation Status as defined in RFC7942. regards John > Abstract: > This document describes a data representation for collections of DNS > messages. The format is designed for efficient storage and > transmission of large packet captures of DNS traffic; it attempts to > minimize the size of such packet capture files but retain the full > DNS message contents along with the most useful transport metadata. > It is intended to assist with the development of DNS traffic > monitoring applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-03 > > > 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/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K. --=_MailMate_8B81B260-C908-4C11-BCD9-7CD715EE616C_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZWgo9AAoJEC3GFEI9J+IsINAP/AyivmAWzqRIUaWwJX/AZL2/ e6T8daI8VoK2Rvl2CIFxKP3uyXIFx5aexaUjcs5OZCMBqj5pDRc89oR1UAt+MYVc J8GfjTcWzJMALtf15XgB2W2rkZA/omeflV6XCV1n+c1zVsFPljQLkgcpjvRnix2s 0DMEqU5h1ZNwrS/u3l5UE2RWX9r945ka1dAhz3KkD7ql9VJyqaxWU40oPn/tu57S u4dkIjr9Wakv1z9ML8W6t+f+7QdwfNbTSLgY8/jY7CD892krr04NqIgtusKiVqmz z0sZfo8g30JVFQP1Ez2kiLNQlLqAGMgIlix3wYVdK3uHX9rJ8Qb/qC7ygJko9595 bktwUGA+bYLDm5YJjiUVEwbosSayMffcedDG8s+npuqnrqWLUuh2xvNwo50LFvm+ cpWELwWUXwvKXi41r8xBx4pHNkZFIa934xeItTVgkH/vWdZbEDbqIYkZYsI9lX2E lQul23D6SJv4mnxg3FIyH7nOCMfQbb51/diM6ppMuF4DJVKFouBI6RkIQyleu/J7 fKd+XMHBigpgQr8/P1RTAtzu+am5oqMMuQLrSZrIzDEG7yr4LSXRJmHBTcjEO7MM MVo9qoNCbwnYNhzwWk5jXoBYiZfwIhkxMLaSpr3YXw70tQtu1RBJLr7aLNemO/23 l4DhxI2rCfsljZMwyfE1 =J20O -----END PGP SIGNATURE----- --=_MailMate_8B81B260-C908-4C11-BCD9-7CD715EE616C_=-- From nobody Mon Jul 3 02:22:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF2131545 for ; Mon, 3 Jul 2017 02:22:28 -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, URIBL_BLOCKED=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 JRhIbwRlFpUz for ; Mon, 3 Jul 2017 02:22:26 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69485131546 for ; Mon, 3 Jul 2017 02:22:26 -0700 (PDT) Received: from [10.242.2.15] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 26C5C1BCE3; Mon, 3 Jul 2017 11:22:21 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Mon, 03 Jul 2017 11:23:01 +0200 Message-ID: <8FFF06E9-59D8-4033-B914-43E9C1DE16E8@powerdns.com> In-Reply-To: References: <20170407181139.GB66383@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:22:29 -0000 Hello Jinmei, apologies for the delay. Due to the length of your email I flagged it for later reading and then I got distracted by other things. On 13 Apr 2017, at 22:27, 神明達哉 wrote: > Overall I agree this is worth trying to achieve. There is a clear > need for the ability of defining an alias at a zone apex, and it will > be nicer if we provide a standard-compliant and interoperable way for > that. I also agree that a long-term goal (hope) should deploy it in > the resolver side even if it will take quite long (if not fail), so > that authoritative server implementations can be kept lightweight and > simple. I do not envision a future in which all resolvers support it, so I fear auths that want it will need to do it, forever. > I have one high-level concern in terms of the merit of providing a > standard/interoperable version of 'alias'. As already noted in the > draft there are currently several proprietary mechanisms of 'alias', > mainly to allow an alias at a zone apex. In order for the standard > version to be successful, it will have to be compatible with these > existing ones as much as possible and as long as it doesn't break > other DNS standards. I’d like to agree, but if the existing implementations are not all the same, this is unfeasible. > In that sense I see some disparity with the > ALIAS record of Amazon Route53, one of the earliest (and probably > largest) players of the idea: > - Supporting other types of records than AAAA and A > - Allowing different target names for different types As I replied to John Levine, we do not feel this is prudent at this stage. Operational experience with ANAME, once standardised and deployed, would be a good basis for another draft that is more extensive, like having a type bitmap - this would support both these features. > I don't know how critical these are for existing R53 ALIAS users, but > depending on that ANAME may not be able to be successful in practice. Outside of R53, most implementations appear to be similar. That’s a pretty decent installed base that we can try to convert! > I also wonder whether it's okay to allow 'AAAA or A' and ANAME to > coexist for the same owner name. Shouldn't it be prohibited similar > to that CNAME and other types can't coexist? If A and/or AAAA coexist with ANAME, no ANAME expansion happens, as this is deemed to have already happened during provisioning or slaving etc. > Some specific comments on the draft text follow: > > - Section 3 > > If the original query is for type A, and an RRset of type A exists > at > the final ANAME , then that A RRset (with changed > to > match that of the ANAME RR), MUST be appended to the answer section > after the ANAME RRset. > > What if the target name of ANAME does not exist (NXDOMAIN)? > Returning NXDOMAIN is quite likely to be a bad choice, since the > owner name of the query actually does exist. It will be certainly > problematic if it's a zone apex. So should it be translated into > NOERROR+NODATA? Or something else? Also, if the zone is signed, > what kind of proof should be returned? The draft does not usefully cover this right now. Indeed returning NXDOMAIN would be wrong, so a NODATA-ish response would be right. The proof would consist of a signed NSEC(3) with a type bitmap containing ANAME, and if at the apex, also SOA, NS, perhaps MX, etc. A/AAAA would not be in the type bitmap. > - Section 3.1 > > Address records cached locally MUST have a limited TTL. The > initial > TTL for locally-cached address records MUST be set to the lesser of > the ANAME TTL and the TTL of the address records retrieved from the > ANAME . The local TTL MUST count down, just as it would in > a > conventional resolver cache.[...] > > Should the local TTL count down, even if the initial value is from > the ANAME TTL? I suspect that's not the intent, and if I'm correct > I think the current text is confusing and should clarify it. Noted. > - Section 3.2 > > If the zone is configured with an A or AAAA RRset at the same DNS > node as ANAME, then the ANAME is considered to have been > pre-expanded > for zone transfer purposes. When a zone is being transferred to a > secondary server, if any address record already exists at the same > node as an ANAME RR, then the ANAME RR MUST NOT be further expanded > by the authoritative server. > > (I have a more fundamental concern about the coexistence as stated > above, but ignoring it in this context) I'm afraid this text talks > about something not explained before this point or not even > explained clearly anywhere in the draft. I guess the "pre-expand" > means the following behavior described in section 3.3, but not > necessarily with RRSIGs: > > Implementers MAY allow address records associated with the ANAME to > be populated and signed by the primary server, then sent along with > their RRSIGs to secondaries via zone transfer. > > If my understanding is correct, the concept of population/pre-expand > behavior for zone transfer should be explicitly introduced before > the discussion in Section 3.2. Also noted. Thank you for your extensive review! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Jul 3 04:38:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CD61315DB for ; Mon, 3 Jul 2017 04:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cephRw0nEfxl for ; Mon, 3 Jul 2017 04:38:18 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 DD2AA1315D7 for ; Mon, 3 Jul 2017 04:38:17 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 3277A24AE09 for ; Mon, 3 Jul 2017 11:36:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DCABD160044; Mon, 3 Jul 2017 11:36:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BB0F9160051; Mon, 3 Jul 2017 11:36:57 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XEt5GU7pYaz6; Mon, 3 Jul 2017 11:36:57 +0000 (UTC) Received: from stephen-morriss-macbook-pro-2.local (222.66.20.149.in-addr.arpa [149.20.66.222]) by zmx1.isc.org (Postfix) with ESMTPSA id 0C6E2160044; Mon, 3 Jul 2017 11:36:56 +0000 (UTC) References: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> From: Stephen Morris To: dnsop@ietf.org X-Forwarded-Message-Id: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> Message-ID: <185af195-dac6-1438-916f-c9b6d73df644@isc.org> Date: Mon, 3 Jul 2017 12:36:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 11:38:20 -0000 Hi We have submitted a new draft which attempts to formalize an idea that has been kicking around for a couple of years, namely to use serial number information from DNS responses to determine whether stale records in a cache can be refreshed without the need for an upstream query. Please send comments and feedback to the list. Stephen -------- Forwarded Message -------- Subject: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt Date: Fri, 30 Jun 2017 13:41:45 -0700 From: internet-drafts@ietf.org To: Mukund Sivaraman , Shane Kerr , Stephen Morris A new version of I-D, draft-muks-dnsop-dns-opportunistic-refresh-00.txt has been successfully submitted by Mukund Sivaraman and posted to the IETF repository. Name: draft-muks-dnsop-dns-opportunistic-refresh Revision: 00 Title: DNS Opportunistic Refresh for Resolvers Document date: 2017-06-29 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-opportunistic-refresh-00.txt Status: https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-opportunistic-refresh/ Htmlized: https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-opportunistic-refresh-00 Abstract: This document describes a mechanism whereby a DNS resolver can opportunistically refresh the TTLs of cached records of a zone using serial number information carried in responses from the zone's nameservers. As well as improving resolver response time by reducing the need to make upstream queries, the mechanism can also reduce the workload of authoritative servers. 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. The IETF Secretariat From nobody Mon Jul 3 04:39:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001281315DB for ; Mon, 3 Jul 2017 04:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, 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=gmail.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 O-5jtnEKpTlv for ; Mon, 3 Jul 2017 04:39:19 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 901061315D7 for ; Mon, 3 Jul 2017 04:39:19 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p21so143544217qke.3 for ; Mon, 03 Jul 2017 04:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jC7qqFStYw4uILEaueLrdglbIz012VSGclVGsMJumn4=; b=U5PTYM4Yr65/zm20e+TYiPP/x3q9hh9+/BqAz8RGlnuPN/rBUlShlWCfuDYipiigfH SQvMU3ijwb3IFJRIrN2spJSpk3q8PRmNOfCsbJiR/r2LP+7hnrqxyRwVFrnkA/CukGUs PNks6gnu3Q1ehsLA6fe7kquNInfeWdiYlLRuvdPk5XNcaM3JMLjhIsfVwU+5QZDGf4vR ipCHlLvVatZCmZo6Dwk7WlzebdYAF3PtpbnT7RfzvxnHiLt7lPVXAZ80du03GPBV+LCk NilT/V6miIW21zNCjkpVmLwcWHkNnJhW8vGFq6rbi+C7Y7iyQ/aUjnET+pAaSmuVlUk2 xW9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jC7qqFStYw4uILEaueLrdglbIz012VSGclVGsMJumn4=; b=MBzNlDtCdJwxQFJeu8faFor3yKaJIztJnYLmqIqOqxFIYyogbY8ZdFUYL+fyuxrVhb 8oGAJIkovTH9fjFX0UTGNFrOAcmZGnyMUN+K9KxrzVz/+t7baANZbjhlUNxBDGolK9FA MSNoaF3xe1M0RFZCynx1QUFZsMQkFncI/Ml2bZONijL6BN7KWN1+SkR7iAstSeqrqDso 7BO0Nj5mlDZOvrfXH4TDUlRYE43DqzEsn4VJL1Dz8NZ0Z/kk1TBkCC94VL7nf64LUfew AMy0nJUZkZB0LnujEfTx0iDjmzf5JWNDeZ7QDOGisC/i9TkO8A4Eg2NC6sMlVj+7Jt2m xwUw== X-Gm-Message-State: AKS2vOwyNQQq/nFfAEFfjwelGWIwbpN/mBsSbA6JlqT5ggghOPHuYCyk f0CMJ0G7qmc0eUDRWaPjO1TYOCojjbqa X-Received: by 10.55.113.197 with SMTP id m188mr38403519qkc.227.1499081958618; Mon, 03 Jul 2017 04:39:18 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> In-Reply-To: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> From: Lanlan Pan Date: Mon, 03 Jul 2017 11:39:08 +0000 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="94eb2c0b93e4a1fd6a0553683737" Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 11:39:22 -0000 --94eb2c0b93e4a1fd6a0553683737 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, We have submitted a new draft as draft-pan-dnsop-swild-rr-type-00. Nowadays wildcard domain is globally used, especially on CDN, P2P, advertise, anti-virus, DNSBLs service. Wildcard domain is simple configured on Authoritative Nameserver, but Intermediate Nameservers have to cache various domains (for example, xxx.github.io, yyy.github.io, ... ) of the same wildcard domain configuration. This document specifies a new SWILD RR type for Intermediate Nameservers to cache subdomain wildcard record, in order to reduce the cache size and optimize the wildcard domain cache miss. Your comments are appreciated. Thanks Lanlan & Yu ---------- Forwarded message --------- From: Date: 2017=E5=B9=B47=E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D= =887:15 Subject: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt To: Pan Lanlan , Yu Fu A new version of I-D, draft-pan-dnsop-swild-rr-type-00.txt has been successfully submitted by Lanlan Pan and posted to the IETF repository. Name: draft-pan-dnsop-swild-rr-type Revision: 00 Title: SWILD RR Type (Wildcard on Intermediate Nameservers) Document date: 2017-07-03 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-pan-dnsop-swild-rr-type-00.txt Status: https://datatracker.ietf.org/doc/draft-pan-dnsop-swild-rr-type/ Htmlized: https://tools.ietf.org/html/draft-pan-dnsop-swild-rr-type-0= 0 Htmlized: https://datatracker.ietf.org/doc/html/draft-pan-dnsop-swild-rr-type-00 Abstract: This document describes a new SWILD RR type for Intermediate Nameservers to cache subdomain wildcard record, in order to reduce the cache size and optimize the wildcard domain cache miss. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c0b93e4a1fd6a0553683737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

We have submitted a new draft as draft-pan-= dnsop-swild-rr-type-00.

Nowadays wildcard domain is globally used, e= specially on CDN, P2P, advertise, anti-virus, DNSBLs service. Wildcard doma= in is simple configured on Authoritative Nameserver, but Intermediate Names= ervers have to cache various domains (for example, xxx.github.io, yyy.github.io<= /a>, ... ) of the same wildcard domain configuration.

This document = specifies a new SWILD RR type for Intermediate Nameservers to cache subdoma= in wildcard record, in order to reduce the cache size and optimize the wild= card domain cache miss.

Your comments are appreciated.

Thanks=
Lanlan & Yu

----= ------ Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: 2017=E5=B9=B47= =E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=887:15
Subject: Ne= w Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
To: Pan = Lanlan <abbypan@gmail.com>, = Yu Fu <fuyu@cnnic.cn>
<= br>

A new version of I-D, draft-pan-dnsop-swild-rr-type-00.txt
has been successfully submitted by Lanlan Pan and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-pan-dnsop-swild-rr-type=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SWILD RR Type (Wildcard on Interme= diate Nameservers)
Document date:=C2=A0 2017-07-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-pan-dnsop-swi= ld-rr-type-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-pan-dnsop-swild-rr-type/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-pan-dnsop-swild-rr-type-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-pan-dnsop-swild-rr-type-0= 0


Abstract:
=C2=A0 =C2=A0This document describes a new SWILD RR type for Intermediate =C2=A0 =C2=A0Nameservers to cache subdomain wildcard record, in order to re= duce
=C2=A0 =C2=A0the cache size and optimize the wildcard domain cache miss.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD= =98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--94eb2c0b93e4a1fd6a0553683737-- From nobody Mon Jul 3 05:18:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FDB126C3D for ; Mon, 3 Jul 2017 05:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 sMTtQzNxnYNQ for ; Mon, 3 Jul 2017 05:18:38 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 C69901200F3 for ; Mon, 3 Jul 2017 05:18:37 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50767) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dS0JI-000nP0-eC (Exim 4.89) (return-path ); Mon, 03 Jul 2017 13:18:36 +0100 Date: Mon, 3 Jul 2017 13:18:36 +0100 From: Tony Finch To: Lanlan Pan cc: dnsop In-Reply-To: Message-ID: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:18:40 -0000 Lanlan Pan wrote: > > This document specifies a new SWILD RR type for Intermediate Nameservers to > cache subdomain wildcard record, in order to reduce the cache size and > optimize the wildcard domain cache miss. Isn't this functionality already provided by https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fitzroy: Variable 4 for a time in north, otherwise northeasterly becoming cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate, occasionally poor. From nobody Mon Jul 3 05:34:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E0C12762F for ; Mon, 3 Jul 2017 05:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=sidn.nl 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 M9O3AxCaj7I4 for ; Mon, 3 Jul 2017 05:34:36 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245B712F287 for ; Mon, 3 Jul 2017 05:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:user-agent:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:content-id:content-transfer-encoding:mime-version; bh=RPNfU1hEU/6fdkMGKCi2o/PglYroMDimaFfzPnsJmjc=; b=wKzVlg6TATQ95n2OW4lctPvETXzmI4UIJVrNJurmepQ3vm4NS9OFJMbh73QmyTWB9KAZa6BfptbSomaPJUmV9878+nxAAH+VUh+tebwBFPGsqJ5H1qejnBN0ZfNdEdi39UZrMj5GCEfsbTUfgN6NO3NGDHoZHkBdP2kf8bjdovY4MTY47vyNHyAFYFnw+VQNGi3u6vWrMUcdjkRwMeQKDns790o9FLQkueLcnecsn0TBZNmEOvZjiJze6RisocsNxxvmtzEMAcuB1AcKAnyGinKFh9Dj7PCg8WWuBTf1mD2JCPvmn4pl5xa7r/AWZkTWbTT0dlsAOEVOjMhMG+2j0g== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id v63CYXX8027232-v63CYXXA027232 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Mon, 3 Jul 2017 14:34:33 +0200 Received: from ka-mbx01.SIDN.local (192.168.2.177) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 3 Jul 2017 14:34:33 +0200 Received: from ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d]) by ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d%13]) with mapi id 15.00.1130.005; Mon, 3 Jul 2017 14:34:32 +0200 From: Marc Groeneweg To: "dnsop@ietf.org" Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt Thread-Index: AQHS89v9ufJ+oMoxvUCIaywQGhdnn6JBr3AAgABaSoA= Date: Mon, 3 Jul 2017 12:34:32 +0000 Message-ID: References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <555FCD98-C509-4D9A-ADDB-9621623E109E@sinodun.com> In-Reply-To: <555FCD98-C509-4D9A-ADDB-9621623E109E@sinodun.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.23.0.170610 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.7.63] Content-Type: text/plain; charset="utf-8" Content-ID: <35ACE865F3882C4DB3641D09D9CBF2E6@sidn.nl> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:34:39 -0000 SGkgYWxsLA0KDQpXaGF04oCZcyB0aGUgc3RhdHVzIG9mIHRoZSBJUFIgZmlsZWQgYnkgUmF5IEJl bGxpcz8gSXMgdGhpcyBhIHZpYWJsZSBJUFIgY2xhaW1zPyBSYXkgc3RhdGVzIGhpbXNlbGYgdGhh dCB0aGUgY2xhaW0gbWF5IGhhdmUgaW1wbGljYXRpb25zLCBidXQgaXMgbm90IHN1cmUuIEFuZCBp biBteSBvcGluaW9uLCBubyBvbmUgYXQgTm9taW5ldCBoYXMgY2xhaW1lZCB0aGlzIElQUi4gQ2Fu IHdlIGRyb3AgdGhpcyBjbGFpbSwgYW5kIHByb2NlZWQgdGhpcyBkcmFmdCB0byBzdGFuZGFyZD8N Cg0KQmVzdCByZWdhcmRzLA0KTWFyYyBHcm9lbmV3ZWcNCg0KT24gMDMvMDcvMjAxNywgMTE6MTEs ICJETlNPUCBvbiBiZWhhbGYgb2YgSm9obiBEaWNraW5zb24iIDxkbnNvcC1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBqYWRAc2lub2R1bi5jb20+IHdyb3RlOg0KDQogICAgT24gMyBKdWwg MjAxNywgYXQgMTA6MDgsIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCiAgICANCiAg ICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu dGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIERvbWFpbiBOYW1lIFN5c3RlbSBPcGVyYXRpb25zIG9mIHRoZSBJRVRGLg0KICAg ID4NCiAgICA+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogQy1ETlM6IEEgRE5TIFBhY2tldCBD YXB0dXJlIEZvcm1hdA0KICAgID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBKb2huIERpY2tp bnNvbg0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICBKaW0gSGFndWUNCiAgICA+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2FyYSBEaWNraW5zb24NCiAgICA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgVGVycnkgTWFuZGVyc29uDQogICAgPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIEpvaG4gQm9uZA0KICAgID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZG5z b3AtZG5zLWNhcHR1cmUtZm9ybWF0LTAzLnR4dA0KICAgID4gCVBhZ2VzICAgICAgICAgICA6IDQ5 DQogICAgPiAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNy0wMw0KICAgID4gDQoNCg== From nobody Mon Jul 3 05:52:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703421315FD for ; Mon, 3 Jul 2017 05:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 SSiQUqnG6s35 for ; Mon, 3 Jul 2017 05:52:29 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DD6128D3E for ; Mon, 3 Jul 2017 05:52:29 -0700 (PDT) Received: from [46.227.151.81] (port=54922 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dS0q1-0007qN-Tt (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 03 Jul 2017 13:52:25 +0100 To: dnsop@ietf.org References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <555FCD98-C509-4D9A-ADDB-9621623E109E@sinodun.com> From: Ray Bellis Message-ID: <1634b6a7-80b3-d752-2a2c-7f0adcb02f8d@bellis.me.uk> Date: Mon, 3 Jul 2017 13:52:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:52:30 -0000 On 03/07/2017 13:34, Marc Groeneweg wrote: > What’s the status of the IPR filed by Ray Bellis? Is this a viable > IPR claims? Ray states himself that the claim may have implications, > but is not sure. And in my opinion, no one at Nominet has claimed > this IPR. Can we drop this claim, and proceed this draft to > standard? I didn't make a "claim" - I made a third party disclosure on the belief and understanding that implementations of this draft *might* be affected by this patent application should it be granted. Whilst I am one of the two authors of the patent application in question, I am not the assignee and therefore cannot make any binding statements (nor claims) about them. I did notify Nominet's legal counsel of the IPR declaration but heard nothing from them. kind regards, Ray From nobody Mon Jul 3 06:25:45 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EE2129B34; Mon, 3 Jul 2017 06:25:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149908832951.4117.17798099796292917923@ietfa.amsl.com> Date: Mon, 03 Jul 2017 06:25:29 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 13:25:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : DNS catalog zones Authors : Mukund Sivaraman Stephen Morris Ray Bellis Witold Krecicki Filename : draft-muks-dnsop-dns-catalog-zones-03.txt Pages : 18 Date : 2017-07-03 Abstract: This document describes a method for automatic zone catalog provisioning and synchronization among DNS primary and secondary nameservers by storing and transferring the catalogs as regular DNS zones. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-muks-dnsop-dns-catalog-zones-03 https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-catalog-zones-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dns-catalog-zones-03 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 Mon Jul 3 06:31:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B98127735 for ; Mon, 3 Jul 2017 06:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fBykXfdlXlUJ for ; Mon, 3 Jul 2017 06:31:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 6D75A1201FA for ; Mon, 3 Jul 2017 06:31:49 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 04829349314 for ; Mon, 3 Jul 2017 13:31:30 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EA713160044 for ; Mon, 3 Jul 2017 13:31:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BBDF8160069 for ; Mon, 3 Jul 2017 13:31:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 64DKL2hIJ1GO for ; Mon, 3 Jul 2017 13:31:29 +0000 (UTC) Received: from rays-mbp.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 40179160044 for ; Mon, 3 Jul 2017 13:31:29 +0000 (UTC) References: <149908772964.4070.2471656184158486415.idtracker@ietfa.amsl.com> To: dnsop From: Ray Bellis X-Forwarded-Message-Id: <149908772964.4070.2471656184158486415.idtracker@ietfa.amsl.com> Message-ID: <4889c9c7-cda4-9685-ed88-7ae9143b4348@isc.org> Date: Mon, 3 Jul 2017 14:31:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149908772964.4070.2471656184158486415.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 13:31:51 -0000 Following feedback and discussion on this draft I've updated it to use a META RR rather than an EDNS option. This simplifies questions about adding an OPT RR if one wasn't already in the proxied packet. It also avoids (some) issues with TSIG / SIG(0). This RR now contains the entire 5-tuple of src/dest address and port (and protocol) and not just the source IP address - the rationale for this is explained in the draft. As I won't be present for DNSOP in Prague this is due to be presented by Peter van Dijk, one of my two new co-authors. Ray -------- Forwarded Message -------- A new version of I-D, draft-bellis-dnsop-xpf-02.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. Name: draft-bellis-dnsop-xpf Revision: 02 Title: DNS X-Proxied-For Document date: 2017-07-03 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-02.txt Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-xpf-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-xpf-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-xpf-02 Abstract: It is becoming more commonplace to install front end proxy devices in front of DNS servers to provide (for example) load balancing or to perform transport layer conversions. This document defines a meta resource record that allows a DNS server to receive information about the client's original transport protocol parameters when supplied by trusted proxies. From nobody Mon Jul 3 08:56:48 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCDB1293E1; Mon, 3 Jul 2017 08:56:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909740588.22718.8995346041745751260@ietfa.amsl.com> Date: Mon, 03 Jul 2017 08:56:45 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-wkumari-dnsop-multiple-responses-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:56:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Returning extra answers in DNS responses. Authors : Warren Kumari Zhiwei Yan Wes Hardaker Filename : draft-wkumari-dnsop-multiple-responses-04.txt Pages : 9 Date : 2017-07-03 Abstract: This document (re)introduces the ability to provide multiple answers in a DNS response. This is especially useful as, in many cases, the entity making the request has no a prori knowledge of what other questions it will need to ask. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-04 https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-multiple-responses-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-multiple-responses-04 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 Mon Jul 3 09:49:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CF812F3D5 for ; Mon, 3 Jul 2017 09:49:26 -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, URIBL_BLOCKED=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 mc20iw03ZJzd for ; Mon, 3 Jul 2017 09:49:25 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 5205D129B77 for ; Mon, 3 Jul 2017 09:49:25 -0700 (PDT) Received: from [169.254.117.148] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v63GmfPq045563 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 3 Jul 2017 09:48:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.117.148] From: "Paul Hoffman" To: dnsop@ietf.org Date: Mon, 03 Jul 2017 09:49:23 -0700 Message-ID: <751C4965-0C2A-4BE8-ADA3-545564ACA35E@vpnc.org> In-Reply-To: <20170703035355.DA71A7D6C89D@rock.dv.isc.org> References: <20170702213334.dm5olfbvkpbxdq3m@mycre.ws> <20170703035355.DA71A7D6C89D@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] [internet-drafts@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:49:27 -0000 On 2 Jul 2017, at 20:53, Mark Andrews wrote: > There are three things that made it hard to deploy new features. > > 1) Firewall vendor shipping firewalls with ridiculously strict rules > with zero evidence that they are needed. > > 2) Misimplementation of STD 13 and RFC 2671 by nameserver vendors. > > 3) Unknown EDNS option behaviour was not well defined by RFC 2671, > this is addressed in RFC 6891. > > 1 and 2 made it impossible to do a clean update from RFC 2671 to > RFC 6891 which tightened the unknown EDNS option behaviour. Proper > implementation of RFC 2671 would have allowed the EDNS version 1 > to be used to signal that RFC 6891 unknown option behaviour is > required. > > I don't see how adding a capabilities option will help here when > the primary problem is bad code. I do. The fact that some middleboxes and servers have bad code doesn't mean that all of them do. --Paul Hoffman From nobody Mon Jul 3 09:50:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E773131464 for ; Mon, 3 Jul 2017 09:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 I91jX15lu1sw for ; Mon, 3 Jul 2017 09:50:52 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736AC131443 for ; Mon, 3 Jul 2017 09:50:52 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id E334E12C10FC; Mon, 3 Jul 2017 12:50:51 -0400 (EDT) Date: Mon, 3 Jul 2017 12:50:51 -0400 From: Robert Edmonds To: dnsop@ietf.org Message-ID: <20170703165051.eifyac7xlgk7b6tb@mycre.ws> References: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> <185af195-dac6-1438-916f-c9b6d73df644@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <185af195-dac6-1438-916f-c9b6d73df644@isc.org> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:50:54 -0000 Stephen Morris wrote: > Hi > > We have submitted a new draft which attempts to formalize an idea that > has been kicking around for a couple of years, namely to use serial > number information from DNS responses to determine whether stale records > in a cache can be refreshed without the need for an upstream query. > > Please send comments and feedback to the list. > > Stephen Hi, I noticed this draft defines an EDNS0 option that communicates a single bit of information: FLAGS Flags field. Bit 7 of this field is the request/acknowledge flag. This bit MUST be clear in requests from the resolver to the authoritative server and MUST be set in responses from the authoritative server to the resolver. By flipping the bit in a response, answers from misbehaving authoritiative servers that just copy unknown EDNS0 options from query to response are not mistakenly treated as being from servers that understand opportunistic DNS refresh. Just an observation: this bit indicates client-side support in queries and server-side support in responses. This is the exact use case for the "DNS Features" capability in draft-edmonds-dnsop-capabilities [0]. And the capabilities option already detects and discards echoing, so no need to flip the bit between query and response. [0] https://tools.ietf.org/html/draft-edmonds-dnsop-capabilities-00#section-4.1 -- Robert Edmonds From nobody Mon Jul 3 09:55:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B207126D05 for ; Mon, 3 Jul 2017 09:55:22 -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] 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 sr2J4odXuiMf for ; Mon, 3 Jul 2017 09:55:21 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 258BB129B0D for ; Mon, 3 Jul 2017 09:55:21 -0700 (PDT) Received: from [169.254.117.148] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v63GsaqA045648 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Jul 2017 09:54:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.117.148] From: "Paul Hoffman" To: "Marc Groeneweg" Cc: "dnsop@ietf.org" Date: Mon, 03 Jul 2017 09:55:18 -0700 Message-ID: In-Reply-To: References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <555FCD98-C509-4D9A-ADDB-9621623E109E@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:55:22 -0000 On 3 Jul 2017, at 5:34, Marc Groeneweg wrote: > What’s the status of the IPR filed by Ray Bellis? Is this a viable > IPR claims? The status is that he filed it. It doesn't matter whether there are viable claims in it. > Ray states himself that the claim may have implications, but is not > sure. Correct. > And in my opinion, no one at Nominet has claimed this IPR. That opinion matches a search of the IPR database for draft-ietf-dnsop-dns-capture-format. > Can we drop this claim, and proceed this draft to standard? There is no need to "drop this claim" in order to move the draft forward. Plenty of documents in the IETF have claims like this associated with them. --Paul Hoffman From nobody Mon Jul 3 10:47:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E7613169F for ; Mon, 3 Jul 2017 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HtLmnfpcx8wL for ; Mon, 3 Jul 2017 10:47:28 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 5524D13147B for ; Mon, 3 Jul 2017 10:47:28 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id A294D3493A2 for ; Mon, 3 Jul 2017 17:47:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 65E87160044 for ; Mon, 3 Jul 2017 17:47:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 39735160071 for ; Mon, 3 Jul 2017 17:47:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z99FYjW1vGGV for ; Mon, 3 Jul 2017 17:47:25 +0000 (UTC) Received: from rays-mbp.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 97ADC160044 for ; Mon, 3 Jul 2017 17:47:24 +0000 (UTC) References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> To: dnsop From: Ray Bellis X-Forwarded-Message-Id: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 3 Jul 2017 18:47:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:47:30 -0000 This is just a "keep alive" so as to keep this draft in consideration as one of the multiple solutions in this problem space while DNSOP decides whether this is a problem worth solving. I still think it's the most elegant of those proposed ;-) Ray -------- Forwarded Message -------- A new version of I-D, draft-bellis-dnsext-multi-qtypes-04.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. Name: draft-bellis-dnsext-multi-qtypes Revision: 04 Title: DNS Multiple QTYPEs Document date: 2017-07-03 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsext-multi-qtypes-04.txt Status: https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ Htmlized: https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-bellis-dnsext-multi-qtypes-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsext-multi-qtypes-04 Abstract: This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. From nobody Mon Jul 3 10:57:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0AA1296CF for ; Mon, 3 Jul 2017 10:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZXAfLyCmdNFY for ; Mon, 3 Jul 2017 10:57:05 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26BF120227 for ; Mon, 3 Jul 2017 10:57:05 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id 4C7B812C10FC; Mon, 3 Jul 2017 13:57:05 -0400 (EDT) Date: Mon, 3 Jul 2017 13:57:05 -0400 From: Robert Edmonds To: Mark Andrews Cc: dnsop@ietf.org Message-ID: <20170703175705.cysvvn54xgq52kp7@mycre.ws> References: <20170702213334.dm5olfbvkpbxdq3m@mycre.ws> <20170703035355.DA71A7D6C89D@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170703035355.DA71A7D6C89D@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] [internet-drafts@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:57:07 -0000 Mark Andrews wrote: > There are three things that made it hard to deploy new features. > > 1) Firewall vendor shipping firewalls with ridiculously strict rules > with zero evidence that they are needed. > > 2) Misimplementation of STD 13 and RFC 2671 by nameserver vendors. > > 3) Unknown EDNS option behaviour was not well defined by RFC 2671, > this is addressed in RFC 6891. > > 1 and 2 made it impossible to do a clean update from RFC 2671 to > RFC 6891 which tightened the unknown EDNS option behaviour. Proper > implementation of RFC 2671 would have allowed the EDNS version 1 > to be used to signal that RFC 6891 unknown option behaviour is > required. I'm more that willing to strip out any opinionated text in the draft about what makes it hard to deploy new DNS features. I agree that there is a lot of bad code out there, but my primary use case is for greenfield deployments where both client and server side have new code, and there is a need to detect the other side's capabilities. If you have old or bad code running in the client, server, or middlebox, you just don't get to use the new features. > I don't see how adding a capabilities option will help here when > the primary problem is bad code. There are cases where all you need is a feature flag, and in some cases, the ability to remember an advertised feature for subsequent queries. Currently there are 16 reserved bits between the DNS and EDNS headers that require standards action to use. The small number of bits available and the difficulty required to obtain one (the last allocation was over 10 years ago) means that an EDNS0 option is a more likely path for a feature flag, but that path wastes a minimum of 5 octets. There's a limited amount of space available in a UDP DNS query packet, maybe around ~200 octets for a query with a maximum length QNAME and a plausible set of EDNS0 options. The "DNS Features" capability in my proposal provides space for 256 feature bits at a cost of up to 32 octets. If we make that space a FCFS registry (and provide a handful of "Reserved for Local/Experimental Use" bits) it becomes easier to experiment with new features (using a new bit in an existing EDNS0 option is easier than implementing an entirely new EDNS0 option). -- Robert Edmonds From nobody Mon Jul 3 11:17:02 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95966131687; Mon, 3 Jul 2017 11:16:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910581457.22758.9362742606445936639@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:16:54 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-wkumari-dnsop-multiple-responses-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:16:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Returning extra answers in DNS responses. Authors : Warren Kumari Zhiwei Yan Wes Hardaker David C Lawrence Filename : draft-wkumari-dnsop-multiple-responses-05.txt Pages : 9 Date : 2017-07-03 Abstract: This document (re)introduces the ability to provide multiple answers in a DNS response. This is especially useful as, in many cases, the entity making the request has no a prori knowledge of what other questions it will need to ask. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05 https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-multiple-responses-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-multiple-responses-05 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 Mon Jul 3 11:56:22 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4935131718; Mon, 3 Jul 2017 11:56:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910817990.22766.8962927264092833527@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:56:19 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:56:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Special-Use Domain Names Problem Statement Authors : Ted Lemon Ralph Droms Warren Kumari Filename : draft-ietf-dnsop-sutld-ps-07.txt Pages : 29 Date : 2017-07-03 Abstract: The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-07 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-07 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 Mon Jul 3 14:14:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7229F12EC35 for ; Mon, 3 Jul 2017 14:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 9L8sff2zoM_y for ; Mon, 3 Jul 2017 14:14:00 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 8F87C12EC01 for ; Mon, 3 Jul 2017 14:14:00 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id 191so101328469vko.2 for ; Mon, 03 Jul 2017 14:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=0zU62tE4zlq6N5aCr/wQOYzCUnUltCd7Vg6z4La+w5k=; b=uvkIOODumUX2210FA5rQpEUpV9zWnYcxItLh6gNRNnsZ2UVod5XWmhktyTUVioUvlE OZnxQUyv+LI6yn2UwUwrGXgdtXrDBjbMsMVlfjnN78t1H5nr5PJAYiYzqfJ319015vdd q+6kETYfK/u6G6cwcuPvNtSxfMvUzPu+QeUCvZc98/F29MR985S3vyzOc+epq3hb+p66 iZqyP8LaXppOkfW4JzBNE/CvLAWdD2lYeSDuCYkgTfuO09AqdZio37YRD+7/elWQCE6/ peHm3HhKEwXiPCQ0sEy1VA/E+SayCImXPR75ONGH2tc4KhP4P2Dxk7MahB2oVnWmHWTh 2mlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=0zU62tE4zlq6N5aCr/wQOYzCUnUltCd7Vg6z4La+w5k=; b=ojhYABfiJED4QDhaRXCUasIguaOBNVIMqY/1xBM5Fe3277Hi35IuESoBhF+zVMO9jJ +nAts4WKybUO/wiY3bFb7oyHo/SxCaibN5m6zw4EVIJDgCyaBFaD7Jkv/6MXXjJElJaY kVg+MZIO2wxwAUtyd/Cw8NVsqnRoqTNXmyYLJsrrOA93XhhsxhR2RipNFo0jZz+uHX1f 7SAOYrC7g35H812BUfw6MK7KlsLXgQKpCiWnO7wc481Vv2OqsLTJqYWwbELzWQIc4hck 8McVf9z0E6eC8H2V9i3HxOloCIPy+7NdGMdPhUR8LFckyLmxcvuh9pzeK9AGTfM1nwi5 +8Bg== X-Gm-Message-State: AKS2vOyGZpkTXSJFaHQcY5vCPjG7GCprGyI+RlV/S4LoEbXexlADDFUz sPvFx5piTLlwCJ3F/Ag89GpUN+fhw8Zy2527JQ== X-Received: by 10.31.65.87 with SMTP id o84mr20109731vka.7.1499116439368; Mon, 03 Jul 2017 14:13:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.165 with HTTP; Mon, 3 Jul 2017 14:13:19 -0700 (PDT) From: Warren Kumari Date: Mon, 3 Jul 2017 17:13:19 -0400 Message-ID: To: dnsop@ietf.org Cc: IETF Discuss Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:14:02 -0000 Hi all, The Special-Use Domain Names Problem Statement document unsurprisingly contains a list of problems. This was an unordered list of 21 problems, including descriptions and sub-bullets. While trying to write another draft referring to specific problems it became clear that it would be much better to have this as a *numbered* list, so that one can refer to specific problems and say thing like "This helps address problem #17" instead of "This helps address the problem in the list which begins with the text "foo bar baz"... I have checked with my co-authors, the DNSOP chairs, IESG and responsible AD, and have updated the document changing the list from unordered to numbered (and adding "This is not an ordered list, it is numbered merely to facilitate referencing specific problems:"). The consensus was that this is a purely editorial change, but please scream if you disagree -- the document is on Thursday's telechat, and Benoit is the responsible AD. W On Mon, Jul 3, 2017 at 2:56 PM, wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Special-Use Domain Names Problem Statement > Authors : Ted Lemon > Ralph Droms > Warren Kumari > Filename : draft-ietf-dnsop-sutld-ps-07.txt > Pages : 29 > Date : 2017-07-03 > > Abstract: > The Special-Use Domain Names IANA registry policy defined in RFC 6761 > has been shown through experience to present unanticipated > challenges. This memo presents a list, intended to be comprehensive, > of the problems that have been identified. In addition it reviews > the history of Domain Names and summarizes current IETF publications > and some publications from other organizations relating to Special- > Use Domain Names. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-07 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-07 > > > 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/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Jul 3 15:04:16 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E5D12F28B; Mon, 3 Jul 2017 15:04:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911945436.16104.4945055646551352620.idtracker@ietfa.amsl.com> Date: Mon, 03 Jul 2017 15:04:14 -0700 Archived-At: Subject: [DNSOP] Ben Campbell's Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:04:14 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dnsop-sutld-ps-07: 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-dnsop-sutld-ps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Is there something to be gained by going out on the "believed to be complete" limb? From nobody Mon Jul 3 15:05:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE5129B26 for ; Mon, 3 Jul 2017 15:05:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 wuMiukVvlHj8 for ; Mon, 3 Jul 2017 15:05:22 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 CACB912F4B2 for ; Mon, 3 Jul 2017 15:05:20 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id i2so153103538qta.3 for ; Mon, 03 Jul 2017 15:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fm9/AIxEcWEhJPJ7uOVAD0iDi6CSsz7nLFAiyPUjQ34=; b=yP3fW4uDbSewMIaN5oia/V+v4/ubE56dIeIJu/QlddrO4UA7g2DL4crficLnv7A4C9 rgEYuObVkIwSbGiB6M7P0t89chwYeeJfTFhM1SFilSfUomkE8Gu9u2wBU2NsYg7sWprK Bzzyb51B6XzpjbPaaEan8fXlFnEbB9CeV18BVlivkRC3n0ZyKYzpLO9QutVQXO2o+gb+ U9BsjZLoVHBEXMpxfh5chfoQv/UN38boLSYT2qtO9fosTeVU30DgF3t59KVv50G40QcB 5G8dmPWheEA//8sE1FFUQzFBUlz3+Eoe0LaAsAZgrxoGGzdh6nFqo4QhGpwVtl3QTN8g qm0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fm9/AIxEcWEhJPJ7uOVAD0iDi6CSsz7nLFAiyPUjQ34=; b=mpDFKMnIZ55EgE2r5CADaMP+ZVvZmO2oIoNKxfnWCP/WO7ohaoPQmQeRNHEJoLtTAI KjK4J8FerydGnP9aUzaSmXoGhX8bhFsa1AMbLzM76AnXfJK9Yx2CafBG+gX+TqtZQ/Ja rqWil7azKg7GYU4StH/UAs0d4FgUX+c/Bn+TDnc9PH26aXguwuUKwwLCadFwXnY/We4b uHKf8DXgpfH850gc59eWoDsHcdcFpsQriiTKyhP2/Naz9FmNJN3Cz/PK8lokKdi76mY9 hBHGnK0QiJ9Chog2lX4+qaLtYNoqEuDL6scRYD4m9UiWRrjJkF/OGyKIiiw+3rF2SoYT X95Q== X-Gm-Message-State: AKS2vOwJuJ1AXoYYdDBPZsHeqPz2SF6GPUmNd/tC8Y2tmzMkF4P98qgN p7eLa0MUU2V663Ul X-Received: by 10.200.40.73 with SMTP id 9mr46020163qtr.37.1499119519967; Mon, 03 Jul 2017 15:05:19 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n69sm12598667qke.68.2017.07.03.15.05.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 15:05:19 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F2E937BE-B68E-4D96-9342-DFD366F0D9F7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 18:05:18 -0400 In-Reply-To: <149911945436.16104.4945055646551352620.idtracker@ietfa.amsl.com> Cc: The IESG , "dnsop@ietf.org WG" , draft-ietf-dnsop-sutld-ps@ietf.org, dnsop-chairs@ietf.org, suzworldwide@gmail.com To: Ben Campbell References: <149911945436.16104.4945055646551352620.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Ben Campbell's Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:05:23 -0000 --Apple-Mail=_F2E937BE-B68E-4D96-9342-DFD366F0D9F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2017, at 6:04 PM, Ben Campbell wrote: > Is there something to be gained by going out on the "believed to be = complete" limb? The idea was to dare people to contradict the statement. Seems to have = worked... :) --Apple-Mail=_F2E937BE-B68E-4D96-9342-DFD366F0D9F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 3, 2017, at 6:04 PM, Ben Campbell <ben@nostrum.com> = wrote:
Is there something = to be gained by going out on the "believed to be complete" = limb?

The idea was to dare people to contradict the = statement.   Seems to have worked... :)

= --Apple-Mail=_F2E937BE-B68E-4D96-9342-DFD366F0D9F7-- From nobody Mon Jul 3 15:10:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB1E131677; Mon, 3 Jul 2017 15:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 2UeU0jvAOnfw; Mon, 3 Jul 2017 15:10:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BC5E913162A; Mon, 3 Jul 2017 15:10:19 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v63MAGBG042116 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 3 Jul 2017 17:10:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Mon, 3 Jul 2017 17:10:16 -0500 Cc: The IESG , "dnsop@ietf.org WG" , draft-ietf-dnsop-sutld-ps@ietf.org, dnsop-chairs@ietf.org, suzworldwide@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <149911945436.16104.4945055646551352620.idtracker@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Ben Campbell's Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:10:27 -0000 > On Jul 3, 2017, at 5:05 PM, Ted Lemon wrote: >=20 > On Jul 3, 2017, at 6:04 PM, Ben Campbell wrote: >> Is there something to be gained by going out on the "believed to be = complete" limb? >=20 > The idea was to dare people to contradict the statement. Seems to = have worked... :) >=20 Okay. It seemed like tempting fate, but if that was the intent=E2=80=A6 = :-)= From nobody Mon Jul 3 15:18:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848EB131659 for ; Mon, 3 Jul 2017 15:18:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 tS0YyvWeZqWc for ; Mon, 3 Jul 2017 15:18:48 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 BF6401316A5 for ; Mon, 3 Jul 2017 15:18:43 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id b40so44809702qtb.2 for ; Mon, 03 Jul 2017 15:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vHWBUGe3EhmmjBs7NM00brHDmCKqrXunPxbNgacAvzE=; b=lUJxDvxaFwZThjnSn/4Z2Rufs2olapf7ro1SbPlQvibE7Ncp2n1l/dQukRAOKv7KGk AbqTA3h717UfO1bqB2+8Yh57dYrQAObgiyI2USbyGV5NFMjPorApk35PmkPGhLZrU4UZ sPalrLx5CCPvIBGPylt31irRMYwdaifmMQUjIhv4jOfwMSxVS0ryN9vgf1Kr7UzbOFle MPOA+kl93kuIM6w76hqwpHhU3YBNQPspjzuhBRTdLcld4IUCW1wFqbUnlocMIkz4xHa/ QEjfUt+VmZ6F7cBfmSBtqrQno2UxNYcDbMR4lBd+T4ctqK9bQXgA4n22h88kky/HgXBf Ep2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vHWBUGe3EhmmjBs7NM00brHDmCKqrXunPxbNgacAvzE=; b=bf2AGriHkXXQPYDQONY0PSsqKdAI9lgeq6ZVo7ehTIn19v7km5YCqSRI9pC4CEI6/m JOyqfCKR5QnCyyQa912IvSGWKCu2rdOeEVxP2HAKNYG/G/LnAyNzDVGh749T9hzjj1on KeoKditK+bxFwImaa0M+jj0WmPCPBYussm5egeGS5duRYuul1xuJy5dP7wCIbcVeYjK+ 7DBEp82vK2iZeDhibX0QJfs1QE873fkXUilw5jpICNRDySuxHhr7vhXawjXw38viaYaN w3ONj1nzswE9FdnZxGV9hIVKHu0NoaWYKYyIPboZGY/3w4Ajk4Ss2vmKZ0fNSTSSw+Jn +kJg== X-Gm-Message-State: AKS2vOyQMJ1kVl/PPW+87W2g15AairJSV8J+ILFf2DQwVAI3uPb6/knn s3FVGLoCno4PfU2V X-Received: by 10.237.46.99 with SMTP id j90mr27761982qtd.155.1499120322891; Mon, 03 Jul 2017 15:18:42 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id w43sm14172766qtc.48.2017.07.03.15.18.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 15:18:42 -0700 (PDT) From: Ted Lemon Message-Id: <5E879743-EB1D-4FA9-B749-AF62339C3B28@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2F51864A-876E-4155-83B9-C6CCEE143C2C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 18:18:41 -0400 In-Reply-To: Cc: The IESG , "dnsop@ietf.org WG" , draft-ietf-dnsop-sutld-ps@ietf.org, dnsop-chairs@ietf.org, suzworldwide@gmail.com To: Ben Campbell References: <149911945436.16104.4945055646551352620.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Ben Campbell's Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:18:49 -0000 --Apple-Mail=_2F51864A-876E-4155-83B9-C6CCEE143C2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 3, 2017, at 6:10 PM, Ben Campbell wrote: > Okay. It seemed like tempting fate, but if that was the intent=E2=80=A6 = :-) We wanted for the statement to be true more than for no further comments = to arrive. :) --Apple-Mail=_2F51864A-876E-4155-83B9-C6CCEE143C2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 3, 2017, at 6:10 PM, Ben Campbell <ben@nostrum.com> = wrote:
Okay. It seemed = like tempting fate, but if that was the intent=E2=80=A6 = :-)

We = wanted for the statement to be true more than for no further comments to = arrive.   :)

= --Apple-Mail=_2F51864A-876E-4155-83B9-C6CCEE143C2C-- From nobody Mon Jul 3 16:22:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173471317BF for ; Mon, 3 Jul 2017 16:22:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 Thg24hDErl6m for ; Mon, 3 Jul 2017 16:22:41 -0700 (PDT) Received: from mail-ua0-x248.google.com (mail-ua0-x248.google.com [IPv6:2607:f8b0:400c:c08::248]) (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 1E6A61317B2 for ; Mon, 3 Jul 2017 16:22:36 -0700 (PDT) Received: by mail-ua0-x248.google.com with SMTP id j53so77215789uaa.2 for ; Mon, 03 Jul 2017 16:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0B2zkxjxvfobK/XfBhGR4Qcj4Jg7qscXF8mXglUKcx0=; b=H+IQq4ujTnWbnC6R88PASySf3F9oLPB/G2VGmfPnuM96DbSAZvi+QlXm3nlGMqeQn+ j/a4vD1N5CTA8ty3irwpDTmvm0l5bbNRTR11ASHkbRqidOCX4GAo6P4kxepRwZn8hu0M KkaHTKnFwGO58ksF5Hh9boeD+qEA1gFSgW2DQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0B2zkxjxvfobK/XfBhGR4Qcj4Jg7qscXF8mXglUKcx0=; b=XIbV0RTJEwmPE/Q8AwAuvI+29a23vuN9hkFts3gO350PkbhvcHsa08pKKwXFJDVlO4 a7pcPAJJH0D/p0VcvGI+DhpQPOdtw7W+Dkne83XAUl/2BWH40MHnttyUUHv0RktOfSeB Ls4SAEhe1Pc8fibPx1+EujCA5ZSCNlhly9U5ObLqwCXCradSfAlmjsKN4LlwlGp09lEg EkmHNS9yPjuTspIk/XBr9+u96a0+rP5SoeDWiKcwbZTvCvAZtmC6V8y8Q+iKUcKbWrYu 5benZF1YKBcFOM+GqpJ4MX/A9OtoZ4am/2+vbD+vCwCwqW3pYZAmrOZQfuN6wh2B87HY wC+Q== X-Gm-Message-State: AKS2vOzxoXLEWEnqASFzcDdJLNQiXbe+FeruYW9LVsPu0Bk2/VqBS4V2 KJKL7h2BeMQU3XnG9wN2TgjgMeg9/AWP X-Received: by 10.159.59.18 with SMTP id i18mr20289617uah.62.1499124155163; Mon, 03 Jul 2017 16:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.62.209 with HTTP; Mon, 3 Jul 2017 16:22:14 -0700 (PDT) In-Reply-To: <149907291397.4998.8059630450980375262@ietfa.amsl.com> References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> From: Richard Gibson Date: Mon, 3 Jul 2017 19:22:14 -0400 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, dnsop Content-Type: multipart/alternative; boundary="f403043c449cbe3bf30553720a8f" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:22:50 -0000 --f403043c449cbe3bf30553720a8f Content-Type: text/plain; charset="UTF-8" I looked over this draft in detail, and found a handful of ambiguous points ("Clarifications" and "Potentially Missing Data" below). But more importantly, it is very close to defining a format that could replace much of my organization's in-house technology. Would you consider some generalizations to take it over the finish line ("Extension Fields" and "Opt-in Lossyness")? Only the suggestions related to representing time and "classtype" items would change the representation of existing data in such a way that implementations already supporting the draft specification would require changes. *Clarifications* * Items in the "classtype" table (section 7.11) are missing data type documentation. Both "type" and "class" should be unsigned numbers. * And speaking of 7.11, why are CLASS/TYPE pairs represented as CBOR maps instead of more efficient two-item arrays? If it was an intentional decision for clarity, then maybe the section 7.7 block preamble "earliest-time" field should also be promoted to a map ("time-seconds", "time-useconds", "time-pseconds", mirroring Q/R items) for the same reason. * In "query-sig" table items (section 7.13) "transport-flags" field, the bit corresponding to "trailing bytes" shouldn't be limited to UDP. * In section 7.18, "and an unsigned key" appears to be meaningless and should probably be removed. *Potentially Missing Data* * In "query-sig" table items (section 7.13), "transport-flags" should probably be extended to include a TLS bit (cf. RFC 7858). *Extension Fields* Of the many potentially open-ended key-value maps (file preamble, file preamble configuration, block preamble, block statistics, query signatures, Q/R data), only block statistics allows for "implementation-specific fields", and no further guidance is provided. I think all maps should allow such fields, with a recommendation that they use an implementation-specific prefix to avoid collisions with fields added by other implementations or later versions of C-DNS. Example use cases: * Extend file preamble configuration (section 7.5) to document aggregation of queries answered by wildcard names. * Extend the block preamble (section 7.7) to override file preamble fields like "host-id" and "server-addresses", enabling fleet-wide file merges. * Extend query signatures (section 7.13) to indicate EDNS Client Subnet use (cf. RFC 7871) or selection of context-dependent handling like views. * Extend Q/R data (section 7.18) to include actual EDNS Client Subnet values or even a "count" field (which would come with *tremendous* space savings, sufficient for my organization to abandon its internal summarization format in favor of C-DNS). *Opt-in Lossyness* The format is generally quite good about allowing for detail without requiring it. However, there are some areas where more space savings could be had: * Communicate aggregation of IP addresses into prefixes (i.e., the irrelevance of least-significant bits in ip-address values) with new "client-prefix-length-ipv4" and "client-prefix-length-ipv6" and "server-prefix-length-ipv4" and "server-prefix-length-ipv6" file preamble configuration options. * Communicate case-normalizing aggregation of names (e.g., transforming "eXaMpLe.com" into "example.com") with a new boolean-valued "name-normalization" file preamble configuration option. * In "rr" table items (section 7.15), "ttl" should be optional to accommodate decrementing in recursive resolver responses. * In Q/R data items (section 7.18) and malformed packet records (section 7.20), I'd like "time-useconds" broken out into "time-seconds" and optional "time-useconds", both for parity with block-preamble "earliest-time" and for space savings in applications that are content with second-level resolution. * For truly customizable aggregation, I think all query signature (section 7.13) and Q/R (section 7.18) data item fields should be optional... but especially Q/R data "client-port" and "transaction-id". On Mon, Jul 3, 2017 at 5:08 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : C-DNS: A DNS Packet Capture Format > Authors : John Dickinson > Jim Hague > Sara Dickinson > Terry Manderson > John Bond > Filename : draft-ietf-dnsop-dns-capture-format-03.txt > Pages : 49 > Date : 2017-07-03 > > Abstract: > This document describes a data representation for collections of DNS > messages. The format is designed for efficient storage and > transmission of large packet captures of DNS traffic; it attempts to > minimize the size of such packet capture files but retain the full > DNS message contents along with the most useful transport metadata. > It is intended to assist with the development of DNS traffic > monitoring applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns- > capture-format-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-03 > > > 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/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f403043c449cbe3bf30553720a8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I looked over this draft in detail, and found a handf= ul of ambiguous points ("Clarifications" and "Potentially Mi= ssing Data" below). But more importantly, it is very close to defining= a format that could replace much of my organization's in-house technol= ogy. Would you consider some generalizations to take it over the finish lin= e ("Extension Fields" and "Opt-in Lossyness")? Only the= suggestions related to representing time and "classtype" items w= ould change the representation of existing data in such a way that implemen= tations already supporting the draft specification would require changes.
Clarifications
* Items in the "classtype" table (section 7.11) a= re missing data type documentation. Both "type" and "class&q= uot; should be unsigned numbers.
=C2=A0 * And speaking of 7.11, w= hy are CLASS/TYPE pairs represented as CBOR maps instead of more efficient = two-item arrays? If it was an intentional decision for clarity, then maybe = the section 7.7 block preamble "earliest-time" field should also = be promoted to a map ("time-seconds", "time-useconds", = "time-pseconds", mirroring Q/R items)=C2=A0for the same reason.
* In "query-sig" table items (section 7.13) "transp= ort-flags" field, the bit corresponding to "trailing bytes" = shouldn't be limited to UDP.
* In section 7.18, "and= an unsigned key" appears to be meaningless and should probably be rem= oved.

Potentially Missing Data
* = In "query-sig" table items (section 7.13), "transport-flags&= quot; should probably be extended to include a TLS bit (cf. RFC=C2=A07858).=

Extension Fields
Of the many= potentially open-ended key-value maps (file preamble, file preamble config= uration, block preamble, block statistics, query signatures, Q/R data), onl= y block statistics allows for "implementation-specific fields", a= nd no further guidance is provided. I think all maps should allow such fiel= ds, with a recommendation that they use an implementation-specific prefix t= o avoid collisions with fields added by other implementations or later vers= ions of C-DNS. Example use cases:
* Extend file preamble configuration (= section 7.5) to document aggregation of queries answered by wildcard names.=
* Extend the block preamble (section 7.7) to override file pream= ble fields like "host-id" and "server-addresses", enabl= ing fleet-wide file merges.
* Extend query signatures (section 7.= 13) to indicate EDNS Client Subnet use (cf. RFC 7871) or selection of conte= xt-dependent handling like views.
* Extend Q/R data (section 7.18= ) to include actual EDNS Client Subnet values or even a "count" f= ield (which would come with tremendous=C2=A0space savings, sufficien= t for my organization to abandon its internal summarization format in favor= of C-DNS).

Opt-in Lossyness
The = format is generally quite good about allowing for detail without requiring = it. However, there are some areas where more space savings could be had:
* Communicate aggregation of IP addresses into prefixes (i.e., the = irrelevance of least-significant bits in ip-address values) with new "= client-prefix-length-ipv4" and "client-prefix-length-ipv6" a= nd "server-prefix-length-ipv4" and "server-prefix-length-ipv= 6" file preamble configuration options.
* Communicate case-n= ormalizing aggregation of names (e.g., transforming "eXaMpLe.com"= into "example.com") with a ne= w boolean-valued "name-normalization" file preamble configuration= option.
* In "rr" table items (section 7.15), "tt= l" should be optional to accommodate decrementing in recursive resolve= r responses.
* In Q/R data items (section 7.18) and malformed pac= ket records (section 7.20), I'd like "time-useconds" broken o= ut into "time-seconds" and optional "time-useconds", bo= th for parity with block-preamble "earliest-time" and for space s= avings in applications that are content with second-level resolution.
=
* For truly customizable aggregation, I think all query signature (sec= tion 7.13) and Q/R=C2=A0(section 7.18)=C2=A0data item fields should be opti= onal... but especially Q/R data "client-port" and "transacti= on-id".

On Mon, Jul 3, 2017 at 5:08 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= C-DNS: A DNS Packet Capture Format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: John= Dickinson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jim Hague
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sara Dickinson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Terry Manderson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bond
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-dns-capture-format-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 49
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-03

Abstract:
=C2=A0 =C2=A0This document describes a data representation for collections = of DNS
=C2=A0 =C2=A0messages.=C2=A0 The format is designed for efficient storage a= nd
=C2=A0 =C2=A0transmission of large packet captures of DNS traffic; it attem= pts to
=C2=A0 =C2=A0minimize the size of such packet capture files but retain the = full
=C2=A0 =C2=A0DNS message contents along with the most useful transport meta= data.
=C2=A0 =C2=A0It is intended to assist with the development of DNS traffic =C2=A0 =C2=A0monitoring applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/

There are also htmlized versions available at:
https://tools.ietf.org/html/d= raft-ietf-dnsop-dns-capture-format-03
https://datatracker.ietf= .org/doc/html/draft-ietf-dnsop-dns-capture-format-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-dnsop-dns-capture-format-03


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--f403043c449cbe3bf30553720a8f-- From nobody Mon Jul 3 16:40:11 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0383E131769; Mon, 3 Jul 2017 16:40:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912520399.16222.12738253224617069728@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:40:04 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:40:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : DNS Session Signaling Authors : Ray Bellis Stuart Cheshire John Dickinson Sara Dickinson Allison Mankin Tom Pusateri Filename : draft-ietf-dnsop-session-signal-03.txt Pages : 27 Date : 2017-07-03 Abstract: This document defines a new Session Signaling OPCODE used to communicate persistent "per-session" operations, expressed using type-length-value (TLV) syntax, and defines an initial set of TLVs used to manage session timeouts and termination. This mechanism is intended to reduce the overhead of existing "per-packet" signaling mechanisms with "per-message" semantics as well as defining new signaling operations not defined in EDNS(0). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-03 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-03 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 Mon Jul 3 17:00:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5951913183D for ; Mon, 3 Jul 2017 17:00:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 l1XQMHpT9EuM for ; Mon, 3 Jul 2017 17:00:18 -0700 (PDT) Received: from mail-ua0-x246.google.com (mail-ua0-x246.google.com [IPv6:2607:f8b0:400c:c08::246]) (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 EC4BD131823 for ; Mon, 3 Jul 2017 16:59:45 -0700 (PDT) Received: by mail-ua0-x246.google.com with SMTP id l38so77391141uaf.1 for ; Mon, 03 Jul 2017 16:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EQhMgGM6b6ycYu3RJNz+VBMI1ph4HqO2VfxeS9yurYA=; b=VbqluYxf0GdgipCtN5K6oNVRegdll7M9qsdtMNY95n+kUukVHURKDXTDIvx65vtnxZ BlE2BdAubys/Oni72+Z1l2jpkzCmDRr1BVCwkD1UoE2lLMCjeC3T1tHoVapFScgeA6rK xPZhDfpKuS4lykulm1Pox4srB0K4FeTQaSkzs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EQhMgGM6b6ycYu3RJNz+VBMI1ph4HqO2VfxeS9yurYA=; b=nlEC2bhiN0ZKKsPcSjg3gPMdossDMVn0ecI4EnqIhiopKnOV2D1w7m7clqDLndGRGk J0djninqmHSkrq+QTqleckKlIpBxeiB1vU3nuVguXTVnjicR8qNegqgrboqSB0NEGkVs /wKMrILuzPxBiegVugJ+PB6K32XGv8Khzb5G0FZdX0U2GZkPEOOfybTzP8O0K2IadSFI WDdySUsTGWCvi4O/vuVXHV9G9YFvcHYQTecNMnspXHcb0eYBOOdUwA9n7kHzZo2/+G9e c9EHxwPw6iy5ZA5C5g+azZWsFFj++m+TAE8NXplBmSIDmgjGvpJLZlGjdheorA0V3/3f eKGA== X-Gm-Message-State: AKS2vOwVuFvrq6SLdI2+lwnsonYl0ZJTv9xXd4lhc4Fpd/eh+yXRzfF1 42emx7cSq1GrkRdET66lKW6wItbt8qw4 X-Received: by 10.176.82.236 with SMTP id w41mr23678614uaw.98.1499126385043; Mon, 03 Jul 2017 16:59:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.62.209 with HTTP; Mon, 3 Jul 2017 16:59:24 -0700 (PDT) In-Reply-To: <149910581457.22758.9362742606445936639@ietfa.amsl.com> References: <149910581457.22758.9362742606445936639@ietfa.amsl.com> From: Richard Gibson Date: Mon, 3 Jul 2017 19:59:24 -0400 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, dnsop Content-Type: multipart/alternative; boundary="94eb2c191c26a793830553728fde" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-wkumari-dnsop-multiple-responses-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 00:00:20 -0000 --94eb2c191c26a793830553728fde Content-Type: text/plain; charset="UTF-8" Comments: 1. There's a "www.exmaple.com" typo in the introduction. 2. It is very limiting for this functionality to rely upon DNSSEC, given that many practical cases still preclude its use. 3. Why have a composite value for EXTRA instead of just using one EXTRA record per domain (with a Priority field for proper ordering)? 4. Why limit EXTRA domain names to single labels, instead of allowing answers for e.g. en.m.example.org from m.example.org queries? 5. The missing signal about records that *could* have been included via TCP or secured by DNS cookies (the TC bit being too strong) seems to be another case for a "partial response" EDNS header flag (which I raised for refuse-any in https://www.ietf.org/mail-archive/web/dnsop/current/msg19322.html ). On Mon, Jul 3, 2017 at 2:16 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Returning extra answers in DNS responses. > Authors : Warren Kumari > Zhiwei Yan > Wes Hardaker > David C Lawrence > Filename : draft-wkumari-dnsop-multiple-responses-05.txt > Pages : 9 > Date : 2017-07-03 > > Abstract: > This document (re)introduces the ability to provide multiple answers > in a DNS response. This is especially useful as, in many cases, the > entity making the request has no a prori knowledge of what other > questions it will need to ask. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05 > https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop- > multiple-responses-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop- > multiple-responses-05 > > > 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/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c191c26a793830553728fde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments:
1. There's a "www.exmaple.com" typo in the introduction.
2. It is very limiting for this functionality to rely upon DNSSEC, given t= hat many practical cases still preclude its use.
3. Why have a co= mposite value for EXTRA instead of just using one EXTRA record per domain (= with a Priority field for proper ordering)?
4. Why limit EXTRA do= main names to single labels, instead of allowing answers for e.g. en.m.example.org from m.example.org queries?
5. The missing signal abo= ut records that could=C2=A0have been included via TCP or secured by = DNS cookies (the TC bit being too strong) seems to be another case for a &q= uot;partial response" EDNS header flag (which I raised for refuse-any = in https://www.ietf.org/mail-archive/web/dnsop/current/msg19322.html= ).

On= Mon, Jul 3, 2017 at 2:16 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Returning extra answers in DNS responses.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Warr= en Kumari
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Zhiwei Yan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Wes Hardaker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 David C Lawrence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-wku= mari-dnsop-multiple-responses-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-03

Abstract:
=C2=A0 =C2=A0This document (re)introduces the ability to provide multiple a= nswers
=C2=A0 =C2=A0in a DNS response.=C2=A0 This is especially useful as, in many= cases, the
=C2=A0 =C2=A0entity making the request has no a prori knowledge of what oth= er
=C2=A0 =C2=A0questions it will need to ask.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-wkumari-dnsop-multiple-responses/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05
https://datatracker.i= etf.org/doc/html/draft-wkumari-dnsop-multiple-responses-05
A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-wkumari-dnsop-multiple-responses-05


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c191c26a793830553728fde-- From nobody Mon Jul 3 17:21:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD2131811 for ; Mon, 3 Jul 2017 17:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 PUODeb1o-r_h for ; Mon, 3 Jul 2017 17:21:00 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04364131816 for ; Mon, 3 Jul 2017 17:20:55 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 173863F442; Mon, 3 Jul 2017 20:20:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22874.57189.46244.876797@gro.dd.org> Date: Mon, 3 Jul 2017 20:20:53 -0400 From: Dave Lawrence To: dnsop In-Reply-To: References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 00:21:10 -0000 Ray Bellis writes: > This is just a "keep alive" so as to keep this draft in consideration as > one of the multiple solutions in this problem space while DNSOP decides > whether this is a problem worth solving. > > I still think it's the most elegant of those proposed ;-) I whole-heartedly agree, as Ray's idea was the basic conclusion I'd arrived at independently. I was going to propose something very similar (with only minor differences in details) until I found out that I'd somehow overlooked his previous draft. Note that I'm saying this even though I am also now working with Warren and Wes on the multiple-response draft, which I suspect is one of the other proposed solutions that Ray implies above. I believe that multiple-response and multi-qtypes solve similar but somewhat different problems. As Wes observed during a conversation last week, the former is for when the authoritative server believes it knows what records you're going to want next (and even then can't effectively signal the absence of any particular record). The latter is driven by the client knowing just types it'll want to know about for a given qname, and indicates explicitly what the existence of each is. Multi-qtypes is also far easier to implement and will be much more useful much more quickly. It can roll out in resolvers and authorities incrementally without depending on DNSSEC and with far fewer security concerns. At a recent industry meeting I announcement my intention to ask Ray to revive it and was met with fairly widespread support from both authoritative and recursive operators. I'm strongly behind multi-qtypes and will be proselytizing for it as well as contributing text. From nobody Mon Jul 3 20:54:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAB11316C0 for ; Mon, 3 Jul 2017 20:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 d3W2XbeWzo6o for ; Mon, 3 Jul 2017 20:54:34 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 C7156120726 for ; Mon, 3 Jul 2017 20:54:33 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p21so159692216qke.3 for ; Mon, 03 Jul 2017 20:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KDUHCIDCoukMxdN59jUs53fnn87OQiIiEqfsx/nDPyk=; b=rr4sAfFu9MCRGyCRek/V33mfrNhdKgH3w5B/o9I7jg37paea2JjoAnQsif4zfCEn8/ bS2cd7O30CS0mUqRYP2L1g+LwvTU+e7YULgYziN0l+v8kmJWbWAp/d7wvRq0Lyc351b8 DgklwKr1FAC7W3JGCPE1TRhE50dXEDU5jY0mhfV07uRL1ByqyBz7W4LuQFMkrb5Li6/p RSbdsZtrx09J+2siBCnOjuJFB+Lyn7FLG9judfFVcRuUc5+QI1nMxS7r5vv5DPtcHVSX YDHe98B84uWWNXQjwGhoNljeOhznqugDWRMP7bPjXzTKitDka0u5knpjTnvdcOqVNf4H jinA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KDUHCIDCoukMxdN59jUs53fnn87OQiIiEqfsx/nDPyk=; b=K7WSvwe7gZ7pD0Oz+K5zDSPyPgXvPuqpP1hny9IF/kkZCaSvm/vUlonqUSsytGNVt8 qodZQmHwgtBrDjvw8Zsq6oxLIew0VspqAz60aPNIAyN//+AYqDxiWbT78JXWgCB2nmLr EaH5MCYSVfpwMRtvuB2Zxn0gsJ/eHektcToqw4kv5/KenPrpbGMHOWIhErn6gcY6IhFM QLzersU+Ewo2gTf8yKzQyr+0K8tub3n6U9hN/bp7PjWXK6gA1DZa3SVv55kqlEMNf4dU 7avSbDNooblyDEcwS7EBJ+7D4TGV0hTyBfjQ0cn78WkzBYgMb06ZL6csBqbbAY5Rr6TC Ym0A== X-Gm-Message-State: AIVw110Fbtex4VR9VE/Mbd3aoVqqvXIDqOZ6nPvlNGEwL6xhBL/Hklb0 sJFhnVBdFFR8tsbNRp4UF+a7+Ch60yhz X-Received: by 10.55.82.139 with SMTP id g133mr23099395qkb.2.1499140472980; Mon, 03 Jul 2017 20:54:32 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> In-Reply-To: From: Lanlan Pan Date: Tue, 04 Jul 2017 03:54:22 +0000 Message-ID: To: Tony Finch Cc: dnsop Content-Type: multipart/alternative; boundary="001a114a8daa5c4ccf055375d7de" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 03:54:36 -0000 --001a114a8daa5c4ccf055375d7de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, We try to solve similar wildcard problem. NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards = ) : - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information. - cached deduced wildcard: give the default wildcard RR. SWILD: - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR. SWILD is applicable even when Authoritative Nameservers don't give NSEC/NSEC3 RR. SWILD is applicable on non-validating Forwarding Resolvers. Regards, Tony Finch =E4=BA=8E2017=E5=B9=B47=E6=9C=883=E6=97=A5=E5=91= =A8=E4=B8=80 =E4=B8=8B=E5=8D=888:18=E5=86=99=E9=81=93=EF=BC=9A > Lanlan Pan wrote: > > > > This document specifies a new SWILD RR type for Intermediate Nameserver= s > to > > cache subdomain wildcard record, in order to reduce the cache size and > > optimize the wildcard domain cache miss. > > Isn't this functionality already provided by > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > punycode > Fitzroy: Variable 4 for a time in north, otherwise northeasterly becoming > cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate, > occasionally > poor. > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a114a8daa5c4ccf055375d7de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

We try to solve similar wildcard problem.<= br>
NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards) : - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
- c= ached deduced wildcard: give the default wildcard RR.

SWILD:
- Di= rectly give "ALL SUBDOMAIN" information, and the default wildcard= RR.

SWILD is applicable even when Authoritative Nameservers don'= ;t give NSEC/NSEC3 RR.
SWILD is applicable on non-validating Forwarding = Resolvers.

Regards,

Tony Finch <dot@dotat.at>=E4=BA=8E2017=E5=B9=B47=E6=9C=883=E6=97=A5=E5=91=A8= =E4=B8=80 =E4=B8=8B=E5=8D=888:18=E5=86=99=E9=81=93=EF=BC=9A
Lanlan Pan <abbypan@gmail.com> wrote:
>
> This document specifies a new SWILD RR type for Intermediate Nameserve= rs to
> cache subdomain wildcard record, in order to reduce the cache size and=
> optimize the wildcard domain cache miss.

Isn't this functionality already provided by
https://tools.ietf.org/html/draft-iet= f-dnsop-nsec-aggressiveuse ?

Tony.
--
f.anthony.n.finch=C2=A0 <dot@dotat.at>=C2=A0 http://dotat.at/=C2=A0 -=C2=A0 I xn--zr8h punycode=
Fitzroy: Variable 4 for a time in north, otherwise northeasterly becoming cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate, occasionall= y
poor.
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Re= gards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--001a114a8daa5c4ccf055375d7de-- From nobody Tue Jul 4 00:31:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C255131A40 for ; Tue, 4 Jul 2017 00:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 MfXZ_hD8ffVi for ; Tue, 4 Jul 2017 00:31:11 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 7C3CC131A38 for ; Tue, 4 Jul 2017 00:30:59 -0700 (PDT) Received: from [IPv6:2001:981:19be:1:74df:1ae0:7501:ee46] (unknown [IPv6:2001:981:19be:1:74df:1ae0:7501:ee46]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 3E1CABD24 for ; Tue, 4 Jul 2017 09:30:57 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl To: dnsop@ietf.org References: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> <185af195-dac6-1438-916f-c9b6d73df644@isc.org> From: Matthijs Mekking Message-ID: <83761c92-b5c4-7927-8897-718741fe1c6b@pletterpet.nl> Date: Tue, 4 Jul 2017 09:30:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <185af195-dac6-1438-916f-c9b6d73df644@isc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 07:31:14 -0000 Hi, I already said this in private, but will also mention it here: I like this idea. Some initial comments: 1. Why actually define a new option for this. Since the option only uses one bit to request/acknowledge opportunistic refresh, can't we use one bit from the Z field from the OPT Record TTL Field? 2. The draft says: If Client Subnet [RFC7871] is enabled, resource records in the cache may be associated with a subnet. In these cases, the resolver MUST ensure that the zone serial number associated with such records is obtained from an SOA record associated with the identical subnet. But a SOA record is not associated with a subnet, and most likely will return with a SCOPE of 0 since the option is not actually used to generate the response. Typically with Client Subnet only address records (A, AAAA) will result in a tailored response. Also, an authoritative name server may generate a different response for QTYPE=AAAA while the SOA record has not changed. It would be tricky to make opportunistic refresh work with Client Subnet. It would definitely require more thought, but I would also be fine with just specifying it does not work with ECS. 3. Security Considerations I think this could use some words on the risk that an adversary tries to make a record stick in the cache for longer than it is allowed, by spoofing a response with an additional SOA record (this can be stopped with DNSSEC obviously). Best regards, Matthijs On 03-07-17 13:36, Stephen Morris wrote: > Hi > > We have submitted a new draft which attempts to formalize an idea that > has been kicking around for a couple of years, namely to use serial > number information from DNS responses to determine whether stale records > in a cache can be refreshed without the need for an upstream query. > > Please send comments and feedback to the list. > > Stephen > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-muks-dnsop-dns-opportunistic-refresh-00.txt > Date: Fri, 30 Jun 2017 13:41:45 -0700 > From: internet-drafts@ietf.org > To: Mukund Sivaraman , Shane Kerr > , Stephen Morris > > > A new version of I-D, draft-muks-dnsop-dns-opportunistic-refresh-00.txt > has been successfully submitted by Mukund Sivaraman and posted to the > IETF repository. > > Name: draft-muks-dnsop-dns-opportunistic-refresh > Revision: 00 > Title: DNS Opportunistic Refresh for Resolvers > Document date: 2017-06-29 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-opportunistic-refresh-00.txt > Status: > https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-opportunistic-refresh/ > Htmlized: > https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-opportunistic-refresh-00 > > > Abstract: > This document describes a mechanism whereby a DNS resolver can > opportunistically refresh the TTLs of cached records of a zone using > serial number information carried in responses from the zone's > nameservers. As well as improving resolver response time by reducing > the need to make upstream queries, the mechanism can also reduce the > workload of authoritative servers. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Tue Jul 4 00:39:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4DD131A71; Tue, 4 Jul 2017 00:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 PhiCM8mtJoOp; Tue, 4 Jul 2017 00:39:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 DB74D131A70; Tue, 4 Jul 2017 00:39:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dSIQg-0004ev-IN; Tue, 04 Jul 2017 07:39:26 +0000 Date: Tue, 04 Jul 2017 09:39:25 +0200 Message-ID: From: Randy Bush To: Warren Kumari Cc: dnsop@ietf.org, IETF Rinse Repeat In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 07:39:30 -0000 > The Special-Use Domain Names Problem Statement document unsurprisingly > contains a list of problems. is there a companion document with the list of benefits/advantages? or is thins just one of those ietf documents from on high meant to kill something? randy, who does not have a dog in this fight, just smells dog poop From nobody Tue Jul 4 01:36:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F39131B1B for ; Tue, 4 Jul 2017 01:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 0QtwKhHwvDLw for ; Tue, 4 Jul 2017 01:36:02 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 2940B131B10 for ; Tue, 4 Jul 2017 01:36:02 -0700 (PDT) Received: from jurassic (unknown [115.117.162.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 4BF0456A0054; Tue, 4 Jul 2017 08:35:57 +0000 (GMT) Date: Tue, 4 Jul 2017 14:05:50 +0530 From: Mukund Sivaraman To: Matthijs Mekking Cc: dnsop@ietf.org Message-ID: <20170704083550.GA17654@jurassic> References: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> <185af195-dac6-1438-916f-c9b6d73df644@isc.org> <83761c92-b5c4-7927-8897-718741fe1c6b@pletterpet.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83761c92-b5c4-7927-8897-718741fe1c6b@pletterpet.nl> User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 08:36:04 -0000 Hi Matthijs On Tue, Jul 04, 2017 at 09:30:55AM +0200, Matthijs Mekking wrote: > Hi, > > I already said this in private, but will also mention it here: I like > this idea. > > Some initial comments: > > > 1. Why actually define a new option for this. Since the option only uses > one bit to request/acknowledge opportunistic refresh, can't we use one > bit from the Z field from the OPT Record TTL Field? > > > 2. The draft says: > > If Client Subnet [RFC7871] is enabled, resource records in the > cache may be associated with a subnet. In these cases, the > resolver MUST ensure that the zone serial number associated with > such records is obtained from an SOA record associated with the > identical subnet. > > But a SOA record is not associated with a subnet, and most likely will > return with a SCOPE of 0 since the option is not actually used to > generate the response. Typically with Client Subnet only address records > (A, AAAA) will result in a tailored response. Also, an authoritative > name server may generate a different response for QTYPE=AAAA while the > SOA record has not changed. > > It would be tricky to make opportunistic refresh work with Client > Subnet. It would definitely require more thought, but I would also be > fine with just specifying it does not work with ECS. You're right that ECS makes things a bit tricky. RFC7871 doesn't say anything about caching SOA, only that the address prefix in the CLIENT-SUBNET option applies to just things that are returned in the answer section. SOA can be returned in the answer section when querying for type SOA. The SOA serial field is so far only assumed to be defined for zone transfers, and currently has no use with QUERY. Zone transfers with address prefixed RRs are not specified by RFC7871. BIND's resolver ECS does not cache SOA against an address prefix, but on the authoritative side, note that there is no master file or zone representation for zones with ECS. It is quite possible that if the auth side is using different zone sources for different address prefixes, they may well have different SOA serials. The problem is that none of these is defined. What the draft suggests is that on the resolver side, the SOA serial is maintained for that scope subnet corresponding to the answer. With this, it will handle cases when there are per-prefix zone sources with differing SOA serials, albeit at a slight reduction in efficiency of this scheme because all address prefixes cannot be refreshed at once. In your example, the QTYPE=AAAA answer will be cached against its specific scope prefix, and when looking for whether it needs to be refreshed, the resolver will go looking for the SOA serial associated with that prefix. Mukund From nobody Tue Jul 4 03:13:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5069B131DAE for ; Tue, 4 Jul 2017 03:13:40 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 T9a1TW26nVX0 for ; Tue, 4 Jul 2017 03:13:37 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 4804C131DAB for ; Tue, 4 Jul 2017 03:13:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3x20Fn2dyHzvk; Tue, 4 Jul 2017 12:13:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1499163213; bh=XqPLTiRKP9jgI5ic2F5HvnbV6xvdGT1LVbARF5cRAgM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sgIooFNj2BwUJPsAdceT0/w7VyxgeWcJWjdlZI+XvbG5fsdjnIFNAw2iKPA6zdvdz f9Mz2KgVA87vZBBOmZ1u1SEZWRZED7WmKCCNEAZGDedKc+dCM5wjpJLqHkwq7KlHF+ IDJtFQjSI0c8RsttJuL/ReSZTUtNfkK8wXXmaKNA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id gWicBysbw47Y; Tue, 4 Jul 2017 12:13:32 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 4 Jul 2017 12:13:32 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2C85730AF02; Tue, 4 Jul 2017 06:13:31 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2C85730AF02 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0FE0340D3592; Tue, 4 Jul 2017 06:13:30 -0400 (EDT) Date: Tue, 4 Jul 2017 06:13:30 -0400 (EDT) From: Paul Wouters To: Dave Lawrence cc: dnsop In-Reply-To: <22874.57189.46244.876797@gro.dd.org> Message-ID: References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <22874.57189.46244.876797@gro.dd.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 10:13:40 -0000 On Mon, 3 Jul 2017, Dave Lawrence wrote: >> This is just a "keep alive" so as to keep this draft in consideration as >> one of the multiple solutions in this problem space while DNSOP decides >> whether this is a problem worth solving. >> >> I still think it's the most elegant of those proposed ;-) > > I whole-heartedly agree, as Ray's idea was the basic conclusion I'd > arrived at independently. I agree. > I believe that multiple-response and multi-qtypes solve similar but > somewhat different problems. As Wes observed during a conversation > last week, the former is for when the authoritative server believes it > knows what records you're going to want next (and even then can't > effectively signal the absence of any particular record). The latter > is driven by the client knowing just types it'll want to know about > for a given qname, and indicates explicitly what the existence of each > is. > > Multi-qtypes is also far easier to implement and will be much more > useful much more quickly. It can roll out in resolvers and > authorities incrementally without depending on DNSSEC and with far > fewer security concerns. At a recent industry meeting I announcement > my intention to ask Ray to revive it and was met with fairly > widespread support from both authoritative and recursive operators. Good! And I think any ANAME/ALIAS record should be used in combination with these, and of itself not define any new special handling. Although, we should also be a bit careful not to create a new ANY type query that will get abused for amplification, so it should really all have source verified IP transports (DNS-COOKIES, TCP, etc) Another issue to look at is returning any prefix special records, such as TLSA records which do not match the QNAME, but are strongly related to the QNAME and would benefit from being returned along. Paul From nobody Tue Jul 4 03:40:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D12131DEA for ; Tue, 4 Jul 2017 03:40:26 -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=gmail.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 kfOQsMl7h71Z for ; Tue, 4 Jul 2017 03:40:24 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 7F0A6131DE5 for ; Tue, 4 Jul 2017 03:40:24 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m68so99508476ith.1 for ; Tue, 04 Jul 2017 03:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/bdbJIUTWzCU6dClwKu3rcv3HHTyXlXcLheHNmXqoI4=; b=JJnTbmcY+M9WrpPpF+PtXzM8M5RS2eo9LVeHa8WdiZL7hBLmOncxyi6E40wQ/SiHgm yNgKx5R8FkJhT62ffpW29lfzGuR28M2sVbqi/1Mkh74hTNRGnPpxZxR0QDvxRZ8hQaFD OGysPbIiZs9idsGxCwkyM3EvdeEMJF7oJoFWHOGT6fbi0ah8dug4dNk/7JDHLg2lsRT/ +RQ0S56bH0Q+MtBL9b8aCX2P1Nna+GFVjN71ro3aqQHmy9mTB1KqRaTomfcm/ekM/DSl WLE+a88ArvYIz+O4VMPL9yMmJBWQtk+qCdrYo2WyG2phblNY+BIQVKm3sVidemIN0OMl NxCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/bdbJIUTWzCU6dClwKu3rcv3HHTyXlXcLheHNmXqoI4=; b=npXdbAPsSliqlQq9z4SmOpnZAnQXZDcIOANaMKJKs81opLd/p1Azh0pMXTBZnTY0PC 1ACqHoyVlc1DOthXNgIRFZDH5Cd0YxXFwhczGFc7kPfJbfNB38ye7ipIa6nMa/GESCVs C3u59twUI3bA0V0VYSF9AObdXdjhmY0jYNgr+PJKqMr/jvJDJF0o1adFjbcbwPlvYEaY E65nXqmqKdyYoEFbCfgb/CsbTz4sph3JlvyCa5/jXSHNYb6yP6qnq59jLCm8lLbzTZlj Bc91gS85JoscjhrDejiPKv8JOTipcxIftK8eRZGuHcoi0oRaTgXR2Az9tpFFVIc5stYf 7rLg== X-Gm-Message-State: AKS2vOxILyEbjOn2yvbxSIl3isqToaiqdsG5aSi1iRhFs1s+Y4UJIpz5 UWWKA9Jq3ffbnDHropo= X-Received: by 10.36.117.202 with SMTP id y193mr34986496itc.111.1499164823639; Tue, 04 Jul 2017 03:40:23 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com ([50.110.82.183]) by smtp.googlemail.com with ESMTPSA id t5sm4117318ita.22.2017.07.04.03.40.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 03:40:22 -0700 (PDT) To: dnsop@ietf.org References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <22874.57189.46244.876797@gro.dd.org> From: Tim Wicinski Message-ID: <978e9cc3-c5d9-87fb-8878-229f4a4c28aa@gmail.com> Date: Tue, 4 Jul 2017 06:40:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 10:40:26 -0000 On 7/4/17 6:13 AM, Paul Wouters wrote: > On Mon, 3 Jul 2017, Dave Lawrence wrote: > >>> This is just a "keep alive" so as to keep this draft in consideration as >>> one of the multiple solutions in this problem space while DNSOP decides >>> whether this is a problem worth solving. >>> >>> I still think it's the most elegant of those proposed ;-) >> >> I whole-heartedly agree, as Ray's idea was the basic conclusion I'd >> arrived at independently. > > I agree. I remember we discussed the various drafts in a meeting (city of which escapes me) and the sense of the people in the room, and the folks I talked to afterward was that the preference was for a client to *ask* for extra things, rather than the server *forcing* extra answers back. I think Ray's qtype draft fits this. The chairs should finally discuss having a Call for Adoption on this after we've heard the updates > > And I think any ANAME/ALIAS record should be used in combination with > these, and of itself not define any new special handling. > Well that's an interesting way to approach it. > Although, we should also be a bit careful not to create a new ANY type > query that will get abused for amplification, so it should really all > have source verified IP transports (DNS-COOKIES, TCP, etc) > The is good guidance, and some wording like this would be useful in the qtypes draft. > Another issue to look at is returning any prefix special records, > such as TLSA records which do not match the QNAME, but are strongly > related to the QNAME and would benefit from being returned along. > Excellent idea. One reason we know why SRV records are not used by many is no one wants to do additional lookups. tim From nobody Tue Jul 4 04:04:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA135131ED4 for ; Tue, 4 Jul 2017 04:04:13 -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=gmail.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 Vnsz3BXJOmqj for ; Tue, 4 Jul 2017 04:04:12 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 07C64131472 for ; Tue, 4 Jul 2017 04:04:12 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id k192so69811812ith.1 for ; Tue, 04 Jul 2017 04:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=u4vC1Pr1zpYuBX7DiW3Fk8wegH65CW/9sU/uFzVElww=; b=PNHE4+XW2XpSEXExVaDxeqro9YnAfIkl2qxN1Dg4EKEEY8MWPhAx3ICbHr1YLff3Ul xodx/+DxLXqNNk+7Jt7pm4giA4lL56yJEsbBfujdZhd7WwKIROu1szkGyzKXLJqQfqZ9 jO+6l+9h6GjHSYA2B1EvXe8SeDHxuhR6mK/lE1jl+zfaC8PqRenF8p/W2SCJDIwpqHdH 25FHUyrIZT07xeF9OY2tDQsWBbxCYlItFAPtWlkuBCoaDrG1+gs4xVRPd6Ytz8+tRIDD idOXRCiQc7+dt6T2+3obO6dv8msjmCAQgiXdsZkxaEyDdhDLgt9odshAGbzD3SVXZrIF KQ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=u4vC1Pr1zpYuBX7DiW3Fk8wegH65CW/9sU/uFzVElww=; b=AhJa4G1vM9DEV3fGqHbLITu3eTDotOw9baU/VixOUSKR+1TcvKdd1IPcbD/jmm+oLi 0r7e7wgyeoydx19kR43ArPc5yLm+qC3IXIKiV4Qba03PkORm3uMdDMmup8AQ27jFYxGG RUeK/+CyHg/GyI2NV+9ONdTMA8oBIpY7fbxGoNCE4Zc4AnMUM/6A8FkTv9cpq4bFosMz k1EQt5qos4TYfOP/YtuZO6k8uz479Ures+MHKraZG/A6S5VVHN/MuZL6MgXPIMgsReIv Xo17ohrMw02K1Xl403QZZtdP+nwxykZ52xK4ynsOl2iYj69KTuUzx1zWwzhsNwj9N7fN TCeQ== X-Gm-Message-State: AIVw1117rGxNCV0+DmXxiJT6q7YF+kUV3c45KV70bGXgUyC4Y/iu6DaK zDhPQPX71nQj1rMLYKU= X-Received: by 10.36.13.11 with SMTP id 11mr30628038itx.93.1499166251203; Tue, 04 Jul 2017 04:04:11 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com ([50.110.82.183]) by smtp.googlemail.com with ESMTPSA id c4sm4337064ioc.18.2017.07.04.04.04.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 04:04:10 -0700 (PDT) To: dnsop@ietf.org References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <555FCD98-C509-4D9A-ADDB-9621623E109E@sinodun.com> From: Tim Wicinski Message-ID: Date: Tue, 4 Jul 2017 07:04:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:04:14 -0000 On 7/3/17 12:55 PM, Paul Hoffman wrote: > On 3 Jul 2017, at 5:34, Marc Groeneweg wrote: > >> Can we drop this claim, and proceed this draft to standard? > > There is no need to "drop this claim" in order to move the draft > forward. Plenty of documents in the IETF have claims like this > associated with them. > Paul is correct about this. We can move the document forward, and let the "process" sort out the issue. The current only outstanding item in this draft is the storing of malformed packets (per the authors). The chairs feel if this version gets some solid review and the group resolves this last issue, it is ready for working group last call. tim From nobody Tue Jul 4 04:11:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC2B131859 for ; Tue, 4 Jul 2017 04:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8] 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 O8ezZ0TF-dQk for ; Tue, 4 Jul 2017 04:11:25 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 EEFAC131E6C for ; Tue, 4 Jul 2017 04:11:24 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v64BBNVQ009096 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 4 Jul 2017 11:11:24 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v64BBNEs024323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 4 Jul 2017 11:11:23 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v64BBMcQ019961 for ; Tue, 4 Jul 2017 11:11:23 GMT Received: from [172.19.129.74] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Jul 2017 04:11:22 -0700 To: dnsop@ietf.org References: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> <185af195-dac6-1438-916f-c9b6d73df644@isc.org> <83761c92-b5c4-7927-8897-718741fe1c6b@pletterpet.nl> <20170704083550.GA17654@jurassic> From: Matthijs Mekking Message-ID: Date: Tue, 4 Jul 2017 13:11:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170704083550.GA17654@jurassic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:11:28 -0000 On 04-07-17 10:35, Mukund Sivaraman wrote: > BIND's resolver ECS does not cache SOA against an address prefix, but on > the authoritative side, note that there is no master file or zone > representation for zones with ECS. It is quite possible that if the auth > side is using different zone sources for different address prefixes, > they may well have different SOA serials. The problem is that none of > these is defined. Which makes it hard to rely on it. From nobody Tue Jul 4 04:28:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B9129A9F; Tue, 4 Jul 2017 04:28:19 -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=gmail.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 lv-vrrkWPZuD; Tue, 4 Jul 2017 04:28:18 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 71D51131F1D; Tue, 4 Jul 2017 04:28:17 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id v143so81884048qkb.0; Tue, 04 Jul 2017 04:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=217Qkbjcosa32WFONDm+lfqdU0/1E3brVKetZdus0FQ=; b=JjaqZeHvZOEB3vpzNbr/UITI6XYMXjC6Pxr1LKR8L3kvxNw4zkL8Uf5hyZHH7LE8nx hZJSuPS33b6iNrILlPyC0jHNnPk+z6x+I0e/hbUpUvkltIqGDIeeTevbumKZtCGwfTKS fkl40QqNlk/OLhCIDS2C+xciM4oZv7a7M3gbarFoBekm4n9gtE0inAIXT1pxzXTNATNU lz6heg5OAphUe9GeyDeqKjOul6N8Ybu3/HzfawVP6Yuw6eGwQF3BHkTpd1iV8TmfNzsE /c1q024DXSVXOQI2GeIZrGFPhcT/AnpjbDBlaDQUf7e5tDtmv80bDTuj55IDyhnmoz5L VC4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=217Qkbjcosa32WFONDm+lfqdU0/1E3brVKetZdus0FQ=; b=uLHnQ9piPIaxjZCaDMUUPvDyNghMwhrWtmqamPEfwkj6RjNiS45eyGKAH6e/zaItMb 14bOgQEzXjdRAUCIsN/EPz8GO61Ye2xWb3RW+I5SbMHb9VZWV7OVAuCpLU4Oe0myBwii 5rYebA4fT7wihpZlGmbRTJobuKcDFaOBLiBHQl+i83zaauC0TwWrvm6Qd3i1jRMHiG7c XOtbV+KcTAWB6U1dWOgFu36T9IRD6M0m5mUAbktla8yyN0revpmmqsLNhCYVHALY1WWV vZoIcUEcWE6kvy29am9fHemAXeq5+6bdHU2iVvVKedMLliEGqwfFbuzkm17hzQDPBg1I 2vWg== X-Gm-Message-State: AKS2vOzBDF1cq+IE6zSDHDj5IZbDh1jrkZRSYK6FAXJ7AF27y3vigoZE 54pd9mEe5xMyUcre9VY= X-Received: by 10.55.204.133 with SMTP id n5mr48238073qkl.135.1499167696654; Tue, 04 Jul 2017 04:28:16 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:4488:ee:f477:1020? ([2601:18f:801:600:4488:ee:f477:1020]) by smtp.gmail.com with ESMTPSA id t11sm15523737qtt.47.2017.07.04.04.28.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 04:28:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ralph Droms In-Reply-To: Date: Tue, 4 Jul 2017 07:28:12 -0400 Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:28:20 -0000 > On Jul 4, 2017, at 3:39 AM, Randy Bush wrote: >=20 >> The Special-Use Domain Names Problem Statement document = unsurprisingly >> contains a list of problems. >=20 > is there a companion document with the list of benefits/advantages? It's a list of problems, not solutions, so there aren't benefits and/or = advantages. > or > is thins just one of those ietf documents from on high meant to kill > something? It's not intended as a dead-end, either. It is intended as a reference = document for solution documents to point at. Warren add numbering to = the list so the problems could be referenced more easily by solutions = documents, such as draft-ietf-dnsop-alt-tld-08=20 >=20 > randy, who does not have a dog in this fight, just smells dog poop >=20 - Ralph From nobody Tue Jul 4 04:42:23 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C75A131F5B; Tue, 4 Jul 2017 04:42:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149916854131.16079.9203202983727964007.idtracker@ietfa.amsl.com> Date: Tue, 04 Jul 2017 04:42:21 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:42:21 -0000 The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ From nobody Tue Jul 4 04:44:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55436131F96 for ; Tue, 4 Jul 2017 04:44:23 -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=gmail.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 xlnkOMdZZf3O for ; Tue, 4 Jul 2017 04:44:21 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 055D0131F8C for ; Tue, 4 Jul 2017 04:44:21 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id 16so166447502qkg.2 for ; Tue, 04 Jul 2017 04:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=FjqDRcXkirR3R70rjAwqQQ5rl7Yf/UYSbKr7riy2gj8=; b=nZ+NM+TSITcqTSHLyRUf6b4h2Fb3895RSBmx6iF8K5gJahfF93ZwjUUvjc/7/uJa2K 3nmDdsuEzmvEnkxKrZyfCdpFI0EFsz+2egCx89FJNDognOmjgXAEN1V0kyi4sKedfAQC T3N7cW1tX5r+ashcQMAZc80xXlAWMH0OaM5mv+yGZXo9/qc1l83l6xR1EaWk5XN4kLEX /YnRnoMspuz3b3kn1QLiAxVFeajvIugIG584Zd0UZ26hK0Zy25pacshcrSwC9F68oyW7 ju7NbRoCuyzoD/JqcjC+gp61p37vKpjhv7c4r1z+fRTMegPQtl0wrrnGWD7UmqlHxxdp DpdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=FjqDRcXkirR3R70rjAwqQQ5rl7Yf/UYSbKr7riy2gj8=; b=mMm1nDniKzayetq1aiTQuETr0DsxX/S+UusP0WuwtA9WlfJyBRfRS8OikY9pcX+mrt PIs4nziJ7RohnhoKtoVhgwa3GXzDLa/JsE5B6a5b+972a8Zub9rEpNXypwq25Wb9inFb FaRsKOXDBvoiNt7nQpj3ziQOoyEsHLSnTfMOyrd9lcVlGGb51wBn+9ZSCp55HlLkxbSu OcMWRgteQKrNP1X+L+VpS1eLxYF2LzDgVCs0jm9wsZhpjEnH9dcqSZGEFYWX8SKAWqBC 0GoYab9HLGtPFq59aLtzVxXcwtwMW+45VeOVEKT5/wmzoX+s1PSqUhD/ZIYsQrC2EvFa hUfg== X-Gm-Message-State: AKS2vOy6GrN2v8dugtPMEcDYAl4vr7VAz/9IU9dLSRuLP6DPdxkSbLJT t0ybqEduQ6pqQkRkKhU= X-Received: by 10.55.22.71 with SMTP id g68mr48982855qkh.218.1499168659868; Tue, 04 Jul 2017 04:44:19 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com ([204.14.236.152]) by smtp.googlemail.com with ESMTPSA id l32sm14757646qkh.15.2017.07.04.04.44.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 04:44:18 -0700 (PDT) To: dnsop From: Tim Wicinski Message-ID: Date: Tue, 4 Jul 2017 07:44:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Agenda for DNSOP, IETF99 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:44:23 -0000 Hi We've uploaded the initial agenda for IETF99. Please take a look and make sure we didn't miss any requests. We'll flesh this out over the coming days. If you contacted and are not on the list, please drop us a note. The Tuesday Meeting is focused on Current/Existing WG business. Thursday is for newer work. Also, please use the agenda as a list of documents to review before the meeting. See you in a few weeks! Tim Suzanne https://datatracker.ietf.org/doc/agenda-99-dnsop/ ------- ## DNS Operations (DNSOP) Working Group # IETF 99, Prague ### Date: Tuesday ### Time: ### Room: ### Chairs: Tim Wicinski ### Chairs: Suzanne Woolf ## Secretary: Paul Hoffman [DocList](https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html) [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/) --- # Agenda ## Agenda Bashing, Blue Sheets, etc, 10 min ## Updates of Old Work, Chairs, 5min ## Current Working Group Business ### draft-ietf-dnsop-terminology-bis, Hoffman, 10min https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ action: get some more reviews and determine how far from WGLC ### draft-ietf-dnsop-dns-capture-format, Dickinson, 10min https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ outstanding: how to store malformed packets ### draft-ietf-dnsop-rfc5011-security-considerations, Hardaker, 15min https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ outstanding: Mike's issues with multiple-key wording ### draft-ietf-dnsop-aname, van Dijk, 15min https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ action: next steps? ### draft-ietf-dnsop-session-signal, Dickinson, 10min https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ action: Enough reviews? Is it ready for WGLC? ### draft-woodworth-bulk-rr, Lawrence, 10min https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ action: new simplified version, adoption? ## New Working Group Business ### Serve Old Data or Prefetch ? ### draft-tale-dnsop-serve-stale, Lawrence, 15min https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ ### draft-muks-dnsop-dns-opportunistic-refresh, Morris, 15min https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-opportunistic-refresh/ action: compare/contrast versions ## End of Session I --- Session II ### Date: Thursday 20 July 2017 ### Time: 18:10-19:10 CEST (UTC+2) ### Room: Grand Hilton Ballroom --- # Agenda ## Agenda Bashing, Blue Sheets, etc, 10 min ## New Working Group Business ### draft-bellis-dnsop-xpf, van Dijk, 10min https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ ### draft-wkumari-dnsop-extended-error, Kumari(?), 10min https://datatracker.ietf.org/doc/draft-wkumari-dnsop-extended-error/ ### draft-tale-dnsop-edns0-clientid, Lawrence, 10min https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ ### draft-edmonds-dnsop-capabilities, Edmonds, 10min https://datatracker.ietf.org/doc/draft-edmonds-dnsop-capabilities/ From nobody Tue Jul 4 04:55:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09775131FCA for ; Tue, 4 Jul 2017 04:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 4pA_rjqwnAxN for ; Tue, 4 Jul 2017 04:55:25 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10F8131FC9 for ; Tue, 4 Jul 2017 04:55:24 -0700 (PDT) Received: from [46.227.151.81] (port=52931 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dSMQL-0001oE-V5 (Exim 4.72) for dnsop@ietf.org (return-path ); Tue, 04 Jul 2017 12:55:21 +0100 To: dnsop@ietf.org References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <22874.57189.46244.876797@gro.dd.org> <978e9cc3-c5d9-87fb-8878-229f4a4c28aa@gmail.com> From: Ray Bellis Message-ID: Date: Tue, 4 Jul 2017 12:55:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <978e9cc3-c5d9-87fb-8878-229f4a4c28aa@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:55:27 -0000 On 04/07/2017 11:40, Tim Wicinski wrote: > > On 7/4/17 6:13 AM, Paul Wouters wrote: >> >> Although, we should also be a bit careful not to create a new ANY >> type query that will get abused for amplification, so it should >> really all have source verified IP transports (DNS-COOKIES, TCP, >> etc) > > The is good guidance, and some wording like this would be useful in > the qtypes draft. I'd rather not constraint this to source verified transports. There's a limit of 7 additional QTYPEs in the draft, which could be trivially reduced to 3 (with little effect on the functionality) if that would mitigate concerns about amplification. Ray From nobody Tue Jul 4 05:14:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF5A131FE5; Tue, 4 Jul 2017 05:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 CPnIGDvARHKu; Tue, 4 Jul 2017 05:14:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 B6B22131FE3; Tue, 4 Jul 2017 05:14:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dSMix-0005p6-Kq; Tue, 04 Jul 2017 12:14:35 +0000 Date: Tue, 04 Jul 2017 14:14:34 +0200 Message-ID: From: Randy Bush To: Ralph Droms Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 12:14:40 -0000 >>> The Special-Use Domain Names Problem Statement document unsurprisingly >>> contains a list of problems. >> >> is there a companion document with the list of benefits/advantages? > > It's a list of problems, not solutions, so there aren't benefits > and/or advantages. so there are no advntages to special use domain spaces. got it. >> or is thins just one of those ietf documents from on high meant to >> kill something? i guess so, eh? randy From nobody Tue Jul 4 06:23:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C767131441 for ; Tue, 4 Jul 2017 06:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_PASS=-0.001] autolearn=unavailable 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 qJXU3AuLqCYg for ; Tue, 4 Jul 2017 06:23:39 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 A1B1312762F for ; Tue, 4 Jul 2017 06:23:39 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id r30so165141717qtc.0 for ; Tue, 04 Jul 2017 06:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ou7b3m34UhCdE18S0bqD1OlTy4/NP2PQg/oUQVl3xxk=; b=1TohnQB2C+AACdtEua6w4WE97ExxTZdUAKIvqEm6MpIcPfnAw7ERd/Afg0N6YfKKpE fHCIh4962spgUYvh7xzHEjrzYm7gm/V1/1nW3n++JG/5Jg2T+N+N8DfPtzZMJxk18vMh jyy9NebhvLnt2LS09Vm+DoSpRsLnps/hiuA2btAfLUJhModduqF2F5JyA6DkWbBRQUpj qUsAcpltQlyCSx0B3sH7vTOcfMuGX1I5Km7OubqtzYsz2RH/VeMm0VsLkKsOqLtNDt25 rLczHgZ93GmaWSVjnOZJoCuZHgQNdpRyIUkMK/E0Bc1mePdvXQ0++A00g7eWGiahCekv BaKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ou7b3m34UhCdE18S0bqD1OlTy4/NP2PQg/oUQVl3xxk=; b=gHpXJpSWnfiy3gaAU7rgvI280Ipp+v2rguTeKX9amNo0MzazFP+64UIDFAXlNGff09 8FV1KyYENEBdCjIu/ksAgVneeVGgHvZmI/WZ7BV8dmxPOKViMBZ/uHQHrZre1Z9MHb4B RNbLaPszKyUgnwll99VC8A4iAVBLM0l98ESw6qZGKzG5n5l+GCZZjGL0b76EBVC34Xv+ 4gKzBJIPYwe6JHapASjzAquwe9M1AbbarEXu+cN4XH6Rd2g+SsdJ24BlsfaPFN53BhBZ iz37YCzrfjWjZ88GooLGC6HB3v0xR0ff3CARkKoJ/X7RjLIzSSDOB8px0qqO4NjVUcwB H65A== X-Gm-Message-State: AKS2vOxMPZKfiHR2Hj129NaWlz4xvNtL1WLWnAnKp3Vb3HBuK7SpXB2c o7acy7/Oqy/KdmliP5IkCA== X-Received: by 10.237.34.196 with SMTP id q4mr40864807qtc.39.1499174618803; Tue, 04 Jul 2017 06:23:38 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id f29sm15771305qtc.13.2017.07.04.06.23.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 06:23:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: Date: Tue, 4 Jul 2017 09:23:37 -0400 Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 13:23:42 -0000 On Jul 4, 2017, at 3:39 AM, Randy Bush wrote: > is there a companion document with the list of benefits/advantages? or > is thins just one of those ietf documents from on high meant to kill > something? This is a very good question. We weren=E2=80=99t asked to answer that questi= on, so we didn=E2=80=99t. It is assumed throughout the document that variou= s proponents of special use domains have good reasons for wanting them, and f= urther that it is already accepted in principle that if their reason for wan= ting them is valid, they can have them (modulo technical constraints like de= legation). So we didn=E2=80=99t delve into that. But perhaps we should have.= =20= From nobody Tue Jul 4 06:37:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204DD13160E; Tue, 4 Jul 2017 06:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 IU8FRxGzJfDA; Tue, 4 Jul 2017 06:37:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2FC7C131613; Tue, 4 Jul 2017 06:37:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dSO0l-0000hd-5t; Tue, 04 Jul 2017 13:37:03 +0000 Date: Tue, 04 Jul 2017 15:37:02 +0200 Message-ID: From: Randy Bush To: Ted Lemon Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 13:37:08 -0000 >> is there a companion document with the list of benefits/advantages? >> or is thins just one of those ietf documents from on high meant to >> kill something? >=20 > This is a very good question. We weren=A2t asked to answer that > question, so we didn=A2t. how depressing. one obvious curiousity is who asked the one-sided question? otoh, maybe i don't want to know. but i wish you had perceived a wider responsibility to the community. randy From nobody Tue Jul 4 06:42:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9CC13189E for ; Tue, 4 Jul 2017 06:42:11 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 h9itor0Vq1gl for ; Tue, 4 Jul 2017 06:42:10 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 23DD41315FE for ; Tue, 4 Jul 2017 06:42:10 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id b40so57126440qtb.2 for ; Tue, 04 Jul 2017 06:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bFtdKImyVeWgMcWbEVh+l51Oz8dDVKMn9yJXspDRaik=; b=o4ffzbXpnQNnWcPwkCozdShAFN0x+GvaMOzFegL5CiMU4ehb51Zr+PtBeek+nMtIlo zdIzJ0HRg7udTHRk/I/FcefHXCR8hNaeY3QzcC1HO7zsu1D6eY1IYAATNtbM/H6Pv6mb y/X99aVN0G4fL/7/iS68kzMxNdz1J0eeoNS3b+uNWc2NNSLpK3wB1JVvRDZCS+aw4SQa O8u+v5C9C2Mgs3BPHM65nno+21AcXNuN2xHexn1lKx2esZePRt43le7IVB60/LAUDz2B e0K6BfY9qgYVLHms5HC0CeM7haptoR7CoZJolSb0Nadj33Co+fyvrt8p1MKGnNA6Ti0P 4gUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bFtdKImyVeWgMcWbEVh+l51Oz8dDVKMn9yJXspDRaik=; b=YEeN5OyLMhfvjRQld3o95t5clrKsuZ4y8cp6dTVZChBLbKwdDnpiqsGWq8O+42hVF6 uVVs3ZM4jVMZtHxY57xf8zuqVKx/KfEtkHQolADQwU6GSmPwbiZPeelb9RLHjH8byExu 0enRAonjm7iTyX9Wb0p3CApKpPNQR2MEHT91sKFAletAOQBeCqAGtQfXyuiN4PA40jsp yEnrN2j7/3v7QO7+XrKrOUNBpJcqhd4YjBBpeffXb06wKgzow1FfU36AdXHc4Qp8c3V4 NtL8GPQfeHnvrBO5r0UEPUDCzyxBra/O05oYhSS25ScnWRT8kae/YQMGbujbd4LfGuu2 bOMA== X-Gm-Message-State: AIVw112sqTPmicjsiPVOwXsgAlvTK1iK7Mr6BDdz1LUut6pqrN95MQnc K3y+S53vJZIM9Tjp X-Received: by 10.237.48.225 with SMTP id 88mr17839861qtf.17.1499175729237; Tue, 04 Jul 2017 06:42:09 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j75sm13632154qke.34.2017.07.04.06.42.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 06:42:08 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C7F39176-8C3A-4238-8F80-116006D97642 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: Date: Tue, 4 Jul 2017 09:42:07 -0400 Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat Content-Transfer-Encoding: 7bit Message-Id: References: To: Randy Bush Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 13:42:12 -0000 --Apple-Mail-C7F39176-8C3A-4238-8F80-116006D97642 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Jul 4, 2017, at 9:37 AM, Randy Bush wrote: > how depressing. one obvious curiousity is who asked the one-sided > question? otoh, maybe i don't want to know. but i wish you had > perceived a wider responsibility to the community. It was discussed at length in the working group, so I would say that you cou= ld In principle have raised this concern sooner. However, I will admit that i= t didn=E2=80=99t occur to me to do so either. In any case, it really is a se= parate issue from that covered by this draft, and so there=E2=80=99s no reas= on why we can=E2=80=99t do this work if you think it=E2=80=99s worth doing. G= iven the situation with ICANN and GTLD, it may be moot, but I wouldn=E2=80=99= t mind writing it down.=20= --Apple-Mail-C7F39176-8C3A-4238-8F80-116006D97642 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 4, 2017, at 9:37 AM,= Randy Bush <randy@psg.com> wrote= :
how depressing.  one obviou= s curiousity is who asked the one-sided
question?  otoh= , maybe i don't want to know.  but i wish you had
perce= ived a wider responsibility to the community.

<= div>It was discussed at length in the working group, so I would s= ay that you could In principle have raised this concern sooner. However, I w= ill admit that it didn=E2=80=99t occur to me to do so either. In any case, i= t really is a separate issue from that covered by this draft, and so there=E2= =80=99s no reason why we can=E2=80=99t do this work if you think it=E2=80=99= s worth doing. Given the situation with ICANN and GTLD, it may be moot, but I= wouldn=E2=80=99t mind writing it down. 
= --Apple-Mail-C7F39176-8C3A-4238-8F80-116006D97642-- From nobody Tue Jul 4 06:53:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B02131490; Tue, 4 Jul 2017 06:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 MAustTeXrJ3c; Tue, 4 Jul 2017 06:53:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 854B013148B; Tue, 4 Jul 2017 06:53:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dSOGa-0000kc-Pe; Tue, 04 Jul 2017 13:53:24 +0000 Date: Tue, 04 Jul 2017 15:53:24 +0200 Message-ID: From: Randy Bush To: Ted Lemon Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 13:53:28 -0000 >> how depressing. one obvious curiousity is who asked the one-sided >> question? otoh, maybe i don't want to know. but i wish you had >> perceived a wider responsibility to the community. >=20 > It was discussed at length in the working group, so I would say that > you could In principle have raised this concern sooner. However, I > will admit that it didn=A2t occur to me to do so either. In any case, it > really is a separate issue from that covered by this draft, and so > there=A2s no reason why we can=A2t do this work if you think it=A2s worth > doing. Given the situation with ICANN and GTLD, it may be moot, but I > wouldn=A2t mind writing it down. we really should not cover our eyes when we send in the assassins. i would offer to put my keyboard where my mouth is. but i fear that, at the bottom, i would have the unreasonable desire for dns classes to support these kinds of things. i.e. i don't think we have a clean fix. but it would be nice to document the good with the bad. randy From nobody Tue Jul 4 07:01:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE6C129459 for ; Tue, 4 Jul 2017 07:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_PASS=-0.001] autolearn=unavailable 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 N5DPhKS-XFRA for ; Tue, 4 Jul 2017 07:01:25 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 F0A8913155F for ; Tue, 4 Jul 2017 07:01:24 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id r30so165923782qtc.0 for ; Tue, 04 Jul 2017 07:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qqDIJrAAbRttRwWVLjKPD1QDEqnQh818CMDMsLr+Gfk=; b=xd21q5juZyMUWYfs3J+eyvvOo2Y0WfZG4Q4ujCC2voJPJ46ir7g8IOjh6AfTRcqTQh hpdmR44kbXBpCMHckDU6NDTEoU47u9tr2ILzbedSuY+/eMpWa1GPCofdFoph9w353x+5 7mBn1LJZbz+Il5XyLEreTCyY1zpGOkUsQpeZ6LQOCAIyCSuiDe9GDoaxdW+VHutBZQBD 60pIovL58crfICwToujpmnOnAfLm5n4npuK4yfMtNuiG7h8rDZEXSGoZ3UBrjwq1wTMa ziL3lvCDGBCt2DbG6lCdh+wqcrCuy2BthPW7/2RBq2cgHdxr8FpyR1TtL+F/QLtSkg7z oOZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qqDIJrAAbRttRwWVLjKPD1QDEqnQh818CMDMsLr+Gfk=; b=aGK+hF1XZBKvUeueJwj5/1SQSjC6oE1fisxfIe3UfI5gxYAKJule5a6DEd/vykJiF+ yGr3K/V9uTIO8u9X6NxE4MZznrPvHO/dNY9hH9YbFvXmGmOKB+RQRQo1bRXIfDA8puCp 5QxbvSA3RGaWvJfhF4DLebRKBGEr7+kR1Juj63qdMgXWZynUx/bHBr27kACoJJ5TD+tv LATjggs2yU/scY+g12Ly8MjM9GhXqwMPbOoz0rvTBNM+eXe0y4+QNrFKogBrtgvFRoXK ygOdmk5yPkBjeYnThB+85zwnvYypodknRBArLvG8uzGUeLa2jQ3M//SypLHUmIY/0doQ D8HQ== X-Gm-Message-State: AKS2vOwzI6mSQ3wCcmuiHSbn5znVEEx1GAa+Br1b53H+KzJCRHnai10K 1eQB2qwc7miBuIqQ X-Received: by 10.200.53.11 with SMTP id y11mr46176003qtb.98.1499176883861; Tue, 04 Jul 2017 07:01:23 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id a6sm14737541qtc.54.2017.07.04.07.01.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 07:01:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: Date: Tue, 4 Jul 2017 10:01:21 -0400 Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> References: To: Randy Bush Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:01:27 -0000 On Jul 4, 2017, at 9:53 AM, Randy Bush wrote: > i would offer to put my keyboard where my mouth is. but i fear that, at > the bottom, i would have the unreasonable desire for dns classes to > support these kinds of things. i.e. i don't think we have a clean fix. > but it would be nice to document the good with the bad. That sounds like a solution, not a motivation. That is, you care about the p= roblem hypothetically, and have a hypothetical solution. In practice when we= =E2=80=99ve talked about using dns classes to solve problems that have motiv= ated rfc6761 allocations, it hasn=E2=80=99t really helped, because the infra= structure required to use them this way is not present, and this isn=E2=80=99= t how they were originally intended to be used. For example, is ICANN.org with a different class not a subdomain of the .org= TLD? Would ICANN not object to us designating it for use by someone else? I= suspect yes, and I wouldn=E2=80=99t blame them.=20= From nobody Tue Jul 4 07:03:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E5912EB21; Tue, 4 Jul 2017 07:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 g6yEsN2BvBSD; Tue, 4 Jul 2017 07:03:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3A5A0129459; Tue, 4 Jul 2017 07:03:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dSOQS-0000mg-Ib; Tue, 04 Jul 2017 14:03:36 +0000 Date: Tue, 04 Jul 2017 16:03:35 +0200 Message-ID: From: Randy Bush To: Ted Lemon Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat In-Reply-To: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:03:39 -0000 >> i would offer to put my keyboard where my mouth is. but i fear that, >> at the bottom, i would have the unreasonable desire for dns classes >> to support these kinds of things. i.e. i don't think we have a clean >> fix. but it would be nice to document the good with the bad. >=20 > That sounds like a solution, not a motivation. That is, you care about > the problem hypothetically, and have a hypothetical solution. In > practice when we=A2ve talked about using dns classes to solve problems > that have motivated rfc6761 allocations, it hasn=A2t really helped, > because the infrastructure required to use them this way is not > present, and this isn=A2t how they were originally intended to be used. >=20 > For example, is ICANN.org with a different class not a subdomain of > the .org TLD? Would ICANN not object to us designating it for use by > someone else? I suspect yes, and I wouldn=A2t blame them. sorry. maybe it would have helped if i had put UNREASONABLE DESIRE in upper case. randy From nobody Tue Jul 4 07:06:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF481320B2 for ; Tue, 4 Jul 2017 07:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 nCLHskr_xjVF for ; Tue, 4 Jul 2017 07:05:55 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 3457612EB21 for ; Tue, 4 Jul 2017 07:05:55 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id 16so169296699qkg.2 for ; Tue, 04 Jul 2017 07:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=84hX1flnV8x3PibXq/MhOrbKDKCqUUhditv1DONSdVg=; b=ig1A/6qHG7loInofDahBCojzsidvouEelO+80WWf//y2aNQVN+vI+fyKPdUfr/ANIs yC8suDAnuDCQ/zkhmQhRX9TTFwetBTRN7D5r8NM1JJT+KQ3o0LkLtbDPv2QUxIILDwfI uiO2ajj8H2ph56KFllvn4GzZSxOj5JHRb09R5eCVLubXxx8nXVOyWb2uVMz4XlXG0pW8 omVEMqbj5xHLTY+RWR3PqcuSHRjsCwDUepggY3BktUzDBpSnstXJSz0qhI3HOUSdRUkL SI2YyOQdzrVpPFAJXF081WIH2WR8Xt223txMr27mZOY5MqobkiTbrrUEL2B+DXF8oHx3 oCng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=84hX1flnV8x3PibXq/MhOrbKDKCqUUhditv1DONSdVg=; b=kfeJPq73zP4k1InjveS83KUq1n7k9qQ+ulYBdLEz54H9D25gdOJwt0E0Oa0yAh/j5M wckWy4+EiAKSoPKb2P1nlhBoDUQCsdxBEKk2nSpzheLWzy7srMPcSAWLL4wyaxF0xp52 kA6neo9Rj/b+Ax1DLVaDRXLTx5v4M45SfLr9+CLj23i8EplnGqqOaY+etk7pawIZWtlm a10EPn8G4XECCdvrgA1floe4LzZG/YJ4yJk7OtBgf1oBOWIW80PTZzFSioweyf09Y0ns o3XLxiHm3XXWxGQmqrFZBtgZ4/S+DOFkYDtxOm8qrObOPxx7EeymxuKX61W1e1NOoNnH eTNw== X-Gm-Message-State: AIVw110Ipl2xCtfXZMY4MN8OY6yT9dWOELjIxN3CosUdGsdEE5xfd9i/ T/wsQ3L5WkEAl1by76g8mg== X-Received: by 10.55.52.202 with SMTP id b193mr29012005qka.220.1499177154349; Tue, 04 Jul 2017 07:05:54 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b64sm13510753qkc.32.2017.07.04.07.05.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 07:05:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: Date: Tue, 4 Jul 2017 10:05:53 -0400 Cc: Warren Kumari , dnsop@ietf.org, IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: <4165F4C5-6A4E-4993-8517-A7AD50AA67B3@fugue.com> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> To: Randy Bush Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:05:57 -0000 On Jul 4, 2017, at 10:03 AM, Randy Bush wrote: > maybe it would have helped if i had put UNREASONABLE DESIRE in > upper case. My point was just that this wouldn=E2=80=99t be a description of what we mig= ht want to accomplish with special-use names.=20= From nobody Tue Jul 4 08:43:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B681320F6 for ; Tue, 4 Jul 2017 08:42:59 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rVuDDjXCo9Ct for ; Tue, 4 Jul 2017 08:42:57 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 A04581320F4 for ; Tue, 4 Jul 2017 08:42:57 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id g40so128877184uaa.3 for ; Tue, 04 Jul 2017 08:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VkiST58YIOBJZVQaq9w0aaKK1e8Awg1iyC2nGQiBUJI=; b=cbwAhhR6v6eWxYlbuQxOBm8r/VUvRZQCVpxezkk3si3km0qyoRZqeCL23aeOWii6vR P5WcYdyv2LYauzo3Jy2RbfUtk3CfIYnE39exV3A1mo09TAhCVpdgJ3D78YEmMj3VjAeA Xy3rUig7uOva/9VhHvwM4utSqOPkFqcs+PSVuoU56WimDmkSX45+Q88s37t+lXv6bZD1 PxlZmmhmHCLc664wg/IOUwD8YkS0Elfa7ksz1jwS6hKr+t32P5L1lz/M0hw5OTl7Cjnm FWNT/ABxVmqu0J6DnkxsKh8kJDF1Yb5u+aplQhpaPp8Ea959xeXakSzsT5sDe0LO03F/ 5EBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VkiST58YIOBJZVQaq9w0aaKK1e8Awg1iyC2nGQiBUJI=; b=pxBX9CvAcqLvj0XmzGvrTgd6UULIs5ih7Xyllrhtix9ZFdcOw99CiD5C9gA9TnRY/Q buk1CmpncRaB66TJh6fc1qy4hYsBlywllQ4vHrG8Bu02Z9sBbmvlPuwrUW9XIaGFUUVP J4b+8MK3jIRS+aRbJ2GbTG98B83UKsMUGHbCuq5cSnHYYq3H0PscH+P/TPWMzNCLXDI9 2xHaLsqKuSXOq+zL8nEPF8ndRhVnBd3e5a7zYgFDEMVXfi9Yy3N5i/oYyRpAbmz2nNut zrVThUgd8QgxzbX872jh0ETAX8FxRNU0YiKhHgcv35lTLmxsokaz0HRQf6AeERT3n3Uz u9fw== X-Gm-Message-State: AKS2vOzlCiR13q1SwvKkVGQOFzSG2qSpViDAh/l5Zvw6/lPY1oDUuowx NbKfJ8wl9zfP2BTRGIEmvoHa5cZC4yRIiMY= X-Received: by 10.176.66.34 with SMTP id i31mr17604250uai.11.1499182976521; Tue, 04 Jul 2017 08:42:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Tue, 4 Jul 2017 08:42:56 -0700 (PDT) From: Shumon Huque Date: Tue, 4 Jul 2017 11:42:56 -0400 Message-ID: To: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c088606c4d91105537fbc74" Archived-At: Subject: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 15:43:00 -0000 --94eb2c088606c4d91105537fbc74 Content-Type: text/plain; charset="UTF-8" Hi folks, We've posted a new draft on algorithm negotiation which we're hoping to discuss at IETF99 (and on list of course). I've discussed this topic with several folks at DNS-OARC recently. https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Algorithm Negotiation in DNSSEC Authors : Shumon Huque Haya Shulman Filename : draft-huque-dnssec-alg-nego-00.txt Pages : 9 Date : 2017-07-03 Abstract: This document specifies a DNS extension that allows a DNS client to specify a list of DNSSEC algorithms, in preference order, that the client desires to use. A DNS server upon receipt of this extension can choose to selectively respond with DNSSEC signatures using the most preferred algorithm they support. This mechanism may make it easier for DNS zone operators to support signing zone data simultaneously with multiple DNSSEC algorithms, without significantly increasing the size of DNS responses. It will also allow an easier way to transition to new algorithms while still retaining support for older DNS validators that do not yet support the new algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-huque-dnssec-alg-nego/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-00 -- Shumon Huque --94eb2c088606c4d91105537fbc74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

We've posted a new draft = on algorithm negotiation which we're hoping to discuss at IETF99 (and o= n list of course). I've discussed this topic with several folks at DNS-= OARC recently.



A New Internet-Draft is available from the on-line Internet-Drafts = directories.


=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Algorithm Negotiation in = DNSSEC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : Shumon Huque
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Haya Shulman
=C2=A0Filename =C2=A0 =C2=A0 =C2=A0= =C2=A0: draft-huque-dnssec-alg-nego-00.txt
=C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 9
=C2=A0Date =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2017-07-03

Abstract:=
=C2=A0 =C2=A0This document specifies a DNS extension that allows= a DNS client to
=C2=A0 =C2=A0specify a list of DNSSEC algorithms= , in preference order, that the
=C2=A0 =C2=A0client desires to us= e.=C2=A0 A DNS server upon receipt of this extension
=C2=A0 =C2= =A0can choose to selectively respond with DNSSEC signatures using the
=
=C2=A0 =C2=A0most preferred algorithm they support.=C2=A0 This mechani= sm may make it
=C2=A0 =C2=A0easier for DNS zone operators to supp= ort signing zone data
=C2=A0 =C2=A0simultaneously with multiple D= NSSEC algorithms, without significantly
=C2=A0 =C2=A0increasing t= he size of DNS responses.=C2=A0 It will also allow an easier
=C2= =A0 =C2=A0way to transition to new algorithms while still retaining support= for
=C2=A0 =C2=A0older DNS validators that do not yet support th= e new algorithms.


The IETF datatrac= ker status page for this draft is:

There are also = htmlized versions available at:

--= =C2=A0
Shumon Huque

--94eb2c088606c4d91105537fbc74-- From nobody Tue Jul 4 10:33:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB671319B0; Tue, 4 Jul 2017 10:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 azdrRrwCM5fS; Tue, 4 Jul 2017 10:33:00 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 D50551325B2; Tue, 4 Jul 2017 10:32:59 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id h64so74502921iod.0; Tue, 04 Jul 2017 10:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u9R+FPH+CbDy52TpOQuT4IozacrJVOeMrm+FLvBugsM=; b=pYgYMR7wQk26OgfH6EKW3nOCUd3XD56ARmik5E4huIS38A/YiWrFnL5d2XSkNRjq5I 41T50wQnGE3aedzTMRCyXPaCYgO41ySLBoSskapP2La+FGFMWqu0DVsJkg5wTDnSNyEC 8Z/5CJhcO2GpxBfLWSmNvRNVzYsnmDY7MyzFIAHwvGP3Kc9a5AOc3+n/xlO619JWwvs7 hmLOORnGNGUaIJ25w4I0ajJbXQTSFcmvv1RC8cVhWkaveTSnjfzeincl4DONfnh+ntiU yF3W3jtuWS096rACyICoia+Y+rEBlrhafSoYqN5I4jCb9pQ09azEET8BUPqKXOxHtEQg Yq2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u9R+FPH+CbDy52TpOQuT4IozacrJVOeMrm+FLvBugsM=; b=Q6oJe7Pncg6mrsjJjnjfWUEzox1BEk4vHgxXuqaZzzLAF4tDVG/a4lDTGYmY4v04W2 C3DaD4kI0AR2mMWEGy0SNLIV9QOXbdVwCb7h8Aunkv2OtxLEVYAq7XYD37/WHspEuG9f DHLOPyIFTLRjNQQpLdfEZJjZ/+O9LYzZubXJuw4yetRLsiwZg7u/qhskTReWDtE7MJRq K4jzbi4rLPa6/0sWpG50ojOnYBLO97wJtzoNYeMrSTzclzYI45bCPyEa15igHUQwP61c DRmIBMJ7SzU04Qz/hgx2rogxFtLE1/gJag2weRwlaQOUwAvrdkd3Mq5aBsYyrmLOA3GG 1xQw== X-Gm-Message-State: AKS2vOwpbeHeWj3JabBn/sHexa4zqFItuLW7iO+gbaEv11OeK/zZqYMO gZcDh7sE321Qxrru0kiTPuVdTDWAXw== X-Received: by 10.107.184.8 with SMTP id i8mr40003825iof.153.1499189579236; Tue, 04 Jul 2017 10:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.170 with HTTP; Tue, 4 Jul 2017 10:32:58 -0700 (PDT) In-Reply-To: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> From: william manning Date: Tue, 4 Jul 2017 10:32:58 -0700 Message-ID: To: Ted Lemon Cc: Randy Bush , dnsop , IETF Rinse Repeat Content-Type: multipart/alternative; boundary="94eb2c07712a525b2f05538146c4" Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:33:02 -0000 --94eb2c07712a525b2f05538146c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I find Randys line of discussion mirroring my own thoughts. And to answer your question above, technically, the TLD org. is a member of the IN class, so in the OF class, it is credible to posit the existence of a org. TLD. TLDs are per class... :) /Wm On Tue, Jul 4, 2017 at 7:01 AM, Ted Lemon wrote: > On Jul 4, 2017, at 9:53 AM, Randy Bush wrote: > > i would offer to put my keyboard where my mouth is. but i fear that, a= t > > the bottom, i would have the unreasonable desire for dns classes to > > support these kinds of things. i.e. i don't think we have a clean fix. > > but it would be nice to document the good with the bad. > > That sounds like a solution, not a motivation. That is, you care about th= e > problem hypothetically, and have a hypothetical solution. In practice whe= n > we=E2=80=99ve talked about using dns classes to solve problems that have = motivated > rfc6761 allocations, it hasn=E2=80=99t really helped, because the infrast= ructure > required to use them this way is not present, and this isn=E2=80=99t how = they were > originally intended to be used. > > For example, is ICANN.org with a different class not a subdomain of the > .org TLD? Would ICANN not object to us designating it for use by someone > else? I suspect yes, and I wouldn=E2=80=99t blame them. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c07712a525b2f05538146c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I find Randys line of discussion mirroring my own thoughts= .
And to answer your question above, technically, the TLD =C2=A0org. = =C2=A0is a member of the IN class, so in the OF class, it is credible to po= sit the existence of =C2=A0a org. TLD. =C2=A0 TLDs are per class... :)

/Wm

On Tue, Jul 4, 2017 at 7:01 AM, Ted Lemon <mellon@fugue.= com> wrote:
On Jul 4, 2017, at 9:53 AM, Randy Bush <randy@psg.com> wrote:
> i would offer to put my keyboard where my mouth is.=C2=A0 but i fear t= hat, at
> the bottom, i would have the unreasonable desire for dns classes to > support these kinds of things.=C2=A0 i.e. i don't think we have a = clean fix.
> but it would be nice to document the good with the bad.

That sounds like a solution, not a motivation. That is, you care abo= ut the problem hypothetically, and have a hypothetical solution. In practic= e when we=E2=80=99ve talked about using dns classes to solve problems that = have motivated rfc6761 allocations, it hasn=E2=80=99t really helped, becaus= e the infrastructure required to use them this way is not present, and this= isn=E2=80=99t how they were originally intended to be used.

For example, is ICANN.org with a different class not a subdomain of the .or= g TLD? Would ICANN not object to us designating it for use by someone else?= =C2=A0 I suspect yes, and I wouldn=E2=80=99t blame them.
______________________________= _________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c07712a525b2f05538146c4-- From nobody Tue Jul 4 10:34:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3021325BF for ; Tue, 4 Jul 2017 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 a-XKCj7PT4oW for ; Tue, 4 Jul 2017 10:34:19 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812211325CD for ; Tue, 4 Jul 2017 10:34:19 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 1F1223F438; Tue, 4 Jul 2017 13:34:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22875.53658.41129.178074@gro.dd.org> Date: Tue, 4 Jul 2017 13:34:18 -0400 From: Dave Lawrence To: dnsop@ietf.org In-Reply-To: References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <22874.57189.46244.876797@gro.dd.org> <978e9cc3-c5d9-87fb-8878-229f4a4c28aa@gmail.com> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:34:21 -0000 On 7/4/17 6:13 AM, Paul Wouters wrote: >> Although, we should also be a bit careful not to create a new ANY >> type query that will get abused for amplification, so it should >> really all have source verified IP transports (DNS-COOKIES, TCP, etc) Ray Bellis writes: > I'd rather not constraint this to source verified transports. > > There's a limit of 7 additional QTYPEs in the draft, which could be > trivially reduced to 3 (with little effect on the functionality) if that > would mitigate concerns about amplification. I very much agree with Ray about not constraining it like this. While for my own imagined use cases three is adequate, such as for querying MX, A and AAAA simultaneously, I also don't see any compelling reason to drop it from his proposed seven. In my own scheme I had planned on using a NSEC-like type bitmap, but having spoken with Ray about this a while ago I know he's not keen on that. To me the focus on answer size amplification is misdirected. I am far more concerned about packet count than packet size, and in any event constraining this option to only verified channels makes it immediately less useful. From nobody Tue Jul 4 10:39:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7731325FA for ; Tue, 4 Jul 2017 10:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 uLrN7eke84Xy for ; Tue, 4 Jul 2017 10:39:56 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 156131325DE for ; Tue, 4 Jul 2017 10:39:56 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id 16so173281013qkg.2 for ; Tue, 04 Jul 2017 10:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pRlYSSgOyURP5PuBxxe9IKT2XRNk5KXildLC8fmDj4Q=; b=tAqTfpShFgFY1AAYAYkp8N9u1JXsMO2TR/5SXiVte9VanIF3xYfmhknluCAaJ1dB1n +3yQ09sc41xKTMIS5UDeazIe2nSh8WcE7JEImYAc0YaeX8yM4tDXMw6IPjUP0FZnlhbE a5DYdVjEEELG75CgzQPSNy18eFGV3/ulEP0jdVa8xMf+JzfCgopD4o20TiJjFd360Iwj EPpFErzRCAThCAVyQ5WrBFf4QzOCBoC2WFVejIoFzabqLK8ZmcYaBw63kUDxVzpcZAVW XHPPO8tbk2u/eWSNJc5ftMn1lQDLXs+dpnMRdaai5YGRXn5XaVNk39sfg1PC8Msv4vUI 2zAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pRlYSSgOyURP5PuBxxe9IKT2XRNk5KXildLC8fmDj4Q=; b=cxVldC8xmDCpkfPqYBatYqmm2vs0mJ7BCt/6IvPmpT3CDL3hza+6Gznu7np6n5/nwh 7qDdwWIFOZfjpWx01c8lLhwxxcxZemDRnEerWYfgzg9V9qqo4HW+Gvxuox06ruQ/q3t4 mcslBZjdvDJK46xEdIP+kXejvfkFRagYrx7nJ3K9zeOh+RMNX/TNrTShn3aCb6Rab1Zr owYWiNqvtqJjQsSG3inrzK5Okscwq2j+K3DoQtDcAVT9XCWofXMbYkcFFCcqdS0hORgX Qv6DHhw/uRsLcfI/xLeaDSdA6fyONdISm07Qbo5lyulBrA0t6tXdibmsyDQcK+eCDs44 2KPg== X-Gm-Message-State: AKS2vOyc/sE8X/tbiME9fSFaG5LCTOHK7iy3peBgPME8hIJHnFrvGxwn tly2cjAw/jxhlLa1XErZ/A== X-Received: by 10.55.71.136 with SMTP id u130mr37057018qka.66.1499189995339; Tue, 04 Jul 2017 10:39:55 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 82sm16308392qkz.16.2017.07.04.10.39.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 10:39:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: Date: Tue, 4 Jul 2017 13:39:53 -0400 Cc: Randy Bush , dnsop , IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> To: william manning Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:39:58 -0000 On Jul 4, 2017, at 1:32 PM, william manning wrot= e: > I find Randys line of discussion mirroring my own thoughts. > And to answer your question above, technically, the TLD org. is a member= of the IN class, so in the OF class, it is credible to posit the existence o= f a org. TLD. TLDs are per class... :) Technically, yes. Would ICANN object? I=E2=80=99d be astonished if they did= not. Is there any practical value in an alternative class hierarchy? No. S= o it=E2=80=99s moot.=20= From nobody Tue Jul 4 10:49:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FE9132616; Tue, 4 Jul 2017 10:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6d35VTTAy3FQ; Tue, 4 Jul 2017 10:49:53 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA879132614; Tue, 4 Jul 2017 10:49:53 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B0F2261FF3; Tue, 4 Jul 2017 17:49:53 +0000 (UTC) Message-ID: <595BD53E.60701@redbarn.org> Date: Tue, 04 Jul 2017 10:49:50 -0700 From: Paul Vixie User-Agent: Postbox 5.0.15 (Windows/20170609) MIME-Version: 1.0 To: Ted Lemon CC: william manning , Randy Bush , dnsop , IETF Rinse Repeat References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> In-Reply-To: <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:49:56 -0000 Ted Lemon wrote: > On Jul 4, 2017, at 1:32 PM, william > manning wrote: >> I find Randys line of discussion mirroring my own thoughts. And to >> answer your question above, technically, the TLD org. is a member >> of the IN class, so in the OF class, it is credible to posit the >> existence of a org. TLD. TLDs are per class... :) > > Technically, yes. Would ICANN object? Id be astonished if they did > not. Is there any practical value in an alternative class hierarchy? > No. So its moot. while IETF governs the protocol, ICANN only governs the IN class. i expect that there will be other classes some day, in order to avoid some aspect of ICANN. but this is not that. -- P Vixie From nobody Tue Jul 4 10:53:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861FC132616; Tue, 4 Jul 2017 10:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 093ASE5-B0VT; Tue, 4 Jul 2017 10:53:41 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4073B13260E; Tue, 4 Jul 2017 10:53:41 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 305982421519; Tue, 4 Jul 2017 17:53:39 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <595BD53E.60701@redbarn.org> Date: Tue, 4 Jul 2017 18:53:38 +0100 Cc: Ted Lemon , Randy Bush , dnsop , IETF Rinse Repeat , william manning Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:53:42 -0000 > On 4 Jul 2017, at 18:49, Paul Vixie wrote: >=20 > while IETF governs the protocol, ICANN only governs the IN class. i = expect that there will be other classes some day, in order to avoid some = aspect of ICANN. Attempts have already been made to do just that. It would be nice not to = have to put out those fires all over again. From nobody Tue Jul 4 10:58:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2897132632 for ; Tue, 4 Jul 2017 10:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 a3g9dD3XqNYz for ; Tue, 4 Jul 2017 10:58:32 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 CF272132622 for ; Tue, 4 Jul 2017 10:58:31 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id 16so173576591qkg.2 for ; Tue, 04 Jul 2017 10:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4qn8CsmUp3VsJv1LXuhDtWSBYCrAZ0i8c5lergRSQ8U=; b=CBoJg9y19WxiAtNSE10Gsan7axBKZTvGcLOf3MBk7LTxERKUxZS5bWiBfLSrCmehcb bWXnCgtKXVzTIdOBU2C79Nwf3/M7mC5muEkig1NA2ezyS1b+etatndPDQPEy78pG0AcH mYZ6ZES8Zploe+AmU4n6xxbEZMWXbrWutpmpCADojNZXFyewXYmZB33BRsu0SxWhJI13 tW97fvSZTJ1/v2NjOcx86eQ9NtxWQofeNBwul3Sn5/qTJRbrpB5Wb2nFGjkf5nC3bEG6 rTYb1XukEQYN6z2/B/1O+smtnIkcpnxlh04HPIlyFUncNf7Q22Yih4qCRLJdhPamM1XI EBgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4qn8CsmUp3VsJv1LXuhDtWSBYCrAZ0i8c5lergRSQ8U=; b=EoD5Oh5Xhj09yw2BwyFnFMkKWmO6cFAkmZusBG6ikYqEKhlb4ThViWEDjcdyyQA1Hb fzptlAywEbW9SpQmfxN8ue0SO6XcrSKXgESMuxMJazHQ2dX1eRCsV2TCiexRqaFWIJWK E/eYGeLT7fRwV9SQZXhH5fhA30LeyJmCI75dYJ/RUBq6yaSLakXdxqOgFqkuLs1yjZ5Q nNfobzoYJcTJkYRfQy3tY12uLmUlN0trRVMBgCOQuuI+FAoS1u4swtrij0kz1EG84JC3 QowmlFG0N7l0Kj7joua6VQ4f1vLnBCpqsK26qZ5QGyeFockPZpRxLMKsvSZn+oHTseL3 +clA== X-Gm-Message-State: AIVw1121wzF0hCAEbkNwA00+BzrVYCilAdjIdv0+OeQKSTMBZ/8UGS5N qPS5xFCodzkCrZO3 X-Received: by 10.55.145.6 with SMTP id t6mr17575675qkd.101.1499191111009; Tue, 04 Jul 2017 10:58:31 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id o23sm15406937qko.67.2017.07.04.10.58.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 10:58:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: Date: Tue, 4 Jul 2017 13:58:29 -0400 Cc: Paul Vixie , Randy Bush , dnsop , IETF Rinse Repeat , william manning Content-Transfer-Encoding: quoted-printable Message-Id: <0E91DDA9-EFF5-4682-972D-95491A3DC22B@fugue.com> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> To: Jim Reid Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:58:40 -0000 On Jul 4, 2017, at 1:53 PM, Jim Reid wrote: > Attempts have already been made to do just that. It would be nice not to h= ave to put out those fires all over again. Realistically, at some point the damage the ICANN process has done will have= to get fixed, just like the damage the itu did got sort of fixed. Like tha= t case, the results will be messy. But we=E2=80=99ll all be gone by then, I s= uspect.=20= From nobody Tue Jul 4 10:59:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF0D132638; Tue, 4 Jul 2017 10:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 14UUa0-_O9uC; Tue, 4 Jul 2017 10:59:23 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58E4132630; Tue, 4 Jul 2017 10:59:18 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 970FF61FF3; Tue, 4 Jul 2017 17:59:18 +0000 (UTC) Message-ID: <595BD773.8050502@redbarn.org> Date: Tue, 04 Jul 2017 10:59:15 -0700 From: Paul Vixie User-Agent: Postbox 5.0.15 (Windows/20170609) MIME-Version: 1.0 To: Jim Reid CC: Randy Bush , dnsop , Ted Lemon , IETF Rinse Repeat , william manning References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:59:24 -0000 Jim Reid wrote: >> On 4 Jul 2017, at 18:49, Paul Vixie wrote: >> >> while IETF governs the protocol, ICANN only governs the IN class. i >> expect that there will be other classes some day, in order to avoid >> some aspect of ICANN. > > Attempts have already been made to do just that. It would be nice not > to have to put out those fires all over again. nobody ever got a bonus for making things simpler. so, look for growth, and look for it in complexity. -- P Vixie From nobody Tue Jul 4 11:12:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82491326F8 for ; Tue, 4 Jul 2017 11:12:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.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 mj7HDGwOZryJ for ; Tue, 4 Jul 2017 11:12:05 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 37CF3132705 for ; Tue, 4 Jul 2017 11:12:05 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id u62so112997725pgb.3 for ; Tue, 04 Jul 2017 11:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=Jexy41v/+ZGD/RsRqU2r1QcdaAAVQO273l/x2IdhIMI=; b=Myj3Fqigmn4hi3uTCqHoYSFcWobukSeh+J1KW0y5gXEzNbMwMvZt61qYNBKKDtjLCD /9Z5fxmMNp3Mxy0hdYIO46lTAezRDIpPAayi6AzI9J3j0CrU4AOkF/5poq24J9mQEA/q SkpCVsaXDa9UcbGQ2dQr4LlfR7h+4m7WakSou+x35aWVITbkr1r27lvRXG2F4R9TdpCc FY952cCgMvRHqFhLi02LXODiCUWNz8rhCXm51lCz80bbnTNuSv03Jdva0dCAZn9BV0JB yiqsYk7HMmn5cgHn1H+3S/ru/YsWZ0XGtX5lulvRaRtnjbkmsUI2Rz134vbvr9GzS8v2 oQBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=Jexy41v/+ZGD/RsRqU2r1QcdaAAVQO273l/x2IdhIMI=; b=pTFEFF0YcFr57Xdilife92dVBiDDH9k56jRBjTmisBysUnmrvYfJzyXG7uaAgPfhHK XsnhH+D8jiA0FDl6kG/r3NF3RVay8PIenoIaVek3UlXXSYDw0HQK3tdC1y99bjcyAiC1 5RxkZsLTBG4D10+NZPQ69WCM8XUkOzdSS4Rr71kd52Ax2TxGRFeJwn36C1/Fe80D9XrD 4n9cun+C0kPY+PDwMASO69hqq8GO4JizN9WrSB3gI+vnz7i/HKsXwQVvQbsZrifL55ou 1WOYNGCEIRx8FX6eO86FRDVSxoBTvtvViWB4xna2m1zXkVsv9eCBcS33hWJimCgI/Lkj +CZA== X-Gm-Message-State: AIVw111aPEU1ZbCNl/Y0Qj0sXW9Jrcx1l4t7lgNXJdvkEXc1Wy7TTBOx VfEmNGaOkv6w/ca2 X-Received: by 10.84.132.39 with SMTP id 36mr17555043ple.237.1499191924881; Tue, 04 Jul 2017 11:12:04 -0700 (PDT) Received: from [192.168.7.50] (c-24-6-172-77.hsd1.ca.comcast.net. [24.6.172.77]) by smtp.gmail.com with ESMTPSA id l22sm42659218pfb.55.2017.07.04.11.12.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 11:12:04 -0700 (PDT) Date: Tue, 4 Jul 2017 11:07:30 -0700 From: David Conrad To: Jim Reid , Paul Vixie Cc: Randy Bush , dnsop , Ted Lemon , IETF Rinse Repeat , william manning Message-ID: <5156fc17-9db9-4ddb-8e6f-4210243d8550@Spark> In-Reply-To: <595BD773.8050502@redbarn.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <595BD773.8050502@redbarn.org> X-Readdle-Message-ID: 5156fc17-9db9-4ddb-8e6f-4210243d8550@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="595bda71_643c9869_da49" Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:12:07 -0000 --595bda71_643c9869_da49 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Paul, On Jul 4, 2017, 10:59 AM -0700, Paul Vixie , wrote: > > > On 4 Jul 2017, at 18:49, Paul Vixie wrote: > > > while IET=46 governs the protocol, ICANN only governs the IN class.= Sorry, could you point me to anything that documents this=3F =C2=A0My imp= ression has always been that ICANN governs (I'd prefer the term coordinat= es myself) what =22the community=22 feels it should coordinate. I don't r= ecall this being limited to a particular DNS class, but I might have miss= ed it. > nobody ever got a bonus for making things simpler. Oh sure they have. Thanks, -drc --595bda71_643c9869_da49 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Paul,

On Jul 4, 2017, = 10:59 AM -0700, Paul Vixie <paul=40redbarn.org>, wrote:

On 4 Jul 2017, at 18:49, Paul = Vixie<paul=40redbarn.org> wrote:
while IET=46 governs the protocol, ICANN only governs the IN class. &=231= 60;

Sorry, could you point me to anything that documents this=3F &=23160= ;My impression has always been that ICANN governs (I'd prefer the term co= ordinates myself) what =22the community=22 feels it should coordinate. I = don't recall this being limited to a particular DNS class, but I might ha= ve missed it.

nobody ever got a bonus for ma= king things simpler. &=23160;

Oh sure they have.

Thanks,
-drc

--595bda71_643c9869_da49-- From nobody Tue Jul 4 11:22:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513E512896F; Tue, 4 Jul 2017 11:22:00 -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] 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 wbBqrpsxPtGW; Tue, 4 Jul 2017 11:21:58 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2BB13270A; Tue, 4 Jul 2017 11:21:55 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dSSSC-000622-Vs; Tue, 04 Jul 2017 14:21:40 -0400 Date: Tue, 04 Jul 2017 14:21:35 -0400 From: John C Klensin To: Jim Reid , Paul Vixie cc: dnsop , IETF Rinse Repeat , william manning Message-ID: <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> In-Reply-To: References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:22:00 -0000 --On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid wrote: >> On 4 Jul 2017, at 18:49, Paul Vixie wrote: >> >> while IETF governs the protocol, ICANN only governs the IN >> class. i expect that there will be other classes some day, in >> order to avoid some aspect of ICANN. > > Attempts have already been made to do just that. It would be > nice not to have to put out those fires all over again. Jim, Paul, First of all, if only because "QCLASS=ANY" is supposed to do something sensible, one really cannot have different, per-Class, roots (more of that argument and the difficulties for many of the things people have wanted to use CLASSes for in recent years appears in draft-sullivan-dns-class-useless). While I don't believe "useless", I don't see any hope for using the CLASS mechanism to "avoid ... ICANN". More important, given historical difficulties with adoption and broad deployment of new features, I suggest that anyone who sees ICANN avoidance as am important goal would find establishing an alternate root and building support for it far easily and more plausible than anything that could be done with CLASSes, if only because an ICANN-free class mechanism would, AFAICT, require a root (even for Class=IN) that was not controlled by ICANN anyway. Having enough of the world get aggravated enough at ICANN (or some other entity of one's choice) to make general adoption of an alternate root plausible is another matter and I don't think we are there, at least yet. The level of confusion and global inconsistencies that would accompany any transition to a different root and root management structure would be bad enough that I hope the day at which that aggravation threshold is reached does not come even if, ICANN seems to be trying some days. Those who are contemplating that sort of adventure might find at least parts of draft-klensin-dns-function-considerations amusing reading. In particular, Section 3.6 briefly addresses the topic of different CLASSes as a mechanism for doing new and different things (technical or administrative). best, john From nobody Tue Jul 4 11:39:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC8A132763; Tue, 4 Jul 2017 11:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 qdCOjBB0_E_V; Tue, 4 Jul 2017 11:39:21 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B20D132762; Tue, 4 Jul 2017 11:39:21 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8B68C61FF3; Tue, 4 Jul 2017 18:39:20 +0000 (UTC) Message-ID: <595BE0D5.5000106@redbarn.org> Date: Tue, 04 Jul 2017 11:39:17 -0700 From: Paul Vixie User-Agent: Postbox 5.0.15 (Windows/20170609) MIME-Version: 1.0 To: dnsop CC: IETF Rinse Repeat References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> In-Reply-To: <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:39:23 -0000 John C Klensin wrote: > > --On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid > wrote: > >>> On 4 Jul 2017, at 18:49, Paul Vixie wrote: >>> >>> while IETF governs the protocol, ICANN only governs the IN >>> class. i expect that there will be other classes some day, in >>> order to avoid some aspect of ICANN. >> Attempts have already been made to do just that. It would be >> nice not to have to put out those fires all over again. > > Jim, Paul, > > First of all, if only because "QCLASS=ANY" is supposed to do > something sensible, one really cannot have different, per-Class, > roots (more of that argument and the difficulties for many of > the things people have wanted to use CLASSes for in recent years > appears in draft-sullivan-dns-class-useless). While I don't > believe "useless", I don't see any hope for using the CLASS > mechanism to "avoid ... ICANN". half of the foundational specification of the dns protocol assumes that classes are inside rrsets. the other half assumes that zones are inside classes. when i started on bind in 1990 or so it tried to do both. by 1995 i had disambiguated in favour of zones-in-classes, and all others since then have done likewise. qtype=any was a casualty of that work. separately, i agree that using class to avoid icann would be useless, if by useless you mean "there's no way to create a competitor to IN". however, the chaos and hesiod classes did get used at varying times, and i can easily imagine something like bluetooth or appletalk or lopan (each of which has its own naming system, so, these aren't practical examples but rather theoretical ones) using the dns protocol on a different class, and passing ICANN like ships in the night. > Having enough of the world get aggravated enough at ICANN ... for those keeping score, i have been aggravated at ICANN, but am not now. i consider the recent transition away from NTIA, and the corporate governance changes made to enable that transition, to have been well considered and well executed, and to have benefited from almost two decades of experience and evolution. if i were designing a replacement for the dns protocol today, i would do all in my power to keep the "one internet, one namespace" element reflected by ICANN's current role. so, please don't misunderstand my participation in this thread as agitation for further evolutionary change. i think we're in a good place now. -- P Vixie From nobody Tue Jul 4 12:25:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF755132852 for ; Tue, 4 Jul 2017 12:25:42 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Jzwk4bDWYCgw for ; Tue, 4 Jul 2017 12:25:41 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 7D20F132851 for ; Tue, 4 Jul 2017 12:25:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3x2DVq2JXqz37q; Tue, 4 Jul 2017 21:25:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1499196339; bh=CZMHp96n7Vpkn9oe0VLQQceN8/wamtjti6WAfoWkBik=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MS2BguStVIRpD968CUeuOgzx3TdDs0TQokloy9tWySIIyPMmNVWfaWW52sjh9BFM9 OgF3FT3mycMwl1CWQeolEfIyqNYfccL3btpgcnwJedXRZ8AJXseN+z8bEYAcIawbx0 vLYmoL8gGdsK+hQXKjFNUPIz2gqjc+mwaPJ9llcY= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fwCd2U1JLkcI; Tue, 4 Jul 2017 21:25:38 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 4 Jul 2017 21:25:38 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A875730AF02; Tue, 4 Jul 2017 15:25:37 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A875730AF02 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A2E5A40D3592; Tue, 4 Jul 2017 15:25:37 -0400 (EDT) Date: Tue, 4 Jul 2017 15:25:37 -0400 (EDT) From: Paul Wouters To: Dave Lawrence cc: dnsop@ietf.org In-Reply-To: <22875.53658.41129.178074@gro.dd.org> Message-ID: References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <22874.57189.46244.876797@gro.dd.org> <978e9cc3-c5d9-87fb-8878-229f4a4c28aa@gmail.com> <22875.53658.41129.178074@gro.dd.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 19:25:43 -0000 On Tue, 4 Jul 2017, Dave Lawrence wrote: > While for my own imagined use cases three is adequate, such as for > querying MX, A and AAAA simultaneously, I also don't see any > compelling reason to drop it from his proposed seven. In my own > scheme I had planned on using a NSEC-like type bitmap, but having > spoken with Ray about this a while ago I know he's not keen on that. I think the bitmap would be great. Limiting it to some artificial special record types just causes people to avoid new records and abuse existing records. > To me the focus on answer size amplification is misdirected. I am far > more concerned about packet count than packet size, and in any event > constraining this option to only verified channels makes it > immediately less useful. Yes, reducing packet count and roundtrips is the obvious goal we all want, but we also want to avoid paying a DDOS price for it. Paul From nobody Tue Jul 4 13:29:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7339113177F for ; Tue, 4 Jul 2017 13:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 JXKAaMr4f0sy for ; Tue, 4 Jul 2017 13:29:55 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EFB12ECBC for ; Tue, 4 Jul 2017 13:29:55 -0700 (PDT) Received: from [46.227.151.81] (port=60655 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dSUSD-0004A0-Ug (Exim 4.72) for dnsop@ietf.org (return-path ); Tue, 04 Jul 2017 21:29:49 +0100 To: dnsop@ietf.org References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <22874.57189.46244.876797@gro.dd.org> <978e9cc3-c5d9-87fb-8878-229f4a4c28aa@gmail.com> <22875.53658.41129.178074@gro.dd.org> From: Ray Bellis Message-ID: Date: Tue, 4 Jul 2017 21:29:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 20:29:57 -0000 On 04/07/2017 20:25, Paul Wouters wrote: > I think the bitmap would be great. Limiting it to some artificial > special record types just causes people to avoid new records and > abuse existing records. My proposed option just uses the QTYPE number directly, so there's no limitation on record types except that they can't be for META RRs (i.e. OPT, and 128 - 255). My argument against using an NSEC style bitmap was that in the vast majority of cases it would result in a longer record (and one that's more complicated to decode) than a simple list of QTYPEs. Ray From nobody Tue Jul 4 14:02:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06565129B26 for ; Tue, 4 Jul 2017 14:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 oohg3nW4cUnp for ; Tue, 4 Jul 2017 14:02:38 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1C0127A91 for ; Tue, 4 Jul 2017 14:02:38 -0700 (PDT) Received: from tums.local (dhcp-181.access.lah1.vix.su [24.104.150.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 692D061FF3; Tue, 4 Jul 2017 21:02:38 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Cc: Ray Bellis Date: Tue, 04 Jul 2017 21:02:36 +0000 Message-ID: <1681359.zi93O8g9E0@tums.local> Organization: Vixie Freehold In-Reply-To: References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 21:02:40 -0000 On Tuesday, July 4, 2017 8:29:53 PM GMT Ray Bellis wrote: > My argument against using an NSEC style bitmap was that in the vast > majority of cases it would result in a longer record (and one that's > more complicated to decode) than a simple list of QTYPEs. not only that, but the nsec bitmap is currently uncompressed, which makes large rrtypes pretty dangerous to dnssec's deployment. until that's fixed, noone should be using that bitmap as an example of how to do other things. vixie From nobody Tue Jul 4 16:33:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FDE13154E; Tue, 4 Jul 2017 16:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Mjaw9-PC69rs; Tue, 4 Jul 2017 16:33:24 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 E90EA13013C; Tue, 4 Jul 2017 16:33:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id C4C3E24AE08; Tue, 4 Jul 2017 23:33:14 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5D141160045; Tue, 4 Jul 2017 23:33:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 295FB160098; Tue, 4 Jul 2017 23:33:18 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 93qHIB75g40v; Tue, 4 Jul 2017 23:33:18 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 82C42160045; Tue, 4 Jul 2017 23:33:17 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AAA7D7D84127; Wed, 5 Jul 2017 09:33:15 +1000 (AEST) To: John C Klensin Cc: Jim Reid , Paul Vixie , dnsop , IETF Rinse Repeat , william manning From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> In-reply-to: Your message of "Tue, 04 Jul 2017 14:21:35 -0400." <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> Date: Wed, 05 Jul 2017 09:33:15 +1000 Message-Id: <20170704233315.AAA7D7D84127@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 23:33:26 -0000 In message <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com>, John C Klensin writes: > > > --On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid > wrote: > > >> On 4 Jul 2017, at 18:49, Paul Vixie wrote: > >> > >> while IETF governs the protocol, ICANN only governs the IN > >> class. i expect that there will be other classes some day, in > >> order to avoid some aspect of ICANN. > > > > Attempts have already been made to do just that. It would be > > nice not to have to put out those fires all over again. > > Jim, Paul, > > First of all, if only because "QCLASS=ANY" is supposed to do > something sensible, one really cannot have different, per-Class, > roots (more of that argument and the difficulties for many of > the things people have wanted to use CLASSes for in recent years > appears in draft-sullivan-dns-class-useless). While I don't > believe "useless", I don't see any hope for using the CLASS > mechanism to "avoid ... ICANN". draft-sullivan-dns-class-useless has lots provably invalid assumptions in it that it is worthless in determining if new classes could be deployed. The only thing useful in it is the warning not to make all new type allocations class independent as it chews through the tuple space too fast. We should be updating the instructions to IANA to allocate types as class dependent unless it can be show that they should be class independent. Note we can always type X class A is identical to type X class B in the future. As to whether a class has a parallel heirachy or not depends on how we define the use of the class. > More important, given historical difficulties with adoption and > broad deployment of new features, I suggest that anyone who sees > ICANN avoidance as am important goal would find establishing an > alternate root and building support for it far easily and more > plausible than anything that could be done with CLASSes, if only > because an ICANN-free class mechanism would, AFAICT, require a > root (even for Class=IN) that was not controlled by ICANN > anyway. Getting new features support into name servers hasn't actually been hard. All STD 13 compliant name servers and resolvers *already* support new classes. What's hard to do is to get GoDaddy and ilk to update their web interfaces. > Having enough of the world get aggravated enough at ICANN (or > some other entity of one's choice) to make general adoption of > an alternate root plausible is another matter and I don't think > we are there, at least yet. The level of confusion and global > inconsistencies that would accompany any transition to a > different root and root management structure would be bad enough > that I hope the day at which that aggravation threshold is > reached does not come even if, ICANN seems to be trying some > days. > > Those who are contemplating that sort of adventure might find at > least parts of draft-klensin-dns-function-considerations amusing > reading. In particular, Section 3.6 briefly addresses the topic > of different CLASSes as a mechanism for doing new and different > things (technical or administrative). > > best, > john -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 4 17:03:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D82D13154E; Tue, 4 Jul 2017 17:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Bt5DK5KuQBpR; Tue, 4 Jul 2017 17:03:52 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 2D85512EC71; Tue, 4 Jul 2017 17:03:52 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 0E3F324AE08; Wed, 5 Jul 2017 00:02:28 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B8910160045; Wed, 5 Jul 2017 00:02:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8506F160098; Wed, 5 Jul 2017 00:02:31 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D-MTbki4BCqF; Wed, 5 Jul 2017 00:02:31 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 293A1160045; Wed, 5 Jul 2017 00:02:31 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5918D7D8457F; Wed, 5 Jul 2017 10:02:29 +1000 (AEST) To: Ted Lemon Cc: william manning , Randy Bush , dnsop , IETF Rinse Repeat From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> In-reply-to: Your message of "Tue, 04 Jul 2017 13:39:53 -0400." <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> Date: Wed, 05 Jul 2017 10:02:29 +1000 Message-Id: <20170705000229.5918D7D8457F@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 00:03:54 -0000 In message <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com>, Ted Lemon writes: > On Jul 4, 2017, at 1:32 PM, william manning > wrote: > > I find Randys line of discussion mirroring my own thoughts. > > And to answer your question above, technically, the TLD org. is a > > member of the IN class, so in the OF class, it is credible to posit the > > existence of a org. TLD. TLDs are per class... :) > > Technically, yes. Would ICANN object? Id be astonished if they did not. > Is there any practical value in an alternative class hierarchy? No. So > its moot. Actually there is practical value in an alternative classes if only to make the type space effectively 32 bits and implicit with that is a alternative class hierarchy (delegation may exist in one that do not exist in the other and they may point to other servers). Who owns a name is a different question to what machines serve the tuple and how do you reach those machines. There is absolutely no reason why the zones and need to be served by the same machines. There is a argument for them both being under control of the same people. Mark > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 4 18:50:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD93E120227 for ; Tue, 4 Jul 2017 18:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5FmwjI-DYMEy for ; Tue, 4 Jul 2017 18:50:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 BDA1912F547 for ; Tue, 4 Jul 2017 18:50:28 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C3DFC34930F; Wed, 5 Jul 2017 01:50:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 93843160045; Wed, 5 Jul 2017 01:50:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7908E160050; Wed, 5 Jul 2017 01:50:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MwrmrMZsqHqk; Wed, 5 Jul 2017 01:50:25 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1A4D3160045; Wed, 5 Jul 2017 01:50:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8B6237D85628; Wed, 5 Jul 2017 11:50:22 +1000 (AEST) To: Paul Vixie Cc: dnsop@ietf.org, Ray Bellis From: Mark Andrews References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <1681359.zi93O8g9E0@tums.local> In-reply-to: Your message of "Tue, 04 Jul 2017 21:02:36 +0000." <1681359.zi93O8g9E0@tums.local> Date: Wed, 05 Jul 2017 11:50:22 +1000 Message-Id: <20170705015022.8B6237D85628@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 01:50:33 -0000 In message <1681359.zi93O8g9E0@tums.local>, Paul Vixie writes: > On Tuesday, July 4, 2017 8:29:53 PM GMT Ray Bellis wrote: > > My argument against using an NSEC style bitmap was that in the vast > > majority of cases it would result in a longer record (and one that's > > more complicated to decode) than a simple list of QTYPEs. > > not only that, but the nsec bitmap is currently uncompressed, which makes > large rrtypes pretty dangerous to dnssec's deployment. until that's fixed, > noone should be using that bitmap as an example of how to do other things. > > vixie While it isn't compressed it is windowed. It's where the type fits in the window and how many windows that are active that control the size of the map not whether the type code is large or not. Yes, using a generic compression algorithm would probably result in less bits. 11:36:33.535473 IP 127.0.0.1.53 > 127.0.0.1.59788: 64667$ 1/0/0 NSEC (85) 0x0000: 4500 0071 3553 0000 4011 0000 7f00 0001 E..q5S..@....... 0x0010: 7f00 0001 0035 e98c 005d fe70 fc9b 81a0 .....5...].p.... 0x0020: 0001 0001 0000 0000 0369 7363 036f 7267 .........isc.org 0x0030: 0364 6c76 0369 7363 036f 7267 0000 2f00 .dlv.isc.org../. 0x0040: 01c0 0c00 2f00 0100 000d a500 2407 6973 ..../.......$.is 0x0050: 632d 736e 7303 6f72 6703 646c 7603 6973 c-sns.org.dlv.is 0x0060: 6303 6f72 6700 0006 0000 0000 0003 8001 c.org........... 0x0070: 40 isc.org.dlv.isc.org. 3493 IN NSEC isc-sns.org.dlv.isc.org. RRSIG NSEC DLV > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 4 19:22:52 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DC612708C; Tue, 4 Jul 2017 19:22:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149922136362.3281.8137557234349761847.idtracker@ietfa.amsl.com> Date: Tue, 04 Jul 2017 19:22:43 -0700 Archived-At: Subject: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:22:44 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dnsop-sutld-ps-07: 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-dnsop-sutld-ps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have loads of editorial comments, but I'm a Yes, thank you folks for writing this, and Just Do The Right Thing ... This text 5. If there is an IETF process through which a TLD can be assigned at zero cost other than time, this process will be used as an alternative to the more costly process of getting the name registered through ICANN. seems extremely certain ("will be used"). Is that what you meant to say? I'm assuming that the intended audience for this document is "people who know less than the authors about the lurid history of DNS". If so, in this text, 11. In some cases where the IETF has made assignments through the RFC 6761 process, technical mistakes have been made due to misunderstandings as to the actual process that RFC 6761 specifies (e.g., treating the list of suggested considerations for assigning a name as a set of requirements all of which must be met). In other cases, the IETF has made de facto assignments of Special-Use Domain Names without following the RFC 6761 process. citations of at least one de facto assignment would likely be helpful. Again, I'm assuming your intention is to give people something to think about. Given that, I wonder how badly you need the last sentence in 4.1. Primary Special-Use Domain Name Documents The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice. Only one of these documents is an IETF consensus document. You're pretty careful about pointing out whether each of the RFCs are consensus documents in the following subsections, and you provide enough explanation for the reader to know why the reader cares about each document. With the last sentence of 4.1 as lead-in, and no background because that comes later, document by document, I wouldn't take that section seriously. I know that text is in Section 4.1, but "these documents" invited me to assume the same thing about the documents in Section 4.2 as well. If you need to keep the last sentence, you might consider Only one of the documents described in Section 4.1 is an IETF consensus document. I know we publish a lot of passive voice text around here, but in 4.1.4. Liaison Statement on Technical Use of Domain Names As a result of processing requests to add names to the Special-Use Domain Name registry, as documented in [I-D.chapin-additional-reserved-tlds] and [I-D.grothoff-iesg-special-use-p2p-names], a review was chartered of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of the review, affirmed that the discussion would be "open and transparent to participation by interested parties" and explicitly invited members of the ICANN community to participate. I am guessing who is requesting what, and who is performing the review, and who sent the liaison statement. Is this saying When the IETF received processing requests to add names to the Special-Use Domain Name registry, as documented in [I-D.chapin-additional-reserved-tlds] and [I-D.grothoff-iesg-special-use-p2p-names], the IETF chartered a review of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The IETF sent a Liaison Statement [SDO-IAB-ICANN-LS] to ICANN to notify ICANN of the review, affirm that the discussion would be "open and transparent to participation by interested parties" and explicitly invite members of the ICANN community to participate. ? But, as I said, I'm guessing. I'm also not sure whether you want the reader to know the IETF sent a liaison to ICANN, and why, or whether you want the reader to look at the liaison statement text itself. If you want readers to look at the text, you might say what you hope readers find when they look. I'm wondering how .onion was "affected" in this text, Second, for some time, the CA/Browser Forum [SDO-CABF] had been issuing certificates for what they referred to as "internal names." Internal names are names allocated unilaterally for use in site-specific contexts. Issuing certificates for such names came to be considered problematic, since no formal process for testing the validity of such names existed. Consequently, CA/ Browser Forum decided to phase out the use of such names in certificates [SDO-CABF-INT], and set a deadline after which no new certificates for such names would be issued [SDO-CABF-DEADLINE]. Because the .onion name had been allocated unilaterally, it was affected by this policy. Is this saying that existing certificates for .onion could not be renewed? Or that the nice .onion people planned to get certificates, and now they couldn't? Or something else? I'm guessing The IETF's designation of .onion as a Special-Use Top-Level Domain Name was needed to facilitate the development of a certificate issuance process specific to .onion domain names [SDO-CABF-BALLOT144]. is describing how .onion was affected, but I don't know if that's what was meant by "was affected", or something else. This text Newcomers to the problem of resolving Domain Names may be under the mistaken impression that the DNS sprang, as in the Greek legend of Athena, directly from Paul Mockapetris' forehead. is the best thing I've seen reviewing documents since IETF 98. Thank you for that moment. If I'm tracking what I'm reading, The Sun Microsystems model of having private domains within a corporate site, while supporting the global Domain Name system for off-site, persisted even after the NIS protocol fell into disuse. Microsoft used to recommend that site administrators use a "private" TLD for internal use, and this practice was very much a part of the zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at the root of the widespread practice of simply picking an unused TLD and using it for experimental purposes, which persists even at the time of writing of this memo. it might be more accurate to say "simply picking an apparently-unused TLD". How often has Ralph started out as an innocent bystander, but been an accurate qualifier? :D From nobody Tue Jul 4 19:24:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3846C12708C; Tue, 4 Jul 2017 19:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=gmail.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 Hk-p8NQhb6x9; Tue, 4 Jul 2017 19:23:55 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 D525E1243FE; Tue, 4 Jul 2017 19:23:54 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id r36so78695520ioi.1; Tue, 04 Jul 2017 19:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jYQ2QOn8eQPLD8Esu0GIsS3u7rsB8jx+JvW66/nMLlw=; b=L64ZRiwlyuBrtaXh8qSY67jQJT8uVDyodeRF4wTEDpIXEJlVFXI0016NtNceQcLckH 23s4nJa1HWZmOxYlUVJTVODPHuYI/+Doy5a+UAa3NiZ6Y7LYEAlZsmsRpSQ5JLqr7R1P OnayLlqlU6AA2fa+uMbH0XCraETrVHQsMZEaGDbky/U9s+EZ26/hTeiArhqh/8QmdCJH w/6SX35cVlofBHbmu4IOPYPr7uV0eFY3bjiCLUVcdeZHSWkkA4jabrGsbc3A0lhGB2MJ EvAFFMmIoql/IB8fQ8KIEUdp3n8tNyxw1iMvmEGIxkZv2BtFhCFKTGOlvepK2hIEx4HL X9WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jYQ2QOn8eQPLD8Esu0GIsS3u7rsB8jx+JvW66/nMLlw=; b=q4P4RTAYnoVLVSckZEqQju4AlTQKw4fFcddUTHJQICrZPong5hBllkSo+XNmxkEAJy SB2i1nYuxYLbnHC43bRJay/4SReCS+a9w23BJNfWrnOHtf0nq/o9wVrCKndZLGxrwJdS 4FeGipRv6gEZkxD+3ohp98k9bwsizSweenrkStLvFcuJn5LNubPuulq9nt/U5NOsDZae gODRJq2oqw53VPwlS/lufiXc7XbBNGEsTCiI3YCSauvUqMPxem+awRew0G6ArIdKhEol f1Qk4OaPH4GqCC/MtmVQP7dP6/vDMOQ2Tu4o4lFI7xOvZll3xFjeQ6c1ROuI1TCUunZ8 jQwg== X-Gm-Message-State: AIVw111Z9SWYEXmqI1EvAIM0nGpN8pIinTwIvT0uy1g1jQwhe3mu0mhe fKGNYy+sG6NW4sNa8afFXhc9yGqSoA== X-Received: by 10.107.46.165 with SMTP id u37mr1215217iou.217.1499221434235; Tue, 04 Jul 2017 19:23:54 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.18.7 with HTTP; Tue, 4 Jul 2017 19:23:53 -0700 (PDT) In-Reply-To: <20170705000229.5918D7D8457F@rock.dv.isc.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> From: Matthew Kerwin Date: Wed, 5 Jul 2017 12:23:53 +1000 X-Google-Sender-Auth: OfnhEjXWfv0h7gZn8xsuBP5SQGc Message-ID: To: Mark Andrews Cc: dnsop , IETF Rinse Repeat Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:23:57 -0000 On 5 July 2017 at 10:02, Mark Andrews wrote: > > Who owns a name is a different question to what machines serve the > tuple and how do you reach those machines. There > is absolutely no reason why the zones and > need to be served by the same machines. There is a argument for > them both being under control of the same people. > > Mark > Hi, I'm jumping in at a random time with a possibly dumb question, but the talk of and tuples got me wondering about representation in general, and URLs in particular. RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks like a DNS name is a DNS name, and that they have to be resolved to IP addresses if you want to fetch them, but they don't talk meaningfully about how to do that resolution. Given that we always assume class=IN (not to mention type=A|AAAA via happy eyeballs), how would we go about practically presenting an alternative class in things like URLs? (Registering a new "alt-http" URL scheme doesn't strike me as a great idea.) Because it's all well and good setting up your own .org hierarchy under class=FOO or whatever, but there's not much point if you can't send people to www.not-icann.org using it. Unless you don't want to expose your new hierarchy to the web ...? Cheers [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 : """A registered name intended for lookup in the DNS uses the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].""" I read that as: "if it matches RFC1034 (and isn't overridden by the specific URI scheme's rules) it's a DNS name." It could be read the other way, but that just adds more assumptions. -- Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Tue Jul 4 19:36:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCB11243FE; Tue, 4 Jul 2017 19:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, 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=gmail.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 fvaAeWbhxZBS; Tue, 4 Jul 2017 19:36:44 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 6D5EF127601; Tue, 4 Jul 2017 19:36:44 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id h64so78723921iod.0; Tue, 04 Jul 2017 19:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1dqQGD5puf7Dlu+IcYs4nRjWmT+Ly9rk1Ar4UTxGMMM=; b=U6+NChRKrY+xJ3+CpxaEAYnQwywpLw+mY9xlToOMgXJJ6hKI7a2lYkopfmvPuVbvXx d2mylhEo1Y1mmYV6n/3kP8jcQYPyyzfRqkSaKHiOCTqSon2MssMB7qpRsooZEB1Djloo vHQTBS58+rzMt7U3wsGnj8aJ2krTiB9cU5T1gKFTzwIe9NtDmD16JlFr/UEh2QPSUFba TvsdgboHKMMHp2Kbr4mHIgBIsv38DBnPIoTrQxMOQRHMm00owH+7QRQpZ9NeHD358eZq m/jcsYtutn/IXL9o1i+yhQL5Ax5lfjzwioYYH63zl8om+B+5ebHC3bShYHzg7qbg4P25 harg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1dqQGD5puf7Dlu+IcYs4nRjWmT+Ly9rk1Ar4UTxGMMM=; b=ZzbLXfHMEVSKxH7E+0v44Kj5hFMe4BS02atjQYHXyr+mohatdj/xD8wRanJUijIGJi l41VigUjIuPTSzh+f5XixKCeqly7JYSRjNldZWrKTmuoHBXCFas81iLvxNMIoV1XngNG Fqoqxq3EaWCzyZhHmCVVPkauMFU3ACdsxskCkqR4U2e+iU86cXTktX2zJwnFEupBudOK SNoJLRyC9MrVKfW8waElAcSIFzgUxBUTPzolmSI95amdxZq1Rzhz5tQMjsTfqHOfY0tM BoPL8D/pNg4n8fIkHdk5wGTia5IU4IFKVMVmRzEVXRe2dcKxKcazycwRkwUlCZJBVoyY szSw== X-Gm-Message-State: AKS2vOwfnpQD/k8phEE9qWq7XKtjxmdIgwvF9bRdqFnVnjMMo1CUFnti 2BrS7as33VdJjWwfEmktoLHeYhrDiQ== X-Received: by 10.107.128.230 with SMTP id k99mr40480581ioi.115.1499222203825; Tue, 04 Jul 2017 19:36:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.170 with HTTP; Tue, 4 Jul 2017 19:36:43 -0700 (PDT) In-Reply-To: References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> From: william manning Date: Tue, 4 Jul 2017 19:36:43 -0700 Message-ID: To: Matthew Kerwin Cc: Mark Andrews , dnsop , IETF Rinse Repeat Content-Type: multipart/alternative; boundary="001a113f8b1ee608f7055388de18" Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:36:47 -0000 --001a113f8b1ee608f7055388de18 Content-Type: text/plain; charset="UTF-8" Most of the other application (besides dns) presume a single class, IN, hence the URL presumption of "DNS name" will -always- be in the IN class. Technically imprecise and sloppy, but pragmatically it works... until some loons come along and do something creative with classes. Then all bets are off. RFC 1034 also uses IN in its examples and most folks forget inheritence rules. /Wm On Tue, Jul 4, 2017 at 7:23 PM, Matthew Kerwin wrote: > On 5 July 2017 at 10:02, Mark Andrews wrote: > > > > Who owns a name is a different question to what machines serve the > > tuple and how do you reach those machines. There > > is absolutely no reason why the zones and > > need to be served by the same machines. There is a argument for > > them both being under control of the same people. > > > > Mark > > > > Hi, I'm jumping in at a random time with a possibly dumb question, but > the talk of and tuples got me wondering > about representation in general, and URLs in particular. > > RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks > like a DNS name is a DNS name, and that they have to be resolved to IP > addresses if you want to fetch them, but they don't talk meaningfully > about how to do that resolution. Given that we always assume class=IN > (not to mention type=A|AAAA via happy eyeballs), how would we go about > practically presenting an alternative class in things like URLs? > (Registering a new "alt-http" URL scheme doesn't strike me as a great > idea.) > > Because it's all well and good setting up your own .org hierarchy > under class=FOO or whatever, but there's not much point if you can't > send people to www.not-icann.org using it. Unless you don't want to > expose your new hierarchy to the web ...? > > Cheers > > > [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 : > > """A registered name intended for lookup in the DNS uses the syntax > defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].""" > > I read that as: "if it matches RFC1034 (and isn't overridden by the > specific URI scheme's rules) it's a DNS name." It could be read the > other way, but that just adds more assumptions. > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a113f8b1ee608f7055388de18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Most of the other application (besides dns) presume a sing= le class, IN, hence the URL presumption of "DNS name" will -alway= s- be in the IN class.=C2=A0 Technically imprecise and sloppy, but pragmati= cally it works... =C2=A0until some loons come along and do something creati= ve with classes. =C2=A0 Then all bets are off.
RFC 1034 also uses IN in= its examples and most folks forget inheritence rules.

=
/Wm

On Tue, Jul 4, 2017 at 7:23 PM, Matthew Kerwin <matthew@kerwin.net.= au> wrote:
On 5 July 2017 at 10:02, Mark Andrews <marka@isc.org> wrote:
>
> Who owns a name is a different question to what machines serve the
> <name,type,class> tuple and how do you reach those machines.=C2= =A0 There
> is absolutely no reason why the zones <name,IN> and <name,CLA= SS56>
> need to be served by the same machines.=C2=A0 There is a argument for<= br> > them both being under control of the same people.
>
> Mark
>

Hi, I'm jumping in at a random time with a possibly dumb questio= n, but
the talk of <name,type> and <name,type,class> tuples got me won= dering
about representation in general, and URLs in particular.

RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that look= s
like a DNS name is a DNS name, and that they have to be resolved to IP
addresses if you want to fetch them, but they don't talk meaningfully about how to do that resolution. Given that we always assume class=3DIN
(not to mention type=3DA|AAAA via happy eyeballs), how would we go about practically presenting an alternative class in things like URLs?
(Registering a new "alt-http" URL scheme doesn't strike me as= a great
idea.)

Because it's all well and good setting up your own .org hierarchy
under class=3DFOO or whatever, but there's not much point if you can= 9;t
send people to www.not-icann.org using it. Unless you don't want to<= br> expose your new hierarchy to the web ...?

Cheers


[*] https://tools.ietf.org/html/rfc3986#sectio= n-3.2.2 :

=C2=A0 =C2=A0"""A registered name intended for lookup in the= DNS uses the syntax
=C2=A0 =C2=A0defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC112= 3]."""

I read that as: "if it matches RFC1034 (and isn't overridden by th= e
specific URI scheme's rules) it's a DNS name."=C2=A0 It could = be read the
other way, but that just adds more assumptions.

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a113f8b1ee608f7055388de18-- From nobody Tue Jul 4 20:21:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4493412EC38; Tue, 4 Jul 2017 20:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JYQk5SfooSzc; Tue, 4 Jul 2017 20:21:22 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 C9E9312EC20; Tue, 4 Jul 2017 20:21:22 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 2E20A24AE12; Wed, 5 Jul 2017 03:19:57 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id ED1F7160045; Wed, 5 Jul 2017 03:20:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D81C5160050; Wed, 5 Jul 2017 03:20:00 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k9Slb0ZcaJ2G; Wed, 5 Jul 2017 03:20:00 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4E893160045; Wed, 5 Jul 2017 03:20:00 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 834B97D8FBDD; Wed, 5 Jul 2017 13:19:57 +1000 (AEST) To: Matthew Kerwin Cc: dnsop , IETF Rinse Repeat From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> In-reply-to: Your message of "Wed, 05 Jul 2017 12:23:53 +1000." Date: Wed, 05 Jul 2017 13:19:57 +1000 Message-Id: <20170705031957.834B97D8FBDD@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 03:21:28 -0000 In message , Matthew Kerwin writes: > On 5 July 2017 at 10:02, Mark Andrews wrote: > > > > Who owns a name is a different question to what machines serve the > > tuple and how do you reach those machines. There > > is absolutely no reason why the zones and > > need to be served by the same machines. There is a argument for > > them both being under control of the same people. > > > > Mark > > > > Hi, I'm jumping in at a random time with a possibly dumb question, but > the talk of and tuples got me wondering > about representation in general, and URLs in particular. > > RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks > like a DNS name is a DNS name, and that they have to be resolved to IP > addresses if you want to fetch them, but they don't talk meaningfully > about how to do that resolution. Given that we always assume class=IN > (not to mention type=A|AAAA via happy eyeballs), how would we go about > practically presenting an alternative class in things like URLs? > (Registering a new "alt-http" URL scheme doesn't strike me as a great > idea.) mailto: is tied to then and directly or indirectly. http: is tied to or and perhaps in the future Note the linkage is not in the name but in the definition of the scheme. If some scheme needs it will be defined in that scheme and you will call the resolver with to lookup data. That may then result in a call to lookup to get the addresses of the servers based on the data returned. Remember we call resolvers most of the time with today. Changing IN to something else is not hard. You just need to know to do that and when people write the code to support the scheme they will do that. When a new globally resolvable class becomes active whois will show a set of nameservers for class IN and a set of nameservers for class FOO. They may be the same or they may be different. One set may be empty. Remember this in not new stuff. HS was used this way but without central delegations. You were still expected to use the namespace delegated to you. The recursive servers knew how to locate the HS data. getpwnam() knew how to map from user name to and lookup the data by calling the resolver with those values. > Because it's all well and good setting up your own .org hierarchy > under class=FOO or whatever, but there's not much point if you can't > send people to www.not-icann.org using it. Unless you don't want to > expose your new hierarchy to the web ...? > > Cheers > > > [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 : > > """A registered name intended for lookup in the DNS uses the syntax > defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].""" > > I read that as: "if it matches RFC1034 (and isn't overridden by the > specific URI scheme's rules) it's a DNS name." It could be read the > other way, but that just adds more assumptions. > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 4 21:24:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073E9129AEA; Tue, 4 Jul 2017 21:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=gmail.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 XpYvvfGDj1I5; Tue, 4 Jul 2017 21:23:57 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 65372126D45; Tue, 4 Jul 2017 21:23:57 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id h134so79645962iof.2; Tue, 04 Jul 2017 21:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/pnFIgZB/9WJCI7pJBpDNLeN/pdDOiOZQqSyolpmpuo=; b=JcjyTKOeVVXja/VCMvK94K2naGVm+4kCsHMcaQ7biNojNpvBlWb4koT2WssmYOqJ7y R+t/spXEchXWiUNGWtIlj+CFE9F83CGxCQDbsPlqAGo5uPiGI/4J2utG9CND2U7OAXr6 rQX9sHmT/ag8A6px7ej+DkY9yH+mzj4yng3yYhepHkZbKtJYrRjbPqTIDZUei+jtukjo U3rnW9d0Qncblaj0e69QhCY2aTfIpol2a/zfIP9kxm2gvAnAC7z9jQqSrO+jrXbRUuF/ q793vQVIkgIeB21y4JQUOy7NrkDJYtwpdA8BRdGKQ7dXNCOhXOZ2nzeV8/Hz7pLUOrE1 5nbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/pnFIgZB/9WJCI7pJBpDNLeN/pdDOiOZQqSyolpmpuo=; b=k6eJIBN2bWYXjCzmgxuIIY2TM2gGfGuJL6oNDhH5czmqCodI98nl0IPoU/fAgnK9zi fAhHsVHZFM5sAqLWWo+c5su70WCIH6lWjxar0jj6y9FzZketIKDjtPyZfWmedgvSY3w9 sF1qdZ+UD4Y9b3xzuyfvLQQs8z8IclGT+DrkNaxv8DcHBAwxRrEeCQTZLOTzTYJ+/8PX g7EWylPYo5aUboiKqZUrgh/0wMvBWKpCYOzdRkMzHr1UJlICTPQU+Xlim4AZpDie3WDk 4yYsoMNybehQlh4jX0grDV7l6QvNUgAdMpmBaUjypAs8+s/WZVyE7PPst65bVJMHOZ9I RQcQ== X-Gm-Message-State: AKS2vOw2bKqdvtpOcH19SMAMtcFUa24eWwJUqM3FwbVMEcy3PY9WhG2S 2Wa+ZrW915xzWrZYcbKXEjnh5ROS8g== X-Received: by 10.107.58.86 with SMTP id h83mr38243411ioa.28.1499228636762; Tue, 04 Jul 2017 21:23:56 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.18.7 with HTTP; Tue, 4 Jul 2017 21:23:56 -0700 (PDT) In-Reply-To: <20170705031957.834B97D8FBDD@rock.dv.isc.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <20170705031957.834B97D8FBDD@rock.dv.isc.org> From: Matthew Kerwin Date: Wed, 5 Jul 2017 14:23:56 +1000 X-Google-Sender-Auth: QrcC7p-hQJl6t_ikxlQyxU-0Svg Message-ID: To: Mark Andrews Cc: dnsop , IETF Rinse Repeat Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 04:24:00 -0000 On 5 July 2017 at 13:19, Mark Andrews wrote: > > In message , Matthew Kerwin writes: >> On 5 July 2017 at 10:02, Mark Andrews wrote: >> > >> > Who owns a name is a different question to what machines serve the >> > tuple and how do you reach those machines. There >> > is absolutely no reason why the zones and >> > need to be served by the same machines. There is a argument for >> > them both being under control of the same people. >> > >> > Mark >> > >> >> Hi, I'm jumping in at a random time with a possibly dumb question, but >> the talk of and tuples got me wondering >> about representation in general, and URLs in particular. >> >> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks >> like a DNS name is a DNS name, and that they have to be resolved to IP >> addresses if you want to fetch them, but they don't talk meaningfully >> about how to do that resolution. Given that we always assume class=IN >> (not to mention type=A|AAAA via happy eyeballs), how would we go about >> practically presenting an alternative class in things like URLs? >> (Registering a new "alt-http" URL scheme doesn't strike me as a great >> idea.) > > mailto: is tied to then and directly or indirectly. > http: is tied to or and perhaps in the future > > Note the linkage is not in the name but in the definition of the > scheme. > In the case of http it seems to be by convention, because I can't find anything anywhere that specifies it. That said, my actual experience in resolving URLs only goes as deep as gethostbyname() so it's never mattered to me. At a similar level, I *get* how RFC 6761 sits between the 'host' name and the IP address, but it's far enough outside my expertise that I don't see how all the bits fit together in any detail. [snip] > > Remember this in not new stuff. HS was used this way but without > central delegations. You were still expected to use the namespace > delegated to you. The recursive servers knew how to locate the HS > data. getpwnam() knew how to map from user name to TXT, HS> and lookup the data by calling the resolver with those > values. > I'm not really a DNS person -- nor am I enough of a sysadmin (nor old enough) to know much about HS -- which is why I asked. I guess that means if someone wanted to wrest control of the names used on the web from ICANN, they'd have to set up alt-http and alt-https schemes, and convince everyone that they're better (and to update all their existing bookmarks, links, templates, etc.) I guess that's one way of future-proofing us against such an event. (That's slightly back toward the track of the original discussion, isn't it?) Cheers > >> Because it's all well and good setting up your own .org hierarchy >> under class=FOO or whatever, but there's not much point if you can't >> send people to www.not-icann.org using it. Unless you don't want to >> expose your new hierarchy to the web ...? >> -- Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Wed Jul 5 01:47:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CB8131BB5; Wed, 5 Jul 2017 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 gORbDvJTXQZ3; Wed, 5 Jul 2017 01:47:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 63AEC131BBA; Wed, 5 Jul 2017 01:47:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dSfyJ-000527-A0; Wed, 05 Jul 2017 08:47:43 +0000 Date: Wed, 05 Jul 2017 10:47:41 +0200 Message-ID: From: Randy Bush To: Paul Vixie Cc: dnsop , IETF Rinse Repeat In-Reply-To: <595BE0D5.5000106@redbarn.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 08:47:47 -0000 i think avoiding icann is a red herring. if the draft in question had done a decent job of exploring the taxa of needs for name resolution outside of the 'normal' topology, we would have the start of a base on which to discuss this. randy From nobody Wed Jul 5 05:01:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B2132978; Wed, 5 Jul 2017 05:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 05yK57Jo313R; Wed, 5 Jul 2017 05:01:39 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 9F9CC13297E; Wed, 5 Jul 2017 05:01:35 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id 16so187503748qkg.2; Wed, 05 Jul 2017 05:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FbSQWMF5YTqw4gIJCTtdbI/LZGLMXwJt/gliUZN2470=; b=Hnx/56I1hUT36A4RH9gQBy70afSlnTTSzeyt1vYvR9Bvlila6biGI6fsC/Gz1CH7OS 9l5+rRMTd5YaM9nFWluJY/yR0iFQZl9HiQkZtDWkcx0gaVFNQacjUipKJLGXL7Z9udAU yD51gHibPaetFUMYXovAwBd6gGB5Q4rq3m0RE4SMs/ARCGVW65b+CpzZTdPy0K8sMVN7 t4HWWfhjexx/rYq6OjRdNtOXiUjC2Q9nhwY/k/8JrEXO6MWRG103M+5cr9yBHYydm60h M2EY/Lsce9lCroItMhGcVfcEqsQxMfPsI5vPgoy19du/qJOQrIacRwnLIOnj/XcjnFJE PrvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FbSQWMF5YTqw4gIJCTtdbI/LZGLMXwJt/gliUZN2470=; b=hZDaj5qs+WWvAckbC4m5yvmKOQjvJcPn0FsunfQH6zDdCnWuC3KucYh8oPDPAbyVam 7VlRvySbaawavUYnVPOJUESwMm5ghRaSzUkO2RUkI/jlCs3hjHTU35jiSofStKcQ80SX QDb54BpstPV9NIq1JOu6xISuMabdtDBIpUvB+eF/FWDHDY3XMJcKK7vdE3xuMkQX/KkA G30vEfzrf8hC7mUIavRCjyyozmYEhCGWAzmqiYyvFH3uRFucTvOEOLhHaTdvbMhoB93T rpIIAv5bom/In4o22zEIiIm7TxuCHmdCQUCy7/a7awQnmRPPooStLi3YQiv+usahzcok wCtg== X-Gm-Message-State: AKS2vOzkuz4yjNKGq6OtkwOM9YKZQ/y8rYSx6vzlqjjv7IjGhlBYQ7rz 3/QshT4T9Njc4Q== X-Received: by 10.55.139.68 with SMTP id n65mr50969999qkd.172.1499256094576; Wed, 05 Jul 2017 05:01:34 -0700 (PDT) Received: from [10.232.156.114] ([73.114.23.114]) by smtp.gmail.com with ESMTPSA id 7sm6796572qtt.27.2017.07.05.05.01.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Jul 2017 05:01:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: Date: Wed, 5 Jul 2017 08:01:30 -0400 Cc: Randy Bush , dnsop@ietf.org, IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: <2ABF6534-D3DA-42B0-AC75-57C667CC38B2@gmail.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 12:01:54 -0000 (not sure which hat. Probably doc shepherd.) > On Jul 4, 2017, at 9:23 AM, Ted Lemon wrote: >=20 > On Jul 4, 2017, at 3:39 AM, Randy Bush wrote: >> is there a companion document with the list of benefits/advantages? = or >> is thins just one of those ietf documents from on high meant to kill >> something? >=20 > This is a very good question. We weren=E2=80=99t asked to answer that = question, so we didn=E2=80=99t. It is assumed throughout the document = that various proponents of special use domains have good reasons for = wanting them, and further that it is already accepted in principle that = if their reason for wanting them is valid, they can have them (modulo = technical constraints like delegation). So we didn=E2=80=99t delve into = that. But perhaps we should have.=20 I=E2=80=99d go a step further: RFC 6761 alludes to some general reasons, = but assumes people who=E2=80=99d go through the IETF standards process = or an IESG approval process to get an entry in the special use names = registry have good enough reasons that the special handling requested = should be accepted as part of the DNS protocol. (I=E2=80=99m one of the = people who isn=E2=80=99t comfortable with this assertion, but we=E2=80=99r= e living with what RFC 6761 says, not what I think it should have said.)=20= That is, RFC 6761 leaves to other processes to assess the value of the = request and the reasons offered, but strictly speaking doesn=E2=80=99t = require them to be documented or evaluated; required documentation for = the registry entry consists mostly of assessing how it interacts with = the DNS, not its primary use. (Sec. 4 starts by saying =E2=80=9CIf it is = determined that special handling of a name is required in order to = implement some desired new functionality,=E2=80=9D the registry entry = policy applies, but openly avoids describing how that determination = should be made.) This isn=E2=80=99t really strange=E2=80=94 plenty of registries don=E2=80=99= t require any particular discussion of the merits of an entry; ISTM that = =E2=80=9Cstandards action=E2=80=9D presumes such evaluation as part of = IETF consensus. But it does seem like a significant part of the observed = problem=E2=80=94 there are only subjective and ad hoc bases for = evaluation for a request that=E2=80=99s not otherwise justified by a = standards track document, leading to endless repetitions of discussions = like whether a new CLASS would be a =E2=80=9Cbetter=E2=80=9D way to = solve a problem that isn=E2=80=99t actually documented in the request. I think the observation that people aren=E2=80=99t really required to = document what problem they are trying to solve with their special use = name is in the draft, but perhaps could be more explicit.=20 Some few people already have been convinced that there should be some = general guidance available for making the determination that a domain = name requires special handling in the DNS. But that also seems to be a = different document. Suzanne= From nobody Wed Jul 5 05:05:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09260131CC3 for ; Wed, 5 Jul 2017 05:05:35 -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_PASS=-0.001, URIBL_BLOCKED=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 SX78mxda6oAH for ; Wed, 5 Jul 2017 05:05:32 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC693131CC0 for ; Wed, 5 Jul 2017 05:05:31 -0700 (PDT) Received: from [2001:b98:204:102:fff1::11] (port=63476 helo=Jims-iMac.local) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dSj3g-0001mq-9E; Wed, 05 Jul 2017 13:05:29 +0100 To: rgibson@dyn.com References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> From: Jim Hague Organization: Sinodun Internet Technologies Ltd. Cc: dnsop@ietf.org Message-ID: <5ec26bfa-b7c9-cdcc-2594-5e2df7bec4c8@sinodun.com> Date: Wed, 5 Jul 2017 13:05:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 12:05:35 -0000 On 04/07/2017 00:22, Richard Gibson wrote: > I looked over this draft in detail, and found a handful of ambiguous > points ("Clarifications" and "Potentially Missing Data" below). But more > importantly, it is very close to defining a format that could replace > much of my organization's in-house technology. Would you consider some > generalizations to take it over the finish line ("Extension Fields" and > "Opt-in Lossyness")? Only the suggestions related to representing time > and "classtype" items would change the representation of existing data > in such a way that implementations already supporting the draft > specification would require changes. > > *Clarifications* > * Items in the "classtype" table (section 7.11) are missing data type > documentation. Both "type" and "class" should be unsigned numbers. Thanks. Yes, the type needs adding. > * And speaking of 7.11, why are CLASS/TYPE pairs represented as CBOR > maps instead of more efficient two-item arrays? If it was an intentional > decision for clarity, then maybe the section 7.7 block preamble > "earliest-time" field should also be promoted to a map ("time-seconds", > "time-useconds", "time-pseconds", mirroring Q/R items) for the same reason. All the tables in the BlockTables section that are multi-valued are maps. I did consider making the Class/Type pairs an array, but decided to go for consistency with the other block tables containing composite data and make it a map. Yes, two-item arrays would be more space-efficient, saving two bytes per item. However, in the data we've observed, the number of entries in the Class/Type table is, as you'd expect, small, typically 15-20 entries. So we're looking at a saving of maybe 40 bytes per block. By the time you've run through compression, that advantage will be further eroded, so I ended up deciding that the cost of consistency here was worth paying. We've also considered specifying an implicit Class entry of IN (i.e. if the Class items isn't present in the map, assume IN), but as, again, the space saving is negligible prefer to keep the values explicit. Timestamps, on the other hand, I always regarded as a basic data type, so naturally a structure. Plus, of course, there's one per query/response item, so in a block the size savings are in the 10-15k bytes region, which is rather more significant. > * In "query-sig" table items (section 7.13) "transport-flags" field, the > bit corresponding to "trailing bytes" shouldn't be limited to UDP. Interesting point. We haven't to date observed trailing data over TCP, but that's not to say that somebody won't try it. > * In section 7.18, "and an unsigned key" appears to be meaningless and > should probably be removed. In most places where we are discussing a map, we've specified the type of the map key in the text, though I notice we're not 100% consistent with that. > *Potentially Missing Data* > * In "query-sig" table items (section 7.13), "transport-flags" should > probably be extended to include a TLS bit (cf. RFC 7858). Agreed. We should also look at indicators for DNS-over-HTTP, DNS-over-QUIC and any other exotica. > *Extension Fields* > Of the many potentially open-ended key-value maps (file preamble, file > preamble configuration, block preamble, block statistics, query > signatures, Q/R data), only block statistics allows for > "implementation-specific fields", and no further guidance is provided. I > think all maps should allow such fields, with a recommendation that they > use an implementation-specific prefix to avoid collisions with fields > added by other implementations or later versions of C-DNS. You are right that extensibility of the tables is not something we have considered deeply up to now, and it's definitely something that should be done. FWIW, my initial inclination is to designate as implementation-specific all key values above a threshold that allows plenty of growth space for standardised fields, as long as we can be sure that generic readers can safely skip over the fields they don't understand. This is a topic we need to discuss and flesh out. Example use > cases: [...] > * Extend the block preamble (section 7.7) to override file preamble > fields like "host-id" and "server-addresses", enabling fleet-wide file > merges. I don't quite follow why you'd need to put this informational-only stuff into the block preamble rather than the file preamble/configuration. Can you expand on that a bit? > *Opt-in Lossyness* > The format is generally quite good about allowing for detail without > requiring it. However, there are some areas where more space savings > could be had: > * Communicate aggregation of IP addresses into prefixes (i.e., the > irrelevance of least-significant bits in ip-address values) with new > "client-prefix-length-ipv4" and "client-prefix-length-ipv6" and > "server-prefix-length-ipv4" and "server-prefix-length-ipv6" file > preamble configuration options. > * Communicate case-normalizing aggregation of names (e.g., transforming > "eXaMpLe.com" into "example.com ") with a new > boolean-valued "name-normalization" file preamble configuration option. These are items that could be addressed by implementation-specific fields, though I do see the motivation behind wanting a standardised representation for interchange. This raises a question about a tension between the background of C-DNS to date and the slightly different angle you are coming from. We've been very much focused on using C-DNS to record traffic in a form where the packets can be recreated in wire format (i.e. as PCAP). The optional data items mean that data may be missing from those packets, but the core query and response will still be present. So, to take the next item: > * In "rr" table items (section 7.15), "ttl" should be optional to > accommodate decrementing in recursive resolver responses. and (skipping out of order) your final: > * For truly customizable aggregation, I think all query signature > (section 7.13) and Q/R (section 7.18) data item fields should be > optional... but especially Q/R data "client-port" and "transaction-id". moves the recording to a point where reconstructing wire format means that the application doing the reconstruction has to not just omit information not present in C-DNS, but must start generating values to fill in for the missing items. This feels a bit like a step that needs discussion; we need to think over the design from your point of view. Possibly those fields should be optional, but with recommendations for how to populate them when/if generating PCAP. > * In Q/R data items (section 7.18) and malformed packet records (section > 7.20), I'd like "time-useconds" broken out into "time-seconds" and > optional "time-useconds", both for parity with block-preamble > "earliest-time" and for space savings in applications that are content > with second-level resolution. time-useconds is a time offset, rather than absolute time. Splitting into seconds and optionally useconds means that people wanting usecond resolution must pay a size overhead in their collection files as there will will be an additional field, a byte for each query/response. If there is a general demand for only having time resolution at the second level, possibly there should instead be a configuration field indicating whether the offset is in usec or sec. I see that second offsets would provide for notable size savings. I'm interested to hear whether others also have similar use cases to the above. We'll be doing a 10 minute slot on C-DNS in Prague, and would welcome discussion there. -- Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Wed Jul 5 05:49:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD6A131CE1; Wed, 5 Jul 2017 05:49:25 -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] 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 b-VwcKcSxa2q; Wed, 5 Jul 2017 05:49:24 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783D11329D8; Wed, 5 Jul 2017 05:49:22 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dSjk7-000DNX-Hd; Wed, 05 Jul 2017 08:49:19 -0400 Date: Wed, 05 Jul 2017 08:49:14 -0400 From: John C Klensin To: Suzanne Woolf cc: Ted Lemon , dnsop@ietf.org, IETF Rinse Repeat Message-ID: <1D0C8C6993058C5A6A40ABB8@JcK-HP5.jck.com> In-Reply-To: <2ABF6534-D3DA-42B0-AC75-57C667CC38B2@gmail.com> References: <2ABF6534-D3DA-42B0-AC75-57C667CC38B2@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 12:49:26 -0000 --On Wednesday, July 05, 2017 8:01 AM -0400 Suzanne Woolf wrote: > (not sure which hat. Probably doc shepherd.) >... >> This is a very good question. We weren't asked to answer >> that question, so we didn't. It is assumed throughout the >> document that various proponents of special use domains have >> good reasons for wanting them, and further that it is already >> accepted in principle that if their reason for wanting them >> is valid, they can have them (modulo technical constraints >> like delegation). So we didn't delve into that. But perhaps >> we should have. > > I'd go a step further: RFC 6761 alludes to some general > reasons, but assumes people who'd go through the IETF > standards process or an IESG approval process to get an entry > in the special use names registry have good enough reasons > that the special handling requested should be accepted as part > of the DNS protocol. (I'm one of the people who isn't > comfortable with this assertion, but we're living with what > RFC 6761 says, not what I think it should have said.) > > That is, RFC 6761 leaves to other processes to assess the > value of the request and the reasons offered, but strictly > speaking doesn't require them to be documented or evaluated; > required documentation for the registry entry consists mostly > of assessing how it interacts with the DNS, not its primary > use. (Sec. 4 starts by saying "If it is determined that > special handling of a name is required in order to implement > some desired new functionality," the registry entry policy > applies, but openly avoids describing how that determination > should be made.) >... > I think the observation that people aren't really required > to document what problem they are trying to solve with their > special use name is in the draft, but perhaps could be more > explicit. > > Some few people already have been convinced that there should > be some general guidance available for making the > determination that a domain name requires special handling in > the DNS. But that also seems to be a different document. Suzanne, Independent of "general guidance", I think the combination of the I-D, this thread to date, and your comments above make an extremely strong case for updating RFC 6761 to require documentation of the problem and discussion of other alternatives and why they are unworkable. Whatever else the problem statement does, I think it makes it clear that yet another special name should be viewed as a preference only if there are no reasonable alternatives rather than, e.g., an option for global vanity names. While "general guidance for making the determination" would be, IMO, desirable, I can imagine months (or years) of quibbling before agreement could be reached on such criteria. In the interim, I'd think a requirement for documentation and explanation sufficient to satisfy the IETF would be in order if only as an interim measure to prevent proposals whose main justification is "because I want one of my very own". Anyone in DNSOP want to write a one-page RFC? john From nobody Wed Jul 5 05:55:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B9E131CE0 for ; Wed, 5 Jul 2017 05:55:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 7_TwHAJI01Mf for ; Wed, 5 Jul 2017 05:55:28 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 9FEC6131CD7 for ; Wed, 5 Jul 2017 05:55:28 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id g40so142505184uaa.3 for ; Wed, 05 Jul 2017 05:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JcK5DwVaN8MW5LeAtVce4f8DXWrqzgokZ1RVG96mwGA=; b=Shh1G92JEHwQ0i/6ggXzvC/ompL1F8BJhrJJYaTP7ZdUGdX8+dsyiqMvK4U39hJLuP gdfgB8aJ6hD1ae++zJIOnx23etT3Hwyk5zbXt0XquYCyHEv3Ivj+S/U1weH6+yckuOuO 8l6AKKQmWf34rMJOgAMEifqtuYnAGleKxmqBKQlJ7S9pz1itFw3DtbKT2PFdNjGkEEIx 4AXLUZBVlk8M70/eym4pvinx2B9C8B1HY/mgWsLEbdrp2WqMgzbAe/0yRG0UGdNLA4Jz K6hORs5SxIIweeOLSNtlQi/qZ0IvryVj6i/mvQ+FeeVg0AmuxfS4avUIYFnWSrX5W2QJ oNIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JcK5DwVaN8MW5LeAtVce4f8DXWrqzgokZ1RVG96mwGA=; b=kmhuamQXvMDozKGe7HjpIHrzyoyYdOKsgcYMCvB/VRqubU7zVbUKftIBIzGYWOdsqh +gw4IwRXO7vowbEELZwlqihOcM5f/496tAgpsev+8Zt1+aO+I54zid0jmnxZoH04lfRH 4JQJTo6ZX/tpQjueEBhwGb2mqLuwKKhrewqiw88iv2kcJp5e1fqi51/PJI3g8sjEN1DR xIxHlAUrlmA2WEVFBpQJGPyM9xM+Rnu6mAXo/If7lK/3f2D6/tfO3uUJ7GE9uZdxQSg5 c/ly639BmQPd1IT6Hw3cFEAuvp0wys9GcEjg4XMY9aE1eU1Roz/yyp9Z1V44I/EiiiDs cNUA== X-Gm-Message-State: AIVw111KnbJ8N23vsColfg3m027VQFn1QHbq21JFmSDkYah3Ob3r8NeA LB1o2n1IURfscfqcds7fFgjDEp3lcahF X-Received: by 10.159.58.97 with SMTP id r33mr17831231uag.110.1499259327583; Wed, 05 Jul 2017 05:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.165 with HTTP; Wed, 5 Jul 2017 05:54:47 -0700 (PDT) In-Reply-To: References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> From: Warren Kumari Date: Wed, 5 Jul 2017 08:54:47 -0400 Message-ID: To: william manning Cc: Matthew Kerwin , dnsop , IETF Rinse Repeat Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 12:55:31 -0000 Been trying to figure out where to insert this. https://tools.ietf.org/html/draft-sullivan-dns-class-useless-03 Abstract Domain Name System Resource Records are identified in part by their class. The class field is not effective, and it is not used the way it appears to have been intended. This memo suspends additions to the DNS class registry pending greater clarity on how classes might be used, and until such clarification requires those defining new RRTYPEs to define them for all classes. Answer wrote a draft about this a few months / years ago. W On Tue, Jul 4, 2017 at 10:36 PM, william manning wrote: > Most of the other application (besides dns) presume a single class, IN, > hence the URL presumption of "DNS name" will -always- be in the IN class. > Technically imprecise and sloppy, but pragmatically it works... until some > loons come along and do something creative with classes. Then all bets are > off. > RFC 1034 also uses IN in its examples and most folks forget inheritence > rules. > > /Wm > > On Tue, Jul 4, 2017 at 7:23 PM, Matthew Kerwin > wrote: >> >> On 5 July 2017 at 10:02, Mark Andrews wrote: >> > >> > Who owns a name is a different question to what machines serve the >> > tuple and how do you reach those machines. There >> > is absolutely no reason why the zones and >> > need to be served by the same machines. There is a argument for >> > them both being under control of the same people. >> > >> > Mark >> > >> >> Hi, I'm jumping in at a random time with a possibly dumb question, but >> the talk of and tuples got me wondering >> about representation in general, and URLs in particular. >> >> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks >> like a DNS name is a DNS name, and that they have to be resolved to IP >> addresses if you want to fetch them, but they don't talk meaningfully >> about how to do that resolution. Given that we always assume class=IN >> (not to mention type=A|AAAA via happy eyeballs), how would we go about >> practically presenting an alternative class in things like URLs? >> (Registering a new "alt-http" URL scheme doesn't strike me as a great >> idea.) >> >> Because it's all well and good setting up your own .org hierarchy >> under class=FOO or whatever, but there's not much point if you can't >> send people to www.not-icann.org using it. Unless you don't want to >> expose your new hierarchy to the web ...? >> >> Cheers >> >> >> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 : >> >> """A registered name intended for lookup in the DNS uses the syntax >> defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].""" >> >> I read that as: "if it matches RFC1034 (and isn't overridden by the >> specific URI scheme's rules) it's a DNS name." It could be read the >> other way, but that just adds more assumptions. >> >> -- >> Matthew Kerwin >> http://matthew.kerwin.net.au/ >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Jul 5 08:15:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4B12EC0B for ; Wed, 5 Jul 2017 08:15:38 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=OKLNA/dB; dkim=pass (1024-bit key) header.d=yitter.info header.b=AkdLxzoL 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 udnHKC3I3b1d for ; Wed, 5 Jul 2017 08:15:36 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF2A12EB8E for ; Wed, 5 Jul 2017 08:15:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D5F67C0354 for ; Wed, 5 Jul 2017 15:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499267735; bh=1MzIHcGZrbTVHIoD8NjgRhRqEoe+awCiIstK6CsOuFo=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OKLNA/dBzOyJMkeMYLV8iq+lCgPPSUERFKdqHl2RHP1haAz2TsQQETv9dgrEnbOP7 Jlq/MMnYHWDAJgPEaNEYuMP/XuZ8dknRkmW9y6WswylRXbxSNxpaupsVbCvuTC6nXE vzUyC8oxHCvDTlxlfmiJgJY5QCeY2//3TtpeTi3g= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8lGfbqUXB1J for ; Wed, 5 Jul 2017 15:15:34 +0000 (UTC) Date: Wed, 5 Jul 2017 11:15:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499267734; bh=1MzIHcGZrbTVHIoD8NjgRhRqEoe+awCiIstK6CsOuFo=; h=Date:From:To:Subject:References:In-Reply-To:From; b=AkdLxzoLHkHc0ku9quoyBbFh7yyx30a/tP6pkNsolKXd0EvtfWDCrlJurjuQt1VnF ojTpOQ4nmzVaMEMBH/5ySp+bofhD2WXJLhzO6JkakZJumu+qNRBbOSiwqM6l/fjuAb VW/AH0UvPQVRdnt0syPBGki6DeB7BN4UKEJYtiRk= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170705151536.5qqdricrsfx73jcr@mx4.yitter.info> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <20170704233315.AAA7D7D84127@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170704233315.AAA7D7D84127@rock.dv.isc.org> Archived-At: Subject: [DNSOP] draft-sullivan-dns-class-useless (was Re: new DNS classes) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:15:38 -0000 Hi Mark, On Wed, Jul 05, 2017 at 09:33:15AM +1000, Mark Andrews wrote: > > draft-sullivan-dns-class-useless has lots provably invalid assumptions > in it that it is worthless in determining if new classes could be > deployed. What are the "lots of provably invalid assumptions in it"? As far as I know, I incorporated changes that were an attempt to address comments you sent me; perhaps I didn't understand you at the time. But this is the first time I've ever heard about provably invalid assumptions. Anyway, I abandoned the effort because it became clear to me that there wasn't going to be any consensus around this: there were too many people too wedded to keeping classes around despite the obvious problem that they haven't actually been used when the obvious opportunities arose. I cheerfully predict that the DNS will be replaced before we ever have a significant deployment of a class that even remotely rivals the deployment of IN. But I'm not going to waste a lot of effort trying to forge a consensus about that. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 5 09:55:06 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F35CC12EB8C; Wed, 5 Jul 2017 09:55:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149927370099.12960.352784964081393622.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 09:55:00 -0700 Archived-At: Subject: [DNSOP] Warren Kumari's Recuse on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:55:01 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dnsop-sutld-ps-07: Recuse 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-dnsop-sutld-ps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am an author on this document, and so recusing myself from balloting. From nobody Wed Jul 5 10:06:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84458129B3A for ; Wed, 5 Jul 2017 10:06:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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_1oJrx_Kp9G for ; Wed, 5 Jul 2017 10:06:34 -0700 (PDT) Received: from mail-ua0-x248.google.com (mail-ua0-x248.google.com [IPv6:2607:f8b0:400c:c08::248]) (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 E8383128B8F for ; Wed, 5 Jul 2017 10:06:33 -0700 (PDT) Received: by mail-ua0-x248.google.com with SMTP id y47so95233881uag.13 for ; Wed, 05 Jul 2017 10:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZXf4XTZnv31/qc+Sz9ykMoD1cS/VUrVEDbVkir3YOWE=; b=W9jr6og8q4oMtsMqwtY+5a/Mx4pS7gIFrBBbzFbsqYTkwAfCaIqn0xC39wg7IyitiY AMRrjZ4pUCrUs9FTDPtozW9oLvFY6Xp6iOnqOIp1UPwbxhaZCqblAwy0rLEjDglOetQl bTQNhlSa0n0haBnCrXy0WOb7i1GGx5W4xivTk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZXf4XTZnv31/qc+Sz9ykMoD1cS/VUrVEDbVkir3YOWE=; b=VbdzDUxaKidDfwM5VZigfFjvBEpYR4NYdN2Mjo+4t7eoLMccjsGoHg+c9kuysr5dyg VKkry7VBP77u5RKZlN8p8cuet7zMgFIgHQdYStwprsE3x/FAoz0lubjAZj55GS8iN3Bb Wf44ko5QL4csN9Ou2LZv3cvrU5y8LOmTkpAGCkdGcJbIWhX3o27sAtU9GFBsYyAUJZX6 0wiCZ55nZlJA1F5eT7onbpRM8amk36L2ZkgaVr11LrRlN/Q0JGeSea7evoVvmwV3mfFs 3imv5+obZcX56R1BgPK33Wd3VFxaFYczzGzO4S4JEMQKT4bWM+/gGw9qsHh4qmPP3Cqh IZJA== X-Gm-Message-State: AKS2vOyevbRRQ/KnrjbK4eX7YOJr5lwul7LrJBrKRwdmnzwCP8THbVdY o6bVQ6feRqcGHob8EGgZY2ZHi3bHg2gEoUYRqg== X-Received: by 10.31.124.66 with SMTP id x63mr25778884vkc.126.1499274393086; Wed, 05 Jul 2017 10:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.62.209 with HTTP; Wed, 5 Jul 2017 10:06:12 -0700 (PDT) In-Reply-To: <5ec26bfa-b7c9-cdcc-2594-5e2df7bec4c8@sinodun.com> References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <5ec26bfa-b7c9-cdcc-2594-5e2df7bec4c8@sinodun.com> From: Richard Gibson Date: Wed, 5 Jul 2017 13:06:12 -0400 Message-ID: To: Jim Hague Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c14c0ec9f06cf055395053f" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:06:36 -0000 --94eb2c14c0ec9f06cf055395053f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 8:05 AM, Jim Hague wrote: > Timestamps, on the other hand, I always regarded as a basic data type, > so naturally a structure. Plus, of course, there's one per > query/response item, so in a block the size savings are in the 10-15k > bytes region, which is rather more significant. > In that case, I'm even more convinced that all of them (block preamble "earliest-time", Q/R data item "time" and "delay", malformed packet item "time") should have the same structure=E2=80=94either variable-precision ar= rays or {"seconds", "useconds", "pseconds"} maps. > * In section 7.18, "and an unsigned key" appears to be meaningless and > > should probably be removed. > > In most places where we are discussing a map, we've specified the type > of the map key in the text, though I notice we're not 100% consistent > with that. > All the keys in those maps (and in every map, as far as I can tell) are strings, for which "unsigned" is a meaningless concept. > Example use > > cases: > [...] > > * Extend the block preamble (section 7.7) to override file preamble > > fields like "host-id" and "server-addresses", enabling fleet-wide file > > merges. > > I don't quite follow why you'd need to put this informational-only stuff > into the block preamble rather than the file preamble/configuration. Can > you expand on that a bit? > Some of our processing can benefit from merging telemetry (e.g., all hosts at a site), which would produce files containing blocks that don't share values for fields currently in the file preamble. In fact, we might even decide to treat "block" as the only relevant unit, using block preamble extension fields for *everything* in the standard file preamble except version information. > *Opt-in Lossyness* > This raises a question about a tension between the background of C-DNS > to date and the slightly different angle you are coming from. We've been > very much focused on using C-DNS to record traffic in a form where the > packets can be recreated in wire format (i.e. as PCAP). The optional > data items mean that data may be missing from those packets, but the > core query and response will still be present. > Agreed. But it's _so close_ that I felt these suggestions were worth raising=E2=80=94not to water down the primary use case, but to cover a few = more with some tradeoffs. moves the recording to a point where reconstructing wire format means > that the application doing the reconstruction has to not just omit > information not present in C-DNS, but must start generating values to > fill in for the missing items. This feels a bit like a step that needs > discussion; we need to think over the design from your point of view. > Possibly those fields should be optional, but with recommendations for > how to populate them when/if generating PCAP. > That sounds great. We'll be doing a 10 minute slot on C-DNS in Prague, and would welcome > discussion there. I don't expect to be there personally, but we'll have a well-informed representative. --94eb2c14c0ec9f06cf055395053f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 8:05 AM, Jim Hague <jim@sinodun.com> wrote:=
Timestamps, on the ot= her hand, I always regarded as a basic data type,
so naturally a structure. Plus, of course, there's one per
query/response item, so in a block the size savings are in the 10-15k
bytes region, which is rather more significant.

In that case, I'm even more convinced that all of them (block = preamble "earliest-time", Q/R data item "time" and &quo= t;delay", malformed packet item "time") should have the same= structure=E2=80=94either variable-precision arrays or {"seconds"= , "useconds", "pseconds"} maps.

> = * In section 7.18, "and an unsigned key" appears to be meaningles= s and
> should probably be removed.

In most places where we are discussing a map, we've specified th= e type
of the map key in the text, though I notice we're not 100% consistent with that.

All the keys in those maps (= and in every map, as far as I can tell) are strings, for which "unsign= ed" is a meaningless concept.
=C2=A0
Example use
> cases:
[...]
> * Extend the block preamble (section 7.7) to ov= erride file preamble
> fields like "host-id" and "server-addresses", enab= ling fleet-wide file
> merges.

I don't quite follow why you'd need to put this informationa= l-only stuff
into the block preamble rather than the file preamble/configuration. Can you expand on that a bit?

Some of our p= rocessing can benefit from merging telemetry (e.g., all hosts at a site), w= hich would produce files containing blocks that don't share values for = fields currently in the file preamble. In fact, we might even decide to tre= at "block" as the only relevant unit, using block preamble extens= ion fields for=C2=A0everything in the standard file preamble except = version information.

> *Opt-in Lossyness*
This raises a question about a t= ension between the background of C-DNS
to date and the slightly different angle you are coming from. We've bee= n
very much focused on using C-DNS to record traffic in a form where the
packets can be recreated in wire format (i.e. as PCAP). The optional
data items mean that data may be missing from those packets, but the
core query and response will still be present.

Agreed. But it's _so close_ that I felt these suggestions were = worth raising=E2=80=94not to water down the primary use case, but to cover = a few more with some tradeoffs.

moves the recording to a point where reconstruct= ing wire format means
that the application doing the reconstruction has to not just omit
information not present in C-DNS, but must start generating values to
fill in for the missing items. This feels a bit like a step that needs
discussion; we need to think over the design from your point of view.
Possibly those fields should be optional, but with recommendations for
how to populate them when/if generating PCAP.

That sounds great.

We'll be doing a 10 minute slot on C-DNS in Prague= , and would welcome
discussion there.

I don't expect to be = there personally, but we'll have a well-informed representative.=C2=A0<= /div>
--94eb2c14c0ec9f06cf055395053f-- From nobody Wed Jul 5 10:11:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DA2131647 for ; Wed, 5 Jul 2017 10:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 2IZxSBO42Hh9 for ; Wed, 5 Jul 2017 10:11:10 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F0E128B8F for ; Wed, 5 Jul 2017 10:11:09 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 75D2824702 for ; Wed, 5 Jul 2017 10:11:08 -0700 (PDT) From: Wes Hardaker To: dnsop@ietf.org Date: Wed, 05 Jul 2017 10:11:08 -0700 Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:11:11 -0000 Folks, We believe that the latest draft-rfc5011-security-considerations document is ready for WGLC, and would like the chairs to start that process unless anyone thinks it's not ready to go forward. In particular, we believe all outstanding issues with it have been resolved. Objections? -- Wes Hardaker USC/ISI From nobody Wed Jul 5 10:20:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5422313013C; Wed, 5 Jul 2017 10:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 cLMvwckx-JHL; Wed, 5 Jul 2017 10:20:14 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 3CBC3129B3A; Wed, 5 Jul 2017 10:20:14 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 1CBA774001F; Wed, 5 Jul 2017 17:20:14 +0000 (UTC) Received: from macbook-pro-6.ether.lede.home (73.167.64.188) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 5 Jul 2017 10:20:09 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <149922136362.3281.8137557234349761847.idtracker@ietfa.amsl.com> Date: Wed, 5 Jul 2017 13:20:11 -0400 CC: The IESG , , Suzanne Woolf , dnsop-chairs , Content-Transfer-Encoding: quoted-printable Message-ID: <4D2C1513-BBA1-4551-B91A-4C8F6B63E200@nominum.com> References: <149922136362.3281.8137557234349761847.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3273) X-Originating-IP: [73.167.64.188] Archived-At: Subject: Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:20:15 -0000 Spencer, not to respond to all your comments right now, but just to = point this out: the list of problems is not claimed to be correct. It = is claimed to be the list of problems that people have asserted exist. = I do not agree that all the problems listed are problems, nor I think = does anyone else. If that's not clear in the document, that's probably = worth correcting. From nobody Wed Jul 5 10:22:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B532D129B3A for ; Wed, 5 Jul 2017 10:22:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 EVUb_WyCLhaf for ; Wed, 5 Jul 2017 10:22:10 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 A13BD13013C for ; Wed, 5 Jul 2017 10:22:10 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id b40so83584513qtb.2 for ; Wed, 05 Jul 2017 10:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=O36WfedRiDsk0G9pyri0mxH7KDRrteiCcBg5gHkOIu4=; b=LXAwA5Oe7qA0/XI2N0UTMZTD2D0QCsGer7EatLrwWqMrrf0Jk4EZgKydaz2B61VYY9 SbmCPjHFzIARiANeSzzF8oAwXAMPIEB3nSWAjpcM0yIBVLGVhcnaNBgqkp5hfpfJz9eJ jJ2OQIAeACb++ZzZxQAxP1FL6V3hTCPI5ijIWXUmVwXLBl1T4UNgLuRbTZOeyth4WRas fJzUwITmNhOQgOziOfTN+B+KxYLrj3V4t2T9CN5iTgypMp6Udc3lxrRtbGK6zwjVvs5f tBWeOHOVf3wG3Y5dGYAk6keX+ltySnYD+UUq7TNlu5dRGJx1aL+7Yy01y+dh9mYZ/OTq Lqfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=O36WfedRiDsk0G9pyri0mxH7KDRrteiCcBg5gHkOIu4=; b=SQ9z6YO/f2281tmZy4bq1YIYLY3/a3udLIYiHU70h0DuSm0+yhs0lZ7QWzSUT5OfF8 CBA21ntovhIbTGteGYeDNtlf+5PH8iOcl91j81YSQO+EAjNm/lQYT9gMTbHy77hfaDgf rO/adF+lE0RyjLaxFlv9LiNV5zrvu/XBzdzxUuKDL5tIof043FVnK6XjaeDy7ooJuH0L crM6pesl48QqsXtsnFUqN6CUujoSwyHPFbsJfiUtOhGa37gxk2Em4Ge57RnllPXAiAzy pz4O5+cHQV3QSHVKHFFO0aFt9uQ6Z9FiYaDiI5FUZcQ+AUp4vGzroBnHtx2B8ubN0XvG 7zaw== X-Gm-Message-State: AKS2vOwC3tun5LkUfQUxXqBqgk9rOHpAhnLKYo8nsrSFpMyNIzJOTwoQ eF90kdRpmxM4DzUM9BU4Cw== X-Received: by 10.200.54.38 with SMTP id m35mr58328970qtb.220.1499275329848; Wed, 05 Jul 2017 10:22:09 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b64sm15922535qkc.32.2017.07.05.10.22.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 10:22:09 -0700 (PDT) From: Ted Lemon Message-Id: <69A1DC89-EEA7-40E7-8F6D-8B1574895BE8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4D4227A7-F19F-478A-9D12-752F35A8803A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Jul 2017 13:22:08 -0400 In-Reply-To: Cc: Mark Andrews , dnsop , IETF Rinse Repeat To: Matthew Kerwin References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:22:13 -0000 --Apple-Mail=_4D4227A7-F19F-478A-9D12-752F35A8803A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 4, 2017, at 10:23 PM, Matthew Kerwin = wrote: > Hi, I'm jumping in at a random time with a possibly dumb question, but > the talk of and tuples got me wondering > about representation in general, and URLs in particular. This is an interesting topic, but out of scope for the document being = discussed. There was discussion of this topic at a BoF a couple of = IETFs ago, I think run by Andrew Sullivan and Suzanne Woolf, but I may = be misremembering. --Apple-Mail=_4D4227A7-F19F-478A-9D12-752F35A8803A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 4, 2017, at 10:23 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
Hi, I'm jumping in at a random time with = a possibly dumb question, but
the talk of = <name,type> and <name,type,class> tuples got me = wondering
about representation in general, and URLs = in particular.

This is an interesting topic, but out of scope for the = document being discussed.   There was discussion of this topic at a = BoF a couple of IETFs ago, I think run by Andrew Sullivan and Suzanne = Woolf, but I may be misremembering.

= --Apple-Mail=_4D4227A7-F19F-478A-9D12-752F35A8803A-- From nobody Wed Jul 5 10:23:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71854131D9D for ; Wed, 5 Jul 2017 10:23:20 -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, URIBL_BLOCKED=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 keT7HLhFaE1A for ; Wed, 5 Jul 2017 10:23:10 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 A02B4131DA5 for ; Wed, 5 Jul 2017 10:23:05 -0700 (PDT) Received: from [169.254.16.195] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v65HMJtb026977 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Jul 2017 10:22:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.16.195] From: "Paul Hoffman" To: "Wes Hardaker" Cc: dnsop@ietf.org Date: Wed, 05 Jul 2017 10:23:01 -0700 Message-ID: <31A2BD38-AB02-4224-91F7-4944435D498D@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:23:20 -0000 On 5 Jul 2017, at 10:11, Wes Hardaker wrote: > Folks, > > We believe that the latest draft-rfc5011-security-considerations > document is ready for WGLC, and would like the chairs to start that > process unless anyone thinks it's not ready to go forward. In > particular, we believe all outstanding issues with it have been > resolved. > > Objections? Just a note that the actual filename for the draft is = draft-ietf-dnsop-rfc5011-security-considerations, and it can be found at = From nobody Wed Jul 5 10:40:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ABD131C88; Wed, 5 Jul 2017 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.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 BizkT1VFhzUx; Wed, 5 Jul 2017 10:40:00 -0700 (PDT) Received: from homiemail-a59.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2910D131C81; Wed, 5 Jul 2017 10:40:00 -0700 (PDT) Received: from homiemail-a59.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a59.g.dreamhost.com (Postfix) with ESMTP id 8F6D5E036902; Wed, 5 Jul 2017 10:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=DK/a8Xow23nO7et9Bc9A7ySc/DE=; b=StIWitCY7ys1iS4UnHYJC6LYXhfB IdKDCMsyKG3hzs8EAiryuD9s5DgV3QFYRllM/lK6XjbXxO/p9U3gE1ZUr2/0mm3i HFRX5CT8hzne2HAPa1B3IRyvKNpDF3DTXt9CAySytVsyrNqLUSby9PcYqiQwP82Q cRWKFQDvt5XuUog= Received: from [192.168.1.11] (ip68-228-64-138.oc.oc.cox.net [68.228.64.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a59.g.dreamhost.com (Postfix) with ESMTPSA id D9D61E003A95; Wed, 5 Jul 2017 10:29:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: Date: Wed, 5 Jul 2017 10:29:18 -0700 Cc: Mark Andrews , dnsop , IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <20170705031957.834B97D8FBDD@rock.dv.isc.org> To: Matthew Kerwin X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:40:03 -0000 > On Jul 4, 2017, at 9:23 PM, Matthew Kerwin = wrote: >=20 > On 5 July 2017 at 13:19, Mark Andrews wrote: >>=20 >> In message = , = Matthew Kerwin writes: >>> On 5 July 2017 at 10:02, Mark Andrews wrote: >>>>=20 >>>> Who owns a name is a different question to what machines serve the >>>> tuple and how do you reach those machines. There >>>> is absolutely no reason why the zones and >>>> need to be served by the same machines. There is a argument for >>>> them both being under control of the same people. >>>>=20 >>>> Mark >>>>=20 >>>=20 >>> Hi, I'm jumping in at a random time with a possibly dumb question, = but >>> the talk of and tuples got me = wondering >>> about representation in general, and URLs in particular. >>>=20 >>> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks >>> like a DNS name is a DNS name, and that they have to be resolved to = IP >>> addresses if you want to fetch them, but they don't talk = meaningfully No, RFC3986 does not say anything of the sort. Neither does 7230. >>> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 : >>>=20 >>> """A registered name intended for lookup in the DNS uses the = syntax >>> defined in Section 3.5 of [RFC1034] and Section 2.1 of = [RFC1123].""" >>>=20 >>> I read that as: "if it matches RFC1034 (and isn't overridden by the >>> specific URI scheme's rules) it's a DNS name." It could be read the >>> other way, but that just adds more assumptions. Just read the text as written: "A registered name intended for lookup = in DNS ..." which doesn't limit much at all, and certainly doesn't say that all = dot-notations are DNS names. The sentence immediately preceding that one is: A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead. with both "usually" and "locally defined" being relevant. And two paragraphs later it has: This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg- name beyond what is necessary for interoperability. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. However, a globally scoped naming system, such as DNS fully qualified domain names, is necessary for URIs intended to have global scope. URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length. And that's exactly how it works, in practice. ....Roy From nobody Wed Jul 5 10:55:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD5B131552 for ; Wed, 5 Jul 2017 10:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 xoPIuHL-vWCZ for ; Wed, 5 Jul 2017 10:55:03 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 38C21131445 for ; Wed, 5 Jul 2017 10:55:03 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id c11so267112470wrc.3 for ; Wed, 05 Jul 2017 10:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oNWCTHHBnuA37mnsuldxbejfGeRGMiv7y2vtu8x2BC0=; b=kk5dgXbdDfQ+saF0YrZ19MJw7EyIhtDAGfPFc1XSiK6q3lE2nWgHdaA12R7RqK9EAX 3ikx4vjJ3F2OLdjuKHmCzLqmGhicpiTvHeBx6wTLpObthwcHLXuPC8cECGSk6sWbBsbt Px5YZpPFITy3Zmg+19bwJaU6DubW24/UicRgcvB+TKcJ16nghhq41Qlaun/p4zwAt1ed fTYZlHXOQfYxrFSVo1WvX2ioNqcVFHXL3I07G81p64mUg/z+6QIshHPmctlP9VsN3wF4 8gz0f0fC4cnbJ3Hv/kHar/pK7bdjl2x+Xwq3FXWZybchch/jUYdn+vtgpKil7OXEL5G9 QBHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oNWCTHHBnuA37mnsuldxbejfGeRGMiv7y2vtu8x2BC0=; b=XFIi3PGCawCKzRgbIXZ+x93obDMzqCYj5uvoUTVZDQpYT11OD681unenu2x/HJ5Kzd v0YJD0SnEJPmmrFhOnFbIYV5UGDkY1JykzVMu8SkJQWYO29EfgopN/DGux1OvXPhFG3D +o+NpecD/iJ2lQgvxGlhysVTrJccXz7cE2jD+tAIC9CyQOF668Y++et1zn1beebB+Qdt ab4ccUOvpiUGdUZvd5UcyV9gwQ+sbcHmg0YkUwWzIDm3MoSGX7q0FhQ6OJjweuXaYGD/ q7rv+QvaMwsers/JPBAf0dbstEYYL6c47ahctnEdSfdOHA2CZDAWMwz5KX60FrGeebHV ptwQ== X-Gm-Message-State: AKS2vOz8B/Z12bXcWyyEI4yPn2KO/4B84VvFoKqSzlrw9AtTecQHNk7u k2833KsrDPvQjIL5Ko3RR6URXZh1XuRX X-Received: by 10.223.136.216 with SMTP id g24mr36990868wrg.199.1499277300889; Wed, 05 Jul 2017 10:55:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael StJohns Date: Wed, 05 Jul 2017 17:54:50 +0000 Message-ID: To: Wes Hardaker , dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a11491848f0939d055395b202" Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:55:05 -0000 --001a11491848f0939d055395b202 Content-Type: text/plain; charset="UTF-8" Could you hold off on this for another week? The revised version dropped last week and I've been on travel and enjoying the holiday and haven't had a chance to review the changes. Thanks - Mike On Wed, Jul 5, 2017 at 13:11 Wes Hardaker wrote: > > Folks, > > We believe that the latest draft-rfc5011-security-considerations > document is ready for WGLC, and would like the chairs to start that > process unless anyone thinks it's not ready to go forward. In > particular, we believe all outstanding issues with it have been > resolved. > > Objections? > > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a11491848f0939d055395b202 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could you hold off on this for another week? The rev= ised version dropped last week and I've been on travel and enjoying the= holiday and haven't had a chance to review the changes. =C2=A0 Thanks = - Mike

On Wed, Jul 5, 2017 at 13:1= 1 Wes Hardaker <wjhns1@hardakers= .net> wrote:

Folks,

We believe that the latest draft-rfc5011-security-considerations
document is ready for WGLC, and would like the chairs to start that
process unless anyone thinks it's not ready to go forward.=C2=A0 In
particular, we believe all outstanding issues with it have been
resolved.

Objections?

--
Wes Hardaker
USC/ISI

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--001a11491848f0939d055395b202-- From nobody Wed Jul 5 11:37:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75F131D9E; Wed, 5 Jul 2017 11:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 4vq8LhQOCIu5; Wed, 5 Jul 2017 11:37:47 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 67F58131442; Wed, 5 Jul 2017 11:37:47 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id f194so15666991yba.3; Wed, 05 Jul 2017 11:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=utIfKahTTGf6e8CmH6+Nk717kCKioY75abtfTMUFgyQ=; b=LzhiVyveg50I+RN0cfpcYjv4baseZuUCd2M8fHQeUbk/8R06YYNLoq5a2kHkEfC5jU nUbjLle1HIYZVX0kr9No/7P0lqt4AvD9NHrIfArjF7aktqoB0Lka90/u1BgZ02t71Z8T DWKYNfSQ0WGEZXpOuoG/TmdfU3IjpwDsmd4DfK8JtbYx4Ke+54TQp3ZK/6Emzx8abuh7 ouGkC9Jld24QERZ23lafQvFP8GPbT2SkJz7ejUOM8Hv4pIGW1ZmUzfWeN9Hc4sm/T4ST ou9wzDq2/OOmEvKxsax8aBNoMAo2gQnDrhR3h0Y/wou8DrAH8AABf8y6/8m+6BT15ArC gklg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=utIfKahTTGf6e8CmH6+Nk717kCKioY75abtfTMUFgyQ=; b=P8w/7M43M//Tkbrb+vd+kuzH/5AFZGWYtgAVoWTroDHDataQ3oNeSqnxJnSRpSAQgn v6wCMzWQHpOX5MpRvay9aaYguiuHzNPfL6drbaxuR/eDMWkKxSpfJYnTHK9icffmy/WQ H9Z0Ni3t6Zn+vwOsLCBEbXI5hhszuk7ccBva8DDIvtffZuSTY+gV55ObafZSlQiouvL8 luIOAEug/ewI2ZezBgwmBzPLe6LoNHxYu4rn6+SKUFnlfSoBRDPKFfQI6w8GqQ6pS+X5 RczMzFvch74RTXMwN+jVdsrPPpL8vy3Vr89Xdsvc90lj2zfhowkl76UV+ZmlWY+pyQi3 lpow== X-Gm-Message-State: AIVw113+Bcab80GrkNRmoS1T3JIAx/6ohSG0zSu2OYJEgmUkCdm/pBQX M1dchF86cLbF4hgl1qY6a05sSBplRQ== X-Received: by 10.37.218.72 with SMTP id n69mr3365444ybf.83.1499279866431; Wed, 05 Jul 2017 11:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Wed, 5 Jul 2017 11:37:46 -0700 (PDT) In-Reply-To: <4D2C1513-BBA1-4551-B91A-4C8F6B63E200@nominum.com> References: <149922136362.3281.8137557234349761847.idtracker@ietfa.amsl.com> <4D2C1513-BBA1-4551-B91A-4C8F6B63E200@nominum.com> From: Spencer Dawkins at IETF Date: Wed, 5 Jul 2017 13:37:46 -0500 Message-ID: To: Ted Lemon Cc: The IESG , draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs , "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c07dd7adb8fe20553964b3f" Archived-At: Subject: Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 18:37:49 -0000 --94eb2c07dd7adb8fe20553964b3f Content-Type: text/plain; charset="UTF-8" Hi, Ted, On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon wrote: > Spencer, not to respond to all your comments right now, but just to point > this out: the list of problems is not claimed to be correct. It is > claimed to be the list of problems that people have asserted exist. I do > not agree that all the problems listed are problems, nor I think does > anyone else. If that's not clear in the document, that's probably worth > correcting. > I think my comments are more likely to be unclear than the way the document describes the problem set. What you said, is what I think the document says. I'm mostly sending comments about specific points that the document makes, that I think I understand at a surface level, but I don't think I understand the implications in a few cases, so, that's what I included in my ballot. I think the document is clear enough on "claimed to be the list of problems that people have asserted exist", and even if I didn't think that was a fine basis for this document, I wouldn't dream of suggesting that the authors change the criteria for what's included. --94eb2c07dd7adb8fe20553964b3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon <ted.lemon@nominum.= com> wrote:
Spencer, not to= respond to all your comments right now, but just to point this out: the li= st of problems is not claimed to be correct.=C2=A0 =C2=A0It is claimed to b= e the list of problems that people have asserted exist.=C2=A0 =C2=A0I do no= t agree that all the problems listed are problems, nor I think does anyone = else.=C2=A0 =C2=A0If that's not clear in the document, that's proba= bly worth correcting.

I think my commen= ts are more likely to be unclear than the way the document describes the pr= oblem set. What you said, is what I think the document says.

=
I'm mostly sending comments about specific points that the d= ocument makes, that I think I understand at a surface level, but I don'= t think I understand the implications in a few cases, so, that's what I= included in my ballot.

I think the document is cl= ear enough on "claimed to be the list of problems that people have ass= erted exist", and even if I didn't think that was a fine basis for= this document, I wouldn't dream of suggesting that the authors change = the criteria for what's included.
--94eb2c07dd7adb8fe20553964b3f-- From nobody Wed Jul 5 12:32:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E5513154F; Wed, 5 Jul 2017 12:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.096 X-Spam-Level: X-Spam-Status: No, score=-13.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 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 Kml23rXVOfnT; Wed, 5 Jul 2017 12:32:26 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6012C1319F9; Wed, 5 Jul 2017 12:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51106; q=dns/txt; s=iport; t=1499283145; x=1500492745; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=hIRIZ4fu0tQDMWBDYAPSEL3i8n7y4BESbsa4lBcxjEE=; b=M11alrRQrLnosdr4f28Eo3K5yQkSM5TEZLgY6PrJMhCZpz3W4+qRAux2 BK+P86m2zOpJrk47JzTypf/Zch+XiyXeZ5KxeQ6mw1m+YlqdXI2QhX9DD UgYyAyJPxDe11rhKjeZ8dF13jecD3w0wUMwep71bT+gKzFrhbhmAv6Dsc A=; X-Files: bmhgnffkkhhgliop.png : 33772 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAQA4Pl1Z/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgniCVI4Jc5BSIoJfjXWCE4MZghEHAYYUAoNbGAECAQEBAQEBAWsohRk?= =?us-ascii?q?BBQUeVhALBBQFAQEBHwMCAgIVAQ4gEQYBDAUBAgEBAooprmGCJimLFgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQ4PgyeDTIIMC4Juh32CYQEEnWqBHIZGAY0+iySGeox?= =?us-ascii?q?hiFIfOD9LMSEIGxVJhRMcgWg+NgGJAgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,313,1496102400"; d="png'150?scan'150,208,217,150";a="695617729" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 19:32:21 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v65JWKEr010245; Wed, 5 Jul 2017 19:32:20 GMT To: Spencer Dawkins at IETF , Ted Lemon Cc: "dnsop@ietf.org WG" , draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs , The IESG References: <149922136362.3281.8137557234349761847.idtracker@ietfa.amsl.com> <4D2C1513-BBA1-4551-B91A-4C8F6B63E200@nominum.com> From: Benoit Claise Message-ID: <81b46c8e-8667-de07-e564-153704d4b4b7@cisco.com> Date: Wed, 5 Jul 2017 21:32:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1177770B537A810C91E269A0" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 19:32:32 -0000 This is a multi-part message in MIME format. --------------1177770B537A810C91E269A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, > Hi, Ted, > > On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon > wrote: > > Spencer, not to respond to all your comments right now, but just > to point this out: the list of problems is not claimed to be > correct. It is claimed to be the list of problems that people > have asserted exist. I do not agree that all the problems listed > are problems, nor I think does anyone else. If that's not clear > in the document, that's probably worth correcting. > > > I think my comments are more likely to be unclear than the way the > document describes the problem set. What you said, is what I think the > document says. > > I'm mostly sending comments about specific points that the document > makes, that I think I understand at a surface level, but I don't think > I understand the implications in a few cases, so, that's what I > included in my ballot. > > I think the document is clear enough on "claimed to be the list of > problems that people have asserted exist", and even if I didn't think > that was a fine basis for this document, I wouldn't dream of > suggesting that the authors change the criteria for what's included. Part of my AD review, I asked the text to clarified. Hopefully, it's clarified. From the 04 to 05 diff: Regards, B. --------------1177770B537A810C91E269A0 Content-Type: multipart/related; boundary="------------1C8DE3F74EEFE0704CAA3F71" --------------1C8DE3F74EEFE0704CAA3F71 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi,
Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon <ted.lemon@nominum.com> wrote:
Spencer, not to respond to all your comments right now, but just to point this out: the list of problems is not claimed to be correct.   It is claimed to be the list of problems that people have asserted exist.   I do not agree that all the problems listed are problems, nor I think does anyone else.   If that's not clear in the document, that's probably worth correcting.

I think my comments are more likely to be unclear than the way the document describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes, that I think I understand at a surface level, but I don't think I understand the implications in a few cases, so, that's what I included in my ballot.

I think the document is clear enough on "claimed to be the list of problems that people have asserted exist", and even if I didn't think that was a fine basis for this document, I wouldn't dream of suggesting that the authors change the criteria for what's included.
Part of my AD review, I asked the text to clarified. Hopefully, it's clarified.
From the 04 to 05 diff:


Regards, B.

--------------1C8DE3F74EEFE0704CAA3F71 Content-Type: image/png; name="bmhgnffkkhhgliop.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bmhgnffkkhhgliop.png" iVBORw0KGgoAAAANSUhEUgAABhQAAADkCAIAAAD/zFkAAAAgAElEQVR4nOx9O3LsONI1NyGn IxTjKIKG7LbktGw5HE9yx79jyBPtMXo2IEP20Pm20IY28HMrvQX9BouFzERmAuCjUI+TcSLu VZHEIzOBQp5Cgs0Pl78hEAgEAoFATi4/EAgEAoFAIJBzlUb8XXvpCIFAIBAI5BalyjIIAoFA IBAIBJIjII8gEAgEAoHUlyrLIAgEAoFAIBBIjoA8gkAgEAgEUl+qLIMgEAgEAoFAIDkC8ggC gUAgEEh9qbIMgkAgEAgEAoHkCMgjCAQCgUAg9aXKMggCgUAgEAgEkiMgjyAQCAQCgdSXKssg CAQCgUAgEEiOgDyCQCAQCARSX6osgyAQCAQCgUAgOQLyCAKBQCAQSH2psgyCQCAQCAQCgeQI yCMIBAKBQCD1pcoyCAKBQCAQCASSIyCPIBAIBAKB1JcqyyAIBAKBQCAQSI6APIJAIBAIBFJf qiyDIBAIBAKBQCA5AvKoQL5emublq3YrbkG+3x+ah/fv2s2IBB7AZY0+oMuTCVQNuRSpsgy6 Bhn7tmn7sXYzbkGGrmm6oXYrIjnTZlWTNfrAaDqZQNUQyAXKGZFHXy9N05wlZTDLGcVg3+8P TXMerVnVFMPoII/K5GCDg5yuhddCHp3/3KNI/sA7J1WfSCaLHqSqYTPMRIbvjZkplirLoLQM XdM0Zx3jnFMMdkbaWtOUsW+bRiEgzpSlOdNmzTY4yOm84lrII8sNz1uyB945qfpEcrDoQaoa NsNMYfjemJkgrpyUPOIhrra2/3q5sACupny/P5xLqPH1sjzq+X5/uAKj1/Tcr5dL4z3OUfa1 4JrSnYF+RnNAmeyq7e/3h/NiYTLNtGYavRapsgz6+fkRIa62th86LJ7z5Xy0Nfbt8qYM3aVF 7YqMfVutE2PfXoEGa8u+FlxVujPQz2cOKJN9tT10Z8bC5Jlp1TQKuT45NXk0r43JMpmGESCP CuSMAkeQR3XJoytQYHUBeXRK2Zs8Oi+tgDzKlirLoJ+fH7qEJstkGkZcaihUR85HWyCPKpNH l6/A6gLy6JSyN3l0ZloBeQRZIOdIHjmb+Fkygrg4X3v5CnucaIDC9j2VRS7JtAJyw8P7d0Fg xDdjFbfq5YvqhD+e0gfXJu9Xslm8w4VRD6n35UuQR1ZvWJMe3r/11q/xD9EuHu85HqDup5sL PhZ5rCn+pEBdVp+olISfetEhiYtbSu+02iT+cO6zfrNC/k8ooWjEcG3Fc8vD+7fbOMMQIueN +pnobpDcdmsGbrhfvnxlDZqNJy7RODlenKG4Sh9x2d7ElV+25lvbzqfeVE0KUM2kfnXNTX6f /iUjznaCchufXKosg35+fnLJI5JxIOMLlowg1tnztqZuCPexW9i+p7LIJZlWQMruhpLAiG/G Km1V248/lrqS+mDaNJRpNot1uDDqIfW2/cjJI9v4tEm0T7T1q/xDtIvFe45P6vvpDneF5+bH 4k8K1CX7xJNz1FsWFB2SuISl1AdFN7SHTecy2mr0OOT/hBJKRgzXlqz7MGqdxiWbxXpHJjXb P8qarDQsMWPuN3H9uOPFG4pr9BGX7U5c+WVrvsUfZHNGZORks7ypmhSgmknX5dzkvptLnO/j hbtmgpyznB151DQ87OJBmiSDonXw10vz8hJO+DiWLRMZlp0Coi/uedlfL83iQzbKWvX9/vDy QnWipC9Z+pDacw8Zks1SOpzfbtbI7xD4RH3TmiMNwFqyxj/UdildMlkyOyaLrVKQVZNlpmXx oF/018vDw4PQSLY++MNWd+3RZDfr+/3h4eGBzB2LE/YiVX69PLy8kJbyZicMIU0QbTXZb+dR w4krtZodJi53vKSH4mJ95IyIZTuPhG9tOZ/mTNV/G2byvrq+3x8ONiMWiCyzzZfTiaTKMujn 5yeLPKJrX5GOI7NztANXhq7puvB5qFAkMiw7BcRY3LOyp6X6sl/VC1s1dG3XEZ0o6UumPqT2 vNNromYpHc5uN2/k0CnRztzwuDmRAWhLVvmH1i6lS+YuKTvu1q2Sq64cMy3cxeEWPfZt2wqN ZOtDPGx01x5NTo+Hrm2DN65J2JOqHPu262hLebOTzZLkWhTB77TzyJkxae1bT1zueEkPxeX6 yBkRyxgS7luqNse+bbvueBPpRdI/UlP1j2EmV5dDN9ssWIA9kDetQc5Tah2YbQThCjlA1snx E18vyr4HdVWu8RMvpatoMwbbbD1eElMpcVPUFEMfWj1exEVvV+7LZ0OUetU4ytIpv5netco/ /s5NGVlAHmnRX/7GkxwzLQrEE0UrjdQ0bJFH/GHdtdRnE82KPG0FKSNapTC3oYUpQ1Qkj+SA zyFdjYdLxBkvOUNxqT6yRsRi8sjYjkb/XjSf5kzVf+s6db+60j/HXFxScJVlkBA7mpG/5bop bWPfxT88KwWrocrQlYYvma1eIUUxlRI3yaYY+lDrcSIudrtyXzYbotSrx1GGTsXN9K41/vGT mzKygDxSicv8jScZZloUiCeK1hqpG14nj6Qb6oNSDZXdHktPW0PK8FYpzG1oYbpZ9cgjc8Zk n249cXnjJWMoLtVH3ohYSh5Z29Ho3yrBluG2qan6R9epr8vkzzHIhLtkOTvyyIzB1ASOaCVv /8SuSWmE4VAHZosSEjWtiDyKWqMkj+ToOXrWaZb2bG7amtHkfPKI8RJf4rf8xf5xrDPpGkvI I97Qgm1HaTNl1L2waN3KWeFuBpViPptq1jpSJvIRTh7ZPU4aoiJ5lFPPDhOXM15yhuJCfeSN iMXk0V7zaU7Reun+V1eaPPp7nY1PL1WWQULMaMaMwdQEjkYuyY1wyDipu3RZba7EWePKgqKo aSXkUdwa8ZnNwSgfy2hHb5b2bHaIojc5nzxivET0E/ti/zheTLnGIvKIN7Rg21HaTOm6FxZt WFnbyZURSmeTR8keJ1kaTyIfEeSR2eP1zdqPPMrRxx4Tlz1ecobiQn1kjojFO49S86mhyGL/ 0D9TSk/oMkke/WRNa5DzlIsijxbvDNnq59esNhTknsU/SBfuPNon2PGbVZc8Ilf4/paVO4fi WowdBkvII8IYFSVagTySj68gZaJxGe08ukHySNy0+LxmNl5yagN5lE0eOYrKIo9EDYttfBqp sgwSsog8Wr4zZKO9QVltKMk9i36QLtx5tBN55DarLnlErvD9LSt3Dik3Gkc9LSCPCGNUlGgF 8ih6fDl5FI/LaOfR7ZFH4qbl5AIdLzm1gTzKJo+8ruSQR/z+pSnVkApyOeRRdgCk3bQRe5RJ PaygUkrT1uJ8jSjNQm2Kl2aRaFbVtLVQmZLAtNw/9GpyTyWZLviGm3pZsu3IKPUy0taWkkcZ +T8LSZn4xjhtTd6xPG0t6tsFkEclo0NtSQl7dLlpa8XzqV50btqa+9VVTB6ts/EppMoySEg5 eZQXAFnB/TbsUSZHsoJKKU1bi/M1orQ1awOPnWaRaFbNtDVSmZLAtNw/cm9dSh7NvSzYdmSV ehlpawvJo/X5YZaozFcim3B52lqklwsgj1bmOJEuZ5RzuWlraskZaWupqdoo3ddlKXm02e8o kFPIBZFHSngXx3vm0jhavpfG8WbpWqsyC+Z3fvG3NiXlO/OAV0sf8lgaI/aLm8Wf/T6+qChL 8vrshkxfL9M7hpQf7pf6h+YeRVE4u//7/SFSyPf7Q/PwUMphemYijVoSiPtFywOzSwigNeRR olnLyaOk0/pHhCcMQW9WB0TSPzxhmmLH7qwhj1ZMXMnxkhyKi/WRMyIWk0d8PlWUuWg+zZuq zdKdr64keZRj4zkz7jw4pSrLICELyCMlvIvjPXfDShTfbZK2prUqs2B+53h8T1WmZBzwmrGB J/472Sz+rHjbVEIy++zFOGPftn2vRnqL/UNzj5KdR/yKdrTS0DX8COosyWEDFwbibtGjPDBb D8g3J49SPV6+8yjltFGPowOznWaNIpsy9umkfzjCNDWyY3dWkEcrJq7keEkPxcX6yBkR2xyY rSjTVlHSbVNTtVm6p8sUeZQ1rR3y2pDSdnZycvJInuFA06H4Z+FOnpykPiyvRJfjqrPXyvqx E3R97labXfbD+/yy5XTTQoBKSjBPutAbxu+IwhO3WfTZl/ld4flhPC2cxtr6aSnafhejtqX+ EduYVprwAF1natsWbRHKMpNbdXnRUwAqzOzVO9ecGsYZujSaRZ6cPgv35W57Y6V+hzeVBf8l 9yjcpKWtqHWkbE1pxW6gGSKpjx0nLn+8KMWr/PBCfbhuG3e4gBDj82nh94vvtvZUnTEitK8u YX4yBZPZOsfGII+CyMN0SBg0fxQSfOjfPz/sQ/5wXG6jhu/O1fwm87rjUylKInladje/bDkv /6pxXy2d1gdveBRjuM2iz7bHd4Xnh/G0cBLHx7pULTWaL4Za7B/RZbkpJd0s0S29bYu2CGWZ yau6vOgpABVm1p/jN5BrU0tCG+XfVqutZmXNEJndDSOnGyjfQ+7RuEnLELLf2jhO+UdJ0/P0 sePE5Y4XrXiVH16mD99to/4WEGJiPpV0mKVJv1lLpurGGxHRQGr7kVKWxPnSZvoBeXS+Umvn EQRyY7Jkq1s9WZNmBYFcoCzbrwTZVqosgyCQG5cFW93qyao0KwjkAmXZfiUIZC8BeQSBnEKK TsquLyCPIDcmII/OQaosgyCQmxY9UeVsBeQR5NYE5BHkvATkEQSyo9hpmucrLNcF8TTk+oUN 00sYo1crVZZBEMhNipmmeb7CkmQQT0NuQNgwvYAxCrkFAXkEgUAgEAikvlRZBkEgEAgEAoFA cgTkEQQCgUAgkPpSZRkEgUAgEAgEAskRkEcQCAQCgUDqS5VlEAQCgUAgEAgkR0AeQSAQCAQC qS9VlkEQCAQCgUAgkBwBeQSBQCAQCKS+VFkGQSAQCAQCgUByBOQRxJbv94flrx76esGruiAQ COSKZdV3hCJVlkGQS5ShW/7qobFv8aouCAQCuWJZ8x0B8QXkEcQWkEdXKoc3k1+Veb5eTvKa 9amarV7qfpGGyND0oV+X17cblmW+CPIIUklAHl2pTG8mvyrzjH17itesH6rZ6KXuJ2r0tpLT 6MnBrs7JrlqWTQogj/aTU5JHc9g1LzVJgJG9Yv162T06vBn5fn+4usAO/sHF0cda85+jqvdu 0/f7w0IyZEdDVJFMTX+9gDzaXTZ0oPr2qrIM+iFh17zUDAFG9op17FssVLeSobu6wA7+wcXT x0rzn6P37G7+oVtIhjgtu0ifzWz02Lfn5yVXJ9sNRdjrrOTEO4/iHze/3x9K4r1zjFgvVS4y aE0I/IMLyKNNZbnOQB5B9hKQRxtJ/OPm0JX8bnmRgda5yjmG/ysF/sEF5NG2srjTII8guwnI oyuV05NHD+9flC+KyCO6H4leoZ8vShthBZAHaR7Ky5fRAJaswpfX8/0P79/hvumWUNT8SPxJ orkvX7RBvL+sUVGBtCmsjdGTSgHhBkvFtIiH9y8Sv9gpKyHfhTzN7uFWZnVrD3MWMu5Svn84 FWu9Yiyo4wGxrmLDW46pPP3ylR0oJvUxlWQZ2tPH6qHo6SNpCH7HyxelMb5eHt6/V6RMybnA 73Nel1caIu0fbrXO/JF0W08fk9aTqrbICNUD5ia/T/+SoS56vWxE2BX/nZpdxI8eVHO5jV72 DUIvaw6QnMgLJp9D07OVaXqs5nrZfltlGXSQoWu6gfFFkjyiaSFsHUv2KQUpibpYAeHBqEJ6 33wbS1YRy+v5/m4I9x1uORZ1fCT+xG9u24+0Qaaq4gKdZoknlQLIDYaKWRHdQOMXM2Ul5LuQ p/k93Mq0bu1hwULGku8fdsWaRnjmjqfqSFex4Q3HVJ5u+zE7UEzqY+jafjQN7egj6T0pcfWR MgS/o+0HQmNMlMbylClz8tHVmeddKUMkG53wD7dab/5Iua2njwN5lFK1RUaoHjAPqn76lzRd n0cOV4qoE8v1ErOL+NGDam6+1HeNKMEeNPnfIPJJx0DGLQnv4c5RQh7Z3xGa610eP3oGUoM8 +v7764XmrgkiR6zotZhlUcVROO/tfyItFH/opzx8vz88vLwcPw8BjZLoIorzW/3wQJ93HtXP nvh6aV5eQl+Z+jKiLmtfmGjH10ujxCV6IPL18vBAW+plAkX25w+rut1k64msmNX0/f7QPDxI 3Zke4HtPwjH501MsVsKI+BteGk6P2qrTzq9aquqM0eRULPT1/f7Q8JHa8Bg/X1mKYaJ27bXz yDZEyj9cyZg/TLdN6OPr5eHlRQwKdbQrn3oeEAxKnN2ejctGRML1/Nklsn0wabLRa75B4j4o fKszg2ZPPgcyqNTB9e8I4Xr533lVlkEHmaiisW9p7hpjkugqMz5OYfGv9CLfRB7Io1FYNCQV UXe8Fh66pus6QifMpceJLrI4t9Vt24o4wnpUPXvCbFb8l1WoVp9ox9i3SvSoByJj37Zty21u NSM6Nkk8rOp2iyhFVhy5Q9tG9ViqTnhPwjH500MXR56pjjg7j2hQ53qldn7V0u0OOaPJqVjo a+hoYDrFszTGL2hjcvL52W3nkdPohH/4kjF/2DOEq4+xb7uONk3XtToHeB4QppJJLd0gy14x IhKul5hdpO2JSYMXhvbQylZ9g0S3KY9aGkh/7UUkVbGD698R3PUKvvMgQeqQR2TVSpee2iJY BF0LI1btse/3FzNGozGPujT/elF+PDZX+3L9nrs+1+61NaCrz/7RdzF5tCplRQkj3OBH7j6S mye2IRf9iqNSFcMYHpDwnqRjrswj8TkLSZg6uosvLlN11mgyq0m5rNRWAdmjdCd+ei/yyDRE 0j9cyZg/zIkroQ+Fw9BcVfnM9wBylTzLd5ctHBFJ1/NnF5888hq99hskejKejfQHs1VNG7EZ eRTx/lleW2UZdJB5oRlWrWTpqQVYYl28kBxQHxs6M4ZnMY+2NB/7Lv7x2PzxXQYO2etz5V5H A0pD7Wbp9ysNULfCLE9Z0cIIuyGiquhhJ6BbJ6ygqH16J1RV+96TdMyVeSQJ8kgSprbu4osL eZSs0WRWnKg00lZ+IzMmn6LyMooPl8xGpycuVzLmD2uGSOhDIbE0V9U+cz2AMzLhv4zjWGiD lOslZheXPCIsSRuN7ZXfIMluWF6Z8B79+2Iz8iji/cEelUol8igs1MnSU18D80Xn4og13j7X yL1Hxo4FNTNAyeRxdxbQoCu/B5pGZARndeh4hxkMLCWPciNoc+eRsj+K7zww9Swf3pA8cirO 5RW0qn3vyXBMfk9pZFdy1A6/1zeEX7TboNRo8ipO1Zn0j+wn9cf3Io/cLS0J/3AkNX/87e0t 9PWRGMbhIzOd1hwRCfJo8YhIup7vPcvJo7XfIKmh6O5SsivWTbgdebRsZq6yDDrIcaF5XKiH pae+vOQr3IVLUDVzJMp60n/8VzMDGiXLx4vSWdBVkkulJTmxwswOJZu1mDzKjKBN8igqkX4W mUqQR1Ltm5FHdsVKf5V6dFUnvCfDMdk9pZGdTx65unMNoTye3aDUaHIqTpk36R/5T+qPn+TM I7H7J+UfjiTmj0MNxt5CVx+pYRw+UtgrxwPS5NHP0hGRdL2E9ywmj9Z+gySneW+Xku09hgm3 23m0D61/S1KNPJrXqacij9KPHdfNzi6khTUcGaPCX3bd4E/L6Llw8ihO50hsPNuKPPIrXkke OcrKcky3nQlZSB4lDeEX7TbIHQCJim+QPFqzk+5cySN/RCTJI3F/7ohITuQ7kkfLv0EyhqJH HjkVgzySwvcZtf14MvIo+VhYNzu7kJbVEBijwl92veBPy+i5dPIoysmIdx7tQx65Fa8kjzxl 5Tim286ELCWPUoZQHs9ukPuYX/EtkkdrQu4zJY8cHWaRR7xJuSMiOZHvSB4t/wbJmeYd8shR Dcijs5eK5NHEpLyfJG0tlz16eGcHMh0/Ty6oExUcSKOibUfhMdHKqYhYE6cij3IjjOK0NaVB pyGPUhVnpq0ZUfiW7FHpA4s5i4Qh/KL9Fjn6SFWc6v1y8iibITwpebSSPcpLW9MrSKetxQ6R t/Mx1wOyyKMSFaXmrTLySP/ZQ230im+QnKFoe2XpYNs0be2iyaMDk9KfIm0tlz2SBzLNn6cX 1IkKJtKo+OQHJ+1EpS9OQx5lRhjlaWtxg05EHiUqzk1bM4K/LdmjwgcWkkdJQ6j35LbIeS5V caL3y8mjumlrdqPXsUd5aWtqBRlpa+J6btqa6wHF5FGBilLzViF5pLZPTVtb8Q2SNc2b6vFV s3PaGsij1VKTPJq31bMoXR6UEL+YhrNPBRkc7sm7x8LfFYJH45Oykw7CEw+lK/NveeCtuSnh m78OiFZrV8kuqqcj2RGN8uKmvC0G8sBsI/L6W/GODHJgoX+kKuZ6mGyZSR6lvMd1TO1iKf1o 6cML75KG8Iv2xdNHhgdEZ6izw6YXk0eRajVVLyePFhoib+LyKrXmD61ddoujvzPPvc8kkMMH KR5m3Yjwh2LCe8QJ2MQz04zX8m+QnKHoTORuxXnfIQm5VvJo3o/P6KREZCPZp4IMDv/k3bnw XuEFND6pIG1tfqJtS3/WlQfeGrHVz5yhUEYesZhm7FvjwG3l+ejnfs0SJnnED8zWI68fxTty yIFl/pGqmF8fOuvAbFXVCe9xHVO7WEo/WvpwwrukIeQ9uvfo4ukjxwOis1TYcctLyaOcyWcF eeQYIslZpCcuu1J7/tDa5V5hf0fDWG9VJoEcPkiSR6tGhD8UE4ag9wrPTJBHa75BcqZ5Zyj6 3pP1HZISkEe7ySnJI3ICAw0F9PdH8/v+1m8o3rRBcyuVRfK3/e4efnxEvORuEkUXhdfkmZcv u8e0Tcf7SBguRc1S0Bqtn5UhgwH9mqaP+GARo+Kor1/h9VnhkamwcKvpQAX+4VQc9ffh/ZvG RhkeYHqPVgDf7eAXXN4x+eFUYGjgoYKkPqyis8TRR7piY4rI9I/8ZkUclZRiJniJIaIOF1Tr zh/Fbkt3HTHjRI+m5oCoaGmx5uWLESXBCVaPCMP1sryH33Ro30O60V7FaUPkDEVrPnUrVh7U yam0HlndWU5tSZVl0M9xwd00DV11N3FwGERbyNKDHIo3beSUra6eebvcI1qMEkqYrvBM249m j2mbwn2HO7KaJUvQO6s+bhpKP2hDRGhGxZF1x/AmKvLIVFi4NeKx1AspVVsVR9enPWScCvBV bXuPUoBgDtyCyzsmP5wKDA2cK0jp48f0ngzx9JGumCtFxPPhI8M/spsVc1TrbKEZIq/R6YnL rNKZP0rdlu06osaJH03MAVHRzbyZkv5NuAwys60dEYbrZRmC33TwzJapgLBKwnMXf4O407xx DxXXe8SDOk+coUdWenp2gWTJiXce3bCUpqz9/feajQ7nK5u9D62qXKNlINcm8FLIpUmVZdDN S3HK2s/Pmo0OZyvX8Qv0dfQCcuVyhfMHBHIzAvLoNLLkMInrDP6ugjxacK4sBHJqucb5A3Ld UmUZdOuy5DCJqwz+roJ2WXmOMQRyErnC+QMCuRkBebSvyM39RSkn4bEr4Fv+/lto49LCWtr4 K7EH5HrlGucPyPVLlWXQjYrc3F+UckKeuw6qgmnj0sJaao9Lazvk9uQK5w8I5KYE5BEEAoFA IJD6UmUZBIFAIBAIBALJEZBHEAgEAoFA6kuVZRAEAoFAIBAIJEdAHkEgEAgEAqkvVZZBEAgE AoFAIJAcAXkEgUAgEAikvlRZBkEgEAgEAoFAcgTkEQQCgUAgkPpSZRkEgUAgEAgEAsmRSySP vl4u71Vdlynf7w94URMEchSMCMj1yZpv1K1HRJVl0IYy9i1ed3UaGTq8qAkCCYIRAbk6WfWN ihGxn5wReTS9Cj1jHbo7eZTdkmuXWwqVJ6NbhicvPr9+3jLD/69MH4fupLuy/4jA5LNCsu0I oQLyKCnTq6Uz1rC7k0eHN8pjRXxLgcHB6Ibh/atXJhn+f236yJ58dh8R2S2BKALtLRGQR2cq Fcij7/cHc6H69XImUdP3+8OZtGSNeKq+VNnZRRKG/3q5kcg0U82Xo49ADnI5Nv98Bst1TD5r BuoaW5yPHa9ATv+FXGUZRGTozIWqc+nEMnRXsCIe+/byOyFk7z75hr8Kt8iRTDVfjj4I3cUk TDhnM/mMfXsmLVkjawbqqkF+Nna8ArnGb5ALEpBHulxH/HaNcRTIo5PIFZJHc4eIiekAOZ/B ch2TD8ijKxCQR3mXTiyXExU7co1Lf5BHJ5FrJI/mlpJG0wnnbCYfkEcgj85ErvEb5ILktOSR +us/Xel/vTy8f5spMelcGVLBy1dZFMEejeM3Ure2S5/27OH961CzyKKYy3h4/z5eep/+fXj/ nsvgpTOVke6E7JZwB9dkQtW52jCCB6KPh/fvghiDKjKZItY0L1/HsvmTogCR7TO3n/Q4XfHh rjLy6KipqO68bI68ZpnPTb6qPk7dTVPI39xL5BXipbbvWOSR6razjd5f5o/n8k8Q7WeSR6bj 7zci/k5OPraZRMV0vDgjItMQrGDSIs31aIPdgVqgCrXTyfFCbKrYzJpP49LzjZjSR9zwbN/Q pvm42dn+IfvkjO+0EZMjwmiW/9VVZRn08/Nj/PpPV/pD1/ajnRIzJSXIh9Qbmm4oW/iSWtt+ jKNiUrQSL7OedcMcv4gsirmMbgiX+m7+aC6Dlc4KJr0OqUXhDq7JWNMFcX46LWmxqnnLtMfo HW0/HMv2+iRSreb2xxpTdCUrLyKPQrGy7kx9p/XhPXfwVfVx6m6KQn64TqIrwUtthVnaUt12 tlE//UuafoJoP5M8Mh0/OSL4BFLGYHALRuSRbSb5NBkvzojINQRzTdJrzfWoUtZMPslnk+Ml qF6xmTWfKqXnT2spfcQNzx3m6UEuOxX3yXNMZ3wnDVEyIkq+uiBHObudR03DyRbtViNi/Xoh q9hp7ZsblCqP0hWxOBNCHhHBnj50wt7QwBXnVQEAACAASURBVKLYQzWktbQwUbA8XuLr5eEh fKJoa/WP8AaVwqv6emlKWA8m0WkbohdBReEJsyp5KeVp2sUlO4+EmeJe5EvZ6SPf7w8PD8IU cUseXl6OXkJUIrxJ/Pn18vDy8sDcWGtYjj5YyWFwBLdZrK0SySGPmsYce6QzW48If/LxzZQY L86ISBlCGkV4pnA9RVsn2XmkjBf6rHDPxHy6xogJfSS+QVzh07xsZpF/WH0yNxBmGFEfEYlm 2V9dVZZBRNydR3Khry1LjV/mh46sQad1ae4andc0HPkcclmsfmkDRDvHvvWyYXgUe6hm6OYV NC1MKkAcLzH2bdu2JBCWa/D1vxsb5MAKVXOJT9sQvQgqCk9YVUWXEp6mlrNg55Hip7Et8qTw 9JGha9tWmCJuSdeFzhKVCBXwP8e+7bqOubERa6f1QUsOg4O4zVJtlUgOeZQz+ej+oUwg2T1S BhN92DVTYrw4IyJpCFGw9Ezueoq2TrLzSBsvxKbimyIxn66a1nx9JL5BCkqOyvb9I88xzb1u OYbQR0SyWf5XF+Tn5xzJI0kl5EasK1JolBUyXfxrjSCPJNbXPnlEgo3w3zjQp0/bVEH0wI7k 0WbZDPKX8FSDNyKPrIIWpa0pgfZi/ZTE3BrrIp7/fn/Q41SlHhF2K3ustD0PypYFx22THM7+ kuvUqiU2HxGJycc3U0pxLnnkGkLr/Pf7i8FgaA+cKG0tqmZ+9usl3onnz6drpjVXH4lvkIQo s4lrJ1ZbXp82J49SzbK/uqosg4j4Ib3cd6NHagZ5tJjBkA+yNbfSYPJIan3tkkck2CD/jQN9 8nRnUwVOVQvFJo+2ymbgbUxv2NiIPDIvLkpbUwLtpfopspkSdMnnh07nMbR6eNitUJHa9gSv FPLswW3THM7+kunUuiVM8mhhD5SuU6smzJRQnE8eeYZQOz90jIdgVUcPnChtLb710Iexb6Od eP58umpac/Xhf4MUlsweTvhHpmNuTh5lNCttG8jZkUc54b+51BUJHCsalIxsfYrHKz2bPDKO +M3aV2D3rEjs0IPn6ZVEXFE+BN/vkiprOXnkVUxvKiePIrKxhMXMapb5qOa5otNqeRYzEnML 7jOKPny3PWvyyBqo6Yf/XjoiEpNPwkyp8bKYPFKTlpq8DZXWBwXiOURqvHy/P7y8SOJoalBi Pv17xbTm6SPxDZISbyimhvF0b7JPW5NHyWbZjlllGUSk4MyjIvIoSh5b06BUZOtTPF7p2eQR z7NSOpYkS3Yjjxar+lCm0aGcBi8njyJ9bkceSbKx6Hd0Rx/pRzXPZZ8ZLbaYEYVb8J5RSvfd 9qzJo5zRY/oHTx7L7Y2hZ88MKYrHKz2bPFKTljI3VNo9yxX32dR4Gbq26yRx9JMxn8p7iprv 6SPxDVJYMv0sNYynv5KOuTV5lGxWGc9/s3Jd5JGoJnP5f8bkkd/NmuQRb0c2VRdbhXViP/Io UTF9Zgl5RBijom1Huc0ynz5L8ihrv9e1kUf80dwRcb7kkV9yJfIoY7x8vz80POXyeGfZztSi 3LIzJo/4c2qfQB4dZT/ySNyUG8OdL3nkl1yTPBLtyA6Xo3Qx1sb9yKO4jVvuPPohjFHZtiNf H+mnz5I8cpzheskjcVOmD5wxeeR3oBJ5lDFehq5peMrl8c4iLyvKLTtj8ohfUR0T5NF5yvWS RwVZCGvT1tzWyKf1mFkjj5L9PBfyKD8uUxok09ZS9RWQR6RVqYppCxeRR7PLlG07ym6W+XhG 2ppeXjptTV7PTFvzneE2yKMCpmJt2prbGmdEJAyRKrkOeZQzXuZ74h4U5zUXPODqI/ENkm6F vNWlD/3RZJ1Sduq0tdsmjwqChdVpa2418mk1ZlbjxVTJ50IeFag6VqVMW0vVV0Ae+UH4xuTR 7DJl245S+kg+npO2Zu2V8hJLFAosN23NdYbbII8KMqDWpq251eSNCNUQqQ7UIY9yxgt5W0HU ojI3K3nA1Ue9tDWttLjeGmlrII/SUoE84itVfjLFCvIoCqSzuaOoRPGeorhC/nf0a/g3O2dG nIBNSk6RR0rcwD5Ia8tRdZboOtRalRlkJRSt/DQuW82axDVNXeCbv+guXbFWfKr90aPNw0PZ sSm5zTJr5Admq6G0UZ68wv/2T+k12k8+tdw2kzz60t48uJHsQB6tGBEpH/DNlBgvzojIOkBc TqglaWvOQE2LNXFljBc+qzrTp/xglRET+vC/QXyRQ5HXlRrGWX3yNlSmjKiPiKTbnit5xFaq IzuZYgV5FEW7JSt/fu/I31MUFyX+jn7OZefM0IaJkhPkkd6pgrQ1vq63Tr/xJO+A6HxVJxSt /Nw/yqNLnD6J835pmgbviLhIZTF5NFXflp12lNSHL/IsXX0fhr2Jw6aZRn6irRrCmqU7bptJ Hs3pQyu5T122J48i5ZScnpNwTddMqfFij4i0IbROFaStrZp8rGdzxgs/FNyePuUHq75BEvpI fIOkSvYGuesfmY5pNyfDiOaB2b7bgjxKSw3y6BgaNjK8P8i0rvwWrz3+Vo/hYHESl6Jfmenj hw0kjeAllErVHmknDZMHDxHPA3tJMgmDvtgb50TJgoayteWqOiX66SBGk1R92CIULbv7d1rX sgT90sv84mwSGNsV+z1OuB7TWynfkdaH++zLl6UPrdGmY7KLwRnJDbaFVH1obst9lgwxbijy +MbkkbSyNrynz8Kd8m9HY5YukpKYfNzJJTFe1BER5h7fEMLOynDQtaV3q0Ahf9sTlzteuObU ZhnzaXSloM1Z+kjNap4mxFDMHMbJPmVNa5YREyPCaZb/1VVlGcRk7JV3+IajGUL6D7tFP4ZD 8DLKlTyhpU8bSBrBS3hF89qNSLgh7yduW/r+ZBoGHa5T7snv7vRRaGDEYxUrJNYl69U6VYsW ie7KOwrfec2daKDvz5JOZ16Me5zQB9dbKd+R1of3bOhJpA9lvNiO2cT27ei7tKMDwRP60NxW +CwZYswW9PFtySPZbm1465NPoseRqot3uNAnJSfiTi5R7Rkjgkw+viF4yflTtfL4ymFhXuDj hU3barOM+TS+UtDmLH2kZjWndGeQxw13ptLkVa10o+L0HGA1K/erC1KJPIJArlDKUta2qfCk 9UEgkFPLmvy/y5MqyyAI5OqlLGVtkwrxez0EctWCQX6zAvIIAtlGik7K3kRAHkEg1y4gjyAQ yDpRjgnaWxBXQiBXLhjkNysgjyCQVSKTP04U6bFqbym6hEBuRljq100QxVWWQRDIlYpM/jgR gcSqRb4HBHJ9gkF+0wLyCAKBQCAQSH2psgyCQCAQCAQCgeQIyCMIBAKBQCD1pcoyCAKBQCAQ CASSIyCPIBAIBAKB1JcqyyAIBAKBQCAQSI6APIJAIBAIBFJfqiyDIBAIBAKBQCA5AvIIAoFA IBBIfamyDIJAIBAIBAKB5AjIo2uX7/eHq3sZ19fL8lcPXaM+rlBgJgjkBqXKMghSSca+ba7t Vc9r+nSN+rhGGTq8XgoCgdyw3AR5dHir+Vm+6Ti8i3mnUPnCovAsfeSQR5bRz1Yf7K3cq1s4 lXaWHc2SszXTtpJhpt1niK2lluud6TR/ps06V6myDKoq0wuPz5IyGPt23zcxXxhZkqWPrD4Z Rj9bfZCeb+AMh9Iul365DfIoY2bafYbYWqq53plO82faLMj5y3WRR9/vD9Ya3bl0DvL9/rAo 2vp6uZCIslCW6oPL10tJzFbTRb7fHxaGl44HXKtzXJnkmWmbEbGleONlpestHopnOs2fabPO Uaosg04iY9+aIcvQnfXyfegWRVtejy9aFuqDy9i3JUav6SJDtzC8dDzgap3juiTT7TYZEZuK 0/CVrrf88TOd5s+0WZDzFpBH5yEgj7jcIHm0sG6QR5cuII+Kit7nwX3lTJt1jlJlGXQSAXl0 NXJ75NHCukEeXbqAPNrw8TOd5s+0WZDzlhrkEc3PIUvqkO0QbshfcbOkH+Xxaflup4AckgsW 5IfMTz68f4dm0IbnFG2EhrxXTBusVLV0s7PSALSo+dZl+ohKim3N222VbOiDPKy6Brl+cKTI wdRaXe85Xjw+Fn9Sqhf9Upm+kx7w9fLw/u2obDcbO26bHi/JNK3k/MHu4rVzB8mkOLSZSR+M 5hzgecDUigzXVhurG3Fu8vvLXOJ83wb6SM+2Cdfz/CNZtCuJad6sOMOpV35HvHx5rs0apqba ahWHjLhwx5kxjMVSZRlEhObnkCV12N0//a9pSlIfwjNE6OND1/ajkwLCCiiKXOYnuyH0jYUK OUXroSFPZeLxR0aP9QdjA9Ci5hKW6UOWpNiat9sq2QiVzT7F9XeDII+cZ7mexV3H546PxZ+U 6sW4VKbvlAdMIbjT7UU2zvAez22T4yWZpmXMHyJbSh2JwkEyOYpQMqmalcsqo/1TK46utP2Y 7rZFHqlGnJvcT/+SWXUDfSTGy+EGx/VWTWu++NO8XXHGxLXuO8K3MWuYPz3FrV76nQk5dzk1 eSSOMpEnm3y9PDw8MAKj6Adbf+dRw4Mr0Qwe+pSeUfH9/vDw8nJsemhIZtE5+wq0Y2Aywj29 6OhTqpF1+pD7fTwzWiUn9KFuKeL1fB3D5tyiHe/h7hJX5oroo9rlnXYeUQ2IFp/MxurpReZ4 YXeobpuYP9gzvFzFQbJDbT4zqR22++R7wNfLw8sLKU3XpaoP14hfL7P1Q1fZA2v08bfvs67r xX1QqPzFO4/saT5VsevUq8bL9/vDywtty5f5h+rjTsXf7w8PD+EOt8eXIFWWQbOIo0yiP9s2 HEkz9m3ZUtjfeURX1qJokTS04FycoWu6LnQm/NKcWXTOvgLlGJiMcM/YfiMrZBpZpY+oQicl yyzZ14feJ1bPGMLmnGen561mxj0o8E3RR73LO+08EqGvCDyX29j1nvje+Jo5Xswq1MLEn5Ey eLmKgxRQZm1L+6i6RNt1Ry2StvgeMHRt15GiDV2q+vCMOPbtwfqkq+yBFfo4NNzZeeS4XtSH BdOaU5g5zScq9ieulePFsbFsJW+Xf3X1dybkjOXE5JES6bI4QS59C4MInzySZAkJMbSw7KV4 +5FSd27ReUkpcf8Wk0cyJqGB01p9RMyczwMZrSskj3T+YSPySIvgMmM0rdS4z3uRRzIYrmJj wzR+7K0WmZ4/EuTR4sBaMbjsltWnlAcoNITu38qGOc+I4Sp5ljZmZSZcgjwyXS+joDXkkTnN pyt2nHrdeFEIsmPpal+/XgIb5FccTXIXnqxaZRk0iRYU0BBEBhmFQUSCPJLhLgkxtLCsePuR EktkF52XlBKFa8vJI6FretdafcTMnM8DGVuMCskjnX/YhjzSIrjcyFEpVenzTuSRDIY3s7Ht PerN6qYnv8eaB6TmjzR5tDSw1oJy0a2xb3XyJeEBCnmiNVT5zDciuUqeFdPtGqLBHy+m62UU tIo8sqb5dMXOxLVyvHg21lQz9t3xxwfv6s/q70zIGctpySN1XeuFtJuSRzI9Qs3QIlJYcyLN yi/aiuOiJI7NyCMWdUS/sa/TBw3Coqg7Kn4b8kjThLVBqZw88ndmOaIXGjV2J/LIHE072zjl thm8RS5ZUjZ/0IYVxdi6e0mm23Bl3wMyitZLTxgxSR79vUIfZsf09jvVav6xhjyypvmcik2n XjletP7Mn6l5eg3Zv+ZXnOrxpUmVZdDPz4+1riXLY7lS3pQ8MotWMyUK34+TTLNKFG08H+WH bEcesahD/sa+Th80CIuj7qj4TcgjTRNq1xeRR1xDJT/vq4XGjT3JmUdspK20sek9h5oT5aZ5 i1yyxKXElFHv+50lhnu5G1eMNshntet5O7F8I6bJoxX6MDsWdS9Z7bJpLbNNsY28iu2Ja+V4 cWyspgAereFfzegx5IIF5NHqH+C9MrKLNvZZxAenbEceEW6FkyEb6CMU4adk/L3dzqO9ySOi pJLUkPMlj3azcYbbViOPeGkFZNmZkkd5e/ps8ojfX0yYLyKPMvxjH/Ior2LVqXfYpEXII6ev yYpBHm0l50serV5u2+RRXtHGPovoQJANySNyhUf/G+jjWEQq6WKznUd7k0ekJwXbjs6ZPFpp Y8t7cty2GnkkSsu347mSR3l7+kzySNxfSpgvIo+2mdYy20RLynFMa+LaYZNWII8crSf29ClF gzy6Hjm7tLUK5NG2kXTe5zn35SQ3rSKP5gBJSRbcQB/zOa60xYqBLiNtba71YToGuMApU0lL mXU7jVpCHu1o46zOLSOPiuePxOv2Ct7Gl5e2Zs0BqbQ1+Vxm2pqvxVLyqEgfiaIc18vxj13I o1zH1Jx65XhR5gxGU61gj0AebSbptLUa5NGmbEnm5xn35SQ3rSKP5gAp2kizjT7afox4ljiI uoy0NVJc6akiVdPWbCplE/ZI8568zi0ij4rT1hKhdzoyp7dmpK1ZW/xSaWsmhbHgM62OLPKo SB+JohzX22hay2wTKSnbMbWJa+V48Wy8kj0CeXS9UuHAbI+nWEke8XX410vDMo2cNbYWK2yR tpZddDo0/D6+Wce851s9dMWLPr7fHx7e39W4eJ0+JlO8R09p7z/bhjzK05dbtO09pMyHh9Io UjZWa/xy8sjxgJLjo7UPkqLaOMsMC8mj1PxBuxDVrCXXlew8epDnGHtjUTzseUDGWdxm6Z4R U+TRKn1E9/Pxkr3pzfCP5FA0JP83AnN+0CeudePlm59qLXWvWcLxB/YByKMNRa7B+d9rF8Ks NH6sil+0FitskbaWXXQ6NByOb9Yx71EPknGjj6Gb3sik7GlYp4+p2l7JZyIfjPwFWbJhZeRR nr7ydmLNbRNNGPu2aduiAFupUG3A8nd52x6Q2Iez3sa692SZYRl5lJo/WBdkzRH/U8KVjPLA bJXxyHGs6G9+4rGZFGnqwzJiijxapY/ofj5e8je9LZ3WDMn/jcCdH6KJ62fdePFtrFnCOUBd JtSBPLpWOTV59Lc844GHCJNMi9/vRW8fTrxi+Zh3FFVPbtKDCkPEc9rDdtH6eReaTsgLmaOw 7HiLTB7yiqZPa51dqg/egNh0sr3svUx+ozVV251+mV/ZPd2QpQ/Ne6IbymMz3vAoTkxaKb90 ss2Cf6SOpr1s7LltYrykzWTNH1GXZM1R0WXzSnDWqOb0HGB5QPBQUrTdW+0O1Yjc/IQoIRpZ pY+4dSwtjRYYu17GtJYeipFkTPM5FVtO/ffC8RKUTx5Xtpl6ljAqzvpiuzCpsgwKwk9xYFsh 2GfhvrJfw0PZNGpIF81PtSjJS2qkKKGQflU/0UJEZOTTgb1LyOmx2qzo0fk2I9tmmT543+I4 RrR3pO9lSugj2SehL0pOZelD6ltVygKWh1ceRYJmh8tLJ9ss+EfhJtNJyjtmeI/rtv54SY0I e/6IuiRrjosuCLKnkNzwD63RUVqiejEwGOQGsY8roQ/ViML8hCgJGlmlj7h1lLPkBUaut2Ja 8yQ9zedUbE5cPwvHS9LGsmVWk+Kr23xnQs5VKpBHEMilSvnmHMh1yIXv54BALkOqLIMgkMuX 0pQ1yLUI9nNAIJDTCsgjCCRXSk7KhlyVgDyCQE4gVZZBEMjFS3FeF+RaBOQRBAI5rYA8gkAS IrOSQCPclrCUImw8g0D2kyrLIAjkUkXm94BAui1h9ofxIRDISQTkEQQCgUAgkPpSZRkEgUAg EAgEAskRkEcQCAQCgUDqS5VlEAQCgUAgEAgkR0AeQSAQCAQCqS9VlkEQCAQCgUAgkByR5NFf P3/th//7fz/AJtjVTAAAAABweqRWLH/uhL3KBQAAAADgDLBv2bckII8uEtWX+AAAAACwLVIr lr1WftUXtQAAAAAA7Id9y74lAXl0kai+xAcAAACAbZFasey18qu+qAWAq8Svvm3a/tfpqx66 pulea3f/OlDNiMDJMPZ3Tfs81m7Gzti37FsSkEfnhP90TdM0/+j/W5M8+nxrm6Zpnob6gYTV tqZpmu6jdmOAv/4a3+7JW4LX+syhtKeP07X8JHUBwIXh46lpmub+bTx11akVy14rv+qL2rPH +Nw2TdM8DtVbcnG4adWBPLoCKEYc+7um8TX8qw/r9Z0MQarYsZZVbeuGBVcr4GrIo6Frmsaa c/as+bYE5NEmGH7PYHyy8L/+t/3Jo8+ehvxB7vvP4w1nSR7NGJ5AHp0BPp4WhpcfT+3bp37p 8609GaHz8XQF5NH4dn+BY+Gjq0BMXCx2HBSOIarYKLVi2WvlV3/Juxt+9e1WtMVrd6MMyHpV b2gF4M+fn9fuKgLdy8b43ObwNcPjTrTO0J37fqih8+gh/yqwHMMjyKOdBeTRjZJHMzdE4ufh CeQRUAKHA1r8IMijQoA8un6APDrKXiu/2ovdHQHy6BxUDfJoW4A8OgPUJ4/u+rG2EhItBHlU AyCPdpfTk0fjP/8Rtrr89q/xSIj8+4/5kyl7q2mapvt3fJX8Od3w33+1TdM0f/RTyaSE9p// C4TL4bZJBEEz1/j7f37+73/9b7Jtw+90f84fA+FxWHdmYfUeC1QuicL/GM6KPPo42iEK9cOl ZkEG2ZQTcXg2IqrIVSu2t8ijgTyazwtMT7Vvn7xhvD3HOGq+J9wwJ9O1b59BM08fPzQ3iiTc xbwJbXbcL3L1aZBhZMIQJK3svv8sjAYdQ9BLRW5A9BCEtmrqYCj/6JNxj8rTaoQVIvLINwSr +uljHi+TCY7tpA4wX3p7OpjvuOmP1ct2AhL3OHzefZCqaZc1KxTQYfxx2V/q58zDVxpC3fYo rewbItvBaLHBTKHwoCvHiLMV3qaSSQms15YRqa7u+09tAvEMwQb4sd2DUvjmhvjo7t9GN1N4 h4krtWLZa+V3+GdgzQoBT9gJPzzOlwMXIDI4Dn82d/14vPQ8JSmQEnjYE4ptZH7TIelp+o39 tZNt44kbPKIeNO/h4cprZ17ihbfP4zbkUcjXmBUlm017HV+l6j3qrSQGo10m3ZmKOnTTUoiJ lKon8iiULGMb2t+mOCQOmoxKnhv2OAjVxS0PfZ9vYG7JtOGPCKFnLZB7jRVGyudXGfXAHV7R WDpbihorVBqyC0MJJRtb5qfa55GrXW25UjLRdjcc2UZtvMQeYoyXDDNxbXevY3+nGkJp8IE8 8g1tk0crfF4bbqxfa0ZE5kBTnxI2EvSQd5VOZWzO16pWmFM+V0v2xLvKZ4DYQP6I4NYPs2iO Pr1vn6Squf88DrRTw2Pb/yIlHH0j38XKcVtyYvJo/Oc/mt//E0iQf//BuZj/dL/9oz0yO//9 VyuvErLp//7f+M9/zOzS//rfDnTPxOZ0/54oIbsoykwdG/P7H+Hzf/8REz1zUZLfsXce/a// jVU0/N5QDQy/EzrpQG+dB3nU8FBKhGH0z8/+XiFETLBcp6miEAuNb/c0/hF/0rBEjVVkcJsf Sn08tff3omGkCkm7xNs9xrf79umpnTUTbvh8a+/vW9JH3k6hPalMdvMUyLGI1zPE+HYvw+Ns hWQZYqedRw2n6kQzaAj68VRw0NLnm7BCw5SZMISoeny7p5E2GTtzXWFYzR7+8dQcaAXqXcLT /hqeGlFRe39PBqlCTGyx80gfxcNT0z0FJR+7ucoQf/3l7mpJGCLfxJPPc93et6G0WPOmEYO5 yRgktkgYcb7nvns6jiNrd6fWX3vn0Z6GmPiduTSp250mrtSKZa+V32ENLRfrdBE8PLZt+GTs 71hEFP0IH34VH5/bw5p7WoI/DlOocCyc/v9wv1wrj/1d2z0eP+cBHsHwGAWHzp6X1y6KuokG fvVtHNtss31m7O/aNihQpp+IXuiduuu6ozmy9/UI3UpVv3btXfhkfG7L+uvvPKIhENe8rOi1 K+WtBNEpY/XXrnnswudh2w7T/PDYtHetGfhFB9/4I4LaWiWP+OByAk7tNJaMnUc6Z6E4Of/z rg1uLwZInoO1j92xzDAt8NEUm4lpgEwURx22VL28Yf54SZiJFTXF27Hv6UYcn9vukT6u55Gp hljn83N1unXWjIgSyDZz3R6YkeMN/tVjU7sumO/YQWk1OSUqc7U/k+vW1DkpZ0S8Suu36mC3 tOd8+yRULf0nfMmGPrKfcw7/L7RwEW5LTkseSfZnYky6wNEQukfSQ0nyaOaG/v3HkZ05cjoa ufO//nfemH//kUXcyFa55JHGQI3//ONws3JVamAX8ohAz9z57O95HEWifTVYHZ6yIxYvV0iJ ZIzqIvJIja8+nnLjauX4HhrdZZFHetgmg66p/bN6FRqFRZVOgl7SEOPb/UJyJ9MQO5FHvGoS 0muB7udbl9UGJVZngbdviFTekEsezZdI14IyNVWMb0/H0iQ7kOGKC6H1cXhSCcc1hrBLyDGE C2mF6dmnUJGk3niXffJoVvJH1wTm/VBayohzL/L2hcWGMN1vT0PQnkol7DdxpVYse638jBSM 4ZGtudnamjMFPnlEWJKwCveIj9eOlzb2d5nETRRQmYyGykAN3eFm5WoxmWJCiWBZ5BzVov6Q Xp4Lo0SbzHCSLDBJOh0+eST3mh17pMXAv/ouL5rV/DYq8LXzdo6wVnm7BsT9/oggOkzEk2m/ ikteSh4p+Sy0cEnx2PkvTl80EkQrZ+wfGQFk+7NGzLkTCN+F4ZopazuhSR5Jci3yc6Nrq3ze K2TdiCgF1bNSL3En/2pop7ptR/P28bnjpKfNcvpXid6MDU3WiIinx/xTqPxvn4Sqk78WSJc7 3r/W4B5uS05KHrHEMSJhJ45DD60hj1jiGBGWgEYfjDkg8WQmeaQmtR0fj0moE515RGCSRzKV 7BgqDFquTJx44kCk/6i10FhIjWmtLBshueyGVrVDW+g7j9S6tPYfH9fCXVE4yy6RuxtShqD3 FO0OyzLESc48YuSL2uOsRC0tSNa33WmGSPV0MXnEX1enGDrytA3JoyglKmegrTWEbY4cQ3iw 3gNAGQ3TTP5VnzxKGnFunjVJpgxhhDwnCQAAIABJREFUkUd7GsL3tN0mrtSKZa+Vn8zQOYrY Ca+tR+eV90LySMnfaRolV8talPPt/U20w99cZ6uZVsfHtcBsszOPosiBREf6QSoifMoLhxKF xPqRN2xKHvFLwZ3UPKwmkyvUWyh9VTec9qzQQOScnDzyRgSpxYsnDeYocs5tyCOVbiB6cMyU Bz0CjwfprE49p0kSo5ql5qYmx0vSTCL9x3CzLPJRbapiiFU+n21Nx45LpzKmq6bxviCmFs4m 9q/an6iVak5Ch6o6dTtXHdf1J64ky+/YTu2S2I9pqDo5/E2fLzZ4AW5LTk0exTuPxL6bvcij DEbGIo9kbl3BzqPxn//Qc9+Mci6EPNrwgF6WD7WSPFpzpuz5kkfCLs1iQ2ipNAXaOAvyaPkJ vudLHvkl70YeyZSu3IG21hC2OXIM4cFhZ9Jm8q8myaOMgWA1L8MQDnm0myFWk0ei75kTV2rF stfKL+NU1x3Jo6W//GsZPfk7j1KHuYI8Ohl5tPzc3z3JIy1VZGPySM8Li/KMNtt5VJE8KipH jOt9ySPRfuMon63Jow3Ouj41eRQrJzpnJ2rhRuRRWVadnwNoXD05eeRNrb6qQR7Vl9OmrSWZ kTLyaPi9yUxb80kcnzyKiaGCtDWfLzvntDWTPNr6HVU0plqRthYlWRTroSRtLW6ARx6tSFtT SqPnAZUZIl9FVdPWLPIogx2wsTptzY3SZSyt0lJq2lqq5L3Io7i/+eTRKkPovXB9IzdtLUni lJFHxIiJtLUsEsdQWo4hzLS1PQ3he9peE1dqxbLXyu/PdDhRRh6R6ChBHmW9c8cIPpXlez55 lMyUyUhbC6f5FqnbI49y09aWBJ/ptLUK5FExs2C33+qm4dt+2locB25MHilpO6oVTpu2tgt5 VB7/Mw9fmbZWQB4Z9rLT1pTDyHLS1lb5/Ix1aWvF5JHKi22etqaNiPLpzv8txDqFqow8WpW2 VvztI9PWXIWAPNpdTv22NXlwtThC2yeP6OHTh0y0TPIoPrg6bolFHnHiSdSr3fPff7XkBnlG OG8J4b/+3/zSN4WrapqG7X7azigLyCPl1F5xAKoDebKsiLtk+GdEZXpMGxFA8enCjh74gdlK CgY94biJ3i7kkUf8wGyuTBn+sXIi4knU4hoiMkoJ2ZRliMXkESuNnwXjkUe6QnI7FXla04gD s21DKPu2PjqSCUibIUpOkEdKF9gYSZJH3KysVSu0EXqtM1NrDBFpm58XljBEqthoeslOW3OM mCCPUkZU+1ViCEb7soOodjSET1PuNHGlVix7rfzm5Wz0trLsGIzuoeCvrEqRR8r+i6glVqzF gw1er3rP8Nh4B9zSlvAFenjzDil8+rD8rFmXPIrjijjSW7pzQQZIopyV5JGjap+ViMLIkuOl ZMCpRGVmqMyeHZ9bemA215V4pWDUBa2P84MG7ymTtvStWKrjxdxK3EHzwGx5rJV3lspW5JFC AFENaA7Alc8PzOZsiD9eXDNprSrZedTeUUctODB7nc8rSmCfLx8RHng54U12pi8xYt2/qrfc Vg4znPbNZZ/WV7S/yR8RTI2Tl+aPF+/bJ6Xq+C0K7LgokEe7y6nJo/87vlNsliOxEs4VkgcV Re8jO9A3E6vS/v4H/fBQzm//GqdXmzWSb5qFcDHRkUaCwZnKkfWyTUO0cIv9IY00H1TIqX3I I3lOB4tG5pZ+zLHKJOxXevZw9q/f8bkk8a4c66p+pgkLQvjJR8Wn/Dgvp+dqmbRnn3hCmj0F qPR0EsnC8BNPaL3xmSbqkca6IaKDVAozXGxDqF0u2wFBS2AROKsudCFErUInRXuvhH2nP4Na bEMovRb9Jc55NPf9fXg76tvn3PKn4S/mP7E+BU0ZGhPaz8yx8MX2Qhv8PXfKwTTCf9YYQjye PyLSELMEoUKoLajO5csfhUKeOmaFqZz7/nNWoOCbFENoE5d8RZppCP2evQ0Rqpv8PHSBTKp7 TFypFcteKz+6JA1CjjQ+fvQ8/tDjGMQ7j8KHh/Vuy94WTBbBE9FDEqZYxVHQzsR6/3eoV1Iz +rO8a6I7yoMROTU8RnUlEb1JXXuJuP2eZu20lKKTs63Xz3Pz0YpK6ANN1eTwjqm6oPPQctGv 0re8kUf9Q4tkd+izj0PM4lElE64wOSL0M02O/dWOceFBKW2VeFddVEJivLg60Zpkm8mG1iP3 7eP0auzVkinoBu/189Z4SZopVpd8JVws3esPJRNJx81Xy4d2C+rW7HKBwydLLhsRHqQJ+Fu9 hMa6QbIezlVF1YLKEQ4mX75m96jwatM0B1vkjAjaqu61lGx1vn2SqhYKyfuyzm9aOW5LKpBH wHrsaqabxOJNNEmkXtQFAAAA/Pz1V33yCCiB8W4g4HKx7J3lwL4o3QEHAHVQulPv1Ni37FsS kEcXiepL/KsDyCMAAIDKSK1Y9lr5VV/UXiL8Y1mBy8MmJ9EAmwPkEXAJ2OYc9D2xb9m3JCCP LhLVl/hXBZZAsSnRwzJZ1r4XCQAA4LqRWrHstfKrvqgFgDpw3hAPnAFYBhaoPeDMwPzz7CnO fcu+JQF5dJGovsQHAAAAgG2RWrHstfKrvqgFAAAAAGA/7Fv2LQnIo4tE9SU+AAAAAGyL1Ipl r5Vf9UUtAAAAAAD7Yd+yb0lAHl0kqi/xAQAAAGBbpFYse638qi9qAQAAAADYD/uWfUtyUvII AAAAAABAhb9eqb70BAAAAHzUrh8ATo/bEpBHAAAAAADUh79eqb48BAAAAHzUrh8ATo/bEpBH gI3x7R7vCLtyfL61zX3/WbsZwJnis79v2rfPPQofnjZ+uSFw+fDXK6dZA+73Bvpffbv8fUlD h5dhXTzG/q5pn8c9Ch8em+Zx2KXZ+40I4CpRu34AOD1uS66EPPromqbxY+CP4/vYESrnIos8 +nxrm6ZpnoadGzM8NU2zVxx7UpU25xQzl5NH12GIGvjs78M7Tev6QLYRF5FH02SbmjrOiDw6 1SS2Lc5uMtlA+f565TRrwA1C5aFT36u9P3k0PDZNsxU9QV7ivhMrUYrDa6Fd67x2Z/xe8xR5 FBpf3H6QR0ePPQeOdXxuvYEzGfquH2u3swTGtBbjPFpxepDX1p+DDwKHUTjbZN857LbkSsij v37++mt4yomBP/t7kEeb46PbLu4a3+67D+Pqx9M1cBYfTxcR712mIT66vfbKffb3q5x8eKrB uDmW2teI+xliJ6y173JDJPH51lozhnPpknD8BvHXK7WXoiUY+7s68c343G68t+W1Oxfy6KDY nCCgmv6X41ff7hLfZGrs1Bif2z0i7J2KXQJ/4Pzq2wsjj35yh9X6ShpNQs3D41kP7uER5NEZ 4LU7KT17WwLyCNgAII9KAPJoR5wzeVRj5gF5lAuQRxUB8mg7gDyqq//l+NW3u+gZ5FElgDxa XMnssESFlDACeQSk8drtlCKs47bklORRyGX4CFtz2cJ3Tuu4fxvnxAqRSnDYqN8oORdTbEZu UCMBizxiGSXHkufkjrepwd3HsXxe+GHj/eHZTaLEkJLAC48rbd8+f44q5YHEcMzVa5pABHyQ T58+eN8PLQ8P6hEgeeRgUKqQD7r12iQgLA8RQnv08dS+fTompv0tI2jmqrsPoVi1baJe1l+l XmFBQR6Rq1FOJTUrGx2Z3aFdOOrtYBEnkXO1IVKgGrvvP0QATK+GkrURQVvOk8LUrtlGPHrO pBzrTyr5jq09zjUmh2T87NMQLJg3vTC/OuqDOE/CiMEKYqZNGWJ+fK4rqoJYSgyWkMEU7ok4 F96wvBQ5zRCivwfyyJv6dDMdmjr7QzROk4bIHSlayyfyKHcszw/OSuuf5r7Mjcz2aj7caHey jGh9g/jrlZ1Xf2SPuwi2Q6bElBfWNEpCSrjUdIOIssxcKvoje9v/4olLUxXJXAjySPcayCOR ODP3jjZgYO7lpNgUkRohJYeUz0qYP38cggZ4IE3zDXgEcIgsg7b1CNyKctmuhmPJc7pf3xE1 ap6wGEEVSkBDTGz02oGXXUh8Mkh+XGuPiPiGtv81dJlsyKs2rYnGU52UkCwH8sjOXmSpLGX0 TWq8kDa3z2M0cPhwYORRckSwqmML+oZwr+ojQnOhaFqzkK9Ry6NzyCPH8RPaynfP7jWiXuMZ OoJFHrHhmD2nhlxkPtOz9hxNOt8Tbpi9sn0euaPlTNWy2XG/mINIAnyV2+abSbZZm2B2p/Nu S0698+iju7+nZ6yMb/dK/HD/1B0P2iC/rIozMqI/77snUtrnW6vEtCp59Nnfs0UzK/njqTks qT+65rBKZs3mFQ1PzWbHKn2+tff3ovA4kGufno4qJbtFxGEl8Z9RXB3HM59vrRLkcHUdgpNj Iz+6KKQv+snd3/DSNME0wnmEchac9j08Nd3T07EvgQQUynHPCZL1Ku7R2F760cXx28dT8/TU EdInR5+6GpV9CuZevMWGSEF4yEcnFUKuxn/SEaE4rb3hJWVE3gvRyL/223kkHEbz24+ueerC pFSyqcfdeZRjxPHtXimhyBD6NGJtwfvs7+/bMMPE3hL+HJ6a9l5rXg6kA3z2908dnUN4p3wz RYMlstF+O48awt0IQ3g+H8Zd+M7SvzSz3IyTcb4RnW8Qf72y69KPLXiVUHl4bNtwYM3Y37HV 6PBI4q7Daj2OsozQSwaZsvBjFcr6l23NP4RTrCV8We38ZD8+t3osvWTn0dDdtfSAp/G5VRb4 j104yIn8TCyO7+F/jv1d11Ft68kJqqoVq4WSX7s5whi6ORpTmr0O3r6wlTuPTDOt33mkjwiu nKC0fFWY8Zw4Zank0KXxue0eqUsMneOHK45zkuOFZx0eQmqmH96MWF3miGDPxidn+YZwr7oj Indai7DG137yyCNKB4hOJLSVgDKhBqsKm1tTpjpVM106063Rqvaute2msIWiAeNz2z52xymZ 3OBP1UJ7UpmKgxguX+q2PrIMgZ1HO8rpyaMo6pbL7s+3Vv39U1tA03hMOX5VCU60UFlb1o9v T0fiYL5KnqWNsUKj9dCW8iIEHd/u9X0fSqdY9BszL7rOo64pnAJpp8o4DE8FAUmCs5Bb1eaS 1fjq46lg39PkQjpZFrf/ozPpEnq/8izVvEYofPZPMuxcQkd+vnWKV8e6XUoeWYZIK9nri3JV jDW5Yyjaq2XulUsbcTaNMk3tRh4pDVaYiMUnlPvkUYYRTfIozxDmBKU04NgMPheRLsQ+ueYk KV6aQnOTvifMVJM84hURQ/g+z7aGke+4hU7OHaDMiMSd/PXKiZaBFnnEQxAa6iurVLFwPi6f 1dCL32zks2gRifJbrVzOZ5NHJsuwjDzSdnyw9r92eiCqcSik2UosqDEymqq1YGJ87g63havk 2a1Tya6MPFoTnNnkkdbg7EBQiSPDgNL2Nvzqu4W9oO1U2kyDY2XcxaSnMSJURQ2PjNJwlONd zR0R1BNOemC24dRyLiRDJ6mtZTUeeh+5j1FdNFWrg/u1y90OozDk1OOyyCODJnWnasUFmKc7 CXor3dZFniFAHu0oFXYeKbkAMhtLC//0UJY8q8VmcXVKqExT4dgmN7nRwyCP/uKpARsSSVrM IPSgh3ZGpMqepeGf9YOzZgtdz2G3jqrLAu6j5KgdEuqomVaFIbfOoOmZI8zQUa/JPiw1+eVg VjXTqlFympYcazJXTdhYnataRB6ZhkjAv1OlfjyKMJs8Shvx2GvDXfchj1ROQXZzxZliBWce FZJHaUM8dfdu9qhJHkn/96iNIlImmiU4eRQVfuxmykw1ySPTEL7PryWPou9NuY3LMKL/DeKv V060DDR3HrEldiJesXa+6KEXZXwkS0XuyYlI2JI8RR5FaU3bkUfJH4KNYnVOgTE7USMVPSiq 5q/eIX2WcRLIo8iaxvYc6j+lgZpJHul6yM1pMQZjN/yppwc2TXEGkTZedIefSzacVtl5pDMl mpgD2U09i/Z+2CMie1qLsMbXLBWKDpmTcY62kh6ku4ZKRuhcdzRVq5ma+YNGq5ooIW/nkV6X N1WrvzXwwlnWo9zEts5ti7ShGALk0Y4C8sjmX6IqbPKI37/ZK593JY8IV2KmHS0ij4o2+8RY Th6tPjjWJo88g0Zb3mjglCSPMmi1pV2bNnyNb09zOqdFzdwIeZTTwo+uuW91ygPkkdNCzRBN 0z1pybCkASclj6KZOdp5dH3kUdZYW0AexcmV0c4jkEcl5BHbHGEEOpuTR9HL3TfdeXSW5JEX TIA8cqyZkdsVuVNaFRXIoxVnVLvjZV/yqOi8Ft8Q9Gpyy9Jlkkcbnm7D9rGtJI/WDe5zJY8o 2K7Qbd02qQ2QR6eV80xbU+ONjLQ1uTrPTFvz885KySONgwhHzBapKy9tTY9JUmlrB/0cDis1 KIzytLX1JM5SzmKDN75ZzJfLiKkEZW7aWoK4XKfS8e2p//zo7t/GyUC6056YPErQi+m0tYXk UQ6tGQaClgxVN23tAsmjqV+O9xaTR6vS1mL9x2lr8by9MG0tnjkrkEe5E1c5eaTclk8eXW7a mhmvrE5b+zkeYuEcsrNF2hptQPzsydPW1GIz0tYyAiNN1T53kEcehdNrF3nXFZNH2bcFVeyV thafvX2w+5p38PnjZaO0NdWCxQPQNwS5mjsi6LNnTh5t/XJIf8rMTlsrHByKHkrS1uIGeOTR irQ1CepQG7stvxNpa5Wl9oHZyrLYpnLkUpjHHsPTfUsPrSg4MDveekMCiRR5FEUvcaQ3ZSct ObZGHJgdRyA2+yB7qt352d/f92/27gDzwGxxpHFDf9LXFFLSd2ZWftqLH+5Gp/aWnodix1pR F0JdCW0IHUY0YhSyxn67mI/7eDoeJzwdLaz1zt79tNgQPtSTqmkGJTNipN4EZ8Hu5wfuOEZU rsbOw9yj/CAq58Ds1NbLFeQRK+2zv2evAjgFeeRsbCwnj4Qqxrf7/AOzeUfEK9L+is54Vg7M 9sxEb1ZfAOcYIg3Wa3Y0W8IQjs+v2nnEp8opPy6XPHLnTH+9cqJlYDl5JFfr4e1s0brbDr1e u+axV4/K1qqgT/GzpRm1QSMD0SremENGz4Y7j9gprOrvwrk0Gbtz7O/almqp4MDsmFkgVFQW eTTpcHkUWIM84vq0jpryral0OQo6F7yVj5+Xyw5Bl2ovODC7vRMn8Qo/Z0Vln4meGi+ciBHv OpRdEK/IyrAgdxsxrh1DJMzkjYi8aU15L2GRc+X7CNVHYjK2tZU0cnSaEreqPPgu+8DseKKy EpRVPfADs5XcMXp8eBO9XMzdeeRM1XIelRtbo8FkHqctDbFq/sgyBMijHaVO2pr+Km71lcY8 3LVeDxwWr+T0GfPl8Wrh4gQH+Yru+7eRxhvkHTfReTfqnvzybUfHwICqJaYhmBS+Qn4uRHm9 lyKWPp+GKHjgOilmzejjx7bJV2irrwnnLc9njpSjmpQA3roqtBFxheIN3zK2FCcfcTosalaJ MknoKMmO9IhYZYh0w2iPo3PutSZFb3wPhcQn7mtmcowoiwp9lOljmpkS0E62iljORi9ZMVPp BhY6UZDUoYQR9cPLnj6yDME8XL6vXT9jTjbDNgS179NH0Y4e4c9TS9q3T/Xt8jGlbpspVumk E5klFxsiF2IOKRgRms+H0u77T8po5//OQb06fPOGL0ffiOY3iL9e2XXpp5+HMi1v5XvWw6kY 0ZvO5qfoEn7QZ1vlt+n4fTPsSIlQgXFwSfs8yqiVv7Ocv6aINmx6D/exy8Z5KLlZP9NPw6L8 n6hJQs9Gr4+Vhoid3GC/0VxVtejXdCmcvXHXjzT8mmrkDVgQkejnfyg20tvsIM9MhiGWjwhN 1eUZYc47wHm/CkL/qSj+DnC3XwWElzdepB0fB8kQ0Xrv+pHST+kRIVyIXvUNkTaTOiK0kSim NfH4tuSR9Gv29ry5PeZk7Ggry4OoOsRw4SXTq+mpWti5+JQf5+X0xLmO7i/1ozfbnapjD6L1 xjOElsFnGGLt/GEbQu3y4h2H2bgtOYczj64ey96W9VciOQ4AAODWsSYdDDg7+OuVXZd+wJbI PaHmsmC/sggAgBm1678+7LiJ5jqn6gq4LQF5tD+iA5WzAfIIAADARN6R88DFwF+vVF8eArm4 yoiEnQcLAICO2vVfH0AenT9uS05JHrFslI3eR3a9YMkdt8e4AQAAaGBpgCvf7QicGfz1SvXl IZADlpuBfToAcGOoXf91geVnbfruR0zVW+K25NQ7jwAAAAAAAGL465Xqy0MAAADAR+36AeD0 uC0BeQQAAAAAQH3465Xqy0MAAADAR+36AeD0uC0BeQQAAAAAQH3465Xqy0MAAADAR+36AeD0 uC0BeQQAAFAH//f/foB8VLcXsDdSK5bqC0QAAAAAAACK2xKQRwAAAHVQnY65LFS3F7A3UiuW 6gtEAAAAAAAAituSWyOPPt/aBq92BoAZFzkiPvv7pn37rN2M9ahOxyTx33+1zT/6/9ZuBsij G0FqxVJ9gQgAAABcOn71bdP2v2o3A9gRQ9c03eupqrstAXmk4KNrmubyIuqrwvBE3iB5/zae rOoPVvH1+MDnW9s0TfM0KJ9fXDfPljxib5Fvnj5S96/mU4bf58p++9cI8gi4dKRWLJWWodPL ktvn8QR1jc/t9q9kBoDrwPRy8bt+rN6SE2Hs75rGj4F/9e3xdesnC5UvHVnk0dA1TbM/x3Ql c/7Zjc1i8miVIW5Lbo08ysVnf39xEfWCPkZUwkYYnlZpb3y7zwi8d8DnWxvTK1n46E7JcC3E R7ewd0AWhqdSSmtDimcReTT8fjbEEMgj4K/65NFrZzJEzqUdmnHxgcSfP+Nze4Gh7NCdUfBz 9thxUDiGuDkbZQ6l4RHk0eYY+7vtyCNnvPzq28uf839+9e1FjM09DHFbAvJIB8ijVVhPHnUf NXTy+dYuJK1AHgEL3B7kEcgjgCK1Yqm4pgR5VAiQR9cPkEcnAcijegB5VAKQR7cipySPpoSg +7fxkBcWZ3bMSR/3b2NIXGLh7vgW0kLIj/ykwOZpUG8L6Uh6gEfypJ6GiDxiWVRF/MIhXShu cy5o1e3bB2d8aJoMaXDIUQo30KpZd477XT+sZjNVHHU7FWj9SSW/19rj3F60YZyvmZ+97z+D uXNJKG4m1uzgt8SNQ8k8U0m0OfEscd2nD+H/SUNkgLTtMO6I86RGBM3g6z5iqpEOuvv+48C7 Ta51tLg6immn2rfPiHNh8wNnEsMlw6mMEaFNPqUEJR014lltQOXwdIHEOT72x/Dff7W//4dT PKTif2eSR//pmqYJGWf/OXR7Lnn85z/iJrf//F8o4d9/zB8bBFO4IRR7bG37z/+RG/4Y4gaT SnM5rDJ7AReI1Ipl11VvPCLoOvi1a5/Hw7b2pmmabuAlkEvlW/dJ7e3zGJFHh9SV6XocybCq H4fhse1/Hcuc2zlX0T6PIR3juZv7MlfB6h3IJE/j0pBKE6rmuop1WUCH8cdFPDzX2Pa/wp30 nqWGoEq2tJ0wRLaDkWeDmULhJLARiTOzRR6HbCOyfomQacrHnJyEKTZpiOR42dEQQ3fXj16u VsJMc6+bpukGEStaZsoyLjOi6HJC1ULbfLAcyKNwg94wizwi/Q0lzxk6/dTgw7SjFE4mgcdh G0Y45DexwpVKH4dgTdu7gldT8931I+/7oeUZagzuIckjbzRleAgX2qPJD+22Lf9+UWZ+rm3P 5/lgVOrlFpTkkfUN8iPMSkdHriZpF2a9HSziTA6rDWHituTUO48+uvt7esaKkqD0+dbeP3XH M03IZpDhiRE34s/x7Z7Hkx+dEhXrW4pYvskhsg23iWyU8e1+8Sk8os0590ekzzEo/egiGoL8 +dnf37f3x09ibdg7j2T2lij5r5+PJ6KBz/4+jqX32Xn08dRI+kN04bO/v++ejgYq3F1l7jyS G4uiFjo7j5LP/vXz8dQ8PQUlfzwF5/cN4YHb5cAExdowNtlFJm5kS+hTH11DHPvY/vA4eZZ3 anhqGlkUnx+0LkeDXdVP9CedfMpSFMUpS/qhSwt3Hg2/E9ZmYlUCF/O//jfK6Yg/EzuPJCmj 0FJJ1uZ//W/KPeM//0FPWRJ//vz7j/a38Mn4z39Qdunnv/9qCZ00/N6Y/BTIo1tDasWyMmhJ wt15RBes43NLF6/iz5/XLmsdHJaz4ebDMjqUJg5ukOc4KC0J692xv+PNIB0cHufF+ms3L7vH /u5Y+NA1Mmqiyhmf2/YuVD08ylBqo51Hst75w7Z7bOdFf+jmKkNMvXY2vLiGyDdx9OzY37Wt qfmfAxtISyNqd41I/z/fL1m8oWu6LnxuaUAzhD1e9jYEZ0Ud3UozMUedIsljOxNF+RBG/Pl5 7aJg21T1+NzSm+M/u0damvSQY9fi1oqByUr+1bfEZ4IjGRVN/MVGm5uG7q5tReHCM1+75rHr COnD5i5yc/xnRHTGvqdvKVLcg02nydHkwt/wQlkM7jyrR9PP+Ny2j91R4WFyLvJ5Wa/iHraX ahPIr76967o7Qvrk6FNXozJjmHvxlhrCw23J6cmjiNCRsfTnW6tGyFpgz6I1EQ1+PGk0jRYq y1iXt1MlFD6eluZVleQ3KQ2z9SYLjzgdP6S3tHq8+Yk3+0AuKMyRUUIBDPJIa7DSqcKtYRQV ySNt+0+WIfJ1qNMlNnlkqzFh3yR55A2BrNw6lTxKjQg5+RRkRyojUfHG5eSRvp9oYmEkVfS/ /jdtI89JyaP/dFF14z//EXrx7z/4Ad68zUuT7EAeXT9SK5aS5fIS+OSR3NBxXEZrge6vvsv6 XTrid3iooFEwpLrEatsnj+aVPfm5+FidSv0Mj6G0KNiTStgsbU3p49jfqWHbGkPYJeQYwoVk f6YuPB6flUGp8EOXPPKMqPrz+NzFW0uy9lDEhjDHy46GmCgY6tXUNEkzObldKTP5iIyo6MdS tdJZ0SkZwWr5QUrX1PnhtQtPv552AAAgAElEQVTEAWEhA3fJ4v8ykqLAvtrmGjEK9H0fWqeY 7SLmRdO5Rh4p/kzamTWaXPichdyqRvYbrh1NE7OjmLLU5+n9yrNE88lvkEOvl9CRQ6d5dazb heSRaQgXtyUVdh5FcaMIzIzYUo/02LOUyNBJDTVU1komt31oKV4FqVhRWlM2eeQGtzr1Q8LX 6IZc8kjNw9I2rXw8qbtCfnYij3RmR3jUusOqau48UonOPENo0Eyg8jKmxlgKoUwvdduQ9DQ6 pmK9sUw9vSKNPEqOiAxDFChTeXzxmUf/638LPaZEkkruMJqmCnmkUFq8cHlDRHjRlLd8IqlI t8AlIrViKVtilqPgzCPCy6g74ZvMH6W1wCAQVQq1xJaziUNnlpNHLNUlCPudma/LNySPWLKD pknjIJJVhrDNkWMID2oeVkNiOc9MSi3Z5BFLdaEVC8OZBEHKEJb77WgI39NyzMTMESdj2mZK Wjm6U9IchqpVNZJntaGkVKeEymoCaaNs9DDII2HKDYkkfd5jejCOftMnFvYsZab0XVrqHGLo OezWyRhNLkqO2mFDe+1ochi0hM9Hvba3tf7JZqHkN4i4vwTHqgMba3BVi8gjyxA+bkuuijwi QbiZk7KIPFr+5q84vaVg51E98ignBv7s75v2Xs/gA3lU8mzJLrlsrCePhEV4Fts68kj03aHD Pt9abU/WlZFHgqwJiWlXSx5JIsm+CvLoppBasRSvMguxmDxafkro+ZJHflC0G3kU5U3oO48M 8mjtca07kUf+bTuSRxlbiizyKMMQDnm0lyGUS4XkkdD8cSvQyqORz5U8ciiGHPJI3L/Ze+t3 JY+I55tpR0vIo7XHwy8mj1afQl2w/Yo/FR3dVUAepef/pV07bPh67eZ0TmvggzzaSc4zbU2N w5Npa6R8+53Z5Wlra95RpbS5LG3N4a0y0taWkUfWgTJCjYc9R8qpVZXT1k5BHg1PzWLyKHrW NHSGIUp0WJS25t6mdMEzSmIE+aVZGWpL0taWkkf7pq0pLMyRCdo2be3ffzSnSlsrII/8xD2Q RzeF1Ipl3QI6jWXk0aqwc3Xamrf4loXTECKZ8eT/sr0XeRSbIJ882uDVSLukraXCzkLyiJgm YcSs2Cyb0ShIW9vREL6nFZuJ620FO5CZtmbwdMm0NaH5zLQ1P++slDxSVRROvy60b07amjoF JdPW/jwe5aMZJdirMG1tPYmzkLPY4I1vlm+7Pq8SlLlpa1nvDF2s0teue52aNxlId1qQR7tJ 7QOzlXDdPhJFBplayD2+3bdvb9pR2RPMA7OjNzrxVzVF8X9eVK+936rgsO1o4xI7EErG5LwX SfKI38+O3YmS/hjvIK/G/BGL7a1DrGx4B2azimJWYifySGZENrJHrN7x7b7R1aU+67CEviGS zqO+gM+9zalXvgMufgffXDhtZFRvNHaYESNf0g1qH5jtjIgV5FHUDLUBi8gjfnr0xMLwE7IZ d8OvJsgjelL14fVqnDxipf33X63yNjfzwGzWDNEAlzxiB4RPVFS88+iQ18arLtItcIlIrVhW rJ6zwNay/GAdjzxSzmRV4r28BfT8FiR6YDYrWSyIo0Nb2bkq9PzXKY8glzxSzsCWx6P65BEP HkoO1vG0cVS+saBfY4ioZH5QSMIQqWKdQ3wT5JEgE6lCkkaMuh+H0wa/kGMIZ7zsagiPpnTN pLWKqNo3U7rB7MBshYUxqRwZw0fKp4fTFx2YHW+9CeM6RR5pziPrnWaVJcfW8AOzVWrSchjZ U+3O4bHpnh3zmQdmi9PWG+9Ub4ec0uCPF4ezWDuaHJLI83lfG9KfIxrR/waJFFKCX317104a m0aH2jtzil5sCAe3JXXS1uhLvsVrmKLMSxmik2vWBqUmPjL5Q0385VRLKLf/jIJ8fvJRwX4Q +Wr5qSUFW5n4W8DNV56zVpHPpy6EQiT5YpQsD9xhVAitLpyMI9PHqD6XdVZpGDuIh5WsnRCU n2+onWwVn+N+/HxqRszraapwn1XqjV+KZ2ojPdzYg5QV9UdErMy4Xl5CxB6SB6fSDv2KTByT UGqTLPfgVVsjIuh5qk66caEy40OgolZlccT/x15afxDO7/z833866yo9OSgIJWLIaUq//+dQ lzzK+vggZWr+o/sHO49JrzR8PlUUOngonz/Y6K9aA3l0m0itWBasMguhvgE6HN8wrTjDIRTx O9dnKXwLD3tQrMJ5ydqhrey69abt8Dbux459GF40fihK6TgrmZyUMXUztF/G7UcpOhmEaYO9 /kY7pCNmNBYbQjwen1LsGsKFaLlyYJY8bSq0nCv8oJD2+KBvRHFqSRQNMpF5Q6YhvPGyoyHk K7SDZvT3tYtWxcfHqGexE21ln/IzMYD0cRFmu6qWY40SiwerEVWbRzjphfOTj45nxNC6CLMc XmYXn/KjZXUt2Hb0M1NUVC0RDcE7VPgKefr+QV6voi3r6Ku2/xX0nxpNWVDHi7AFbSTnPYlk jybtqCbh1Y7PS3+WXKEYpGQW0rza/rosVibhvOSp2xkjYo0hLNyWnMOZRwAAALeIZKIWQFHd XsDeSK1YikMUAACAE0A/deXKsfBtWT/5KZ8AcBm4LQF5BAAAUAfV6ZjLQnV7AXsjtWKpvkAE AABQcIvkUXygcjZAHgHXhduSU5JHLENn6RHUAAAAV4LqdMxlobq9gL2RWrFUXyACAAAIsByc rd5Hdr1gWWk3x7gB14nbklPvPAIAAAAmVKdjLgvV7QXsjdSKpfoCEQAAAAAAgOK2BOQRAABA HVSnYy4L1e0F7I3UiqX6AhEAAAAAAIDitgTkEQAAQB1Up2MuC9XtBeyN1Iql+gIRAAAAAACA 4rYE5BEAAAAAAPWRWrFUXyACAAAAAABQ3JaAPAIAAAAAoD5SK5bqC0QAAAAAAACK2xKQRwAA AAAA1EdqxVJ9gQicC4auabrXXQofHpvmcajdQQAowo4jAgCABG5LQB4BAAAAAFAfqRVL9QXi dWLs78i7s6vyJsNj0zRN+zym7lwSKo/PbU4Hz4g8OrwD/sJeZ56p53PH9Eb5u36s3pIs5IyI w0gHx1QRh9FxkBMO7cNkMlcMH9gWtyUgjwAAAAAAqI/UiqX6AnExfvXtXrH02N+tikCGxxyy ZmOMz60Zvbx2O7ZnR0PshLX2XW6IJBxLXZ6ejV5cDHmUi+Hx+omD4bHtf+1S8qrx8ufPz2tX iY4cumaZTvadf64HtyUgjwAAAAAAqI/UiqX6AnExzpo82ivQcgDyKBsgj+oB5NFl4pzJo9Mz 9T9//vz8OXQLPRnkUR5uS0AeAQAAAABQH6kVy+5LwKEL+/rb/pUHwHTbP1mIhySdcAMNXWiZ RrbCa2dcOiaUTQWKPw9JXrLo7NhGe5w1jGZYiJhnfrYbwm15Adurpg+q59eufR5J1VxXxAqi pylDzI/PdYXuH6xJ0vcE8REymII1Iz2HS+3zWJL0xNMG5SOH4C1qbdJMIkdpruX4eNIQDngK jNKwSc+hCmkIlrwjmnTX949zY+aKsr2aDzdl/HYDUXgUyZPHp9pzLKiVLMyUHi/UHKHZ1Dfa /pd2mz0iIlW3/S9JHumGWKnqPLCqHwfB+NDZiTR4qvTQkbhqnhSmWpkNN3bpqNupQOvPZb3W Huf2ovrUvyC612DubBJK+wJinjPXFZXsfb+knhUTDvV/tWEXT2jeloA8AgAAAACgPlIrln3X f2Jj/9DR2OC1Ywtf8eevvr1r2+MncW6CsxFD3PyrbxsZRIUV+a++lcdk7LXzSBz9o50ENHRN 14XPC37c9nce0ahsfG7VCE3fQFFkiNdOj/30z4furg2mkYZgzjM8Nu1du3CLgXCtP8f+ruuo D/BO+WaK9CxttOPOo4azQoJv5XQh6XIYd8Njc2BMFLfPdTPuAGN/17Z3R8+Jh3z480BD5Lq0 KFlNUDLHi2inbLZ0yLG/U5xfHRFc1Ydw/Xiba4iVqs64X5I+R+WP/Z2kIainDY9tGz5RtGHv PJI3y2mNe1qc0rvXziMx7UffAgf7PgYDFe6usibn6OtDttD5fkk+O03IXXc0Vph+xdCTJr48 3JaAPAIAAAAAoD5SK5Y9F3/uWlxbQNOFchTcytJM8khdmg8dv/kQw+gh9D7kkdbg6M6hK/gB nCFBHslQWemgSR7lGWJ4tHkBizzi4RztQtydNSdJ8TYrYdX43EbBmP54TfJIbr05tkqLY3/1 3aEoRqkQgmCZk4sHI6KBdEEZCAUn1GiEjtSPNV4UhXC7cN8z9kMpI0JxD9pO3xArVe3Cz2pU /IoVLgdXVJo5mWseOz53copoDnv9tJt3IY+UBiudWnN8ez3ySNtVpKpxeLzk/LjbEpBHAAAA AADUR2rFsuPiz4189FCHLMeT0YsZLKlJbUqQMDxGuQw5Lc+AGmjpMZISDC/fp5B95lEheZQ2 RJfgvMydRxbtkuIWM7TBzS/Io6jwuZtJM9UkjyxDqClvjb4fZwF5FOXayG1cRrhr6LmAPDLN FJSvjhdVjfxZSmRYvKQyIrSSw20JQ6xU9VLPyZiRkrOrRR6pSW1KztSvvjWmiH3II5XZkR61 7rCqijuPdKJTkwqn722G2xKQRwAAAAAA1EdqxbLj4q8ieZQRcf3q24ZmamS3PAM3Rx41bfeo p8IdG3BK8ijO94l2Hl0deeQxMqvIoyi5Mt55dJHkEWmJ+dqsJeTRiuPAU6pe6jk7k0c5o3JK O1W5MJBHJc+W7JK7dNyWgDwCAAAAAKA+UiuWPRd/7nI2I21tIXmUsYwOqVjqWSd109YukDya aRczjCwmj9akrSm9i9PW4qPBF6atRbFcBfLoz7G/c7YYrCGP4gg5nzw6Tdqa2otk2loo3zoC 7GdJ2ppviJWqduHzVum0tYXkUQ5fFkauZv26aWsnII+iibGAPFImVUvh1nlzl4vbEpBHAAAA AADUR2rFsuviLzqjdHwmPz7LxS6PA9PRC7ufn14RbSWgQYs8xEc9HZYf01u4+d85MFucDqMe mL2Qt2Kl8bNgTkIe/Tj8Tjl5JFQxPrf5B2bzjoSXSZHueycxJ8xEb1ZfAOcYIgkWGY79HdmK 4hsiOpqKcCJryCPOhogXQqnlMGfj/lzwvjzNTEq4bo4XGXWrIfdr1zz26lHZuicoJYsX8PmG WKnqBKKNS9T3JKsl9JMkj9j9/NidqINsRpVzQswfrRkv0t94F6KT3ZUDs7cnj2RGZKO9WNP6 fkk+67B10fRrbqm7DNyWgDwCAAAAAKA+UiuW3ZeA3sun+XkZ0VuZQuxkvM1dfxW3Vi9jjmh1 1ivG7Xc8e+BviBdVxzewS8pRTaXnQ6uv4pYvpLc1EFedNMThhvC6H+2qqhD5ynnNEPQEmceh 5Mwj+Tr2SQnktdzeO+BdM8UqnXot02FiQ2SCKo3myvmGkOpq4reht/0vaq+pjzmxpRgL5MHo lfbKu95pq+76sYATmWgpacr88cJPgTE2KCWtrxUu7CuDfNUQWbBVXe480YPWVBw+l6PenLtk k8RIVyYf6Y0bjBdteol+M9BaFflG3FkX2slW1tdH+zyKl11qhtbNJJ/V6o1/9jC1cXG4LQF5 BAAAAABAfaRWLNUXiACQiZIDs4HLx9rsUQAALhi3JSCPAAAAAACoj9SKpfoCEQCysOY0GeAS AfIIAG4YtyUgjwAAAAAAqI/UiqX6AhEATLAEomt7lxDggGXogDQEgNvDbQnIIwAAAAAA6iO1 Yqm+QAQAAAAAAKC4LQF5BAAAAABAfaRWLNUXiAAAAAAAABS3JSCPAAAAAACoj9SKpfoCEQAA AAAAgOK2BOQRAAAAAAD1kVqxVF8gAjVRvwUAAADANWLt07ckII8AAAAAAKiP1Iql+vISqIn6 LQAAAACuEWufviUBeQQAAAAAQH2kVizVl5d/Dt0FvkhrfG6bu36s3YzVqN+CJMb+rmmfx9rN AADg1nCRX05nhLVP35KAPAIAAAAAoD5SK5bTrSQPr12PluIXuT4/W/JoeAxvOM9o4foqX7ud X6gO8mgXlbKh+KtvZyte3FCcZpCjrHaVqbQ9nNmaAS8ZB8/phhq1j8/BbfdpwEV+OW2MNSZe V/NtCcgjAAAAAADqI7ViOe1CdHi8+aX4nhif2+ZxKHlks7rH/m5RvP3agRiqAnUoXuD4HPu7 7ds8PK4ij8bn1mqSc+liMfZ3dcijGUO3iNq4RlvshKUmXlftbQnIIwAAAAAA6iO1YjntKvQC g9NLQnk0tFndII8uDFdEHm3PXIA8qm6CEoA82hsgj/YXkEcAAAAAANRHasWy87KTJBa0/S8e nKZzZUg+yuMQLfUPWSBzCUM3ZWlNeVTHjK05rcp89q4fIwaDJH91w6++Jdt5wiUjKYx0mebQ hGyYUELZLiGaIiafpZWWpJHpdppVmVExUaisb+rnUQVzt+cghJg/CKs3mN8gmGi+UohtDn15 HEgVsS4SHrAUc5Meh1CF0alG8XvSqtD+Q9e4jXVtTzfPd7J7vKFIClGHIkuGVBzAH6j+VR90 kIsus/Gv+Y+B2ZmpxY/Kmdo2PLb9L24L0/G4xuhI0TQ2dd+ZRBxVM7Pq81qecwpDZM2YrGHt 80DYhIlZSI5WE85s+2POp6JfgtoQGYLRSEyZKf3lRKcvYsS8yad8RMw26h8bUT55lrml0Z14 +s1hhQ7kke23xogo8AIFtyUgjwAAAAAAqI/UimXN2i4FnkV1WF5mR6xDR1bd05qc3CayVcb+ ji5oJfvB1+f82ddORCXDI/lzWmPH8fKvvtUC1eGR3Rz92bbhAJ+yhBtxypJ66NLCnUeKneya jNOejJ1HkpSJfsHOYG3G51a551ff0qgs/vOubY9x0WvH25zwgLV47ZrHLpyWEvrIfDo6zom1 anxum7u2NflF9TSWoWu6LvhcGAZrhiIbD4oD+APVv+pD9FHt8pI9Efo4IbTFFCRT6sHqkXom l7/zqOGMqjn16GNt7O/a7vH4eX73U2byZkylnYR0mKiZY+FCPwn4s60/n5KuKUpQSEy3j1bz lHteO8a5iD8Tk8/iETF0s3KGx1nhv/rWYH+k8yh35ltq7O+6jlqKdcoeEbleoOO2BOQRAAAA AAD1kVqxrFnb+Yh+QrboEps8MsOi1LI/SR55a+as3B2VPFK6zDJgRAim3p/ZI1UJy8kjmzrJ qvj05JGSWES1GUVK/P6lSXaZeO3UfV+qeYbHEGTGHIS3OU1R3dCpLNiaoaj66GvHyRSHv1iY UmSoK/bGRQk1v/ou0hKtTuqBKCFhRPue4yVuINKjtKoPhivesphjJmfGTAzSaDSV7OPzZtvU fOp3bTfySHM52uXE5LN4RDAumPwEYZUmLynUZK4j6Qzp9Ik3Ihb0kuC2BOQRAAAAAAD1kVqx rFnb+dAiiLKDVlhik7Ma95bZx4WumUnjpzQ5WQuZG3+IHmSz88kjNRzTMjwWnnnEc1LG0opP Th4plBYrPGph5DG+B6zDa6dGZSwjKao9QYf9qST6aeSRFkmuGYpqgk8TkaDGQE1fNaFHxZGW lp3GMvvPr75lqWpGLdGmJMuIE0rOPCKenKPqNbynZwhvxkxNK0sGNX+cNOtVb4Nb+GnJI33W 9khAxZ2WjIg0eRQ5Jy+csVpFG8S0UTZ30xsRmcUbuC0BeQQAAAAAQH2kVixr1nY+1pNHct1r B3fOSn5ebNtV+K9jNt4Uf2XkkbBH4D6uljzK94By2OSRU0vGXqrk/o59yKOifS5xO/OvWtb0 tLTwKN9pZ8T43HWP0/4L5lE+eZR0leXkUVrVG22ak4aoSB6JosJse7XkkWcIBwnyKMrpU4bG cfNR4Ys5E+SRqcYFLsCeviUBeQQAAAAAQH2kVixr1nY+1qatSVAOwU20+onDhEQVftRmZagt SVtbSh7tmramVEZ/oN4ybS0K8/ZLWysgjzQPEKcIF8HyJ9/P3LQ1Ref55NGqoVicZeMPztTQ ZXfulbb258/43B0Ohp+2Y8hT8e2BmkHxLCSPslS9WcYlN4Q7Yya6vCF5xCfWbdPWoil7x7S1 kskne0T45FHe0DhsPio7l0qdLkIbHPdY5ALk6VsSkEcAAAAAANRHasWyZm2XAl8Vixfg+Ovz +JdRETRFm0XYOTN0rRvVKw8wjd8BJw8wydx5pPSFr6tXkEdRM/K3Pnk4qFJuaRHvh0pWbMa0 VJv83WFaafp5LnkG4A3w4zffA+ZPVGfNgh1NyVOvmPJ5F147dmC29KQ4oenHYR/WDEVVXZTH dQZqahj7kN3JjeTzbNTeHXQyPDbtnTgf2huorhFjY7GDqBLbYVxVlyuQOYBrCHfGjLdfknS/ VeRRarb151PLTxRlqlywbSbX5eJm8Aa4k8+KEeGTR9EEaOTETd5eeGzW2N+17Z35JWqOiPwa NNyWgDwCAAAAAKA+UiuWNWu7DNDzELpXGvNqL9rmQZY8vkEJG8llERfwVy2zdxxFR4vY57c0 TcPZDP1YErpEt1ol32QdOpi9u4UfLiHDardVFnjLrAbZFUfPTnfwg0vIg+LFTNLS0RudIrGN wd5TxpoaGnl8/ZkoNQoaxdv7sqH4h4wMeb/sk5imTTGcxWMNnuo6vlgtrph3avFQjPulvuSe Fp55NQ0+GqMANZKCkJgwPox4zhqorhEVbQenou0MWhWv7lK7rJmphHtOGMKZMZ1JIHqlfbgt p23+bBv3Wr4+LBZmC/5q+cmy5rwpyDKlaNPt5dvTiIrk5LNwRASvaPtfcyGPA3/VHR0R+mR7 1FvBMAw8FFFL4jtirjS7EhW3JSCPAAAAAACoj9SKZc3aDrh41G/BWaI0vtqvGUveqwUAAGAg 2t22I9Y+fUsC8ggAAAAAgPpIrViqL2WBmqjfgnPE+NyeLr6ykXkYGAAAQB70w872wtqnb0lA HgEAAAAAUB+pFUv91SxQEfVbADDQ7I/lpw4DAAAQyCzg02xpXPv0LQnIIwAAAAAA6iO1Yqm9 pgWqon4LAAAAgGvE2qdvSUAeAQAAAABQH6kVS/XlJVAT9VsAAAAAXCPWPn1LAvIIAAAAAID6 SK1Yqi8vgZqo3wIAAADgGrH26VsSkEcAAAAAANSHv16pvrgEAAAAdkXt+gFgAW5LQB4BAAAA AFAf/nql+vIQAAAA2BW16weABbgtAXkEAAAAAEB9+OuV6stDAAAAYFfUrh8AFuC2BOQRAAAA AAD14a9Xqi8PF2Ls75qmabrXVeWMzy15d3E31O8XAAAZ+NW3GLP5qF0/ACzAbQnIIwAAAAAA 6sNfr1RfHq7A+NyuIo9eu+auH0/Z5kPEy6R9Hq1LTdM0j8PPnz9Hsix+uv9llrwVIzY8poql tT8OP7/69tDsoaMPMW0fezQX9RrubZ/HuVKtg4fC9zGE7O/cAN7I+WZql26QdORachP4+XPo zEE69ncgj/JQu34AWIDbEpBHAAAAAADUh79eqb48XIH15NGRLzg1XjuNAYmC4cDCkEvk2eGR UhtxmL1tdD32d5xJma1AuaQDe8J7Nzw27fMQPz7RNNQKw2MgXOKixud2Y5Pphpgv3fVDXGO8 5+VX3wrN/+rbphucwoFcgDzaArXrB4AFuC0BeQQAAAAAQH3465X91n1yj8bPD9mXIQmC6M6f sAGEbuhg7AMhj8IOlyxy4ZVtiNE2idAtMzxAnZ/tXsMGlmJG43rIIy22l70bukmHEVs3PDbd 63w1fBLsKyinU5JHc0uiDv7qW0EqReTR3M4l+l8zIhIg+63a55E7D9+NNXdnZvf6bvb5uV7W L7bfqng3H929RZuk7rYTN3SDM/bZ/jKhqLnwu37kii1u87TVjjyeNhOdf4j7CS6Vtyok6hJt Z1u/cFgAwDngtgTkEQAAAAAA9eGvV/Zc+uk7gwIh8jM8RrGTjOSHrum68DmL5Gn5lHTIhbXz 6Fff0qhM/Hms7rEj4WJJDP9nmjyKCiwij3bakaGRRxm7t8bnVjXf0Wrkhpg8Gml24enIo2nr kGqLA1U0dDSljvUrXCrdHLdyRHggPTqUTL36tWPUCf3ztWuamUeb2RZqMvp/pagEho7xtuJP v4MTn3LsBbFI1F+t5MlwXXdHUkezdoqN/R2nv+/a6EHTTONz2/BJjNFtckCxsTw+t+0d1Tbv soMCHwSAc8FtCcgjAAAAAADqw1+v7Lr0+9V3UagfwmktVItIk6Gz9/XMRXn3eDCID4UJipo6 PC7YYcGqNsgja6NE8tkfb7fUNlDIoww2h0XaQrdhd8/cX4U8IiWcjDxihIjwk5kqCvcI8oie pZXLR5g3F42IROFF+V/HXofuEwegx1rFxWoDX4VGrokCffJI7ugh23biETT2j3F24Qaks6TP PDMp3WFKSJFHSkU5E1FhFwHgHHBbAvIIAAAAAID6+P/t3dF1mzAYBlAvwQx5yBTZgMcs0QU8 QRfxOF6lK6QPTowkBAhc/Cfl3vM9ObWNDe4R30Fifryy7+jv68QmOUm7n9TVL8ooz52yOU1F rm8v/Wu/bubO3Hvl25ylPLvecqFT/tYrrzxafO5HyJVHy21OcQFIvvH3r/F+Vlwrj4Y65lnl UVZ4lQfh0MJ8dV55L3N5TVuD+kJR1Tz+i1j+sNXJZfWG6+twmi+PFhZ6XzyiKp9laTLm9NOz Ta1u1mha6PoKuKVcntxN1f9z0qcvlUejI6Ttx77peBGJzbEoj0RERCQ+8+OVnUd/l9fbwh99 /3prB7LpG4+XR6eu77utPc43Lo+SRyozxZbKo52yZdpacfex4gQ++Ro/X7xeHiUT3J5RHtUK kWF3p43D7elZB3EZr6fVuM27l0fFB7+/zoPl0fajbtfyqKGzUx6JfOMci/JIRERE4jM/Xtl5 9Hd968+/Ln13vt6uQElPk1on6cxeefT+serijiyPTVv7geXRrdfYeqHW1ILZc11GZU2WyZWq 3vtTdz5PlEe3K5jOow7gvg8AAAODSURBVPKoenO3B3dEfunQ6ADIGofruTv1b8Mj2ycW/f4H v4hVyZu7zdPWtv76RgfDxNe1rTxq6xm3NV+t09aqu2nttLXsdUxbk0PlWJRHIiIiEp/58cre o7/3/qX7PIu7vJ5euuxcsaxgKmfyLeXRx4qFY4ttm1owOzsfq5we/8jy6DZrafvN4ydqgtEZ +LDMc7r6T/rva8tjp/eTuu/fdAcV96JKnrK9vJg45GrL5XTJdTrFCkfDLLBivtt9y1u38MFf xPwrz13BNHWDvN+L5dF4aepqxzGV8uOMflnX4nZ7yZVrc+VRZV+MtnPrZVP5D+G9n1owu7qb ylar2IZ0I/ObuH1UFsyuHVqfkxPzx1cfLyLxORblkYiIiMRnfryy+wAwORV/H69PlC9NUt6y amb6T140DIu5NJ1X1+ZSTd9LO19S9+v+2VObPZvafKjhTk+jPxUbVm52ec65sEnXt5dtPUvl I5/Kk/bxJ6rdcj7Z3V3fd6NXG27slb5pUliU5dGlP22qw6Z2RO129dmd0d/67N/fP9Tn/dfq n+jzoaa2cfMvYu1OrFwRNv7r8KzufE1/dLcvKl0XPH3tVXskf259Vtf4C0keLA+Y4d2LlY/y hatGX+aaOjjZF7fLKrM7oC3spnxflP9lJTuiv+T16K0ur/2yxj9G5ZH8+ByL8khERETiMz9e CR8eypNyPXePXHb0LVOpI0WenlX31Hsg9VWxWhL9DYlsyLEoj0RERCQ+8+OV8OGhPCe/zi// Xc8yzI8Ticujk1ibozySQ+VYlEciIiISn/nxSvjwUETkpyWdevaP7wBYTzYFb/U7xn9hIqtz LMojERERic/8eCV8eCgiIrsm+v1FNuRYlEciIiISn/nxSvjwUEREdk30+4tsyLEoj0RERCQ+ 8+OV8OGhiIjsmuj3F9mQYynLoz8AAE8XMgwCAKCF8ggAiBcyDAIAoIXyCACIFzIMAgCghfII AIgXMgwCAKCF8ggAiBcyDAIAoIXyCACIFzIMAgCghfIIAIgXMgwCAKCF8ggAiBcyDAIAoIXy CACIFzIMAgCghfIIAIgXMgwCAKCF8ggAiBcyDAIAoIXyCACIFzIMAgCghfIIAIgXMgwCAKCF 8ggAiBcyDAIAoIXyCACIFzIMAgCghfIIAIgXMgwCAKCF8ggAiBcyDAIAoIXyCACIFzIMAgCg xV8RtJnBrnyZowAAAABJRU5ErkJggg== --------------1C8DE3F74EEFE0704CAA3F71-- --------------1177770B537A810C91E269A0-- From nobody Wed Jul 5 14:33:30 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7441126D73; Wed, 5 Jul 2017 14:33:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149929040880.20397.719737848609666151.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 14:33:28 -0700 Archived-At: Subject: [DNSOP] Alissa Cooper's Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:33:29 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dnsop-sutld-ps-07: 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-dnsop-sutld-ps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 4, "the IAB technical document" could use a reference. From nobody Wed Jul 5 15:21:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ED2127201 for ; Wed, 5 Jul 2017 15:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0SN8GbPSMOvi for ; Wed, 5 Jul 2017 15:21:21 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8BA126B72 for ; Wed, 5 Jul 2017 15:21:19 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 6C6EC24BCC; Wed, 5 Jul 2017 15:21:19 -0700 (PDT) From: Wes Hardaker To: "Paul Hoffman" Cc: "Wes Hardaker" , dnsop@ietf.org References: <31A2BD38-AB02-4224-91F7-4944435D498D@vpnc.org> Date: Wed, 05 Jul 2017 15:21:19 -0700 In-Reply-To: <31A2BD38-AB02-4224-91F7-4944435D498D@vpnc.org> (Paul Hoffman's message of "Wed, 05 Jul 2017 10:23:01 -0700") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:21:22 -0000 "Paul Hoffman" writes: > Just a note that the actual filename for the draft is > draft-ietf-dnsop-rfc5011-security-considerations, and it can be found Whoops; thanks Paul. -- Wes Hardaker USC/ISI From nobody Wed Jul 5 15:22:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB791127201 for ; Wed, 5 Jul 2017 15:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1N5rWTB98ktv for ; Wed, 5 Jul 2017 15:22:29 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83483126B72 for ; Wed, 5 Jul 2017 15:22:29 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 423E924BCC; Wed, 5 Jul 2017 15:22:29 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: Date: Wed, 05 Jul 2017 15:22:29 -0700 In-Reply-To: (Michael StJohns's message of "Wed, 05 Jul 2017 17:54:50 +0000") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:22:31 -0000 Michael StJohns writes: > Could you hold off on this for another week? The revised version > dropped last week and I've been on travel and enjoying the holiday and > haven't had a chance to review the changes. =C2=A0 Thanks - Mike FYI, the changes are very small: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dnsop-rfc5011-security-consi= derations-01&url2=3Ddraft-ietf-dnsop-rfc5011-security-considerations-02 --=20 Wes Hardaker USC/ISI From nobody Wed Jul 5 15:33:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D26127201 for ; Wed, 5 Jul 2017 15:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 YeIWIOaqsQAk for ; Wed, 5 Jul 2017 15:33:21 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 5F54F126B72 for ; Wed, 5 Jul 2017 15:33:21 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id k67so3890577wrc.2 for ; Wed, 05 Jul 2017 15:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Eavl18xpbWXP5CTrJXj98jjct9M/yygg4bPvi3CfMbY=; b=lxAxFICMGuZ6bygTCJz4e47YU8uXw+IM3Z0dvnZiV03E4IypjNjGLnMsmb7HgSJDQI jzGpXtWmEmplSPYEFqTRQpSpVz0h6qNe0Dv1D1tqoizKFVQn0G77jGTRPVc3O/nqR7HG QsjoanRBiQ68FYIs72rO4S8vv7uFRAWVu962qi+7xx7i73xc4VmqBksV7j2IFSzx06aU 6jrr9FuB+kJTfI4PfK6zCPY6+HM/zHcce+jxPHOyKzdqgac2JKUBqTpQUpMX3T++TPCx lGyk1oDTRrPcJFbs6ThhV9hIQNcavZ026XHKfooUiU2LursM6XsVJFO88iRlDlV+WhgT qTNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Eavl18xpbWXP5CTrJXj98jjct9M/yygg4bPvi3CfMbY=; b=UjuNqdmzpSaj4OXu4C/CFEGqEYAgMeefYBVV8hOuqzQ0cMKmgrF/92r0rp/7hhd8AG VCaExDA7lh1FzgJ7/ku0r9UGyhkQlmxSHZoxSPSX9NAEOpCcdEm6YyoXGw7shtRS0kic FjeueeKWsioTWlUEMHKfFcPVFw7pE/b/2g0TKHcAHrPfgfS0crjLIXljU0LnUCFmHiNQ KLviDf82GlC8RhYuaB5YMrP3Xd2oYBvgXLygNAyPkwHoU1lIxERZfDMdwPUJCIH2Oqpu 9E+8/FM6hYgG6LHcy3ukg/CcBqpgT401Sqs3m3JukhxGdOGEsw4ja6gAEX3Werfmv+H+ le6Q== X-Gm-Message-State: AKS2vOwDJz0FkTjeRFD4RpTsCKb3qWKJ5FRB6sujiVAlq1jVru3Yh0uu 9Jh4K5lzZrL7J1uPjP/gIeGK+/g+t536 X-Received: by 10.28.223.86 with SMTP id w83mr31621279wmg.9.1499293999893; Wed, 05 Jul 2017 15:33:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael StJohns Date: Wed, 05 Jul 2017 22:33:09 +0000 Message-ID: To: Wes Hardaker Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a114b08064726bc0553999619" Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:33:23 -0000 --001a114b08064726bc0553999619 Content-Type: text/plain; charset="UTF-8" That's not actually a plus you understand. Mike On Wed, Jul 5, 2017 at 18:22 Wes Hardaker wrote: > Michael StJohns writes: > > > Could you hold off on this for another week? The revised version > > dropped last week and I've been on travel and enjoying the holiday and > > haven't had a chance to review the changes. Thanks - Mike > > FYI, the changes are very small: > > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-rfc5011-security-considerations-01&url2=draft-ietf-dnsop-rfc5011-security-considerations-02 > > > -- > Wes Hardaker > USC/ISI > --001a114b08064726bc0553999619 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's not actually a plus you understand. =C2= =A0 Mike

On Wed, Jul 5, 2017 at 18= :22 Wes Hardaker <wjhns1@hardake= rs.net> wrote:
Michael StJoh= ns <msj@nthp= ermutation.com> writes:

> Could you hold off on this for another week? The revised version
> dropped last week and I've been on travel and enjoying the holiday= and
> haven't had a chance to review the changes. =C2=A0 Thanks - Mike
FYI, the changes are very small:

https://www.ietf.org/rfcd= iff?url1=3Ddraft-ietf-dnsop-rfc5011-security-considerations-01&url2=3Dd= raft-ietf-dnsop-rfc5011-security-considerations-02


--
Wes Hardaker
USC/ISI
--001a114b08064726bc0553999619-- From nobody Wed Jul 5 16:11:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A7A126B6E; Wed, 5 Jul 2017 16:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HrM3A69TEmxV; Wed, 5 Jul 2017 16:11:12 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 03662120227; Wed, 5 Jul 2017 16:11:12 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 8A3AB24AE15; Wed, 5 Jul 2017 23:11:02 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3C822160098; Wed, 5 Jul 2017 23:11:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2A6F7160099; Wed, 5 Jul 2017 23:11:06 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ts9GJnjE8INH; Wed, 5 Jul 2017 23:11:06 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7F304160098; Wed, 5 Jul 2017 23:11:05 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E23E77D9B7A1; Thu, 6 Jul 2017 09:11:01 +1000 (AEST) To: "Roy T. Fielding" Cc: Matthew Kerwin , dnsop , IETF Rinse Repeat From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <20170705031957.834B97D8FBDD@rock.dv.isc.org> <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com> In-reply-to: Your message of "Wed, 05 Jul 2017 10:29:18 -0700." <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com> Date: Thu, 06 Jul 2017 09:11:01 +1000 Message-Id: <20170705231101.E23E77D9B7A1@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 23:11:14 -0000 In message <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com>, "Roy T. Fielding" writes: > > On Jul 4, 2017, at 9:23 PM, Matthew Kerwin = > wrote: > >=20 > > On 5 July 2017 at 13:19, Mark Andrews wrote: > >>=20 > >> In message = > , = > Matthew Kerwin writes: > >>> On 5 July 2017 at 10:02, Mark Andrews wrote: > >>>>=20 > >>>> Who owns a name is a different question to what machines serve the > >>>> tuple and how do you reach those machines. There > >>>> is absolutely no reason why the zones and > >>>> need to be served by the same machines. There is a argument for > >>>> them both being under control of the same people. > >>>>=20 > >>>> Mark > >>>>=20 > >>>=20 > >>> Hi, I'm jumping in at a random time with a possibly dumb question, = > but > >>> the talk of and tuples got me = > wondering > >>> about representation in general, and URLs in particular. > >>>=20 > >>> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks > >>> like a DNS name is a DNS name, and that they have to be resolved to = > IP > >>> addresses if you want to fetch them, but they don't talk = > meaningfully > > No, RFC3986 does not say anything of the sort. Neither does 7230. > > >>> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 : > >>>=20 > >>> """A registered name intended for lookup in the DNS uses the = > syntax > >>> defined in Section 3.5 of [RFC1034] and Section 2.1 of = > [RFC1123].""" > >>>=20 > >>> I read that as: "if it matches RFC1034 (and isn't overridden by the > >>> specific URI scheme's rules) it's a DNS name." It could be read the > >>> other way, but that just adds more assumptions. > > Just read the text as written: "A registered name intended for lookup = > in DNS ..." > which doesn't limit much at all, and certainly doesn't say that all = > dot-notations > are DNS names. > > The sentence immediately preceding that one is: > > A host identified by a registered name is a sequence of characters > usually intended for lookup within a locally defined host or service > name registry, though the URI's scheme-specific semantics may require > that a specific registry (or fixed name table) be used instead. > > with both "usually" and "locally defined" being relevant. > > And two paragraphs later it has: > > This specification does not mandate a particular registered name > lookup technology and therefore does not restrict the syntax of reg- > name beyond what is necessary for interoperability. Instead, it > delegates the issue of registered name syntax conformance to the > operating system of each application performing URI resolution, and > that operating system decides what it will allow for the purpose of > host identification. A URI resolution implementation might use DNS, > host tables, yellow pages, NetInfo, WINS, or any other system for > lookup of registered names. However, a globally scoped naming > system, such as DNS fully qualified domain names, is necessary for > URIs intended to have global scope. URI producers should use names > that conform to the DNS syntax, even when use of DNS is not > immediately apparent, and should limit these names to no more than > 255 characters in length. > > And that's exactly how it works, in practice. > > ....Roy And the actual presentation limit for LDH with DNS is 253 (encodes as 255 octets on the wire). Remember URI names do not have a final period and the each label has length octet when encoded as a DNS name and the name is terminated by the root label (0x00) in DNS wire form and the DNS wire name is limited to 255 octets. The name "a" is 0x01 0x61 0x00 on the wire when encoded in the DNS. The name "a.b" is 0x01 0x61 0x01 0x62 0x00 on the wire when encoded in the DNS. An arbitary DNS name may be up to 1004 ascii characters when converted to presentation format. 0x00 has a presentation format of "\000" and this may occur up to 250 times as the maximum label length is 63. Add in seperating periods (3) and a final period the becomes 1004 in absolute form. As a C NUL terminated string you need a buffer of 1005 bytes to hold it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 5 17:11:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C615131545 for ; Wed, 5 Jul 2017 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hQle3cIdmY_O for ; Wed, 5 Jul 2017 17:11:22 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23808131484 for ; Wed, 5 Jul 2017 17:11:22 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 8C92A24C0D; Wed, 5 Jul 2017 17:11:21 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: Date: Wed, 05 Jul 2017 17:11:21 -0700 In-Reply-To: (Michael StJohns's message of "Wed, 05 Jul 2017 22:33:09 +0000") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 00:11:23 -0000 Michael StJohns writes: > That's not actually a plus you understand. =C2=A0 Mike Sure it is. We're down to the point where large changes aren't needed :-P --=20 Wes Hardaker USC/ISI From nobody Wed Jul 5 20:05:52 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BCC127977; Wed, 5 Jul 2017 20:05:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149931035067.22765.6562709307798083149.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 20:05:50 -0700 Archived-At: Subject: [DNSOP] Terry Manderson's No Objection on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 03:05:51 -0000 Terry Manderson has entered the following ballot position for draft-ietf-dnsop-sutld-ps-07: 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-dnsop-sutld-ps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for writing this document - I believe that having such a document makes future discussions much easier, that said I am not a fan of publishing problem statements in the RFC series. Given the document already lays out a level of dissent in so far as some people don't see all these listed "problems" as problems, (and I agree with them!) - they could however be universally described as "issues", where any particular concern or issue doesn't necessarily need to a response (irrespective of which forum or SDO holds the baton for that discussion piece). My suggestion would be to reword language portions to describe the information contained in this draft as "issues and concerns" and further because the text provided covers more than just the enumerated set of "issues" (was problems), may I also suggest a title change to something like "Issues, Concerns, and information related to Special-Use Domain Names". From nobody Wed Jul 5 21:36:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193C8129461; Wed, 5 Jul 2017 21:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=gmail.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 Vci55RV2p_rE; Wed, 5 Jul 2017 21:36:16 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 41B951243FE; Wed, 5 Jul 2017 21:36:16 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h22so4400569lfk.3; Wed, 05 Jul 2017 21:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=V8dDEX5M0XIia6gUEqiksXZFnKBoTQBiiR7LFzF8d08=; b=fFN36po4WTLFNsUR1emAnSQMOw+s4M3Asrs1YDZn4fnx8921WlYsJLWVM4B8tENehS mP5J+riEJjtkCkaxuaxGQFlFZXQHY6alxaO1MqvZ9lFg5zrpqClvEwSj7yxKzNPPA5YC HUru+1YnkMtw5FvQflmEusTNltJSK5sE/nmsn9evAZ3S3MDizdjCunuyPbscMPSgCTtj oEfZvkI8zozJlaqhqpdQZeftzcozvccql1l2TIYyNIuJjbY15e8FOJ9Ip4L48a7jE3Nn Af2xK732090fFS9FddlkF96RgK6dJoD0AwfLiU4AlMcBziK+egso+YiGLh2eMuOJnrfk CLEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=V8dDEX5M0XIia6gUEqiksXZFnKBoTQBiiR7LFzF8d08=; b=icAH8GGPEc8S7tFsBiO/Gu/zrLomkKzddbRoVBD0L85YYaGfFloaLO2WOYVFh7pqqC d53+G63H7oG62mBoooHgjbtZdlofdDWfCiqof1vlCSwD9hDwZcdJN52eo54uePKuxEPo 7SFZaPjJ6waNfKWMy4tSfHd9LQD7n/BjQRyGSoF0zH6MhnZ9WY/I9GixrGXGFW6OFKc0 w5We1U1X4EUPoBwrHJAx1KcEeb7bLqghcHyItntyZEhN6mwmGsDqmBsPrxY1yxAyPLxB Z/s1XQUFt8q2cn1SUVS6z0IU5xZEGD5rCKIzVCb3DHh9ZG6kew38yAahJB5eX2qTvbp4 K5+w== X-Gm-Message-State: AKS2vOz4nA33sjERjYXb2+8WMfMEGp06nmn2U5/T3V9pVZVgD+9Cielp bj22RekIzC/s6WYnmxKq7LdZ7y1Wxg== X-Received: by 10.46.22.22 with SMTP id w22mr14248753ljd.76.1499315774526; Wed, 05 Jul 2017 21:36:14 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Wed, 5 Jul 2017 21:36:13 -0700 (PDT) In-Reply-To: <595BE0D5.5000106@redbarn.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> From: Phillip Hallam-Baker Date: Thu, 6 Jul 2017 00:36:13 -0400 X-Google-Sender-Auth: 11VU_fcJcw2ddh7WhambWdWUxQM Message-ID: To: Paul Vixie Cc: dnsop , IETF Rinse Repeat Content-Type: multipart/alternative; boundary="f403045fb428259b6605539ea89e" Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 04:36:18 -0000 --f403045fb428259b6605539ea89e Content-Type: text/plain; charset="UTF-8" There are changes to the DNS that are practical and those that are not. For better or worse, I can't see any way that teaching DNS to use new classes makes any sense at this point. The only point at which it would have made sense was when internationalization happened. But the path chosen makes more sense. ICANN will manage whatever bits of the DNS consensus agrees it should manage. The only events likely to break consensus would be an attempt by some government to strong arm ICANN into a breach of faith with the community and succeeding or some really spectacular peculation. It seems to me that if people want to do anything new with DNS that they should use prefixes, new RRs or both as the mechanism, not the class which is limited anyway. DNS is not a full service directory. Nor does it need to be. A UDP packet is big enough for a link, a fingerprint and a digital signature. That is all that you ever need. The X.500 and UDDI models were broken because there is no point in putting information into a directory if the service can return it in a service handshake. --f403045fb428259b6605539ea89e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= re are changes to the DNS that are practical and those that are not. For be= tter or worse, I can't see any way that teaching DNS to use new classes= makes any sense at this point. The only point at which it would have made = sense was when internationalization happened. But the path chosen makes mor= e sense.

ICANN will manag= e whatever bits of the DNS consensus agrees it should manage. The only even= ts likely to break consensus would be an attempt by some government to stro= ng arm ICANN into a breach of faith with the community and succeeding or so= me really spectacular peculation.

It seems to me that if people want to do anything new with DNS t= hat they should use prefixes, new RRs or both as the mechanism, not the cla= ss which is limited anyway.

DNS is not a full service directory. Nor does it need to be. A UDP packe= t is big enough for a link, a fingerprint and a digital signature. That is = all that you ever need.

T= he X.500 and UDDI models were broken because there is no point in putting i= nformation into a directory if the service can return it in a service hands= hake.



--f403045fb428259b6605539ea89e-- From nobody Wed Jul 5 22:44:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CA01243FE; Wed, 5 Jul 2017 22:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.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 6mtrzMaUtiXa; Wed, 5 Jul 2017 22:44:28 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 4B1EA1200CF; Wed, 5 Jul 2017 22:44:28 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l21so3735153ywb.1; Wed, 05 Jul 2017 22:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uHVeNbNHoK29aRMz27nqKGVR+c6W6CgvPf6zqu0ydWE=; b=aJczYaxJr41VDyifvM8tZrEBTkbHgZ2+8M08FLTwK/NCQf+vi5X7SwYDJpGfOImZGR r105VsePH0lTcbwnNYkqAEnzrZSaJAbaMHH9TFCmLZVP5rxG9rfetT0Edo32o/1cvxuF 0VFBlP2Kn/uSI9/Dahg2GwiGPp9NGFohCyb386anc7rZJ2GLRxpxJSe7PcBymC/y9uCp MMKlWWstLj0SzjdtVKD2tLc5fPwDBJdZfS2mUaJjQcpqHe2CB+IdmS1HPPK/FYxP7o2a /eI4vP81Bzr9Gu4zNrR2qMVQrfqOoPQUioq1XEj/EjLgBGyZPv68/fdvhDzO3atJQ6es ZaVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uHVeNbNHoK29aRMz27nqKGVR+c6W6CgvPf6zqu0ydWE=; b=uhZ9KO7CCd72YaXkRrOMsLGFCS3MUgZu1Oo6z8De8WxG8vAPC878dUwS3QrGSGPKce SIbJZGaMPcW08uSfH/v9qVd5WtCXW+Yd+TjdOk9OnLmkhfkYlNt53Cy+zWLpsTXRzAJq tB/xuwctiqGgAFZOTuudRyWIFfZkgAPlkGRzvelFXdjm1uTy1g8w9zQa/8F7aYTPzyiJ MHtTZbW8P0BAkculrwq9kYXYZjFMcAacVNEqjPJFPLZzfBlsIBKb4iDCkKhmtpmzLwOj dbqWkSh0H3UQUWR/ORu7jDsvrn0MWcxqnd1J+h8fODAarDOxbbz+21n4jvV8txvQ3PDP 8YRA== X-Gm-Message-State: AKS2vOy4UA9i2AKTZXi/5WU0BL3wNfONERzYs8vdJGSMBBou1GMxo8Is Jf/gUwGJF7pWkTAAa7rbJrSf41YBBw== X-Received: by 10.129.78.80 with SMTP id c77mr36594565ywb.289.1499319867376; Wed, 05 Jul 2017 22:44:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Wed, 5 Jul 2017 22:44:26 -0700 (PDT) Received: by 10.37.91.137 with HTTP; Wed, 5 Jul 2017 22:44:26 -0700 (PDT) In-Reply-To: <81b46c8e-8667-de07-e564-153704d4b4b7@cisco.com> References: <149922136362.3281.8137557234349761847.idtracker@ietfa.amsl.com> <4D2C1513-BBA1-4551-B91A-4C8F6B63E200@nominum.com> <81b46c8e-8667-de07-e564-153704d4b4b7@cisco.com> From: Spencer Dawkins at IETF Date: Thu, 6 Jul 2017 00:44:26 -0500 Message-ID: To: Benoit Claise Cc: iesg@ietf.org, Suzanne Woolf , Ted Lemon , draft-ietf-dnsop-sutld-ps@ietf.org, dnsop-chairs , "dnsop@ietf.org WG" Content-Type: multipart/related; boundary="001a114dae1a1a602805539f9c1b" Archived-At: Subject: Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 05:44:30 -0000 --001a114dae1a1a602805539f9c1b Content-Type: multipart/alternative; boundary="001a114dae1a1a602405539f9c1a" --001a114dae1a1a602405539f9c1a Content-Type: text/plain; charset="UTF-8" Hi, Benoit, On Jul 5, 2017 12:32 PM, "Benoit Claise" wrote: Hi, Hi, Ted, On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon wrote: > Spencer, not to respond to all your comments right now, but just to point > this out: the list of problems is not claimed to be correct. It is > claimed to be the list of problems that people have asserted exist. I do > not agree that all the problems listed are problems, nor I think does > anyone else. If that's not clear in the document, that's probably worth > correcting. > I think my comments are more likely to be unclear than the way the document describes the problem set. What you said, is what I think the document says. I'm mostly sending comments about specific points that the document makes, that I think I understand at a surface level, but I don't think I understand the implications in a few cases, so, that's what I included in my ballot. I think the document is clear enough on "claimed to be the list of problems that people have asserted exist", and even if I didn't think that was a fine basis for this document, I wouldn't dream of suggesting that the authors change the criteria for what's included. Part of my AD review, I asked the text to clarified. Hopefully, it's clarified. >From the 04 to 05 diff: That is clear (and clearer than -04). Spencer Regards, B. On Jul 5, 2017 12:32 PM, "Benoit Claise" wrote: Hi, Hi, Ted, On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon wrote: > Spencer, not to respond to all your comments right now, but just to point > this out: the list of problems is not claimed to be correct. It is > claimed to be the list of problems that people have asserted exist. I do > not agree that all the problems listed are problems, nor I think does > anyone else. If that's not clear in the document, that's probably worth > correcting. > I think my comments are more likely to be unclear than the way the document describes the problem set. What you said, is what I think the document says. I'm mostly sending comments about specific points that the document makes, that I think I understand at a surface level, but I don't think I understand the implications in a few cases, so, that's what I included in my ballot. I think the document is clear enough on "claimed to be the list of problems that people have asserted exist", and even if I didn't think that was a fine basis for this document, I wouldn't dream of suggesting that the authors change the criteria for what's included. Part of my AD review, I asked the text to clarified. Hopefully, it's clarified. >From the 04 to 05 diff: Regards, B. --001a114dae1a1a602405539f9c1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Benoit,

<= div class=3D"gmail_quote">On Jul 5, 2017 12:32 PM, "Benoit Claise"= ; <bclaise@cisco.com> wrote:=
=20 =20 =20
Hi,
=20
Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon <ted.lemon@nominum.com> wrote:
Spencer, not to respond to all your comments right now, but just to point this out: the list of problems is not claimed to be correct.=C2=A0 =C2=A0It is claimed to be the list of problems= that people have asserted exist.=C2=A0 =C2=A0I do not agree that a= ll the problems listed are problems, nor I think does anyone else.=C2=A0 =C2=A0If that's not clear in the document, th= at's probably worth correcting.

I think my comments are more likely to be unclear than the way the document describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes, that I think I understand at a surface level, but I don't think I understand the implications in a few cases, so, that's what I included in my ballot.

I think the document is clear enough on "claimed to b= e the list of problems that people have asserted exist", a= nd even if I didn't think that was a fine basis for this document, I wouldn't dream of suggesting that the authors change the criteria for what's included.
Part of my AD review, I asked the text to clarified. Hopefully, it'= s clarified.
From the 04 to 05 diff:
<= div dir=3D"auto">
That is clear (and clearer tha= n -04).

Spencer

=
3D""

Regards, B.




On Jul 5, 2017 12:32 PM, "Benoit Claise" &l= t;bclaise@cisco.com> wrote:
=20 =20 =20
Hi,
=20
Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon <ted.lemon@nominum.com> wrote:
Spencer, not to respond to all your comments right now, but just to point this out: the list of problems is not claimed to be correct.=C2=A0 =C2=A0It is claimed to be the list of problems= that people have asserted exist.=C2=A0 =C2=A0I do not agree that a= ll the problems listed are problems, nor I think does anyone else.=C2=A0 =C2=A0If that's not clear in the document, th= at's probably worth correcting.

I think my comments are more likely to be unclear than the way the document describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes, that I think I understand at a surface level, but I don't think I understand the implications in a few cases, so, that's what I included in my ballot.

I think the document is clear enough on "claimed to b= e the list of problems that people have asserted exist", a= nd even if I didn't think that was a fine basis for this document, I wouldn't dream of suggesting that the authors change the criteria for what's included.
Part of my AD review, I asked the text to clarified. Hopefully, it'= s clarified.
From the 04 to 05 diff:
3D""

Regards, B.


--001a114dae1a1a602405539f9c1a-- --001a114dae1a1a602805539f9c1b Content-Type: image/png; name="bmhgnffkkhhgliop.png" Content-Disposition: inline; filename="bmhgnffkkhhgliop.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 18f81655d1aa3295_0.1.1 iVBORw0KGgoAAAANSUhEUgAABhQAAADkCAIAAAD/zFkAAAAgAElEQVR4nOx9O3LsONI1NyGnIxTj KIKG7LbktGw5HE9yx79jyBPtMXo2IEP20Pm20IY28HMrvQX9BouFzERmAuCjUI+TcSLuVZHEIzOB Qp5Cgs0Pl78hEAgEAoFATi4/EAgEAoFAIJBzlUb8XXvpCIFAIBAI5BalyjIIAoFAIBAIBJIjII8g EAgEAoHUlyrLIAgEAoFAIBBIjoA8gkAgEAgEUl+qLIMgEAgEAoFAIDkC8ggCgUAgEEh9qbIMgkAg EAgEAoHkCMgjCAQCgUAg9aXKMggCgUAgEAgEkiMgjyAQCAQCgdSXKssgCAQCgUAgEEiOgDyCQCAQ CARSX6osgyAQCAQCgUAgOQLyCAKBQCAQSH2psgyCQCAQCAQCgeQIyCMIBAKBQCD1pcoyCAKBQCAQ CASSIyCPIBAIBAKB1JcqyyAIBAKBQCAQSI6APIJAIBAIBFJfqiyDIBAIBAKBQCA5AvKoQL5emubl q3YrbkG+3x+ah/fv2s2IBB7AZY0+oMuTCVQNuRSpsgy6Bhn7tmn7sXYzbkGGrmm6oXYrIjnTZlWT NfrAaDqZQNUQyAXKGZFHXy9N05wlZTDLGcVg3+8PTXMerVnVFMPoII/K5GCDg5yuhddCHp3/3KNI /sA7J1WfSCaLHqSqYTPMRIbvjZkplirLoLQMXdM0Zx3jnFMMdkbaWtOUsW+bRiEgzpSlOdNmzTY4 yOm84lrII8sNz1uyB945qfpEcrDoQaoaNsNMYfjemJkgrpyUPOIhrra2/3q5sACupny/P5xLqPH1 sjzq+X5/uAKj1/Tcr5dL4z3OUfa14JrSnYF+RnNAmeyq7e/3h/NiYTLNtGYavRapsgz6+fkRIa62 th86LJ7z5Xy0Nfbt8qYM3aVF7YqMfVutE2PfXoEGa8u+FlxVujPQz2cOKJN9tT10Z8bC5Jlp1TQK uT45NXk0r43JMpmGESCPCuSMAkeQR3XJoytQYHUBeXRK2Zs8Oi+tgDzKlirLoJ+fH7qEJstkGkZc aihUR85HWyCPKpNHl6/A6gLy6JSyN3l0ZloBeQRZIOdIHjmb+Fkygrg4X3v5CnucaIDC9j2VRS7J tAJyw8P7d0FgxDdjFbfq5YvqhD+e0gfXJu9Xslm8w4VRD6n35UuQR1ZvWJMe3r/11q/xD9EuHu85 HqDup5sLPhZ5rCn+pEBdVp+olISfetEhiYtbSu+02iT+cO6zfrNC/k8ooWjEcG3Fc8vD+7fbOMMQ IueN+pnobpDcdmsGbrhfvnxlDZqNJy7RODlenKG4Sh9x2d7ElV+25lvbzqfeVE0KUM2kfnXNTX6f /iUjznaCchufXKosg35+fnLJI5JxIOMLlowg1tnztqZuCPexW9i+p7LIJZlWQMruhpLAiG/GKm1V 248/lrqS+mDaNJRpNot1uDDqIfW2/cjJI9v4tEm0T7T1q/xDtIvFe45P6vvpDneF5+bH4k8K1CX7 xJNz1FsWFB2SuISl1AdFN7SHTecy2mr0OOT/hBJKRgzXlqz7MGqdxiWbxXpHJjXbP8qarDQsMWPu N3H9uOPFG4pr9BGX7U5c+WVrvsUfZHNGZORks7ypmhSgmknX5dzkvptLnO/jhbtmgpyznB151DQ8 7OJBmiSDonXw10vz8hJO+DiWLRMZlp0Coi/uedlfL83iQzbKWvX9/vDyQnWipC9Z+pDacw8Zks1S OpzfbtbI7xD4RH3TmiMNwFqyxj/UdildMlkyOyaLrVKQVZNlpmXxoF/018vDw4PQSLY++MNWd+3R ZDfr+/3h4eGBzB2LE/YiVX69PLy8kJbyZicMIU0QbTXZb+dRw4krtZodJi53vKSH4mJ95IyIZTuP hG9tOZ/mTNV/G2byvrq+3x8ONiMWiCyzzZfTiaTKMujn5yeLPKJrX5GOI7NztANXhq7puvB5qFAk Miw7BcRY3LOyp6X6sl/VC1s1dG3XEZ0o6UumPqT2vNNromYpHc5uN2/k0CnRztzwuDmRAWhLVvmH 1i6lS+YuKTvu1q2Sq64cMy3cxeEWPfZt2wqNZOtDPGx01x5NTo+Hrm2DN65J2JOqHPu262hLebOT zZLkWhTB77TzyJkxae1bT1zueEkPxeX6yBkRyxgS7luqNse+bbvueBPpRdI/UlP1j2EmV5dDN9ss WIA9kDetQc5Tah2YbQThCjlA1snxE18vyr4HdVWu8RMvpatoMwbbbD1eElMpcVPUFEMfWj1exEVv V+7LZ0OUetU4ytIpv5netco//s5NGVlAHmnRX/7GkxwzLQrEE0UrjdQ0bJFH/GHdtdRnE82KPG0F KSNapTC3oYUpQ1Qkj+SAzyFdjYdLxBkvOUNxqT6yRsRi8sjYjkb/XjSf5kzVf+s6db+60j/HXFxS cJVlkBA7mpG/5bopbWPfxT88KwWrocrQlYYvma1eIUUxlRI3yaYY+lDrcSIudrtyXzYbotSrx1GG TsXN9K41/vGTmzKygDxSicv8jScZZloUiCeK1hqpG14nj6Qb6oNSDZXdHktPW0PK8FYpzG1oYbpZ 9cgjc8Zkn249cXnjJWMoLtVH3ohYSh5Z29Ho3yrBluG2qan6R9epr8vkzzHIhLtkOTvyyIzB1ASO aCVv/8SuSWmE4VAHZosSEjWtiDyKWqMkj+ToOXrWaZb2bG7amtHkfPKI8RJf4rf8xf5xrDPpGkvI I97Qgm1HaTNl1L2waN3KWeFuBpViPptq1jpSJvIRTh7ZPU4aoiJ5lFPPDhOXM15yhuJCfeSNiMXk 0V7zaU7Reun+V1eaPPp7nY1PL1WWQULMaMaMwdQEjkYuyY1wyDipu3RZba7EWePKgqKoaSXkUdwa 8ZnNwSgfy2hHb5b2bHaIojc5nzxivET0E/ti/zheTLnGIvKIN7Rg21HaTOm6FxZtWFnbyZURSmeT R8keJ1kaTyIfEeSR2eP1zdqPPMrRxx4Tlz1ecobiQn1kjojFO49S86mhyGL/0D9TSk/oMkke/WRN a5DzlIsijxbvDNnq59esNhTknsU/SBfuPNon2PGbVZc8Ilf4/paVO4fiWowdBkvII8IYFSVagTyS j68gZaJxGe08ukHySNy0+LxmNl5yagN5lE0eOYrKIo9EDYttfBqpsgwSsog8Wr4zZKO9QVltKMk9 i36QLtx5tBN55DarLnlErvD9LSt3Dik3Gkc9LSCPCGNUlGgF8ih6fDl5FI/LaOfR7ZFH4qbl5AId Lzm1gTzKJo+8ruSQR/z+pSnVkApyOeRRdgCk3bQRe5RJPaygUkrT1uJ8jSjNQm2Kl2aRaFbVtLVQ mZLAtNw/9GpyTyWZLviGm3pZsu3IKPUy0taWkkcZ+T8LSZn4xjhtTd6xPG0t6tsFkEclo0NtSQl7 dLlpa8XzqV50btqa+9VVTB6ts/EppMoySEg5eZQXAFnB/TbsUSZHsoJKKU1bi/M1orQ1awOPnWaR aFbNtDVSmZLAtNw/cm9dSh7NvSzYdmSVehlpawvJo/X5YZaozFcim3B52lqklwsgj1bmOJEuZ5Rz uWlraskZaWupqdoo3ddlKXm02e8okFPIBZFHSngXx3vm0jhavpfG8WbpWqsyC+Z3fvG3NiXlO/OA V0sf8lgaI/aLm8Wf/T6+qChL8vrshkxfL9M7hpQf7pf6h+YeRVE4u//7/SFSyPf7Q/PwUMphemYi jVoSiPtFywOzSwigNeRRolnLyaOk0/pHhCcMQW9WB0TSPzxhmmLH7qwhj1ZMXMnxkhyKi/WRMyIW k0d8PlWUuWg+zZuqzdKdr64keZRj4zkz7jw4pSrLICELyCMlvIvjPXfDShTfbZK2prUqs2B+53h8 T1WmZBzwmrGBJ/472Sz+rHjbVEIy++zFOGPftn2vRnqL/UNzj5KdR/yKdrTS0DX8COosyWEDFwbi btGjPDBbD8g3J49SPV6+8yjltFGPowOznWaNIpsy9umkfzjCNDWyY3dWkEcrJq7keEkPxcX6yBkR 2xyYrSjTVlHSbVNTtVm6p8sUeZQ1rR3y2pDSdnZycvJInuFA06H4Z+FOnpykPiyvRJfjqrPXyvqx E3R97labXfbD+/yy5XTTQoBKSjBPutAbxu+IwhO3WfTZl/ld4flhPC2cxtr6aSnafhejtqX+EduY VprwAF1natsWbRHKMpNbdXnRUwAqzOzVO9ecGsYZujSaRZ6cPgv35W57Y6V+hzeVBf8l9yjcpKWt qHWkbE1pxW6gGSKpjx0nLn+8KMWr/PBCfbhuG3e4gBDj82nh94vvtvZUnTEitK8uYX4yBZPZOsfG II+CyMN0SBg0fxQSfOjfPz/sQ/5wXG6jhu/O1fwm87rjUylKInladje/bDkv/6pxXy2d1gdveBRj uM2iz7bHd4Xnh/G0cBLHx7pULTWaL4Za7B/RZbkpJd0s0S29bYu2CGWZyau6vOgpABVm1p/jN5Br U0tCG+XfVqutZmXNEJndDSOnGyjfQ+7RuEnLELLf2jhO+UdJ0/P0sePE5Y4XrXiVH16mD99to/4W EGJiPpV0mKVJv1lLpurGGxHRQGr7kVKWxPnSZvoBeXS+UmvnEQRyY7Jkq1s9WZNmBYFcoCzbrwTZ VqosgyCQG5cFW93qyao0KwjkAmXZfiUIZC8BeQSBnEKKTsquLyCPIDcmII/OQaosgyCQmxY9UeVs BeQR5NYE5BHkvATkEQSyo9hpmucrLNcF8TTk+oUN00sYo1crVZZBEMhNipmmeb7CkmQQT0NuQNgw vYAxCrkFAXkEgUAgEAikvlRZBkEgEAgEAoFAcgTkEQQCgUAgkPpSZRkEgUAgEAgEAskRkEcQCAQC gUDqS5VlEAQCgUAgEAgkR0AeQSAQCAQCqS9VlkEQCAQCgUAgkBwBeQSBQCAQCKS+VFkGQSAQCAQC gUByBOQRxJbv94flrx76esGruiAQCOSKZdV3hCJVlkGQS5ShW/7qobFv8aouCAQCuWJZ8x0B8QXk EcQWkEdXKoc3k1+Veb5eTvKa9amarV7qfpGGyND0oV+X17cblmW+CPIIUklAHl2pTG8mvyrzjH17 itesH6rZ6KXuJ2r0tpLT6MnBrs7JrlqWTQogj/aTU5JHc9g1LzVJgJG9Yv162T06vBn5fn+4usAO /sHF0cda85+jqvdu0/f7w0IyZEdDVJFMTX+9gDzaXTZ0oPr2qrIM+iFh17zUDAFG9op17FssVLeS obu6wA7+wcXTx0rzn6P37G7+oVtIhjgtu0ifzWz02Lfn5yVXJ9sNRdjrrOTEO4/iHze/3x9K4r1z jFgvVS4yaE0I/IMLyKNNZbnOQB5B9hKQRxtJ/OPm0JX8bnmRgda5yjmG/ysF/sEF5NG2srjTII8g uwnIoyuV05NHD+9flC+KyCO6H4leoZ8vShthBZAHaR7Ky5fRAJaswpfX8/0P79/hvumWUNT8SPxJ orkvX7RBvL+sUVGBtCmsjdGTSgHhBkvFtIiH9y8Sv9gpKyHfhTzN7uFWZnVrD3MWMu5Svn84FWu9 Yiyo4wGxrmLDW46pPP3ylR0oJvUxlWQZ2tPH6qHo6SNpCH7HyxelMb5eHt6/V6RMybnA73Nel1ca Iu0fbrXO/JF0W08fk9aTqrbICNUD5ia/T/+SoS56vWxE2BX/nZpdxI8eVHO5jV72DUIvaw6QnMgL Jp9D07OVaXqs5nrZfltlGXSQoWu6gfFFkjyiaSFsHUv2KQUpibpYAeHBqEJ633wbS1YRy+v5/m4I 9x1uORZ1fCT+xG9u24+0Qaaq4gKdZoknlQLIDYaKWRHdQOMXM2Ul5LuQp/k93Mq0bu1hwULGku8f dsWaRnjmjqfqSFex4Q3HVJ5u+zE7UEzqY+jafjQN7egj6T0pcfWRMgS/o+0HQmNMlMbylClz8tHV meddKUMkG53wD7dab/5Iua2njwN5lFK1RUaoHjAPqn76lzRdn0cOV4qoE8v1ErOL+NGDam6+1HeN KMEeNPnfIPJJx0DGLQnv4c5RQh7Z3xGa610eP3oGUoM8+v7764XmrgkiR6zotZhlUcVROO/tfyIt FH/opzx8vz88vLwcPw8BjZLoIorzW/3wQJ93HtXPnvh6aV5eQl+Z+jKiLmtfmGjH10ujxCV6IPL1 8vBAW+plAkX25w+rut1k64msmNX0/f7QPDxI3Zke4HtPwjH501MsVsKI+BteGk6P2qrTzq9aquqM 0eRULPT1/f7Q8JHa8Bg/X1mKYaJ27bXzyDZEyj9cyZg/TLdN6OPr5eHlRQwKdbQrn3oeEAxKnN2e jctGRML1/Nklsn0wabLRa75B4j4ofKszg2ZPPgcyqNTB9e8I4Xr533lVlkEHmaiisW9p7hpjkugq Mz5OYfGv9CLfRB7Io1FYNCQVUXe8Fh66pus6QifMpceJLrI4t9Vt24o4wnpUPXvCbFb8l1WoVp9o x9i3SvSoByJj37Zty21uNSM6Nkk8rOp2iyhFVhy5Q9tG9ViqTnhPwjH500MXR56pjjg7j2hQ53ql dn7V0u0OOaPJqVjoa+hoYDrFszTGL2hjcvL52W3nkdPohH/4kjF/2DOEq4+xb7uONk3XtToHeB4Q ppJJLd0gy14xIhKul5hdpO2JSYMXhvbQylZ9g0S3KY9aGkh/7UUkVbGD698R3PUKvvMgQeqQR2TV Spee2iJYBF0LI1btse/3FzNGozGPujT/elF+PDZX+3L9nrs+1+61NaCrz/7RdzF5tCplRQkj3OBH 7j6Smye2IRf9iqNSFcMYHpDwnqRjrswj8TkLSZg6uosvLlN11mgyq0m5rNRWAdmjdCd+ei/yyDRE 0j9cyZg/zIkroQ+Fw9BcVfnM9wBylTzLd5ctHBFJ1/NnF5888hq99hskejKejfQHs1VNG7EZeRTx /lleW2UZdJB5oRlWrWTpqQVYYl28kBxQHxs6M4ZnMY+2NB/7Lv7x2PzxXQYO2etz5V5HA0pD7Wbp 9ysNULfCLE9Z0cIIuyGiquhhJ6BbJ6ygqH16J1RV+96TdMyVeSQJ8kgSprbu4osLeZSs0WRWnKg0 0lZ+IzMmn6LyMooPl8xGpycuVzLmD2uGSOhDIbE0V9U+cz2AMzLhv4zjWGiDlOslZheXPCIsSRuN 7ZXfIMluWF6Z8B79+2Iz8iji/cEelUol8igs1MnSU18D80Xn4og13j7XyL1Hxo4FNTNAyeRxdxbQ oCu/B5pGZARndeh4hxkMLCWPciNoc+eRsj+K7zww9Swf3pA8cirO5RW0qn3vyXBMfk9pZFdy1A6/ 1zeEX7TboNRo8ipO1Zn0j+wn9cf3Io/cLS0J/3AkNX/87e0t9PWRGMbhIzOd1hwRCfJo8YhIup7v PcvJo7XfIKmh6O5SsivWTbgdebRsZq6yDDrIcaF5XKiHpae+vOQr3IVLUDVzJMp60n/8VzMDGiXL x4vSWdBVkkulJTmxwswOJZu1mDzKjKBN8igqkX4WmUqQR1Ltm5FHdsVKf5V6dFUnvCfDMdk9pZGd Tx65unMNoTye3aDUaHIqTpk36R/5T+qPn+TMI7H7J+UfjiTmj0MNxt5CVx+pYRw+UtgrxwPS5NHP 0hGRdL2E9ywmj9Z+gySneW+Xku09hgm323m0D61/S1KNPJrXqacij9KPHdfNzi6khTUcGaPCX3bd 4E/L6Llw8ihO50hsPNuKPPIrXkkeOcrKcky3nQlZSB4lDeEX7TbIHQCJim+QPFqzk+5cySN/RCTJ I3F/7ohITuQ7kkfLv0EyhqJHHjkVgzySwvcZtf14MvIo+VhYNzu7kJbVEBijwl92veBPy+i5dPIo ysmIdx7tQx65Fa8kjzxl5Tim286ELCWPUoZQHs9ukPuYX/EtkkdrQu4zJY8cHWaRR7xJuSMiOZHv SB4t/wbJmeYd8shRDcijs5eK5NHEpLyfJG0tlz16eGcHMh0/Ty6oExUcSKOibUfhMdHKqYhYE6ci j3IjjOK0NaVBpyGPUhVnpq0ZUfiW7FHpA4s5i4Qh/KL9Fjn6SFWc6v1y8iibITwpebSSPcpLW9Mr SKetxQ6Rt/Mx1wOyyKMSFaXmrTLySP/ZQ230im+QnKFoe2XpYNs0be2iyaMDk9KfIm0tlz2SBzLN n6cX1IkKJtKo+OQHJ+1EpS9OQx5lRhjlaWtxg05EHiUqzk1bM4K/LdmjwgcWkkdJQ6j35LbIeS5V caL3y8mjumlrdqPXsUd5aWtqBRlpa+J6btqa6wHF5FGBilLzViF5pLZPTVtb8Q2SNc2b6vFVs3Pa Gsij1VKTPJq31bMoXR6UEL+YhrNPBRkc7sm7x8LfFYJH45Oykw7CEw+lK/NveeCtuSnhm78OiFZr V8kuqqcj2RGN8uKmvC0G8sBsI/L6W/GODHJgoX+kKuZ6mGyZSR6lvMd1TO1iKf1o6cML75KG8Iv2 xdNHhgdEZ6izw6YXk0eRajVVLyePFhoib+LyKrXmD61ddoujvzPPvc8kkMMHKR5m3Yjwh2LCe8QJ 2MQz04zX8m+QnKHoTORuxXnfIQm5VvJo3o/P6KREZCPZp4IMDv/k3bnwXuEFND6pIG1tfqJtS3/W lQfeGrHVz5yhUEYesZhm7FvjwG3l+ejnfs0SJnnED8zWI68fxTtyyIFl/pGqmF8fOuvAbFXVCe9x HVO7WEo/WvpwwrukIeQ9uvfo4ukjxwOis1TYcctLyaOcyWcFeeQYIslZpCcuu1J7/tDa5V5hf0fD WG9VJoEcPkiSR6tGhD8UE4ag9wrPTJBHa75BcqZ5Zyj63pP1HZISkEe7ySnJI3ICAw0F9PdH8/v+ 1m8o3rRBcyuVRfK3/e4efnxEvORuEkUXhdfkmZcvu8e0Tcf7SBguRc1S0Bqtn5UhgwH9mqaP+GAR o+Kor1/h9VnhkamwcKvpQAX+4VQc9ffh/ZvGRhkeYHqPVgDf7eAXXN4x+eFUYGjgoYKkPqyis8TR R7piY4rI9I/8ZkUclZRiJniJIaIOF1Trzh/Fbkt3HTHjRI+m5oCoaGmx5uWLESXBCVaPCMP1sryH 33Ro30O60V7FaUPkDEVrPnUrVh7Uyam0HlndWU5tSZVl0M9xwd00DV11N3FwGERbyNKDHIo3beSU ra6eebvcI1qMEkqYrvBM249mj2mbwn2HO7KaJUvQO6s+bhpKP2hDRGhGxZF1x/AmKvLIVFi4NeKx 1AspVVsVR9enPWScCvBVbXuPUoBgDtyCyzsmP5wKDA2cK0jp48f0ngzx9JGumCtFxPPhI8M/spsV c1TrbKEZIq/R6YnLrNKZP0rdlu06osaJH03MAVHRzbyZkv5NuAwys60dEYbrZRmC33TwzJapgLBK wnMXf4O407xxDxXXe8SDOk+coUdWenp2gWTJiXce3bCUpqz9/feajQ7nK5u9D62qXKNlINcm8FLI pUmVZdDNS3HK2s/Pmo0OZyvX8Qv0dfQCcuVyhfMHBHIzAvLoNLLkMInrDP6ugjxacK4sBHJqucb5 A3LdUmUZdOuy5DCJqwz+roJ2WXmOMQRyErnC+QMCuRkBebSvyM39RSkn4bEr4Fv+/lto49LCWtr4 K7EH5HrlGucPyPVLlWXQjYrc3F+UckKeuw6qgmnj0sJaao9Lazvk9uQK5w8I5KYE5BEEAoFAIJD6 UmUZBIFAIBAIBALJEZBHEAgEAoFA6kuVZRAEAoFAIBAIJEdAHkEgEAgEAqkvVZZBEAgEAoFAIJAc AXkEgUAgEAikvlRZBkEgEAgEAoFAcgTkEQQCgUAgkPpSZRkEgUAgEAgEAsmRSySPvl4u71Vdlynf 7w94URMEchSMCMj1yZpv1K1HRJVl0IYy9i1ed3UaGTq8qAkCCYIRAbk6WfWNihGxn5wReTS9Cj1j Hbo7eZTdkmuXWwqVJ6NbhicvPr9+3jLD/69MH4fupLuy/4jA5LNCsu0IoQLyKCnTq6Uz1rC7k0eH N8pjRXxLgcHB6Ibh/atXJhn+f236yJ58dh8R2S2BKALtLRGQR2cqFcij7/cHc6H69XImUdP3+8OZ tGSNeKq+VNnZRRKG/3q5kcg0U82Xo49ADnI5Nv98Bst1TD5rBuoaW5yPHa9ATv+FXGUZRGTozIWq c+nEMnRXsCIe+/byOyFk7z75hr8Kt8iRTDVfjj4I3cUkTDhnM/mMfXsmLVkjawbqqkF+Nna8ArnG b5ALEpBHulxH/HaNcRTIo5PIFZJHc4eIiekAOZ/Bch2TD8ijKxCQR3mXTiyXExU7co1Lf5BHJ5Fr JI/mlpJG0wnnbCYfkEcgj85ErvEb5ILktOSR+us/Xel/vTy8f5spMelcGVLBy1dZFMEejeM3Ure2 S5/27OH961CzyKKYy3h4/z5eep/+fXj/nsvgpTOVke6E7JZwB9dkQtW52jCCB6KPh/fvghiDKjKZ ItY0L1/HsvmTogCR7TO3n/Q4XfHhrjLy6KipqO68bI68ZpnPTb6qPk7dTVPI39xL5BXipbbvWOSR 6razjd5f5o/n8k8Q7WeSR6bj7zci/k5OPraZRMV0vDgjItMQrGDSIs31aIPdgVqgCrXTyfFCbKrY zJpP49LzjZjSR9zwbN/Qpvm42dn+IfvkjO+0EZMjwmiW/9VVZRn08/Nj/PpPV/pD1/ajnRIzJSXI h9Qbmm4oW/iSWtt+jKNiUrQSL7OedcMcv4gsirmMbgiX+m7+aC6Dlc4KJr0OqUXhDq7JWNMFcX46 LWmxqnnLtMfoHW0/HMv2+iRSreb2xxpTdCUrLyKPQrGy7kx9p/XhPXfwVfVx6m6KQn64TqIrwUtt hVnaUt12tlE//UuafoJoP5M8Mh0/OSL4BFLGYHALRuSRbSb5NBkvzojINQRzTdJrzfWoUtZMPsln k+MlqF6xmTWfKqXnT2spfcQNzx3m6UEuOxX3yXNMZ3wnDVEyIkq+uiBHObudR03DyRbtViNi/Xoh q9hp7ZsblCqP0hWxOBNCHhHBnj50wt7QwBXnVQEAACAASURBVKLYQzWktbQwUbA8XuLr5eEhfKJo a/WP8AaVwqv6emlKWA8m0WkbohdBReEJsyp5KeVp2sUlO4+EmeJe5EvZ6SPf7w8PD8IUcUseXl6O XkJUIrxJ/Pn18vDy8sDcWGtYjj5YyWFwBLdZrK0SySGPmsYce6QzW48If/LxzZQYL86ISBlCGkV4 pnA9RVsn2XmkjBf6rHDPxHy6xogJfSS+QVzh07xsZpF/WH0yNxBmGFEfEYlm2V9dVZZBRNydR3Kh ry1LjV/mh46sQad1ae4andc0HPkcclmsfmkDRDvHvvWyYXgUe6hm6OYVNC1MKkAcLzH2bdu2JBCW a/D1vxsb5MAKVXOJT9sQvQgqCk9YVUWXEp6mlrNg55Hip7Et8qTw9JGha9tWmCJuSdeFzhKVCBXw P8e+7bqOubERa6f1QUsOg4O4zVJtlUgOeZQz+ej+oUwg2T1SBhN92DVTYrw4IyJpCFGw9Ezueoq2 TrLzSBsvxKbimyIxn66a1nx9JL5BCkqOyvb9I88xzb1uOYbQR0SyWf5XF+Tn5xzJI0kl5EasK1Jo lBUyXfxrjSCPJNbXPnlEgo3w3zjQp0/bVEH0wI7k0WbZDPKX8FSDNyKPrIIWpa0pgfZi/ZTE3Brr Ip7/fn/Q41SlHhF2K3ustD0PypYFx22THM7+kuvUqiU2HxGJycc3U0pxLnnkGkLr/Pf7i8FgaA+c KG0tqmZ+9usl3onnz6drpjVXH4lvkIQos4lrJ1ZbXp82J49SzbK/uqosg4j4Ib3cd6NHagZ5tJjB kA+yNbfSYPJIan3tkkck2CD/jQN98nRnUwVOVQvFJo+2ymbgbUxv2NiIPDIvLkpbUwLtpfopspkS dMnnh07nMbR6eNitUJHa9gSvFPLswW3THM7+kunUuiVM8mhhD5SuU6smzJRQnE8eeYZQOz90jIdg VUcPnChtLb710Iexb6OdeP58umpac/Xhf4MUlsweTvhHpmNuTh5lNCttG8jZkUc54b+51BUJHCsa lIxsfYrHKz2bPDKO+M3aV2D3rEjs0IPn6ZVEXFE+BN/vkiprOXnkVUxvKiePIrKxhMXMapb5qOa5 otNqeRYzEnML7jOKPny3PWvyyBqo6Yf/XjoiEpNPwkyp8bKYPFKTlpq8DZXWBwXiOURqvHy/P7y8 SOJoalBiPv17xbTm6SPxDZISbyimhvF0b7JPW5NHyWbZjlllGUSk4MyjIvIoSh5b06BUZOtTPF7p 2eQRz7NSOpYkS3Yjjxar+lCm0aGcBi8njyJ9bkceSbKx6Hd0Rx/pRzXPZZ8ZLbaYEYVb8J5RSvfd 9qzJo5zRY/oHTx7L7Y2hZ88MKYrHKz2bPFKTljI3VNo9yxX32dR4Gbq26yRx9JMxn8p7iprv6SPx DVJYMv0sNYynv5KOuTV5lGxWGc9/s3Jd5JGoJnP5f8bkkd/NmuQRb0c2VRdbhXViP/IoUTF9Zgl5 RBijom1Huc0ynz5L8ihrv9e1kUf80dwRcb7kkV9yJfIoY7x8vz80POXyeGfZztSi3LIzJo/4c2qf QB4dZT/ySNyUG8OdL3nkl1yTPBLtyA6Xo3Qx1sb9yKO4jVvuPPohjFHZtiNfH+mnz5I8cpzheskj cVOmD5wxeeR3oBJ5lDFehq5peMrl8c4iLyvKLTtj8ohfUR0T5NF5yvWSRwVZCGvT1tzWyKf1mFkj j5L9PBfyKD8uUxok09ZS9RWQR6RVqYppCxeRR7PLlG07ym6W+XhG2ppeXjptTV7PTFvzneE2yKMC pmJt2prbGmdEJAyRKrkOeZQzXuZ74h4U5zUXPODqI/ENkm6FvNWlD/3RZJ1Sduq0tdsmjwqChdVp a2418mk1ZlbjxVTJ50IeFag6VqVMW0vVV0Ae+UH4xuTR7DJl245S+kg+npO2Zu2V8hJLFAosN23N dYbbII8KMqDWpq251eSNCNUQqQ7UIY9yxgt5W0HUojI3K3nA1Ue9tDWttLjeGmlrII/SUoE84itV fjLFCvIoCqSzuaOoRPGeorhC/nf0a/g3O2dGnIBNSk6RR0rcwD5Ia8tRdZboOtRalRlkJRSt/DQu W82axDVNXeCbv+guXbFWfKr90aPNw0PZsSm5zTJr5Admq6G0UZ68wv/2T+k12k8+tdw2kzz60t48 uJHsQB6tGBEpH/DNlBgvzojIOkBcTqglaWvOQE2LNXFljBc+qzrTp/xglRET+vC/QXyRQ5HXlRrG WX3yNlSmjKiPiKTbnit5xFaqIzuZYgV5FEW7JSt/fu/I31MUFyX+jn7OZefM0IaJkhPkkd6pgrQ1 vq63Tr/xJO+A6HxVJxSt/Nw/yqNLnD6J835pmgbviLhIZTF5NFXflp12lNSHL/IsXX0fhr2Jw6aZ Rn6irRrCmqU7bptJHs3pQyu5T122J48i5ZScnpNwTddMqfFij4i0IbROFaStrZp8rGdzxgs/FNye PuUHq75BEvpIfIOkSvYGuesfmY5pNyfDiOaB2b7bgjxKSw3y6BgaNjK8P8i0rvwWrz3+Vo/hYHES l6Jfmenjhw0kjeAllErVHmknDZMHDxHPA3tJMgmDvtgb50TJgoayteWqOiX66SBGk1R92CIULbv7 d1rXsgT90sv84mwSGNsV+z1OuB7TWynfkdaH++zLl6UPrdGmY7KLwRnJDbaFVH1obst9lgwxbijy +MbkkbSyNrynz8Kd8m9HY5YukpKYfNzJJTFe1BER5h7fEMLOynDQtaV3q0Ahf9sTlzteuObUZhnz aXSloM1Z+kjNap4mxFDMHMbJPmVNa5YREyPCaZb/1VVlGcRk7JV3+IajGUL6D7tFP4ZD8DLKlTyh pU8bSBrBS3hF89qNSLgh7yduW/r+ZBoGHa5T7snv7vRRaGDEYxUrJNYl69U6VYsWie7KOwrfec2d aKDvz5JOZ16Me5zQB9dbKd+R1of3bOhJpA9lvNiO2cT27ei7tKMDwRP60NxW+CwZYswW9PFtySPZ bm1465NPoseRqot3uNAnJSfiTi5R7Rkjgkw+viF4yflTtfL4ymFhXuDjhU3barOM+TS+UtDmLH2k ZjWndGeQxw13ptLkVa10o+L0HGA1K/erC1KJPIJArlDKUta2qfCk9UEgkFPLmvy/y5MqyyAI5Oql LGVtkwrxez0EctWCQX6zAvIIAtlGik7K3kRAHkEg1y4gjyAQyDpRjgnaWxBXQiBXLhjkNysgjyCQ VSKTP04U6bFqbym6hEBuRljq100QxVWWQRDIlYpM/jgRgcSqRb4HBHJ9gkF+0wLyCAKBQCAQSH2p sgyCQCAQCAQCgeQIyCMIBAKBQCD1pcoyCAKBQCAQCASSIyCPIBAIBAKB1JcqyyAIBAKBQCAQSI6A PIJAIBAIBFJfqiyDIBAIBAKBQCA5AvIIAoFAIBBIfamyDIJAIBAIBAKB5AjIo2uX7/eHq3sZ19fL 8lcPXaM+rlBgJgjkBqXKMghSSca+ba7tVc9r+nSN+rhGGTq8XgoCgdyw3AR5dHir+Vm+6Ti8i3mn UPnCovAsfeSQR5bRz1Yf7K3cq1s4lXaWHc2SszXTtpJhpt1niK2lluud6TR/ps06V6myDKoq0wuP z5IyGPt23zcxXxhZkqWPrD4ZRj9bfZCeb+AMh9Iul365DfIoY2bafYbYWqq53plO82faLMj5y3WR R9/vD9Ya3bl0DvL9/rAo2vp6uZCIslCW6oPL10tJzFbTRb7fHxaGl44HXKtzXJnkmWmbEbGleONl pestHopnOs2fabPOUaosg04iY9+aIcvQnfXyfegWRVtejy9aFuqDy9i3JUav6SJDtzC8dDzgap3j uiTT7TYZEZuK0/CVrrf88TOd5s+0WZDzFpBH5yEgj7jcIHm0sG6QR5cuII+Kit7nwX3lTJt1jlJl GXQSAXl0NXJ75NHCukEeXbqAPNrw8TOd5s+0WZDzlhrkEc3PIUvqkO0QbshfcbOkH+Xxaflup4Ac kgsW5IfMTz68f4dm0IbnFG2EhrxXTBusVLV0s7PSALSo+dZl+ohKim3N222VbOiDPKy6Brl+cKTI wdRaXe85Xjw+Fn9Sqhf9Upm+kx7w9fLw/u2obDcbO26bHi/JNK3k/MHu4rVzB8mkOLSZSR+M5hzg ecDUigzXVhurG3Fu8vvLXOJ83wb6SM+2Cdfz/CNZtCuJad6sOMOpV35HvHx5rs0apqbaahWHjLhw x5kxjMVSZRlEhObnkCV12N0//a9pSlIfwjNE6OND1/ajkwLCCiiKXOYnuyH0jYUKOUXroSFPZeLx R0aP9QdjA9Ci5hKW6UOWpNiat9sq2QiVzT7F9XeDII+cZ7mexV3H546PxZ+U6sW4VKbvlAdMIbjT 7UU2zvAez22T4yWZpmXMHyJbSh2JwkEyOYpQMqmalcsqo/1TK46utP2Y7rZFHqlGnJvcT/+SWXUD fSTGy+EGx/VWTWu++NO8XXHGxLXuO8K3MWuYPz3FrV76nQk5dzk1eSSOMpEnm3y9PDw8MAKj6Adb f+dRw4Mr0Qwe+pSeUfH9/vDw8nJsemhIZtE5+wq0Y2Aywj296OhTqpF1+pD7fTwzWiUn9KFuKeL1 fB3D5tyiHe/h7hJX5oroo9rlnXYeUQ2IFp/MxurpReZ4YXeobpuYP9gzvFzFQbJDbT4zqR22++R7 wNfLw8sLKU3XpaoP14hfL7P1Q1fZA2v08bfvs67rxX1QqPzFO4/saT5VsevUq8bL9/vDywtty5f5 h+rjTsXf7w8PD+EOt8eXIFWWQbOIo0yiP9s2HEkz9m3ZUtjfeURX1qJokTS04FycoWu6LnQm/NKc WXTOvgLlGJiMcM/YfiMrZBpZpY+oQiclyyzZ14feJ1bPGMLmnGen561mxj0o8E3RR73LO+08EqGv CDyX29j1nvje+Jo5Xswq1MLEn5EyeLmKgxRQZm1L+6i6RNt1Ry2StvgeMHRt15GiDV2q+vCMOPbt wfqkq+yBFfo4NNzZeeS4XtSHBdOaU5g5zScq9ieulePFsbFsJW+Xf3X1dybkjOXE5JES6bI4QS59 C4MInzySZAkJMbSw7KV4+5FSd27ReUkpcf8Wk0cyJqGB01p9RMyczwMZrSskj3T+YSPySIvgMmM0 rdS4z3uRRzIYrmJjwzR+7K0WmZ4/EuTR4sBaMbjsltWnlAcoNITu38qGOc+I4Sp5ljZmZSZcgjwy XS+joDXkkTnNpyt2nHrdeFEIsmPpal+/XgIb5FccTXIXnqxaZRk0iRYU0BBEBhmFQUSCPJLhLgkx tLCsePuREktkF52XlBKFa8vJI6FretdafcTMnM8DGVuMCskjnX/YhjzSIrjcyFEpVenzTuSRDIY3 s7HtPerN6qYnv8eaB6TmjzR5tDSw1oJy0a2xb3XyJeEBCnmiNVT5zDciuUqeFdPtGqLBHy+m62UU tIo8sqb5dMXOxLVyvHg21lQz9t3xxwfv6s/q70zIGctpySN1XeuFtJuSRzI9Qs3QIlJYcyLNyi/a iuOiJI7NyCMWdUS/sa/TBw3Coqg7Kn4b8kjThLVBqZw88ndmOaIXGjV2J/LIHE072zjlthm8RS5Z UjZ/0IYVxdi6e0mm23Bl3wMyitZLTxgxSR79vUIfZsf09jvVav6xhjyypvmcik2nXjletP7Mn6l5 eg3Zv+ZXnOrxpUmVZdDPz4+1riXLY7lS3pQ8MotWMyUK34+TTLNKFG08H+WHbEcesahD/sa+Th80 CIuj7qj4TcgjTRNq1xeRR1xDJT/vq4XGjT3JmUdspK20sek9h5oT5aZ5i1yyxKXElFHv+50lhnu5 G1eMNshntet5O7F8I6bJoxX6MDsWdS9Z7bJpLbNNsY28iu2Ja+V4cWyspgAereFfzegx5IIF5NHq H+C9MrKLNvZZxAenbEceEW6FkyEb6CMU4adk/L3dzqO9ySOipJLUkPMlj3azcYbbViOPeGkFZNmZ kkd5e/ps8ojfX0yYLyKPMvxjH/Ior2LVqXfYpEXII6evyYpBHm0l50serV5u2+RRXtHGPovoQJAN ySNyhUf/G+jjWEQq6WKznUd7k0ekJwXbjs6ZPFppY8t7cty2GnkkSsu347mSR3l7+kzySNxfSpgv Io+2mdYy20RLynFMa+LaYZNWII8crSf29ClFgzy6Hjm7tLUK5NG2kXTe5zn35SQ3rSKP5gBJSRbc QB/zOa60xYqBLiNtba71YToGuMApU0lLmXU7jVpCHu1o46zOLSOPiuePxOv2Ct7Gl5e2Zs0BqbQ1 +Vxm2pqvxVLyqEgfiaIc18vxj13Io1zH1Jx65XhR5gxGU61gj0AebSbptLUa5NGmbEnm5xn35SQ3 rSKP5gAp2kizjT7afox4ljiIuoy0NVJc6akiVdPWbCplE/ZI8568zi0ij4rT1hKhdzoyp7dmpK1Z W/xSaWsmhbHgM62OLPKoSB+JohzX22hay2wTKSnbMbWJa+V48Wy8kj0CeXS9UuHAbI+nWEke8XX4 10vDMo2cNbYWK2yRtpZddDo0/D6+Wce851s9dMWLPr7fHx7e39W4eJ0+JlO8R09p7z/bhjzK05db tO09pMyHh9IoUjZWa/xy8sjxgJLjo7UPkqLaOMsMC8mj1PxBuxDVrCXXlew8epDnGHtjUTzseUDG Wdxm6Z4RU+TRKn1E9/Pxkr3pzfCP5FA0JP83AnN+0CeudePlm59qLXWvWcLxB/YByKMNRa7B+d9r F8KsNH6sil+0FitskbaWXXQ6NByOb9Yx71EPknGjj6Gb3sik7GlYp4+p2l7JZyIfjPwFWbJhZeRR nr7ydmLNbRNNGPu2aduiAFupUG3A8nd52x6Q2Iez3sa692SZYRl5lJo/WBdkzRH/U8KVjPLAbJXx yHGs6G9+4rGZFGnqwzJiijxapY/ofj5e8je9LZ3WDMn/jcCdH6KJ62fdePFtrFnCOUBdJtSBPLpW OTV59Lc844GHCJNMi9/vRW8fTrxi+Zh3FFVPbtKDCkPEc9rDdtH6eReaTsgLmaOw7HiLTB7yiqZP a51dqg/egNh0sr3svUx+ozVV251+mV/ZPd2QpQ/Ne6IbymMz3vAoTkxaKb90ss2Cf6SOpr1s7Llt YrykzWTNH1GXZM1R0WXzSnDWqOb0HGB5QPBQUrTdW+0O1Yjc/IQoIRpZpY+4dSwtjRYYu17GtJYe ipFkTPM5FVtO/ffC8RKUTx5Xtpl6ljAqzvpiuzCpsgwKwk9xYFsh2GfhvrJfw0PZNGpIF81PtSjJ S2qkKKGQflU/0UJEZOTTgb1LyOmx2qzo0fk2I9tmmT543+I4RrR3pO9lSugj2SehL0pOZelD6ltV ygKWh1ceRYJmh8tLJ9ss+EfhJtNJyjtmeI/rtv54SY0Ie/6IuiRrjosuCLKnkNzwD63RUVqiejEw GOQGsY8roQ/ViML8hCgJGlmlj7h1lLPkBUaut2Ja8yQ9zedUbE5cPwvHS9LGsmVWk+Kr23xnQs5V KpBHEMilSvnmHMh1yIXv54BALkOqLIMgkMuX0pQ1yLUI9nNAIJDTCsgjCCRXSk7KhlyVgDyCQE4g VZZBEMjFS3FeF+RaBOQRBAI5rYA8gkASIrOSQCPclrCUImw8g0D2kyrLIAjkUkXm94BAui1h9ofx IRDISQTkEQQCgUAgkPpSZRkEgUAgEAgEAskRkEcQCAQCgUDqS5VlEAQCgUAgEAgkR0AeQSAQCAQC qS9VlkEQCAQCgUAgkByR5NFfP3/th//7fz/AJtjVTAAAAABweqRWLH/uhL3KBQAAAADgDLBv2bck II8uEtWX+AAAAACwLVIrlr1WftUXtQAAAAAA7Id9y74lAXl0kai+xAcAAACAbZFasey18qu+qAWA q8Svvm3a/tfpqx66pulea3f/OlDNiMDJMPZ3Tfs81m7Gzti37FsSkEfnhP90TdM0/+j/W5M8+nxr m6Zpnob6gYTVtqZpmu6jdmOAv/4a3+7JW4LX+syhtKeP07X8JHUBwIXh46lpmub+bTx11akVy14r v+qL2rPH+Nw2TdM8DtVbcnG4adWBPLoCKEYc+7um8TX8qw/r9Z0MQarYsZZVbeuGBVcr4GrIo6Fr msaac/as+bYE5NEmGH7PYHyy8L/+t/3Jo8+ehvxB7vvP4w1nSR7NGJ5AHp0BPp4WhpcfT+3bp37p 8609GaHz8XQF5NH4dn+BY+Gjq0BMXCx2HBSOIarYKLVi2WvlV3/Juxt+9e1WtMVrd6MMyHpVb2gF 4M+fn9fuKgLdy8b43ObwNcPjTrTO0J37fqih8+gh/yqwHMMjyKOdBeTRjZJHMzdE4ufhCeQRUAKH A1r8IMijQoA8un6APDrKXiu/2ovdHQHy6BxUDfJoW4A8OgPUJ4/u+rG2EhItBHlUAyCPdpfTk0fj P/8Rtrr89q/xSIj8+4/5kyl7q2mapvt3fJX8Od3w33+1TdM0f/RTyaSE9p//C4TL4bZJBEEz1/j7 f37+73/9b7Jtw+90f84fA+FxWHdmYfUeC1QuicL/GM6KPPo42iEK9cOlZkEG2ZQTcXg2IqrIVSu2 t8ijgTyazwtMT7Vvn7xhvD3HOGq+J9wwJ9O1b59BM08fPzQ3iiTcxbwJbXbcL3L1aZBhZMIQJK3s vv8sjAYdQ9BLRW5A9BCEtmrqYCj/6JNxj8rTaoQVIvLINwSr+uljHi+TCY7tpA4wX3p7OpjvuOmP 1ct2AhL3OHzefZCqaZc1KxTQYfxx2V/q58zDVxpC3fYorewbItvBaLHBTKHwoCvHiLMV3qaSSQms 15YRqa7u+09tAvEMwQb4sd2DUvjmhvjo7t9GN1N4h4krtWLZa+V3+GdgzQoBT9gJPzzOlwMXIDI4 Dn82d/14vPQ8JSmQEnjYE4ptZH7TIelp+o39tZNt44kbPKIeNO/h4cprZ17ihbfP4zbkUcjXmBUl m017HV+l6j3qrSQGo10m3ZmKOnTTUoiJlKon8iiULGMb2t+mOCQOmoxKnhv2OAjVxS0PfZ9vYG7J tOGPCKFnLZB7jRVGyudXGfXAHV7RWDpbihorVBqyC0MJJRtb5qfa55GrXW25UjLRdjcc2UZtvMQe YoyXDDNxbXevY3+nGkJp8IE88g1tk0crfF4bbqxfa0ZE5kBTnxI2EvSQd5VOZWzO16pWmFM+V0v2 xLvKZ4DYQP6I4NYPs2iOPr1vn6Squf88DrRTw2Pb/yIlHH0j38XKcVtyYvJo/Oc/mt//E0iQf//B uZj/dL/9oz0yO//9VyuvErLp//7f+M9/zOzS//rfDnTPxOZ0/54oIbsoykwdG/P7H+Hzf/8REz1z UZLfsXce/a//jVU0/N5QDQy/EzrpQG+dB3nU8FBKhGH0z8/+XiFETLBcp6miEAuNb/c0/hF/0rBE jVVkcJsfSn08tff3omGkCkm7xNs9xrf79umpnTUTbvh8a+/vW9JH3k6hPalMdvMUyLGI1zPE+HYv w+NshWQZYqedRw2n6kQzaAj68VRw0NLnm7BCw5SZMISoeny7p5E2GTtzXWFYzR7+8dQcaAXqXcLT /hqeGlFRe39PBqlCTGyx80gfxcNT0z0FJR+7ucoQf/3l7mpJGCLfxJPPc93et6G0WPOmEYO5yRgk tkgYcb7nvns6jiNrd6fWX3vn0Z6GmPiduTSp250mrtSKZa+V32ENLRfrdBE8PLZt+GTs71hEFP0I H34VH5/bw5p7WoI/DlOocCyc/v9wv1wrj/1d2z0eP+cBHsHwGAWHzp6X1y6KuokGfvVtHNtss31m 7O/aNihQpp+IXuiduuu6ozmy9/UI3UpVv3btXfhkfG7L+uvvPKIhENe8rOi1K+WtBNEpY/XXrnns wudh2w7T/PDYtHetGfhFB9/4I4LaWiWP+OByAk7tNJaMnUc6Z6E4Of/zrg1uLwZInoO1j92xzDAt 8NEUm4lpgEwURx22VL28Yf54SZiJFTXF27Hv6UYcn9vukT6u55Gphljn83N1unXWjIgSyDZz3R6Y keMN/tVjU7sumO/YQWk1OSUqc7U/k+vW1DkpZ0S8Suu36mC3tOd8+yRULf0nfMmGPrKfcw7/L7Rw EW5LTkseSfZnYky6wNEQukfSQ0nyaOaG/v3HkZ05cjoaufO//nfemH//kUXcyFa55JHGQI3//ONw s3JVamAX8ohAz9z57O95HEWifTVYHZ6yIxYvV0iJZIzqIvJIja8+nnLjauX4HhrdZZFHetgmg66p /bN6FRqFRZVOgl7SEOPb/UJyJ9MQO5FHvGoS0muB7udbl9UGJVZngbdviFTekEsezZdI14IyNVWM b0/H0iQ7kOGKC6H1cXhSCcc1hrBLyDGEC2mF6dmnUJGk3niXffJoVvJH1wTm/VBayohzL/L2hcWG MN1vT0PQnkol7DdxpVYse638jBSM4ZGtudnamjMFPnlEWJKwCveIj9eOlzb2d5nETRRQmYyGykAN 3eFm5WoxmWJCiWBZ5BzVov6QXp4Lo0SbzHCSLDBJOh0+eST3mh17pMXAv/ouL5rV/DYq8LXzdo6w Vnm7BsT9/oggOkzEk2m/ikteSh4p+Sy0cEnx2PkvTl80EkQrZ+wfGQFk+7NGzLkTCN+F4Zopazuh SR5Jci3yc6Nrq3zeK2TdiCgF1bNSL3En/2pop7ptR/P28bnjpKfNcvpXid6MDU3WiIinx/xTqPxv n4Sqk78WSJc73r/W4B5uS05KHrHEMSJhJ45DD60hj1jiGBGWgEYfjDkg8WQmeaQmtR0fj0moE515 RGCSRzKV7BgqDFquTJx44kCk/6i10FhIjWmtLBshueyGVrVDW+g7j9S6tPYfH9fCXVE4yy6RuxtS hqD3FO0OyzLESc48YuSL2uOsRC0tSNa33WmGSPV0MXnEX1enGDrytA3JoyglKmegrTWEbY4cQ3iw 3gNAGQ3TTP5VnzxKGnFunjVJpgxhhDwnCQAAIABJREFUkUd7GsL3tN0mrtSKZa+Vn8zQOYrYCa+t R+eV90LySMnfaRolV8talPPt/U20w99cZ6uZVsfHtcBsszOPosiBREf6QSoifMoLhxKFxPqRN2xK HvFLwZ3UPKwmkyvUWyh9VTec9qzQQOScnDzyRgSpxYsnDeYocs5tyCOVbiB6cMyUBz0CjwfprE49 p0kSo5ql5qYmx0vSTCL9x3CzLPJRbapiiFU+n21Nx45LpzKmq6bxviCmFs4m9q/an6iVak5Ch6o6 dTtXHdf1J64ky+/YTu2S2I9pqDo5/E2fLzZ4AW5LTk0exTuPxL6bvcijDEbGIo9kbl3BzqPxn//Q c9+Mci6EPNrwgF6WD7WSPFpzpuz5kkfCLs1iQ2ipNAXaOAvyaPkJvudLHvkl70YeyZSu3IG21hC2 OXIM4cFhZ9Jm8q8myaOMgWA1L8MQDnm0myFWk0ei75kTV2rFstfKL+NU1x3Jo6W//GsZPfk7j1KH uYI8Ohl5tPzc3z3JIy1VZGPySM8Li/KMNtt5VJE8KipHjOt9ySPRfuMon63Jow3Ouj41eRQrJzpn J2rhRuRRWVadnwNoXD05eeRNrb6qQR7Vl9OmrSWZkTLyaPi9yUxb80kcnzyKiaGCtDWfLzvntDWT PNr6HVU0plqRthYlWRTroSRtLW6ARx6tSFtTSqPnAZUZIl9FVdPWLPIogx2wsTptzY3SZSyt0lJq 2lqq5L3Io7i/+eTRKkPovXB9IzdtLUnilJFHxIiJtLUsEsdQWo4hzLS1PQ3he9peE1dqxbLXyu/P dDhRRh6R6ChBHmW9c8cIPpXlez55lMyUyUhbC6f5FqnbI49y09aWBJ/ptLUK5FExs2C33+qm4dt+ 2locB25MHilpO6oVTpu2tgt5VB7/Mw9fmbZWQB4Z9rLT1pTDyHLS1lb5/Ix1aWvF5JHKi22etqaN iPLpzv8txDqFqow8WpW2VvztI9PWXIWAPNpdTv22NXlwtThC2yeP6OHTh0y0TPIoPrg6bolFHnHi SdSr3fPff7XkBnlGOG8J4b/+3/zSN4WrapqG7X7azigLyCPl1F5xAKoDebKsiLtk+GdEZXpMGxFA 8enCjh74gdlKCgY94biJ3i7kkUf8wGyuTBn+sXIi4knU4hoiMkoJ2ZRliMXkESuNnwXjkUe6QnI7 FXla04gDs21DKPu2PjqSCUibIUpOkEdKF9gYSZJH3KysVSu0EXqtM1NrDBFpm58XljBEqthoeslO W3OMmCCPUkZU+1ViCEb7soOodjSET1PuNHGlVix7rfzm5Wz0trLsGIzuoeCvrEqRR8r+i6glVqzF gw1er3rP8Nh4B9zSlvAFenjzDil8+rD8rFmXPIrjijjSW7pzQQZIopyV5JGjap+ViMLIkuOlZMCp RGVmqMyeHZ9bemA215V4pWDUBa2P84MG7ymTtvStWKrjxdxK3EHzwGx5rJV3lspW5JFCAFENaA7A lc8PzOZsiD9eXDNprSrZedTeUUctODB7nc8rSmCfLx8RHng54U12pi8xYt2/qrfcVg4znPbNZZ/W V7S/yR8RTI2Tl+aPF+/bJ6Xq+C0K7LgokEe7y6nJo/87vlNsliOxEs4VkgcVRe8jO9A3E6vS/v4H /fBQzm//GqdXmzWSb5qFcDHRkUaCwZnKkfWyTUO0cIv9IY00H1TIqX3II3lOB4tG5pZ+zLHKJOxX evZw9q/f8bkk8a4c66p+pgkLQvjJR8Wn/Dgvp+dqmbRnn3hCmj0FqPR0EsnC8BNPaL3xmSbqkca6 IaKDVAozXGxDqF0u2wFBS2AROKsudCFErUInRXuvhH2nP4NabEMovRb9Jc55NPf9fXg76tvn3PKn 4S/mP7E+BU0ZGhPaz8yx8MX2Qhv8PXfKwTTCf9YYQjyePyLSELMEoUKoLajO5csfhUKeOmaFqZz7 /nNWoOCbFENoE5d8RZppCP2evQ0Rqpv8PHSBTKp7TFypFcteKz+6JA1CjjQ+fvQ8/tDjGMQ7j8KH h/Vuy94WTBbBE9FDEqZYxVHQzsR6/3eoV1Iz+rO8a6I7yoMROTU8RnUlEb1JXXuJuP2eZu20lKKT s63Xz3Pz0YpK6ANN1eTwjqm6oPPQctGv0re8kUf9Q4tkd+izj0PM4lElE64wOSL0M02O/dWOceFB KW2VeFddVEJivLg60Zpkm8mG1iP37eP0auzVkinoBu/189Z4SZopVpd8JVws3esPJRNJx81Xy4d2 C+rW7HKBwydLLhsRHqQJ+Fu9hMa6QbIezlVF1YLKEQ4mX75m96jwatM0B1vkjAjaqu61lGx1vn2S qhYKyfuyzm9aOW5LKpBHwHrsaqabxOJNNEmkXtQFAAAA/Pz1V33yCCiB8W4g4HKx7J3lwL4o3QEH AHVQulPv1Ni37FsSkEcXiepL/KsDyCMAAIDKSK1Y9lr5VV/UXiL8Y1mBy8MmJ9EAmwPkEXAJ2OYc 9D2xb9m3JCCPLhLVl/hXBZZAsSnRwzJZ1r4XCQAA4LqRWrHstfKrvqgFgDpw3hAPnAFYBhaoPeDM wPzz7CnOfcu+JQF5dJGovsQHAAAAgG2RWrHstfKrvqgFAAAAAGA/7Fv2LQnIo4tE9SU+AAAAAGyL 1Iplr5Vf9UUtAAAAAAD7Yd+yb0lAHl0kqi/xAQAAAGBbpFYse638qi9qAQAAAADYD/uWfUtyUvII AAAAAABAhb9eqb70BAAAAHzUrh8ATo/bEpBHAAAAAADUh79eqb48BAAAAHzUrh8ATo/bEpBHgI3x 7R7vCLtyfL61zX3/WbsZwJnis79v2rfPPQofnjZ+uSFw+fDXK6dZA+73Bvpffbv8fUlDh5dhXTzG /q5pn8c9Ch8em+Zx2KXZ+40I4CpRu34AOD1uS66EPPromqbxY+CP4/vYESrnIos8+nxrm6Zpnoad GzM8NU2zVxx7UpU25xQzl5NH12GIGvjs78M7Tev6QLYRF5FH02SbmjrOiDw61SS2Lc5uMtlA+f56 5TRrwA1C5aFT36u9P3k0PDZNsxU9QV7ivhMrUYrDa6Fd67x2Z/xe8xR5FBpf3H6QR0ePPQeOdXxu vYEzGfquH2u3swTGtBbjPFpxepDX1p+DDwKHUTjbZN857LbkSsijv37++mt4yomBP/t7kEeb46Pb Lu4a3+67D+Pqx9M1cBYfTxcR712mIT66vfbKffb3q5x8eKrBuDmW2teI+xliJ6y173JDJPH51loz hnPpknD8BvHXK7WXoiUY+7s68c343G68t+W1Oxfy6KDYnCCgmv6X41ff7hLfZGrs1Bif2z0i7J2K XQJ/4Pzq2wsjj35yh9X6ShpNQs3D41kP7uER5NEZ4LU7KT17WwLyCNgAII9KAPJoR5wzeVRj5gF5 lAuQRxUB8mg7gDyqq//l+NW3u+gZ5FElgDxaXMnssESFlDACeQSk8drtlCKs47bklORRyGX4CFtz 2cJ3Tuu4fxvnxAqRSnDYqN8oORdTbEZuUCMBizxiGSXHkufkjrepwd3HsXxe+GHj/eHZTaLEkJLA C48rbd8+f44q5YHEcMzVa5pABHyQT58+eN8PLQ8P6hEgeeRgUKqQD7r12iQgLA8RQnv08dS+fTom pv0tI2jmqrsPoVi1baJe1l+lXmFBQR6Rq1FOJTUrGx2Z3aFdOOrtYBEnkXO1IVKgGrvvP0QATK+G krURQVvOk8LUrtlGPHrOpBzrTyr5jq09zjUmh2T87NMQLJg3vTC/OuqDOE/CiMEKYqZNGWJ+fK4r qoJYSgyWkMEU7ok4F96wvBQ5zRCivwfyyJv6dDMdmjr7QzROk4bIHSlayyfyKHcszw/OSuuf5r7M jcz2aj7caHeyjGh9g/jrlZ1Xf2SPuwi2Q6bElBfWNEpCSrjUdIOIssxcKvoje9v/4olLUxXJXAjy SPcayCORODP3jjZgYO7lpNgUkRohJYeUz0qYP38cggZ4IE3zDXgEcIgsg7b1CNyKctmuhmPJc7pf 3xE1ap6wGEEVSkBDTGz02oGXXUh8Mkh+XGuPiPiGtv81dJlsyKs2rYnGU52UkCwH8sjOXmSpLGX0 TWq8kDa3z2M0cPhwYORRckSwqmML+oZwr+ojQnOhaFqzkK9Ry6NzyCPH8RPaynfP7jWiXuMZOoJF HrHhmD2nhlxkPtOz9hxNOt8Tbpi9sn0euaPlTNWy2XG/mINIAnyV2+abSbZZm2B2p/NuS0698+ij u7+nZ6yMb/dK/HD/1B0P2iC/rIozMqI/77snUtrnW6vEtCp59Nnfs0UzK/njqTksqT+65rBKZs3m FQ1PzWbHKn2+tff3ovA4kGufno4qJbtFxGEl8Z9RXB3HM59vrRLkcHUdgpNjIz+6KKQv+snd3/DS NME0wnmEchac9j08Nd3T07EvgQQUynHPCZL1Ku7R2F760cXx28dT8/TUEdInR5+6GpV9CuZevMWG SEF4yEcnFUKuxn/SEaE4rb3hJWVE3gvRyL/223kkHEbz24+ueerCpFSyqcfdeZRjxPHtXimhyBD6 NGJtwfvs7+/bMMPE3hL+HJ6a9l5rXg6kA3z2908dnUN4p3wzRYMlstF+O48awt0IQ3g+H8Zd+M7S vzSz3IyTcb4RnW8Qf72y69KPLXiVUHl4bNtwYM3Y37HV6PBI4q7Daj2OsozQSwaZsvBjFcr6l23N P4RTrCV8We38ZD8+t3osvWTn0dDdtfSAp/G5VRb4j104yIn8TCyO7+F/jv1d11Ft68kJqqoVq4WS X7s5whi6ORpTmr0O3r6wlTuPTDOt33mkjwiunKC0fFWY8Zw4Zank0KXxue0eqUsMneOHK45zkuOF Zx0eQmqmH96MWF3miGDPxidn+YZwr7ojIndai7DG137yyCNKB4hOJLSVgDKhBqsKm1tTpjpVM106 063Rqvaute2msIWiAeNz2z52xymZ3OBP1UJ7UpmKgxguX+q2PrIMgZ1HO8rpyaMo6pbL7s+3Vv39 U1tA03hMOX5VCU60UFlb1o9vT0fiYL5KnqWNsUKj9dCW8iIEHd/u9X0fSqdY9BszL7rOo64pnAJp p8o4DE8FAUmCs5Bb1eaS1fjq46lg39PkQjpZFrf/ozPpEnq/8izVvEYofPZPMuxcQkd+vnWKV8e6 XUoeWYZIK9nri3JVjDW5Yyjaq2XulUsbcTaNMk3tRh4pDVaYiMUnlPvkUYYRTfIozxDmBKU04NgM PheRLsQ+ueYkKV6aQnOTvifMVJM84hURQ/g+z7aGke+4hU7OHaDMiMSd/PXKiZaBFnnEQxAa6iur VLFwPi6f1dCL32zks2gRifJbrVzOZ5NHJsuwjDzSdnyw9r92eiCqcSik2UosqDEymqq1YGJ87g63 havk2a1Tya6MPFoTnNnkkdbg7EBQiSPDgNL2Nvzqu4W9oO1U2kyDY2XcxaSnMSJURQ2PjNJwlONd zR0R1BNOemC24dRyLiRDJ6mtZTUeeh+5j1FdNFWrg/u1y90OozDk1OOyyCODJnWnasUFmKc7CXor 3dZFniFAHu0oFXYeKbkAMhtLC//0UJY8q8VmcXVKqExT4dgmN7nRwyCP/uKpARsSSVrMIPSgh3ZG pMqepeGf9YOzZgtdz2G3jqrLAu6j5KgdEuqomVaFIbfOoOmZI8zQUa/JPiw1+eVgVjXTqlFympYc azJXTdhYnataRB6ZhkjAv1OlfjyKMJs8Shvx2GvDXfchj1ROQXZzxZliBWceFZJHaUM8dfdu9qhJ Hkn/96iNIlImmiU4eRQVfuxmykw1ySPTEL7PryWPou9NuY3LMKL/DeKvV060DDR3HrEldiJesXa+ 6KEXZXwkS0XuyYlI2JI8RR5FaU3bkUfJH4KNYnVOgTE7USMVPSiq5q/eIX2WcRLIo8iaxvYc6j+l gZpJHul6yM1pMQZjN/yppwc2TXEGkTZedIefSzacVtl5pDMlmpgD2U09i/Z+2CMie1qLsMbXLBWK DpmTcY62kh6ku4ZKRuhcdzRVq5ma+YNGq5ooIW/nkV6XN1WrvzXwwlnWo9zEts5ti7ShGALk0Y4C 8sjmX6IqbPKI37/ZK593JY8IV2KmHS0ij4o2+8RYTh6tPjjWJo88g0Zb3mjglCSPMmi1pV2bNnyN b09zOqdFzdwIeZTTwo+uuW91ygPkkdNCzRBN0z1pybCkASclj6KZOdp5dH3kUdZYW0AexcmV0c4j kEcl5BHbHGEEOpuTR9HL3TfdeXSW5JEXTIA8cqyZkdsVuVNaFRXIoxVnVLvjZV/yqOi8Ft8Q9Gpy y9Jlkkcbnm7D9rGtJI/WDe5zJY8o2K7Qbd02qQ2QR6eV80xbU+ONjLQ1uTrPTFvz885KySONgwhH zBapKy9tTY9JUmlrB/0cDis1KIzytLX1JM5SzmKDN75ZzJfLiKkEZW7aWoK4XKfS8e2p//zo7t/G yUC6056YPErQi+m0tYXkUQ6tGQaClgxVN23tAsmjqV+O9xaTR6vS1mL9x2lr8by9MG0tnjkrkEe5 E1c5eaTclk8eXW7amhmvrE5b+zkeYuEcsrNF2hptQPzsydPW1GIz0tYyAiNN1T53kEcehdNrF3nX FZNH2bcFVeyVthafvX2w+5p38PnjZaO0NdWCxQPQNwS5mjsi6LNnTh5t/XJIf8rMTlsrHByKHkrS 1uIGeOTRirQ1CepQG7stvxNpa5Wl9oHZyrLYpnLkUpjHHsPTfUsPrSg4MDveekMCiRR5FEUvcaQ3 ZSctObZGHJgdRyA2+yB7qt352d/f92/27gDzwGxxpHFDf9LXFFLSd2ZWftqLH+5Gp/aWnodix1pR F0JdCW0IHUY0YhSyxn67mI/7eDoeJzwdLaz1zt79tNgQPtSTqmkGJTNipN4EZ8Hu5wfuOEZUrsbO w9yj/CAq58Ds1NbLFeQRK+2zv2evAjgFeeRsbCwnj4Qqxrf7/AOzeUfEK9L+is54Vg7M9sxEb1Zf AOcYIg3Wa3Y0W8IQjs+v2nnEp8opPy6XPHLnTH+9cqJlYDl5JFfr4e1s0brbDr1eu+axV4/K1qqg T/GzpRm1QSMD0SremENGz4Y7j9gprOrvwrk0Gbtz7O/almqp4MDsmFkgVFQWeTTpcHkUWIM84vq0 jpryral0OQo6F7yVj5+Xyw5Bl2ovODC7vRMn8Qo/Z0Vln4meGi+ciBHvOpRdEK/IyrAgdxsxrh1D JMzkjYi8aU15L2GRc+X7CNVHYjK2tZU0cnSaEreqPPgu+8DseKKyEpRVPfADs5XcMXp8eBO9XMzd eeRM1XIelRtbo8FkHqctDbFq/sgyBMijHaVO2pr+Km71lcY83LVeDxwWr+T0GfPl8Wrh4gQH+Yru +7eRxhvkHTfReTfqnvzybUfHwICqJaYhmBS+Qn4uRHm9lyKWPp+GKHjgOilmzejjx7bJV2irrwnn Lc9njpSjmpQA3roqtBFxheIN3zK2FCcfcTosalaJMknoKMmO9IhYZYh0w2iPo3PutSZFb3wPhcQn 7mtmcowoiwp9lOljmpkS0E62iljORi9ZMVPpBhY6UZDUoYQR9cPLnj6yDME8XL6vXT9jTjbDNgS1 79NH0Y4e4c9TS9q3T/Xt8jGlbpspVumkE5klFxsiF2IOKRgRms+H0u77T8po5//OQb06fPOGL0ff iOY3iL9e2XXpp5+HMi1v5XvWw6kY0ZvO5qfoEn7QZ1vlt+n4fTPsSIlQgXFwSfs8yqiVv7Ocv6aI Nmx6D/exy8Z5KLlZP9NPw6L8n6hJQs9Gr4+Vhoid3GC/0VxVtejXdCmcvXHXjzT8mmrkDVgQkejn fyg20tvsIM9MhiGWjwhN1eUZYc47wHm/CkL/qSj+DnC3XwWElzdepB0fB8kQ0Xrv+pHST+kRIVyI XvUNkTaTOiK0kSimNfH4tuSR9Gv29ry5PeZk7Ggry4OoOsRw4SXTq+mpWti5+JQf5+X0xLmO7i/1 ozfbnapjD6L1xjOElsFnGGLt/GEbQu3y4h2H2bgtOYczj64ey96W9VciOQ4AAODWsSYdDDg7+OuV XZd+wJbIPaHmsmC/sggAgBm1678+7LiJ5jqn6gq4LQF5tD+iA5WzAfIIAADARN6R88DFwF+vVF8e Arm4yoiEnQcLAICO2vVfH0AenT9uS05JHrFslI3eR3a9YMkdt8e4AQAAaGBpgCvf7QicGfz1SvXl IZADlpuBfToAcGOoXf91geVnbfruR0zVW+K25NQ7jwAAAAAAAGL465Xqy0MAAADAR+36AeD0uC0B eQQAAAAAQH3465Xqy0MAAADAR+36AeD0uC0BeQQAAAAAQH3465Xqy0MAAADAR+36AeD0uC0BeQQA AFAH//f/foB8VLcXsDdSK5bqC0QAAAAAAACK2xKQRwAAAHVQnY65LFS3F7A3UiuW6gtEAAAAAAAA ituSWyOPPt/aBq92BoAZFzkiPvv7pn37rN2M9ahOxyTx33+1zT/6/9ZuBsijG0FqxVJ9gQgAAABc On71bdP2v2o3A9gRQ9c03eupqrstAXmk4KNrmubyIuqrwvBE3iB5/zaerOoPVvH1+MDnW9s0TfM0 KJ9fXDfPljxib5Fvnj5S96/mU4bf58p++9cI8gi4dKRWLJWWodPLktvn8QR1jc/t9q9kBoDrwPRy 8bt+rN6SE2Hs75rGj4F/9e3xdesnC5UvHVnk0dA1TbM/x3Qlc/7Zjc1i8miVIW5Lbo08ysVnf39x EfWCPkZUwkYYnlZpb3y7zwi8d8DnWxvTK1n46E7JcC3ER7ewd0AWhqdSSmtDimcReTT8fjbEEMgj 4K/65NFrZzJEzqUdmnHxgcSfP+Nze4Gh7NCdUfBz9thxUDiGuDkbZQ6l4RHk0eYY+7vtyCNnvPzq 28uf839+9e1FjM09DHFbAvJIB8ijVVhPHnUfNXTy+dYuJK1AHgEL3B7kEcgjgCK1Yqm4pgR5VAiQ R9cPkEcnAcijegB5VAKQR7cipySPpoSg+7fxkBcWZ3bMSR/3b2NIXGLh7vgW0kLIj/ykwOZpUG8L 6Uh6gEfypJ6GiDxiWVRF/MIhXShucy5o1e3bB2d8aJoMaXDIUQo30KpZd477XT+sZjNVHHU7FWj9 SSW/19rj3F60YZyvmZ+97z+DuXNJKG4m1uzgt8SNQ8k8U0m0OfEscd2nD+H/SUNkgLTtMO6I86RG BM3g6z5iqpEOuvv+48C7Ta51tLg6immn2rfPiHNh8wNnEsMlw6mMEaFNPqUEJR014lltQOXwdIHE OT72x/Dff7W//4dTPKTif2eSR//pmqYJGWf/OXR7Lnn85z/iJrf//F8o4d9/zB8bBFO4IRR7bG37 z/+RG/4Y4gaTSnM5rDJ7AReI1Ipl11VvPCLoOvi1a5/Hw7b2pmmabuAlkEvlW/dJ7e3zGJFHh9SV 6XocybCqH4fhse1/Hcuc2zlX0T6PIR3juZv7MlfB6h3IJE/j0pBKE6rmuop1WUCH8cdFPDzX2Pa/ wp30nqWGoEq2tJ0wRLaDkWeDmULhJLARiTOzRR6HbCOyfomQacrHnJyEKTZpiOR42dEQQ3fXj16u VsJMc6+bpukGEStaZsoyLjOi6HJC1ULbfLAcyKNwg94wizwi/Q0lzxk6/dTgw7SjFE4mgcdhG0Y4 5DexwpVKH4dgTdu7gldT8931I+/7oeUZagzuIckjbzRleAgX2qPJD+22Lf9+UWZ+rm3P5/lgVOrl FpTkkfUN8iPMSkdHriZpF2a9HSziTA6rDWHituTUO48+uvt7esaKkqD0+dbeP3XHM03IZpDhiRE3 4s/x7Z7Hkx+dEhXrW4pYvskhsg23iWyU8e1+8Sk8os0590ekzzEo/egiGoL8+dnf37f3x09ibdg7 j2T2lij5r5+PJ6KBz/4+jqX32Xn08dRI+kN04bO/v++ejgYq3F1l7jySG4uiFjo7j5LP/vXz8dQ8 PQUlfzwF5/cN4YHb5cAExdowNtlFJm5kS+hTH11DHPvY/vA4eZZ3anhqGlkUnx+0LkeDXdVP9Ced fMpSFMUpS/qhSwt3Hg2/E9ZmYlUCF/O//jfK6Yg/EzuPJCmj0FJJ1uZ//W/KPeM//0FPWRJ//vz7 j/a38Mn4z39Qdunnv/9qCZ00/N6Y/BTIo1tDasWyMmhJwt15RBes43NLF6/iz5/XLmsdHJaz4ebD MjqUJg5ukOc4KC0J692xv+PNIB0cHufF+ms3L7vH/u5Y+NA1Mmqiyhmf2/YuVD08ylBqo51Hst75 w7Z7bOdFf+jmKkNMvXY2vLiGyDdx9OzY37WtqfmfAxtISyNqd41I/z/fL1m8oWu6LnxuaUAzhD1e 9jYEZ0Ud3UozMUedIsljOxNF+RBG/Pl57aJg21T1+NzSm+M/u0damvSQY9fi1oqByUr+1bfEZ4Ij GRVN/MVGm5uG7q5tReHCM1+75rHrCOnD5i5yc/xnRHTGvqdvKVLcg02nydHkwt/wQlkM7jyrR9PP +Ny2j91R4WFyLvJ5Wa/iHraXahPIr76967o7Qvrk6FNXozJjmHvxlhrCw23J6cmjiNCRsfTnW6tG yFpgz6I1EQ1+PGk0jRYqy1iXt1MlFD6eluZVleQ3KQ2z9SYLjzgdP6S3tHq8+Yk3+0AuKMyRUUIB DPJIa7DSqcKtYRQVySNt+0+WIfJ1qNMlNnlkqzFh3yR55A2BrNw6lTxKjQg5+RRkRyojUfHG5eSR vp9oYmEkVfS//jdtI89JyaP/dFF14z//EXrx7z/4Ad68zUuT7EAeXT9SK5aS5fIS+OSR3NBxXEZr ge6vvsv6XTrid3iooFEwpLrEatsnj+aVPfm5+FidSv0Mj6G0KNiTStgsbU3p49jfqWHbGkPYJeQY woVkf6YuPB6flUGp8EOXPPKMqPrz+NzFW0uy9lDEhjDHy46GmCgY6tXUNEkzObldKTP5iIyo6MdS tdJZ0SkZwWr5QUrX1PnhtQtPv552AAAgAElEQVTEAWEhA3fJ4v8ykqLAvtrmGjEK9H0fWqeY7SLm RdO5Rh4p/kzamTWaXPichdyqRvYbrh1NE7OjmLLU5+n9yrNE88lvkEOvl9CRQ6d5dazbheSRaQgX tyUVdh5FcaMIzIzYUo/02LOUyNBJDTVU1komt31oKV4FqVhRWlM2eeQGtzr1Q8LX6IZc8kjNw9I2 rXw8qbtCfnYij3RmR3jUusOqau48UonOPENo0Eyg8jKmxlgKoUwvdduQ9DQ6pmK9sUw9vSKNPEqO iAxDFChTeXzxmUf/638LPaZEkkruMJqmCnmkUFq8cHlDRHjRlLd8IqlIt8AlIrViKVtilqPgzCPC y6g74ZvMH6W1wCAQVQq1xJaziUNnlpNHLNUlCPudma/LNySPWLKDpknjIJJVhrDNkWMID2oeVkNi Oc9MSi3Z5BFLdaEVC8OZBEHKEJb77WgI39NyzMTMESdj2mZKWjm6U9IchqpVNZJntaGkVKeEymoC aaNs9DDII2HKDYkkfd5jejCOftMnFvYsZab0XVrqHGLoOezWyRhNLkqO2mFDe+1ochi0hM9Hvba3 tf7JZqHkN4i4vwTHqgMba3BVi8gjyxA+bkuuijwiQbiZk7KIPFr+5q84vaVg51E98ignBv7s75v2 Xs/gA3lU8mzJLrlsrCePhEV4Fts68kj03aHDPt9abU/WlZFHgqwJiWlXSx5JIsm+CvLoppBasRSv MguxmDxafkro+ZJHflC0G3kU5U3oO48M8mjtca07kUf+bTuSRxlbiizyKMMQDnm0lyGUS4XkkdD8 cSvQyqORz5U8ciiGHPJI3L/Ze+t3JY+I55tpR0vIo7XHwy8mj1afQl2w/Yo/FR3dVUAepef/pV07 bPh67eZ0TmvggzzaSc4zbU2Nw5Npa6R8+53Z5Wlra95RpbS5LG3N4a0y0taWkUfWgTJCjYc9R8qp VZXT1k5BHg1PzWLyKHrWNHSGIUp0WJS25t6mdMEzSmIE+aVZGWpL0taWkkf7pq0pLMyRCdo2be3f fzSnSlsrII/8xD2QRzeF1Ipl3QI6jWXk0aqwc3Xamrf4loXTECKZ8eT/sr0XeRSbIJ882uDVSLuk raXCzkLyiJgmYcSs2Cyb0ShIW9vREL6nFZuJ620FO5CZtmbwdMm0NaH5zLQ1P++slDxSVRROvy60 b07amjoFJdPW/jwe5aMZJdirMG1tPYmzkLPY4I1vlm+7Pq8SlLlpa1nvDF2s0teue52aNxlId1qQ R7tJ7QOzlXDdPhJFBplayD2+3bdvb9pR2RPMA7OjNzrxVzVF8X9eVK+936rgsO1o4xI7EErG5LwX SfKI38+O3YmS/hjvIK/G/BGL7a1DrGx4B2azimJWYifySGZENrJHrN7x7b7R1aU+67CEviGSzqO+ gM+9zalXvgMufgffXDhtZFRvNHaYESNf0g1qH5jtjIgV5FHUDLUBi8gjfnr0xMLwE7IZd8OvJsgj elL14fVqnDxipf33X63yNjfzwGzWDNEAlzxiB4RPVFS88+iQ18arLtItcIlIrVhWrJ6zwNay/GAd jzxSzmRV4r28BfT8FiR6YDYrWSyIo0Nb2bkq9PzXKY8glzxSzsCWx6P65BEPHkoO1vG0cVS+saBf Y4ioZH5QSMIQqWKdQ3wT5JEgE6lCkkaMuh+H0wa/kGMIZ7zsagiPpnTNpLWKqNo3U7rB7MBshYUx qRwZw0fKp4fTFx2YHW+9CeM6RR5pziPrnWaVJcfW8AOzVWrSchjZU+3O4bHpnh3zmQdmi9PWG+9U b4ec0uCPF4ezWDuaHJLI83lfG9KfIxrR/waJFFKCX317104am0aH2jtzil5sCAe3JXXS1uhLvsVr mKLMSxmik2vWBqUmPjL5Q0385VRLKLf/jIJ8fvJRwX4Q+Wr5qSUFW5n4W8DNV56zVpHPpy6EQiT5 YpQsD9xhVAitLpyMI9PHqD6XdVZpGDuIh5WsnRCUn2+onWwVn+N+/HxqRszraapwn1XqjV+KZ2oj PdzYg5QV9UdErMy4Xl5CxB6SB6fSDv2KTByTUGqTLPfgVVsjIuh5qk66caEy40OgolZlccT/x15a fxDO7/z833866yo9OSgIJWLIaUq//+dQlzzK+vggZWr+o/sHO49JrzR8PlUUOngonz/Y6K9aA3l0 m0itWBasMguhvgE6HN8wrTjDIRTxO9dnKXwLD3tQrMJ5ydqhrey69abt8Dbux459GF40fihK6Tgr mZyUMXUztF/G7UcpOhmEaYO9/kY7pCNmNBYbQjwen1LsGsKFaLlyYJY8bSq0nCv8oJD2+KBvRHFq SRQNMpF5Q6YhvPGyoyHkK7SDZvT3tYtWxcfHqGexE21ln/IzMYD0cRFmu6qWY40SiwerEVWbRzjp hfOTj45nxNC6CLMcXmYXn/KjZXUt2Hb0M1NUVC0RDcE7VPgKefr+QV6voi3r6Ku2/xX0nxpNWVDH i7AFbSTnPYlkjybtqCbh1Y7PS3+WXKEYpGQW0rza/rosVibhvOSp2xkjYo0hLNyWnMOZRwAAALeI ZKIWQFHdXsDeSK1YikMUAACAE0A/deXKsfBtWT/5KZ8AcBm4LQF5BAAAUAfV6ZjLQnV7AXsjtWKp vkAEAABQcIvkUXygcjZAHgHXhduSU5JHLENn6RHUAAAAV4LqdMxlobq9gL2RWrFUXyACAAAIsByc rd5Hdr1gWWk3x7gB14nbklPvPAIAAAAmVKdjLgvV7QXsjdSKpfoCEQAAAAAAgOK2BOQRAABAHVSn Yy4L1e0F7I3UiqX6AhEAAAAAAIDitgTkEQAAQB1Up2MuC9XtBeyN1Iql+gIRAAAAAACA4rYE5BEA AAAAAPWRWrFUXyACAAAAAABQ3JaAPAIAAAAAoD5SK5bqC0QAAAAAAACK2xKQRwAAAAAA1EdqxVJ9 gQicC4auabrXXQofHpvmcajdQQAowo4jAgCABG5LQB4BAAAAAFAfqRVL9QXidWLs78i7s6vyJsNj 0zRN+zym7lwSKo/PbU4Hz4g8OrwD/sJeZ56p53PH9Eb5u36s3pIs5IyIw0gHx1QRh9FxkBMO7cNk MlcMH9gWtyUgjwAAAAAAqI/UiqX6AnExfvXtXrH02N+tikCGxxyyZmOMz60Zvbx2O7ZnR0PshLX2 XW6IJBxLXZ6ejV5cDHmUi+Hx+omD4bHtf+1S8qrx8ufPz2tXiY4cumaZTvadf64HtyUgjwAAAAAA qI/UiqX6AnExzpo82ivQcgDyKBsgj+oB5NFl4pzJo9Mz9T9//vz8OXQLPRnkUR5uS0AeAQAAAABQ H6kVy+5LwKEL+/rb/pUHwHTbP1mIhySdcAMNXWiZRrbCa2dcOiaUTQWKPw9JXrLo7NhGe5w1jGZY iJhnfrYbwm15Adurpg+q59eufR5J1VxXxAqipylDzI/PdYXuH6xJ0vcE8REymII1Iz2HS+3zWJL0 xNMG5SOH4C1qbdJMIkdpruX4eNIQDngKjNKwSc+hCmkIlrwjmnTX949zY+aKsr2aDzdl/HYDUXgU yZPHp9pzLKiVLMyUHi/UHKHZ1Dfa/pd2mz0iIlW3/S9JHumGWKnqPLCqHwfB+NDZiTR4qvTQkbhq nhSmWpkNN3bpqNupQOvPZb3WHuf2ovrUvyC612DubBJK+wJinjPXFZXsfb+knhUTDvV/tWEXT2je loA8AgAAAACgPlIrln3Xf2Jj/9DR2OC1Ywtf8eevvr1r2+MncW6CsxFD3PyrbxsZRIUV+a++lcdk 7LXzSBz9o50ENHRN14XPC37c9nce0ahsfG7VCE3fQFFkiNdOj/30z4furg2mkYZgzjM8Nu1du3CL gXCtP8f+ruuoD/BO+WaK9CxttOPOo4azQoJv5XQh6XIYd8Njc2BMFLfPdTPuAGN/17Z3R8+Jh3z4 80BD5Lq0KFlNUDLHi2inbLZ0yLG/U5xfHRFc1Ydw/Xiba4iVqs64X5I+R+WP/Z2kIainDY9tGz5R tGHvPJI3y2mNe1qc0rvXziMx7UffAgf7PgYDFe6usibn6OtDttD5fkk+O03IXXc0Vph+xdCTJr48 3JaAPAIAAAAAoD5SK5Y9F3/uWlxbQNOFchTcytJM8khdmg8dv/kQw+gh9D7kkdbg6M6hK/gBnCFB HslQWemgSR7lGWJ4tHkBizzi4RztQtydNSdJ8TYrYdX43EbBmP54TfJIbr05tkqLY3/13aEoRqkQ gmCZk4sHI6KBdEEZCAUn1GiEjtSPNV4UhXC7cN8z9kMpI0JxD9pO3xArVe3Cz2pU/IoVLgdXVJo5 mWseOz53copoDnv9tJt3IY+UBiudWnN8ez3ySNtVpKpxeLzk/LjbEpBHAAAAAADUR2rFsuPiz418 9FCHLMeT0YsZLKlJbUqQMDxGuQw5Lc+AGmjpMZISDC/fp5B95lEheZQ2RJfgvMydRxbtkuIWM7TB zS/Io6jwuZtJM9UkjyxDqClvjb4fZwF5FOXayG1cRrhr6LmAPDLNFJSvjhdVjfxZSmRYvKQyIrSS w20JQ6xU9VLPyZiRkrOrRR6pSW1KztSvvjWmiH3II5XZkR617rCqijuPdKJTkwqn722G2xKQRwAA AAAA1EdqxbLj4q8ieZQRcf3q24ZmamS3PAM3Rx41bfeop8IdG3BK8ijO94l2Hl0deeQxMqvIoyi5 Mt55dJHkEWmJ+dqsJeTRiuPAU6pe6jk7k0c5o3JKO1W5MJBHJc+W7JK7dNyWgDwCAAAAAKA+UiuW PRd/7nI2I21tIXmUsYwOqVjqWSd109YukDyaaRczjCwmj9akrSm9i9PW4qPBF6atRbFcBfLoz7G/ c7YYrCGP4gg5nzw6Tdqa2otk2loo3zoC7GdJ2ppviJWqduHzVum0tYXkUQ5fFkauZv26aWsnII+i ibGAPFImVUvh1nlzl4vbEpBHAAAAAADUR2rFsuviLzqjdHwmPz7LxS6PA9PRC7ufn14RbSWgQYs8 xEc9HZYf01u4+d85MFucDqMemL2Qt2Kl8bNgTkIe/Tj8Tjl5JFQxPrf5B2bzjoSXSZHueycxJ8xE b1ZfAOcYIgkWGY79HdmK4hsiOpqKcCJryCPOhogXQqnlMGfj/lzwvjzNTEq4bo4XGXWrIfdr1zz2 6lHZuicoJYsX8PmGWKnqBKKNS9T3JKsl9JMkj9j9/NidqINsRpVzQswfrRkv0t94F6KT3ZUDs7cn j2RGZKO9WNP6fkk+67B10fRrbqm7DNyWgDwCAAAAAKA+UiuW3ZeA3sun+XkZ0VuZQuxkvM1dfxW3 Vi9jjmh11ivG7Xc8e+BviBdVxzewS8pRTaXnQ6uv4pYvpLc1EFedNMThhvC6H+2qqhD5ynnNEPQE mceh5Mwj+Tr2SQnktdzeO+BdM8UqnXot02FiQ2SCKo3myvmGkOpq4reht/0vaq+pjzmxpRgL5MHo lfbKu95pq+76sYATmWgpacr88cJPgTE2KCWtrxUu7CuDfNUQWbBVXe480YPWVBw+l6PenLtkk8RI VyYf6Y0bjBdteol+M9BaFflG3FkX2slW1tdH+zyKl11qhtbNJJ/V6o1/9jC1cXG4LQF5BAAAAABA faRWLNUXiACQiZIDs4HLx9rsUQAALhi3JSCPAAAAAACoj9SKpfoCEQCysOY0GeASAfIIAG4YtyUg jwAAAAAAqI/UiqX6AhEATLAEomt7lxDggGXogDQEgNvDbQnIIwAAAAAA6iO1Yqm+QAQAAAAAAKC4 LQF5BAAAAABAfaRWLNUXiAAAAAAAABS3JSCPAAAAAACoj9SKpfoCEQAAAAAAgOK2BOQRAAAAAAD1 kVqxVF8gAjVRvwUAAADANWLt07ckII8AAAAAAKiP1Iql+vISqIn6LQAAAACuEWufviUBeQQAAAAA QH2kVizVl5d/Dt0FvkhrfG6bu36s3YzVqN+CJMb+rmmfx9rNAADg1nCRX05nhLVP35KAPAIAAAAA oD5SK5bTrSQPr12PluIXuT4/W/JoeAxvOM9o4foqX7udX6gO8mgXlbKh+KtvZyte3FCcZpCjrHaV qbQ9nNmaAS8ZB8/phhq1j8/BbfdpwEV+OW2MNSZeV/NtCcgjAAAAAADqI7ViOe1CdHi8+aX4nhif 2+ZxKHlks7rH/m5RvP3agRiqAnUoXuD4HPu77ds8PK4ij8bn1mqSc+liMfZ3dcijGUO3iNq4Rlvs hKUmXlftbQnIIwAAAAAA6iO1YjntKvQCg9NLQnk0tFndII8uDFdEHm3PXIA8qm6CEoA82hsgj/YX kEcAAAAAANRHasWy87KTJBa0/S8enKZzZUg+yuMQLfUPWSBzCUM3ZWlNeVTHjK05rcp89q4fIwaD JH91w6++Jdt5wiUjKYx0mebQhGyYUELZLiGaIiafpZWWpJHpdppVmVExUaisb+rnUQVzt+cghJg/ CKs3mN8gmGi+UohtDn15HEgVsS4SHrAUc5Meh1CF0alG8XvSqtD+Q9e4jXVtTzfPd7J7vKFIClGH IkuGVBzAH6j+VR90kIsus/Gv+Y+B2ZmpxY/Kmdo2PLb9L24L0/G4xuhI0TQ2dd+ZRBxVM7Pq81qe cwpDZM2YrGHt80DYhIlZSI5WE85s+2POp6JfgtoQGYLRSEyZKf3lRKcvYsS8yad8RMw26h8bUT55 lrml0Z14+s1hhQ7kke23xogo8AIFtyUgjwAAAAAAqI/UimXN2i4FnkV1WF5mR6xDR1bd05qc3Cay Vcb+ji5oJfvB1+f82ddORCXDI/lzWmPH8fKvvtUC1eGR3Rz92bbhAJ+yhBtxypJ66NLCnUeKneya jNOejJ1HkpSJfsHOYG3G51a551ff0qgs/vOubY9x0WvH25zwgLV47ZrHLpyWEvrIfDo6zom1anxu m7u2NflF9TSWoWu6LvhcGAZrhiIbD4oD+APVv+pD9FHt8pI9Efo4IbTFFCRT6sHqkXoml7/zqOGM qjn16GNt7O/a7vH4eX73U2byZkylnYR0mKiZY+FCPwn4s60/n5KuKUpQSEy3j1bzlHteO8a5iD8T k8/iETF0s3KGx1nhv/rWYH+k8yh35ltq7O+6jlqKdcoeEbleoOO2BOQRAAAAAAD1kVqxrFnb+Yh+ QrboEps8MsOi1LI/SR55a+as3B2VPFK6zDJgRAim3p/ZI1UJy8kjmzrJqvj05JGSWES1GUVK/P6l SXaZeO3UfV+qeYbHEGTGHIS3OU1R3dCpLNiaoaj66GvHyRSHv1iYUmSoK/bGRQk1v/ou0hKtTuqB KCFhRPue4yVuINKjtKoPhivesphjJmfGTAzSaDSV7OPzZtvUfOp3bTfySHM52uXE5LN4RDAumPwE YZUmLynUZK4j6Qzp9Ik3Ihb0kuC2BOQRAAAAAAD1kVqxrFnb+dAiiLKDVlhik7Ma95bZx4WumUnj pzQ5WQuZG3+IHmSz88kjNRzTMjwWnnnEc1LG0opPTh4plBYrPGph5DG+B6zDa6dGZSwjKao9QYf9 qST6aeSRFkmuGYpqgk8TkaDGQE1fNaFHxZGWlp3GMvvPr75lqWpGLdGmJMuIE0rOPCKenKPqNbyn ZwhvxkxNK0sGNX+cNOtVb4Nb+GnJI33W9khAxZ2WjIg0eRQ5Jy+csVpFG8S0UTZ30xsRmcUbuC0B eQQAAAAAQH2kVixr1nY+1pNHct1rB3fOSn5ebNtV+K9jNt4Uf2XkkbBH4D6uljzK94By2OSRU0vG Xqrk/o59yKOifS5xO/OvWtb0tLTwKN9pZ8T43HWP0/4L5lE+eZR0leXkUVrVG22ak4aoSB6JosJs e7XkkWcIBwnyKMrpU4bGcfNR4Ys5E+SRqcYFLsCeviUBeQQAAAAAQH2kVixr1nY+1qatSVAOwU20 +onDhEQVftRmZagtSVtbSh7tmramVEZ/oN4ybS0K8/ZLWysgjzQPEKcIF8HyJ9/P3LQ1Ref55NGq oVicZeMPztTQZXfulbb258/43B0Ohp+2Y8hT8e2BmkHxLCSPslS9WcYlN4Q7Yya6vCF5xCfWbdPW oil7x7S1kskne0T45FHe0DhsPio7l0qdLkIbHPdY5ALk6VsSkEcAAAAAANRHasWyZm2XAl8Vixfg +Ovz+JdRETRFm0XYOTN0rRvVKw8wjd8BJw8wydx5pPSFr6tXkEdRM/K3Pnk4qFJuaRHvh0pWbMa0 VJv83WFaafp5LnkG4A3w4zffA+ZPVGfNgh1NyVOvmPJ5F147dmC29KQ4oenHYR/WDEVVXZTHdQZq ahj7kN3JjeTzbNTeHXQyPDbtnTgf2huorhFjY7GDqBLbYVxVlyuQOYBrCHfGjLdfknS/VeRRarb1 51PLTxRlqlywbSbX5eJm8Aa4k8+KEeGTR9EEaOTETd5eeGzW2N+17Z35JWqOiPwaNNyWgDwCAAAA AKA+UiuWNWu7DNDzELpXGvNqL9rmQZY8vkEJG8llERfwVy2zdxxFR4vY57c0TcPZDP1YErpEt1ol 32QdOpi9u4UfLiHDardVFnjLrAbZFUfPTnfwg0vIg+LFTNLS0RudIrGNwd5TxpoaGnl8/ZkoNQoa xdv7sqH4h4wMeb/sk5imTTGcxWMNnuo6vlgtrph3avFQjPulvuSeFp55NQ0+GqMANZKCkJgwPox4 zhqorhEVbQenou0MWhWv7lK7rJmphHtOGMKZMZ1JIHqlfbgtp23+bBv3Wr4+LBZmC/5q+cmy5rwp yDKlaNPt5dvTiIrk5LNwRASvaPtfcyGPA3/VHR0R+mR71FvBMAw8FFFL4jtirjS7EhW3JSCPAAAA AACoj9SKZc3aDrh41G/BWaI0vtqvGUveqwUAAGAg2t22I9Y+fUsC8ggAAAAAgPpIrViqL2WBmqjf gnPE+NyeLr6ykXkYGAAAQB70w872wtqnb0lAHgEAAAAAUB+pFUv91SxQEfVbADDQ7I/lpw4DAAAQ yCzg02xpXPv0LQnIIwAAAAAA6iO1Yqm9pgWqon4LAAAAgGvE2qdvSUAeAQAAAABQH6kVS/XlJVAT 9VsAAAAAXCPWPn1LAvIIAAAAAID6SK1Yqi8vgZqo3wIAAADgGrH26VsSkEcAAAAAANSHv16pvrgE AAAAdkXt+gFgAW5LQB4BAAAAAFAf/nql+vIQAAAA2BW16weABbgtAXkEAAAAAEB9+OuV6stDAAAA YFfUrh8AFuC2BOQRAAAAAAD14a9Xqi8PF2Ls75qmabrXVeWMzy15d3E31O8XAAAZ+NW3GLP5qF0/ ACzAbQnIIwAAAAAA6sNfr1RfHq7A+NyuIo9eu+auH0/Z5kPEy6R9Hq1LTdM0j8PPnz9Hsix+uv9l lrwVIzY8poqltT8OP7/69tDsoaMPMW0fezQX9RrubZ/HuVKtg4fC9zGE7O/cAN7I+WZql26QdORa chP4+XPozEE69ncgj/JQu34AWIDbEpBHAAAAAADUh79eqb48XIH15NGRLzg1XjuNAYmC4cDCkEvk 2eGRUhtxmL1tdD32d5xJma1AuaQDe8J7Nzw27fMQPz7RNNQKw2MgXOKixud2Y5Pphpgv3fVDXGO8 5+VX3wrN/+rbphucwoFcgDzaArXrB4AFuC0BeQQAAAAAQH3465X91n1yj8bPD9mXIQmC6M6fsAGE buhg7AMhj8IOlyxy4ZVtiNE2idAtMzxAnZ/tXsMGlmJG43rIIy22l70bukmHEVs3PDbd63w1fBLs KyinU5JHc0uiDv7qW0EqReTR3M4l+l8zIhIg+63a55E7D9+NNXdnZvf6bvb5uV7WL7bfqng3H929 RZuk7rYTN3SDM/bZ/jKhqLnwu37kii1u87TVjjyeNhOdf4j7CS6Vtyok6hJtZ1u/cFgAwDngtgTk EQAAAAAA9eGvV/Zc+uk7gwIh8jM8RrGTjOSHrum68DmL5Gn5lHTIhbXz6Fff0qhM/Hms7rEj4WJJ DP9nmjyKCiwij3bakaGRRxm7t8bnVjXf0Wrkhpg8Gml24enIo2nrkGqLA1U0dDSljvUrXCrdHLdy RHggPTqUTL36tWPUCf3ztWuamUeb2RZqMvp/pagEho7xtuJPv4MTn3LsBbFI1F+t5MlwXXdHUkez doqN/R2nv+/a6EHTTONz2/BJjNFtckCxsTw+t+0d1TbvsoMCHwSAc8FtCcgjAAAAAADqw1+v7Lr0 +9V3UagfwmktVItIk6Gz9/XMRXn3eDCID4UJipo6PC7YYcGqNsgja6NE8tkfb7fUNlDIoww2h0Xa Qrdhd8/cX4U8IiWcjDxihIjwk5kqCvcI8oiepZXLR5g3F42IROFF+V/HXofuEwegx1rFxWoDX4VG rokCffJI7ugh23biETT2j3F24Qaks6TPPDMp3WFKSJFHSkU5E1FhFwHgHHBbAvIIAAAAAID6+P/t 3dF1mzAYBlAvwQx5yBTZgMcs0QU8QRfxOF6lK6QPTowkBAhc/Cfl3vM9ObWNDe4R30Fifryy7+jv 68QmOUm7n9TVL8ooz52yOU1Frm8v/Wu/bubO3Hvl25ylPLvecqFT/tYrrzxafO5HyJVHy21OcQFI vvH3r/F+Vlwrj4Y65lnlUVZ4lQfh0MJ8dV55L3N5TVuD+kJR1Tz+i1j+sNXJZfWG6+twmi+PFhZ6 XzyiKp9laTLm9NOzTa1u1mha6PoKuKVcntxN1f9z0qcvlUejI6Ttx77peBGJzbEoj0RERCQ+8+OV nUd/l9fbwh99/3prB7LpG4+XR6eu77utPc43Lo+SRyozxZbKo52yZdpacfex4gQ++Ro/X7xeHiUT 3J5RHtUKkWF3p43D7elZB3EZr6fVuM27l0fFB7+/zoPl0fajbtfyqKGzUx6JfOMci/JIRERE4jM/ Xtl59Hd968+/Ln13vt6uQElPk1on6cxeefT+serijiyPTVv7geXRrdfYeqHW1ILZc11GZU2WyZWq 3vtTdz5PlEe3K5jOow7gvg8AAAODSURBVPKoenO3B3dEfunQ6ADIGofruTv1b8Mj2ycW/f4Hv4hV yZu7zdPWtv76RgfDxNe1rTxq6xm3NV+t09aqu2nttLXsdUxbk0PlWJRHIiIiEp/58creo7/3/qX7 PIu7vJ5euuxcsaxgKmfyLeXRx4qFY4ttm1owOzsfq5we/8jy6DZrafvN4ydqgtEZ+LDMc7r6T/rv a8tjp/eTuu/fdAcV96JKnrK9vJg45GrL5XTJdTrFCkfDLLBivtt9y1u38MFfxPwrz13BNHWDvN+L 5dF4aepqxzGV8uOMflnX4nZ7yZVrc+VRZV+MtnPrZVP5D+G9n1owu7qbylar2IZ0I/ObuH1UFsyu HVqfkxPzx1cfLyLxORblkYiIiMRnfryy+wAwORV/H69PlC9NUt6yamb6T140DIu5NJ1X1+ZSTd9L O19S9+v+2VObPZvafKjhTk+jPxUbVm52ec65sEnXt5dtPUvlI5/Kk/bxJ6rdcj7Z3V3fd6NXG27s lb5pUliU5dGlP22qw6Z2RO129dmd0d/67N/fP9Tn/dfqn+jzoaa2cfMvYu1OrFwRNv7r8KzufE1/ dLcvKl0XPH3tVXskf259Vtf4C0keLA+Y4d2LlY/yhatGX+aaOjjZF7fLKrM7oC3spnxflP9lJTui v+T16K0ur/2yxj9G5ZH8+ByL8khERETiMz9eCR8eypNyPXePXHb0LVOpI0WenlX31Hsg9VWxWhL9 DYlsyLEoj0RERCQ+8+OV8OGhPCe/zi//Xc8yzI8Ticujk1ibozySQ+VYlEciIiISn/nxSvjwUETk pyWdevaP7wBYTzYFb/U7xn9hIqtzLMojERERic/8eCV8eCgiIrsm+v1FNuRYlEciIiISn/nxSvjw UEREdk30+4tsyLEoj0RERCQ+8+OV8OGhiIjsmuj3F9mQYynLoz8AAE8XMgwCAKCF8ggAiBcyDAIA oIXyCACIFzIMAgCghfIIAIgXMgwCAKCF8ggAiBcyDAIAoIXyCACIFzIMAgCghfIIAIgXMgwCAKCF 8ggAiBcyDAIAoIXyCACIFzIMAgCghfIIAIgXMgwCAKCF8ggAiBcyDAIAoIXyCACIFzIMAgCghfII AIgXMgwCAKCF8ggAiBcyDAIAoIXyCACIFzIMAgCghfIIAIgXMgwCAKCF8ggAiBcyDAIAoIXyCACI FzIMAgCgxV8RtJnBrnyZowAAAABJRU5ErkJggg== --001a114dae1a1a602805539f9c1b-- From nobody Thu Jul 6 02:17:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E4D120721 for ; Thu, 6 Jul 2017 02:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 F7ntvBGroXz4 for ; Thu, 6 Jul 2017 02:17:30 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7FE1201F8 for ; Thu, 6 Jul 2017 02:17:30 -0700 (PDT) Received: from [2001:470:1f09:d2::4a7] (port=55648 helo=cho.localnet) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dT2ue-0003Il-5E; Thu, 06 Jul 2017 10:17:28 +0100 From: Jim Hague To: Richard Gibson Cc: dnsop Date: Thu, 06 Jul 2017 10:17:26 +0100 Message-ID: <2658248.mqps5m5hH4@cho> Organization: Sinodun Ltd X-Face: "YyOu7Hab"VGm^bAO1; {iOPso3{hw9JL`&?c6?!@&m`z?E\ZMv; T44B_v+/9i''$IUz\h: 7+|+U\Sm3S)ajt}IU6bG#OB^ma3dQ%l4]6jGS1:=9N]LF\ZmxO!"2bQ}v@,\x?0{/mu; a, g3:!#KL>aL\D; )@?UJG=m@@vt; LJJxqV.w-.VxYKp-r1'$`0+>4D72C#o5(tax+Dp:0UWU ]+s_'{u[#cEm^9VXGTf0+#@VwB/%U?KWb~C<@19. References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <5ec26bfa-b7c9-cdcc-2594-5e2df7bec4c8@sinodun.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 09:17:32 -0000 On Wednesday, 5 July 2017 13:06:12 BST Richard Gibson wrote: > On Wed, Jul 5, 2017 at 8:05 AM, Jim Hague wrote: > > Timestamps, on the other hand, I always regarded as a basic data type, > > so naturally a structure. Plus, of course, there's one per > > query/response item, so in a block the size savings are in the 10-15k > > bytes region, which is rather more significant. >=20 > In that case, I'm even more convinced that all of them (block preamble > "earliest-time", Q/R data item "time" and "delay", malformed packet item > "time") should have the same structure=E2=80=94either variable-precision = arrays or > {"seconds", "useconds", "pseconds"} maps. Q/R data item and malformed packet items have the same structure, though it= 's=20 not an explicit data type in CDDL as Timeval is at the moment. I'll amend=20 that. However, they are time deltas, not timestamps, so I don't think they= =20 should have the same type as the block earliest time. It it turns out that = no- better-then-second resolution is a common use case, there are potential=20 savings to be made in using seconds as the time delta, because the deltas w= ill=20 tend to be very small numbers with consequent space savings in CDDL. We'll= =20 look at this. > > * In section 7.18, "and an unsigned key" appears to be meaningless and= =20 > > > should probably be removed. > >=20 > > In most places where we are discussing a map, we've specified the type > > of the map key in the text, though I notice we're not 100% consistent > > with that. >=20 > All the keys in those maps (and in every map, as far as I can tell) are > strings, for which "unsigned" is a meaningless concept. No. All keys are unsigned ints, with values specified in the CDDL. We shoul= d=20 make this more explicit in the text. String keys would bloat the output file size enormously. > > I don't quite follow why you'd need to put this informational-only stuff > > into the block preamble rather than the file preamble/configuration. Can > > you expand on that a bit? >=20 > Some of our processing can benefit from merging telemetry (e.g., all hosts > at a site), which would produce files containing blocks that don't share > values for fields currently in the file preamble. In fact, we might even > decide to treat "block" as the only relevant unit, using block preamble > extension fields for *everything* in the standard file preamble except > version information. Ah, so you are talking about doing a merge at the block level rather than t= he=20 Q/R item level? We'll think about the implications of that. The fields you cited, host-id and server-addresses, are purely informationa= l=20 anyway. > > *Opt-in Lossyness* > > This raises a question about a tension between the background of C-DNS > > to date and the slightly different angle you are coming from. We've been > > very much focused on using C-DNS to record traffic in a form where the > > packets can be recreated in wire format (i.e. as PCAP). The optional > > data items mean that data may be missing from those packets, but the > > core query and response will still be present. >=20 > Agreed. But it's _so close_ that I felt these suggestions were worth > raising=E2=80=94not to water down the primary use case, but to cover a fe= w more > with some tradeoffs. Oh, absolutely! You've give an important use case we hadn't considered - we= =20 need to look into it. > We'll be doing a 10 minute slot on C-DNS in Prague, and would welcome > > discussion there. >=20 > I don't expect to be there personally, but we'll have a well-informed > representative. We'd definitely like to talk, then. =2D-=20 Jim Hague - jim@sinodun.com Never trust a computer you can't lift. From nobody Thu Jul 6 05:46:02 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2222C13153F; Thu, 6 Jul 2017 05:45:55 -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?= To: "The IESG" Cc: draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf , dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149934515513.2355.130457730053156062.idtracker@ietfa.amsl.com> Date: Thu, 06 Jul 2017 05:45:55 -0700 Archived-At: Subject: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dnsop-sutld-ps-07=3A_=28with_COMMENT=29?= X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 12:45:55 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-sutld-ps-07: 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-dnsop-sutld-ps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I guess SUDN (registry) and MoU could be added to the terminology section. Thanks for writting this document! From nobody Thu Jul 6 08:15:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B43131548; Thu, 6 Jul 2017 08:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 2iP2yO2Rkf0z; Thu, 6 Jul 2017 08:15:45 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B85F129B66; Thu, 6 Jul 2017 08:15:45 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dT8VI-0009FI-Tl; Thu, 06 Jul 2017 11:15:40 -0400 Date: Thu, 06 Jul 2017 11:15:34 -0400 From: John C Klensin To: Phillip Hallam-Baker , Paul Vixie cc: dnsop , IETF Rinse Repeat Message-ID: <562EC659F89FA92A09CAC4DB@PSB> In-Reply-To: References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 15:15:46 -0000 --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker wrote: > There are changes to the DNS that are practical and those that > are not. For better or worse, I can't see any way that > teaching DNS to use new classes makes any sense at this point. > The only point at which it would have made sense was when > internationalization happened. But the path chosen makes more > sense. As the author of the I-D that proposed using a Class to deal with internationalization, it would not have worked, and the two important reasons are perhaps worth understanding. First, that approach included a transition strategy that permitted legacy clients and registrations to keep working in a way that users would see as normal. But that strategy depends on CLASSes sharing the same root and hierarchy. At Paul points out, that interpretation of 1034/1035 is not universally accepted and implemented. Second, IIR, we intended that the different CLASS allow a different set of matching rule assumptions and conditions. Because labels must generally be interpreted and compared before CLASS values are accessed and, perhaps more important, in optimization of databases, one probably needs label types to do that, not CLASSes. And label types don't have a good history. > ICANN will manage whatever bits of the DNS consensus agrees it > should manage. The only events likely to break consensus would > be an attempt by some government to strong arm ICANN into a > breach of faith with the community and succeeding or some > really spectacular peculation. We disagree about that, but I no proof that my impressions/ predictions are any better than yours. > It seems to me that if people want to do anything new with DNS > that they should use prefixes, new RRs or both as the > mechanism, not the class which is limited anyway. > > DNS is not a full service directory. Nor does it need to be. A > UDP packet is big enough for a link, a fingerprint and a > digital signature. That is all that you ever need. As I think you know, I just love "all you will ever need" statements about the Internet (and its predecessors) although my favorite remains "we will never need more than 8 bits of address space". > The X.500 and UDDI models were broken because there is no > point in putting information into a directory if the service > can return it in a service handshake. The X.500 and UDDI approaches failed because... sorry, I lost count of the reasons :-( john From nobody Thu Jul 6 08:40:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632371317C4; Thu, 6 Jul 2017 08:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 GBDm5KSYDChC; Thu, 6 Jul 2017 08:40:01 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF561317C8; Thu, 6 Jul 2017 08:40:01 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id A136FC0028BB; Thu, 6 Jul 2017 08:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=kYjLJSqN5bcVCU gZEYpNGC9mLIQ=; b=ylF7B86MeUvSNOgJk/QiEoJfbmIKcCO5KwIYhZd9mwweAD e4IbWAncThxaKJgWUzUrWxMuOMQLRlBdeUAj6RXVP2GL7NWpZRYsbwwvJpvRHn0F w0Ap/PR9F9To3sFKqUoGYAQj+5Zq46H7g2RJeWa+8/HPRNcb8LOkxCoz4nyog= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 24CEBC0028BA; Thu, 6 Jul 2017 08:40:00 -0700 (PDT) Date: Thu, 6 Jul 2017 10:39:56 -0500 From: Nico Williams To: John C Klensin Cc: Phillip Hallam-Baker , Paul Vixie , dnsop , IETF Rinse Repeat Message-ID: <20170706153955.GB3393@localhost> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562EC659F89FA92A09CAC4DB@PSB> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 15:40:02 -0000 On Thu, Jul 06, 2017 at 11:15:34AM -0400, John C Klensin wrote: > --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker > wrote: > > The X.500 and UDDI models were broken because there is no > > point in putting information into a directory if the service > > can return it in a service handshake. > > The X.500 and UDDI approaches failed because... sorry, I lost > count of the reasons :-( The complexity and general ugliness of x.400/x.500 naming (indeed, the inability to correctly and canonically represent such names in TEXT!) are all the reason anyone ever should have needed. (See what I did there?) And yet some bits of that horrible thing are still with us (PKIX, LDAP), though of course with various adaptations (eg, SANs) to make them suck less and more Internet-like. DNS is not a directory, but when your only off-the-shelf choices are DNS or LDAP... I'll contribute this extension to your earlier argument about root sharing/non-sharing. I think new classes will only ever be feasible provided that a) they share roots with IN, or b) are like a local HS not really meant to federate at all (thus root sharing / alt. roots would be moot). (a) classes would basically be an RR type extension field for IN. (b) is probably not worth considering -- the lack of security in HS was a big reason for not using it, and so DNSSEC (or something like it) would be a requirement in order to use an HS-like class, but if you'll want DNSSEC then you'll want delegation hierarchy anyways and thus you'll want shared roots, making any HS-like classes just IN-class RR type extension fields. It's easier to develop a new protocol for (b) than to shove whatever it is into DNS. So new classes will only be useful to extend the IN-class RR type namespace. We won't get there. New RR types can be very difficult to deploy due to lack of interest by registrars and domain hosting services. TXT RRs forever. :( Cheers, Nico -- From nobody Thu Jul 6 09:07:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D66B131684; Thu, 6 Jul 2017 09:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 J928WB0qADDx; Thu, 6 Jul 2017 09:06:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 DFB53127444; Thu, 6 Jul 2017 09:06:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dT9Ie-0004HA-DG; Thu, 06 Jul 2017 16:06:40 +0000 Date: Thu, 06 Jul 2017 18:06:39 +0200 Message-ID: From: Randy Bush To: Nico Williams Cc: John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat In-Reply-To: <20170706153955.GB3393@localhost> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:06:47 -0000 > DNS is not a directory, but when your only off-the-shelf choices are DNS > or LDAP... this is the ietf. do not ignore bgp and ldp. From nobody Thu Jul 6 09:25:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5343D131806 for ; Thu, 6 Jul 2017 09:25:57 -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, HTML_MESSAGE=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 (1024-bit key) header.d=dyn.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 YDEuzsxW71vv for ; Thu, 6 Jul 2017 09:25:55 -0700 (PDT) Received: from mail-vk0-x248.google.com (mail-vk0-x248.google.com [IPv6:2607:f8b0:400c:c05::248]) (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 4C0471317CB for ; Thu, 6 Jul 2017 09:25:55 -0700 (PDT) Received: by mail-vk0-x248.google.com with SMTP id r125so2075296vkf.6 for ; Thu, 06 Jul 2017 09:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o3PoP6r211Vo+2mh3vDBnE84mzW358i6n3Ek5/S+0iM=; b=vQyT7POnLmV4wVvbcZktYK2hg8wQyhgdGhO8EPDA6QWIA23IW02LatjSFoxjwMP5a7 PYnDlP8uKS+pLt4Y6K0C4LZk6pVjJkOz1f+p9+nzFCKei+RZoEAGA7P3J377MzT3OFiI 9SnzELF3d1EhBrHHnQiRaqHk6yzgLTPN7xYtI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o3PoP6r211Vo+2mh3vDBnE84mzW358i6n3Ek5/S+0iM=; b=Upc1i1OE5snQZzVqef2gxCPc8IVu/hD4kEKyXUkD0rCFgpLpNpS5ftFYWJst79I2+w 0ykZvGbN/N//Ce5rCmxpjKHlmPRP0ZDeqx9idryCCXs0TNKc/NFv7VDV/vIwH5r2fOPB +GrI1sNBiRhfoi3SqybsYXx6RAaHmlO73L5SOv4v9+fW331kmIbpncKNn+mJbQm4VGq8 tL7qg71vBgueUkY2LwSUfJTEDjM8p6o3CVhv18AgvA7EeMBI8vFlati4M9QEFWzVGY/S Mhh9AmUJjAB8E8p7dHR4z1bZvoorUXTdtOE2anmq2VG5A7SNCyAgH8h9qVf2jWYX8i8L 98CQ== X-Gm-Message-State: AKS2vOz0m8B4cDWEt+x0xDvS1Y1R2Emr3pUJlm8WDcDEm2UOxIF1X56r Cs94NyzdsL6/DNSRMDxfq6IH1D6IyH1aLGVFnA== X-Received: by 10.176.77.96 with SMTP id k32mr32435483uag.39.1499358354321; Thu, 06 Jul 2017 09:25:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.62.209 with HTTP; Thu, 6 Jul 2017 09:25:33 -0700 (PDT) In-Reply-To: <2658248.mqps5m5hH4@cho> References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <5ec26bfa-b7c9-cdcc-2594-5e2df7bec4c8@sinodun.com> <2658248.mqps5m5hH4@cho> From: Richard Gibson Date: Thu, 6 Jul 2017 12:25:33 -0400 Message-ID: To: Jim Hague Cc: dnsop Content-Type: multipart/alternative; boundary="f403043c4b241a1e200553a89272" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:25:57 -0000 --f403043c4b241a1e200553a89272 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 5:17 AM, Jim Hague wrote: > > All the keys in those maps (and in every map, as far as I can tell) are > > strings, for which "unsigned" is a meaningless concept. > > No. All keys are unsigned ints, with values specified in the CDDL. We > should > make this more explicit in the text. > > String keys would bloat the output file size enormously. > Oh, wow. Yes, more explicit documentation in the text would be appreciated. I completely missed that, even in the CDDL where the key definitions follow maps referencing them. It seemed like you were using string keys and relying on general compression to eliminate the bloat, but this greatly clarifies your "designate as implementation-specific all key values above a threshold" statement regarding extension fields (and in that case, might I recommend reserving all nonnegative integers and perhaps also all strings lacking an implementation-extension prefix for standard key values? That would suggest negative numbers and prefixed strings for extension keys, a set encompassing one full major type and then some). --f403043c4b241a1e200553a89272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 6, 2017 at 5:17 AM, Jim Hague <jim@sinodun.com> wrote:=
> All the keys in those maps (and in every map, as far as I can tell) = are
> strings, for which "unsigned" is a meaningless concept.

No. All keys are unsigned ints, with values specified in the CDDL. W= e should
make this more explicit in the text.

String keys would bloat the output file size enormously.

Oh, wow. Yes, more explicit documentation in the text wou= ld be appreciated.=C2=A0I completely missed that, even in the CDDL where th= e key definitions follow maps referencing them. It seemed like you were usi= ng string keys and relying on general compression to eliminate the bloat, b= ut this greatly clarifies your "designate as implementation-specific a= ll key values above a threshold" statement regarding extension fields = (and in that case, might I recommend reserving all nonnegative integers and= perhaps also all strings lacking an implementation-extension prefix for st= andard key values? That would suggest negative numbers and prefixed strings= for extension keys, a set encompassing one full major type and then some).=
--f403043c4b241a1e200553a89272-- From nobody Thu Jul 6 09:36:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4313168A; Thu, 6 Jul 2017 09:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] autolearn=no 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 DFgE6M1KK9bQ; Thu, 6 Jul 2017 09:36:40 -0700 (PDT) Received: from sleekfreak.ath.cx (rrcs-67-79-182-226.se.biz.rr.com [67.79.182.226]) (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 92BED13164A; Thu, 6 Jul 2017 09:36:40 -0700 (PDT) Received: from shogunx (helo=localhost) by sleekfreak.ath.cx with local-esmtp (Exim 4.89) (envelope-from ) id 1dT9jU-0004Q7-4i; Thu, 06 Jul 2017 12:34:24 -0400 Date: Thu, 6 Jul 2017 12:34:23 -0400 (EDT) From: shogunx@sleekfreak.ath.cx To: Randy Bush cc: Nico Williams , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat In-Reply-To: Message-ID: References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:36:41 -0000 On Thu, 6 Jul 2017, Randy Bush wrote: >> DNS is not a directory, but when your only off-the-shelf choices are DNS >> or LDAP... > > this is the ietf. do not ignore bgp and ldp. +1 From nobody Thu Jul 6 10:33:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6594813185E for ; Thu, 6 Jul 2017 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 FVbV9GHcNJ4R for ; Thu, 6 Jul 2017 10:33:22 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 D56EF13185C for ; Thu, 6 Jul 2017 10:33:21 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id v143so8355009qkb.0 for ; Thu, 06 Jul 2017 10:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=fOKZgg/zfGzQ4ShRzbmt7vJknTF1e8qhI/E+2dW35NE=; b=qRmH4XfyazJPoaNHuUOHjVyx5uPfOhlJ+Ymi9Q6SPMCQQiSYGYD3pq6Ejo6w+pLfF7 61RbPKePWE1cOZn8MmoZc3L9AW5kc8uLZ5cFD1Hi5fKNw9vZgjpwLAiA/1jsrXbJkAWS Mm9MoZR8iYr9iapFv0qToEEXuVgqQUC3iTVPFBf6ATBBLl2X0xWU8IH5eT7G65f5JlfF TkDP1ca+gSiUNOMmFPmm+NfyRStUcaG5WStTxRRmJzyy5kO0WAlwiL6BzTYfPLOW+YOw DnQfbdHp+gbTpcX4OYdq4JH+wwD1XRSlVn7EzMkSoJLPPv6IUFQf87VrgcNnp12IuC4S +p+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fOKZgg/zfGzQ4ShRzbmt7vJknTF1e8qhI/E+2dW35NE=; b=NZ8H+OrLFrVgZr6A2xviF/Qh85/2M1wpJBhPuzDC/iHR+OMqfbaqSlz0rW7vF9v325 ySpBngTsONuAo4Hf4fWPk5hz7WDlhr2XU8vrn/yYBtxew1sRy0TzwpfXqcPIx0R7CGZu 0l/iP6DfOIBWdf7uvPXGREvlol5QN9DmD+9EPbWiK3ro+JQ1BBCivFa8WpXdGYw+3dRk qkzAJUyGybibiYEZ+6k8/we0RmpMYGbLmTO3yEv7Ui5bur2GI2jLhrdvoSgGJT6DQDh/ zVTZvHCInPWvD1TH38duE7hW9/bN0+E9GueHqhePYISU3+G10jWBJUiuS0JOH2RxPDdX ybbw== X-Gm-Message-State: AKS2vOy+0monsYXKJk40BPM20wH2xolyqmdKE6c/QcLACzWgX/B3B/xV /y5dZER1ZviA5PdduNw= X-Received: by 10.55.75.204 with SMTP id y195mr63288997qka.183.1499362400498; Thu, 06 Jul 2017 10:33:20 -0700 (PDT) Received: from [192.168.1.100] (c-68-83-216-246.hsd1.md.comcast.net. [68.83.216.246]) by smtp.gmail.com with ESMTPSA id j17sm581915qta.49.2017.07.06.10.33.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 10:33:19 -0700 (PDT) To: Wes Hardaker Cc: dnsop@ietf.org References: From: Michael StJohns Message-ID: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> Date: Thu, 6 Jul 2017 13:33:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 17:33:24 -0000 On 7/5/2017 8:11 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> That's not actually a plus you understand. Mike > Sure it is. We're down to the point where large changes aren't needed :-P I'm sure you think that... but the small changes you've made to address some of my comments haven't gone far enough. There's also a need for a grammar and syntax pass on the document. Here's what I've got so far (in document order rather than order of importance): 1) Use "exclusively" rather than "only" where you can - "only" has some issues with misunderstanding. E.g. in the abstract you have "only recently" which can be interpreted applying to "recently" rather than meaning "exclusively" with " recently added DNSKEYs" Instead in the abstract: "... before exclusively signing with recently added DNSKEYs" 2) In the introduction - "validators can update" vs "validators can extend". 3) In the introduction - same issue with "only recently" 4) In the introduction - "ceasing publication of a revoked key" vs "removing a key from a zone" 5) Section 1.1 - What is the definition of "rolled"? Your use of it doesn't match 5011s and it's not defined either here or in 4033 or . Also "before signing a zone" - I don't think this is exactly what you asked them and the summary is probably inaccurate. 6) Section 2 "which apply to" vs "as required from". 7) Section 2 "Note that it does not..." - which "it" are you talking about? 8) Section 2 "using only recently" - same issue as above. 9) Section 2. New para at "Failure of a DNSKEY..." 10) Section 2. "... leaving that key in their trust anchor storage beyond the key's expected lifetime." vs "... leaving a key in their trust anchor storage beyond their expected lifetime" -"their" applies to two different things 11) Section 3: Attacker. "An entity intent..." vs "An attacker intent..." - self referencing definition problem 12) Section 4.1: This doesn't actually describe what's in 5011 - specifically bullet 3 was modified to clarify your concerns, but isn't what was in 5011. You need to have both here. 13) Section 4.1, bullet 3: Same problem with "only". Instead "Begin to exclusively use recently published DNSKEYs..." 14) Section 4.2 last para: This is only an attack if the private key is compromised. In which case, with only a steady state of a single key, you've got lots of other problems. Basically, in your one in one out with a steady state of one model, once the current private key is compromised you have no ability to fix the problem. But getting the numbers for figuring out when this change becomes "sticky" correct is useful. 15) Section 6 - general comment. You're doing interval calculations and you want to do date/time wall clock calculations instead. While the 5011 values are based on intervals from the RRs get to the validator, the publisher has to be looking at absolute times first (e.g. signature inception and expiration, original TTL) and then deltas from those. [Note, this is NOT a new comment - I've made it previously and strongly] 16) Section 5.1.1 - You're missing a *very* important point here - that DNSKEY RRSets may be signed ahead of their use. You need to assume that once signed, they are available to be published - even by an attacker. So wherever you have "signature lifetime" you want something like "latest signature expiration of any DNSKEY RRSet not containing the new key" or at least you want to calculate the date/time value based on that. 17) Section 5.1.1 doesn't actually apply if you use the 5011 rollover approach (section 6.3). E.g. K_old (and any RRSets it signed) will be revoked the first time K_new is seen and K_standby is the signing key. At this point this reduces to a normal denial of service attack (where you prevent new data from being retrieved by the resolver). You'd need a different section to do that analysis. [And thinking about it, why is there any practical difference between this attack and a normal denial of service attack in the first place?] 18) Section 5.1.1, T+35: "since the hold down time of 30 days + 1/2 the signature validity... " - Two items: Wordsmithing: The hold down time is just the 30 days, not the plus 1/2... which I *think* given the reference to 2.3 is actually the queryInterval. clarify please. And queryInterval is not actually 1/2 the signature validity - its the MIN (15 days, 10 days (sig life)/2 and 1 day(orig ttl)/2) or 1/2 a day. 19) Section 6 - the formulas are wrong. I also don't understand where you got MAX(originalTTL/2,15 days) - there's no support for this in the text. The final formula should be: EarliestDateWhereAttackFails::= latest SignatureExpiration of any DNSKEY RRSet not containing the new key waitExpirationDate = EarliestDateWhereAttackFails + 2*queryInterval (from RFC5011 section 2.3) + holdDownTime + slop (let's call this twice the query interval or some other number - its really there just to deal with an attacker preventing the last RR_New from being delivered) In the given example, assuming a 5/1/2017 00:00UTC inception date for the RR_Old, an 5/1/2017/00:01UTC inception date for the RR_new, a consistent 10 day signature validity and a 1day original TTL. EarliestDateWhereAttackFails == 5/11/2017 00:01UTC queryInterval = 1/2 day waitExpirationDate = EarliestDateWhereAttackFails + 30 + 2 or 6/12/2017 00:01UTC - 42 days after the last old RRSet was signed and 32 days after the last possible expiration date of an RRSet without the new key. So assume you sign both the new and old RRSigs with one seconds difference with identical parameters: At T=0 a publisher sends RR_new At query interval, and until EarliestDateWhereAttackFails and attacker somehow manages to intercept RR_new and substitute RR_Old - alternately, the attacker can let RR_new through until the next step - probably the more reasonable approach. At T=EarliestDateWhereAttackFails-1second attacker intercepts RR_new and sends its last valid RR_old At T=EarliestDate+queryInterval resolver receives another RR_new and starts the hold down From T=EarliestDate+queryInterval until T=EarliestDate+queryInterval+holdDownTime every queryInterval the resolver gets another copy of RR_new At T=EarliestDate+queryInterval+holdDownTime+queryInterval resolver gets the final copy of RR_New it needs to trigger the installation of the new trust anchor An attacker can prevent or delay the installation of the trust anchor by preventing delivery of RR_New (or subsequent RR with the new key), but that's sort of the definition of a Denial of Service attack and really no worse than keeping say "A" records from the resolver. In any event, the point needs to be made that this attack - while real - is a "retail" attack that would be difficult to prosecute by a single attacker across a broad range of end-entities. This goes to the general model that no publisher of DNS data knows each and every consumer of that data, nor can wait its publication on every consumer getting published data. The data protocol for DNS is unidirectional and the update protocol in 5011 was designed with that in mind. 20) The value in 6 regardless of what it is is the wrong value for revocation. revocationPublicationWaitTime is basically EarliestDateAttackFails + queryInterval + slop. Revocations take place immediately. You can delay them only as long as you have old valid signed RRSets. So - not ready for last call. Mike From nobody Thu Jul 6 10:40:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1FB131870 for ; Thu, 6 Jul 2017 10:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8Y6nb5rBvp4i for ; Thu, 6 Jul 2017 10:40:41 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B5F13186B for ; Thu, 6 Jul 2017 10:40:41 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 3B1E224CD4; Thu, 6 Jul 2017 10:40:40 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> Date: Thu, 06 Jul 2017 10:40:40 -0700 In-Reply-To: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> (Michael StJohns's message of "Thu, 6 Jul 2017 13:33:18 -0400") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 17:40:46 -0000 Michael StJohns writes: > I'm sure you think that... but the small changes you've made to > address some of my comments haven't gone far enough. There's also a > need for a grammar and syntax pass on the document. Thanks for the review and suggested text (the previous messages you sent didn't provide as many concrete fixes, so we can now incorporate you exact issues now that they're more directed). We'll try to put together an update to address the issues you've pointed out shortly (which really can't happen till Monday of IETF since we're after cut-off). -- Wes Hardaker USC/ISI From nobody Thu Jul 6 10:43:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7113184A for ; Thu, 6 Jul 2017 10:43:02 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 8qElh1X-8ZnV for ; Thu, 6 Jul 2017 10:43:01 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 C8686131865 for ; Thu, 6 Jul 2017 10:43:00 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id r30so8523862qtc.0 for ; Thu, 06 Jul 2017 10:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=cOnbb3/nit8tgCG03+MeEFk3iUKSb0w8qqJXu73/wr4=; b=r1Rhm+22A0/1o7MESjOuOllzjHc26uO4J7+iQu0HcWc/QdvO6dusN+UQQ8Cq6Fm6qO RAGb9ZpoQoCPQ5S/2824/Qyze9UTTcQFRFOEMRcEI9pCLOcy+bPVk/KCRBpEVk77OFuZ x2sPx7Ffc8i4pGgXINi4PCbkEPmvzpw5dds9lP3i+T0qUQlU0FMGUVRr+T9EzOQjPSGD iYso5SCZAH30mrkaUIqErhLB9M8COUtjGI5YIdIxfKmkc1WtcN6u9Unz3u/RcP2OsYNx RMMGG3gtrWYnMqE+Tsvsgk6LpbJzZ3iOApLcIg/pfjUgrVcjacWXGlFfYJ7ZDNEkkU2d 3blg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cOnbb3/nit8tgCG03+MeEFk3iUKSb0w8qqJXu73/wr4=; b=CXgiefw57hDn1seAgwEm0rsaa+WNRJpxKJ6Sv5rTD0SUNaXln74+VJ9UqPlNf+TP0q 3Uwp8IvziLQVJWwFs6eWw/OVKTRohEuN5iCZkal6x0jvXX09X5uAUdyO4NdaZVSRdop3 cosQOSSOCTdlM139iM1baYUkiO1CbAcgGrp1HQvymDnHXzFNsxApdQj5wb4z0RT+BEPp IQNY41z6ml+rmeC2MqtYNy+dvqn6okb+L5tfR/nInQWhwwMwqfzE+5pKCEiziYs76gty lJIjdBqhFch3+MmcqHXKmFFSCOzZ8ULccSsf4boepKnogM7/57aige6nmaKnTBRxwquR eQlQ== X-Gm-Message-State: AKS2vOxk/1v+MKv7h6hKdkHyQX9BzVULu2IRatapbE2UU/fI5I5ds9SN GcUzJrXs36hTt5UelBg= X-Received: by 10.237.37.52 with SMTP id v49mr60250219qtc.97.1499362979670; Thu, 06 Jul 2017 10:42:59 -0700 (PDT) Received: from [192.168.1.100] (c-68-83-216-246.hsd1.md.comcast.net. [68.83.216.246]) by smtp.gmail.com with ESMTPSA id w72sm577170qka.63.2017.07.06.10.42.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 10:42:58 -0700 (PDT) To: Wes Hardaker Cc: dnsop@ietf.org References: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> From: Michael StJohns Message-ID: Date: Thu, 6 Jul 2017 13:42:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 17:43:02 -0000 On 7/6/2017 1:40 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> I'm sure you think that... but the small changes you've made to >> address some of my comments haven't gone far enough. There's also a >> need for a grammar and syntax pass on the document. > Thanks for the review and suggested text (the previous messages you sent > didn't provide as many concrete fixes, so we can now incorporate you > exact issues now that they're more directed). We'll try to put together > an update to address the issues you've pointed out shortly (which really > can't happen till Monday of IETF since we're after cut-off). I didn't provide concrete fixes because the general model was missing the point and the re-write could have been substantial. Now we're finally on the same page that this only applies to "exclusively signing with the new keys" we can make progress. It wasn't until this last version that you'd adopted those changes. Later, mike From nobody Thu Jul 6 11:04:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6A13188A; Thu, 6 Jul 2017 11:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ZmLOzk9ivNm2; Thu, 6 Jul 2017 11:04:20 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79F1131879; Thu, 6 Jul 2017 11:04:20 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dTB8S-0009TV-WC; Thu, 06 Jul 2017 14:04:17 -0400 Date: Thu, 06 Jul 2017 14:04:10 -0400 From: John C Klensin To: Mark Andrews , "Roy T. Fielding" cc: dnsop , IETF Rinse Repeat Message-ID: <901C29488D8446E4176CF83E@PSB> In-Reply-To: <20170705231101.E23E77D9B7A1@rock.dv.isc.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <20170705031957.834B97D8FBDD@rock.dv.isc.org> <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com> <20170705231101.E23E77D9B7A1@rock.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 18:04:22 -0000 --On Thursday, July 6, 2017 09:11 +1000 Mark Andrews wrote: >... > And the actual presentation limit for LDH with DNS is 253 > (encodes as 255 octets on the wire). Remember URI names do > not have a final period and the each label has length octet > when encoded as a DNS name and the name is terminated by the > root label (0x00) in DNS wire form and the DNS wire name is > limited to 255 octets. Mark, My apologies for nit-picking, but RFC 3986, Section 3.2.2 is quite clear than DNS names in URIs are permitted to have a final period and encouraged to do so under some circumstances. Specifically, "The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain." I don't think that changes the 253 octet limit, but the comment about URIs is misleading and could contribute to an, IMO, already high level of confusion about what RFC 3986 does or does not specify. The same subsection of RFC 3986 also uses the term "host subcomponent" for what you are referring to as a name and allows it to be a "registered name" (or ) that might not be a DNS name or reference at all -- whether it is or not is scheme-dependent. best, john From nobody Thu Jul 6 11:53:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB013190D for ; Thu, 6 Jul 2017 11:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GJHTgiTL5LZz for ; Thu, 6 Jul 2017 11:53:49 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CCE13189B for ; Thu, 6 Jul 2017 11:53:49 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id E7EFE2084A; Thu, 6 Jul 2017 11:53:48 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> Date: Thu, 06 Jul 2017 11:53:47 -0700 In-Reply-To: (Michael StJohns's message of "Thu, 6 Jul 2017 13:42:57 -0400") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 18:53:50 -0000 Michael StJohns writes: > On 7/6/2017 1:40 PM, Wes Hardaker wrote: >> Michael StJohns writes: >> >>> I'm sure you think that... but the small changes you've made to >>> address some of my comments haven't gone far enough. There's also a >>> need for a grammar and syntax pass on the document. >> Thanks for the review and suggested text (the previous messages you sent >> didn't provide as many concrete fixes, so we can now incorporate you >> exact issues now that they're more directed). We'll try to put together >> an update to address the issues you've pointed out shortly (which really >> can't happen till Monday of IETF since we're after cut-off). > > I didn't provide concrete fixes because the general model was missing > the point and the re-write could have been substantial. Now we're > finally on the same page that this only applies to "exclusively > signing with the new keys" we can make progress. It wasn't until this > last version that you'd adopted those changes. We disagreed about the proper way to word it. We always agreed on the idea. It's good to clarify it more completely to ensure everyone else reads that intent though. -- Wes Hardaker USC/ISI From nobody Thu Jul 6 13:32:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADACE12EC1E; Thu, 6 Jul 2017 13:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oi6yI-s-76aQ; Thu, 6 Jul 2017 13:32:41 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BBB126DC2; Thu, 6 Jul 2017 13:32:41 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3x3TvC3hqHz25fP; Thu, 6 Jul 2017 22:32:39 +0200 (CEST) X-purgate-ID: 152705::1499373159-00000810-56044B32/0/0 X-purgate-size: 2009 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3x3TvB1MtmzGnsf; Thu, 6 Jul 2017 22:32:38 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1F32D1A6C7; Thu, 6 Jul 2017 22:32:38 +0200 (CEST) In-Reply-To: <901C29488D8446E4176CF83E@PSB> To: John C Klensin Date: Thu, 6 Jul 2017 22:32:38 +0200 (CEST) CC: Mark Andrews , "Roy T. Fielding" , dnsop , IETF Rinse Repeat Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170706203238.1F32D1A6C7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:32:44 -0000 John C Klensin wrote: > > --On Thursday, July 6, 2017 09:11 +1000 Mark Andrews > wrote: > >>... >> And the actual presentation limit for LDH with DNS is 253 >> (encodes as 255 octets on the wire). Remember URI names do >> not have a final period and the each label has length octet >> when encoded as a DNS name and the name is terminated by the >> root label (0x00) in DNS wire form and the DNS wire name is >> limited to 255 octets. > > My apologies for nit-picking, but RFC 3986, Section 3.2.2 is > quite clear than DNS names in URIs are permitted to have a final > period and encouraged to do so under some circumstances. > Specifically, > > "The rightmost domain label of a fully qualified domain > name in DNS may be followed by a single "." and should > be if it is necessary to distinguish between the > complete domain name and some local domain." Also apologies from my side for nitpicking. While I do believe that final periods on DNS names in URLs should work, they still seem somewhat unusual, and there is a varing amount of breakage around _matching_ DNS names with a final period to names without one in various areas of communication protocols. example: rfc2818 section 3.1 server endpoint identification While _recent_ versions of Firefox & Chrome seem to no longer fail to match them to TLS server certs, users of the blue stuff from Redmond seem to be less lucky and still face cert hostname mismatch errors. (but Google Chrome started delibertatly violating a MUST requirement from rfc2818 3.1 for certs without SANs, so name matching in Chrome _is_ broken, just differently broken). There are other places where the DNS names from URLs will be placed, e.g. TLS extension SNI client-side, TLS extension SNI server-side (virtual hosts), HTTP Host: header fields, Cookies?, Same-origin-policies? and I would not be surprised about more failures comparing DNS names where one carries a final period. -Martin From nobody Thu Jul 6 14:52:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869A7126B7F; Thu, 6 Jul 2017 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 SWzmPiCsgN1O; Thu, 6 Jul 2017 14:52:45 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 25383124217; Thu, 6 Jul 2017 14:52:45 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 97DB924AE0D; Thu, 6 Jul 2017 21:52:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 509F9160047; Thu, 6 Jul 2017 21:52:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 110C4160098; Thu, 6 Jul 2017 21:52:40 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qOdQSm_dyZ_F; Thu, 6 Jul 2017 21:52:39 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 8262B160047; Thu, 6 Jul 2017 21:52:39 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 99A8C7DB2FBA; Fri, 7 Jul 2017 07:52:36 +1000 (AEST) To: Nico Williams Cc: John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> In-reply-to: Your message of "Thu, 06 Jul 2017 10:39:56 -0500." <20170706153955.GB3393@localhost> Date: Fri, 07 Jul 2017 07:52:36 +1000 Message-Id: <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 21:52:46 -0000 In message <20170706153955.GB3393@localhost>, Nico Williams writes: > So new classes will only be useful to extend the IN-class RR type > namespace. We won't get there. New RR types can be very difficult to > deploy due to lack of interest by registrars and domain hosting > services. TXT RRs forever. :( Or you could stop trying to reinforce the myth that new RR types are hard to deploy. They really aren't. They actually get used all the time. > Cheers, > > Nico > -- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jul 6 17:28:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71BF12F28A; Thu, 6 Jul 2017 17:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 s_LIhyIKIJP5; Thu, 6 Jul 2017 17:27:59 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 2166B129AAD; Thu, 6 Jul 2017 17:27:59 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id B6E2B24AE09; Fri, 7 Jul 2017 00:26:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9E46F160047; Fri, 7 Jul 2017 00:26:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 753D5160098; Fri, 7 Jul 2017 00:26:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZQK65qSA3tCX; Fri, 7 Jul 2017 00:26:39 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 00E41160047; Fri, 7 Jul 2017 00:26:39 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E51E97DB60EE; Fri, 7 Jul 2017 10:26:35 +1000 (AEST) Cc: Nico Williams , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat From: Mark Andrews In-reply-to: Your message of "Fri, 07 Jul 2017 07:52:36 +1000." Date: Fri, 07 Jul 2017 10:26:35 +1000 Message-Id: <20170707002635.E51E97DB60EE@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 00:28:01 -0000 As for those that think deploying a new class would be hard the tools that start to lookup records in the class would need to react to error responses like this with a message saying "please install root hints for class50 in your DNS recursive server". [rock:~/git/bind9] marka% dig class50 type1 . ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> class50 type1 . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 60872 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 151e2fd665595893dcd132c0595ecd8c1771012331aceded (good) ;; QUESTION SECTION: ;. CLASS50 A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 07 09:53:48 AEST 2017 ;; MSG SIZE rcvd: 56 [rock:~/git/bind9] marka% In practice the new set of hints will almost certainly already be compiled into the recursive server like root hints for class IN are today with configuration directives to allow them to be overridden. Adding a new class will be mostly transparent. If you care about a name not existing you would need to check all the active classes for NXDOMAIN but otherwise tools would just work like they always had. It requires planning and some lead time before you start to use it in urnest but it is achievable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jul 6 17:44:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CB9129562; Thu, 6 Jul 2017 17:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XckLVaVw8iFw; Thu, 6 Jul 2017 17:44:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 970461293D6; Thu, 6 Jul 2017 17:44:21 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 3DCAA24AE09; Fri, 7 Jul 2017 00:42:58 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D147D160047; Fri, 7 Jul 2017 00:43:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8A298160098; Fri, 7 Jul 2017 00:43:01 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jWbkpEXdm5hh; Fri, 7 Jul 2017 00:43:01 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3B6F8160047; Fri, 7 Jul 2017 00:43:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 541A17DB62A2; Fri, 7 Jul 2017 10:42:59 +1000 (AEST) To: John C Klensin Cc: "Roy T. Fielding" , dnsop , IETF Rinse Repeat From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <20170705031957.834B97D8FBDD@rock.dv.isc.org> <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com> <20170705231101.E23E77D9B7A1@rock.dv.isc.org> <901C29488D8446E4176CF83E@PSB> In-reply-to: Your message of "Thu, 06 Jul 2017 14:04:10 -0400." <901C29488D8446E4176CF83E@PSB> Date: Fri, 07 Jul 2017 10:42:59 +1000 Message-Id: <20170707004259.541A17DB62A2@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 00:44:23 -0000 In message <901C29488D8446E4176CF83E@PSB>, John C Klensin writes: > > > --On Thursday, July 6, 2017 09:11 +1000 Mark Andrews > wrote: > > >... > > And the actual presentation limit for LDH with DNS is 253 > > (encodes as 255 octets on the wire). Remember URI names do > > not have a final period and the each label has length octet > > when encoded as a DNS name and the name is terminated by the > > root label (0x00) in DNS wire form and the DNS wire name is > > limited to 255 octets. > > Mark, > > My apologies for nit-picking, but RFC 3986, Section 3.2.2 is > quite clear than DNS names in URIs are permitted to have a final > period and encouraged to do so under some circumstances. > Specifically, > > "The rightmost domain label of a fully qualified domain > name in DNS may be followed by a single "." and should > be if it is necessary to distinguish between the > complete domain name and some local domain." > > I don't think that changes the 253 octet limit, but the comment > about URIs is misleading and could contribute to an, IMO, > already high level of confusion about what RFC 3986 does or does > not specify. > > The same subsection of RFC 3986 also uses the term "host > subcomponent" for what you are referring to as a name and allows > it to be a "registered name" (or ) that might not be a > DNS name or reference at all -- whether it is or not is > scheme-dependent. > > best, > john Which really should never have been allowed. Beyound the UI everything should be absolute. Relative names in URI really don't work in practice because search lists are not constistent even inside a single organisation. I had my ISP hand me a relative link for their support pages. IT DID NOT WORK. There support line got a call complaining about it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jul 6 20:36:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA912741D; Thu, 6 Jul 2017 20:36: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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 RrKXrtlQN8Dz; Thu, 6 Jul 2017 20:36:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427B61317B0; Thu, 6 Jul 2017 20:36:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dTK4A-000AWp-Sb; Thu, 06 Jul 2017 23:36:26 -0400 Date: Thu, 06 Jul 2017 23:36:21 -0400 From: John C Klensin To: Mark Andrews cc: "Roy T. Fielding" , dnsop , IETF Rinse Repeat Message-ID: <707A073EEBAE4B87504AB9B4@PSB> In-Reply-To: <20170707004259.541A17DB62A2@rock.dv.isc.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <20170705031957.834B97D8FBDD@rock.dv.isc.org> <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com> <20170705231101.E23E77D9B7A1@rock.dv.isc.org> <901C29488D8446E4176CF83E@PSB> <20170707004259.541A17DB62A2@rock.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 03:36:32 -0000 --On Friday, July 7, 2017 10:42 +1000 Mark Andrews wrote: >> The same subsection of RFC 3986 also uses the term "host >> subcomponent" for what you are referring to as a name and >> allows it to be a "registered name" (or ) that >> might not be a DNS name or reference at all -- whether it is >> or not is scheme-dependent. >... > Which really should never have been allowed. Beyound the UI > everything should be absolute. Relative names in URI really > don't work in practice because search lists are not > constistent even inside a single organisation. Mark, it is no secret that I'm not a fan of relative URIs or of 3986 generally. But the latter is, for better or worse, a full standard that went through the IETF process. If you think it is seriously flawed, I'd encourage you to write in I-D to fix it and see if you can get it through the system. My experience predicts that any attempt to do such a thing will produce an outcry about the astronomical number of web pages that contain and depend on such references and the only slightly smaller number of them that are used every day, but maybe you will do better than I did when I tried to get something with far narrower scope through the system. > I had my ISP hand me a relative link for their support pages. > IT DID NOT WORK. There support line got a call complaining > about it. With the above in mind, so? The number of links most of us see a week that don't work --whether the references are relative or absolute-- is rather too large to view one failure as horrible breakage in the model. john From nobody Thu Jul 6 22:53:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D0A12EA58; Thu, 6 Jul 2017 22:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 HMKlTdQ0X7lu; Thu, 6 Jul 2017 22:53:19 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54CE126D45; Thu, 6 Jul 2017 22:53:19 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id D85E1C0028BA; Thu, 6 Jul 2017 22:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bZLi8BEwlnk1FP hFiOr7zO3DpBw=; b=fFPg68NI3ud7kVns8FcFhb7OE2Ftq7vQ0XvGDu0VKzeUZk jafTDJXtCpE+XrU97pgbbQ5Sy4VmpaMGDmBjXTfX4C6rTCB26tTs817dWksBE/ED PQhJUMePIpzJDY7JDpPTrYGt5R6ndAs31gyAiKnRJKSiDjye0Eq1ML38YEP3g= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 2DD34C0028B8; Thu, 6 Jul 2017 22:53:18 -0700 (PDT) Date: Fri, 7 Jul 2017 00:53:16 -0500 From: Nico Williams To: Mark Andrews Cc: John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat Message-ID: <20170707055315.GC3393@localhost> References: <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 05:53:21 -0000 On Fri, Jul 07, 2017 at 07:52:36AM +1000, Mark Andrews wrote: > In message <20170706153955.GB3393@localhost>, Nico Williams writes: > > So new classes will only be useful to extend the IN-class RR type > > namespace. We won't get there. New RR types can be very difficult to > > deploy due to lack of interest by registrars and domain hosting > > services. TXT RRs forever. :( > > Or you could stop trying to reinforce the myth that new RR types > are hard to deploy. They really aren't. They actually get used > all the time. I'm well aware that as to clients and servers, deploying new RR types is easy. The hard part is the management backend and UIs. Not all of them allow you to enter raw RDATA (hex-encoded or whatever). We've struggled with this in KITTEN WG. Deploying the URI RR type when you're using a hosting service can be anywhere from annoying (must enter raw RDATA) to impossible (the hosting service doesn't give a damn). I suppose it's just a matter of time; perhaps things have improved since we last looked. Nico -- From nobody Thu Jul 6 23:56:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6C126579; Thu, 6 Jul 2017 23:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3rum1OPm5FkA; Thu, 6 Jul 2017 23:56:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 D2B8D131445; Thu, 6 Jul 2017 23:56:42 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 7711E3493BB; Fri, 7 Jul 2017 06:56:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 511BD16004A; Fri, 7 Jul 2017 06:56:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 26D79160055; Fri, 7 Jul 2017 06:56:40 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C8rb3xHjmOAA; Fri, 7 Jul 2017 06:56:40 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CC55D16004A; Fri, 7 Jul 2017 06:56:39 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EB9C07DBDEF2; Fri, 7 Jul 2017 16:56:37 +1000 (AEST) To: Nico Williams Cc: John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat From: Mark Andrews References: <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170707055315.GC3393@localhost> In-reply-to: Your message of "Fri, 07 Jul 2017 00:53:16 -0500." <20170707055315.GC3393@localhost> Date: Fri, 07 Jul 2017 16:56:37 +1000 Message-Id: <20170707065637.EB9C07DBDEF2@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 06:56:44 -0000 In message <20170707055315.GC3393@localhost>, Nico Williams writes: > On Fri, Jul 07, 2017 at 07:52:36AM +1000, Mark Andrews wrote: > > In message <20170706153955.GB3393@localhost>, Nico Williams writes: > > > So new classes will only be useful to extend the IN-class RR type > > > namespace. We won't get there. New RR types can be very difficult to > > > deploy due to lack of interest by registrars and domain hosting > > > services. TXT RRs forever. :( > > > > Or you could stop trying to reinforce the myth that new RR types > > are hard to deploy. They really aren't. They actually get used > > all the time. > > I'm well aware that as to clients and servers, deploying new RR types is > easy. The hard part is the management backend and UIs. Not all of them > allow you to enter raw RDATA (hex-encoded or whatever). > > We've struggled with this in KITTEN WG. Deploying the URI RR type when > you're using a hosting service can be anywhere from annoying (must enter > raw RDATA) to impossible (the hosting service doesn't give a damn). I > suppose it's just a matter of time; perhaps things have improved since > we last looked. Then change domain hosting providers and tell them why or run you own master server or use a service which allows for dynamic updates which shouldn't care about the record types. There are plenty of DNS providers that will slave content. As a DNS server vendor we get requests to add the new type within days the type being allocated. We usually already have code written and merged to support the new type in all current branches before those request come in as we poll the type registry daily. It is available over git to anyone that wants to pull it down support for the new type prior to the next maintainence releases. Adding a new type is as simple as adding to files to the source tree and rebuilding the tools. Once that is done all the tools we ship support it. Mark > Nico > -- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jul 7 06:32:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C88127B73; Fri, 7 Jul 2017 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, URIBL_BLOCKED=0.001] autolearn=no 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 GQLYnXr00x1M; Fri, 7 Jul 2017 06:32:34 -0700 (PDT) Received: from agwe.difference.com.au (unknown [103.4.235.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFD8129B10; Fri, 7 Jul 2017 06:32:34 -0700 (PDT) Received: from [192.168.0.195] (unknown [1.126.11.186]) by agwe.difference.com.au (Postfix) with ESMTPSA id E03DD154058; Fri, 7 Jul 2017 23:32:30 +1000 (AEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: David Cake In-Reply-To: Date: Fri, 7 Jul 2017 15:32:21 +0200 Cc: Paul Vixie , dnsop , IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: <33235E8D-147D-4178-BC45-DFC1E1C27B99@davecake.net> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> To: Randy Bush X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:32:37 -0000 If you have a single centralised root for your new class, you will = probably either recreate the problems of ICANN, or create one or more of = the problems that ICANN has very consciously tried to avoid. If you have a system of name resolution that avoids the need for a = centralised root, you probably don=E2=80=99t need a new class to = implement it.=20 The few marginal cases that need to interact with the one root but not = be ICANN controlled are why we have the RFC 6761 process.=20 I agree a taxa of needs that do not fit within those three cases would = have been useful.=20 David > On 5 Jul 2017, at 10:47 am, Randy Bush wrote: >=20 > i think avoiding icann is a red herring. if the draft in question had > done a decent job of exploring the taxa of needs for name resolution > outside of the 'normal' topology, we would have the start of a base on > which to discuss this. >=20 > randy >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Jul 7 08:09:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1CF131636; Fri, 7 Jul 2017 08:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 pLNCyiHikIgJ; Fri, 7 Jul 2017 08:09:35 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681AB131610; Fri, 7 Jul 2017 08:09:35 -0700 (PDT) Received: from [10.170.78.140] (adsl-70-234-237-173.dsl.rcsntx.sbcglobal.net [70.234.237.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9209C61FF3; Fri, 7 Jul 2017 15:09:34 +0000 (UTC) Message-ID: <595FA42A.7050604@redbarn.org> Date: Fri, 07 Jul 2017 08:09:30 -0700 From: Paul Vixie User-Agent: Postbox 5.0.15 (Windows/20170609) MIME-Version: 1.0 To: Nico Williams CC: Mark Andrews , John C Klensin , dnsop , Phillip Hallam-Baker , IETF Rinse Repeat References: <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170707055315.GC3393@localhost> In-Reply-To: <20170707055315.GC3393@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 15:09:36 -0000 Nico Williams wrote: > ... > > I'm well aware that as to clients and servers, deploying new RR types is > easy. The hard part is the management backend and UIs. Not all of them > allow you to enter raw RDATA (hex-encoded or whatever). > > We've struggled with this in KITTEN WG. Deploying the URI RR type when > you're using a hosting service can be anywhere from annoying (must enter > raw RDATA) to impossible (the hosting service doesn't give a damn). I > suppose it's just a matter of time; perhaps things have improved since > we last looked. that would be a prior restraint, and bad for innovation. just like middle boxes or the nearly universal assumption that ip means tcp or udp. i know this kind of thinking is common. but there is a stark choice for all of us: do all of our future protocol work on tcp/80 and make everything fit in JSON, so that we can get our work done; or keep doing what the internet used to mean, and eventually put enough stress on middle box makers, isp's, and in your case dns hosting services, that they have to learn about the internet rather than just the web. i know which future i'd rather live in. i also feel in-year pressure to get my work done. i vacillate as to who gets to receive which burdens. -- P Vixie From nobody Fri Jul 7 09:35:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382891316BB; Fri, 7 Jul 2017 09:35:18 -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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 MA1RWBtj8wMD; Fri, 7 Jul 2017 09:35:16 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E76E1316B2; Fri, 7 Jul 2017 09:35:16 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id DAED8C086D10; Fri, 7 Jul 2017 09:35:15 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 51E03C086D08; Fri, 7 Jul 2017 09:35:15 -0700 (PDT) Date: Fri, 7 Jul 2017 11:35:13 -0500 From: Nico Williams To: Mark Andrews Cc: John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat Message-ID: <20170707163511.GD3393@localhost> References: <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170707055315.GC3393@localhost> <20170707065637.EB9C07DBDEF2@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170707065637.EB9C07DBDEF2@rock.dv.isc.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 16:35:18 -0000 On Fri, Jul 07, 2017 at 04:56:37PM +1000, Mark Andrews wrote: > In message <20170707055315.GC3393@localhost>, Nico Williams writes: > > We've struggled with this in KITTEN WG. Deploying the URI RR type when > > you're using a hosting service can be anywhere from annoying (must enter > > raw RDATA) to impossible (the hosting service doesn't give a damn). I > > suppose it's just a matter of time; perhaps things have improved since > > we last looked. > > Then change domain hosting providers and tell them why or run you > own master server or use a service which allows for dynamic updates > which shouldn't care about the record types. There are plenty of > DNS providers that will slave content. That's easy enough if *I* am the user. Of course I can change hosting providers. However, it's NOT easy when your *customer* is the user that has to change hosting providers -- they'll balk, and you'll just work around it. In the KITTEN WG case there definitely was a vendor who needed to support customers who use hosting providers that didn't support the URI RR type. Can you blame them for not wanting to go with the URI RR type? Sure we should do it anyways -- it might help. But that vnedor will still have to cope with cases where URI is not available, and that actually means falling back onto alternative, possibly slower, methods that need to be specified too and which might have annoying knock-on effects. (In the KITTEN WG case the idea is to improve discovery of Kerberos KDC services. We currently use SRV RRs, but this requires multiple requests, and every time we add a new transport we need to add more requests. One could parallelize the requests, but that's not necessarily very nice, and anyways, it sucks from a resolver API perspective. A URI RR type would solve the problem. But if you have to fallback then you've slowed things down for what might be the common case.) > As a DNS server vendor we get requests to add the new type within > days the type being allocated. We usually already have code written > and merged to support the new type in all current branches before > those request come in as we poll the type registry daily. It is > available over git to anyone that wants to pull it down support for > the new type prior to the next maintainence releases. Adding a new > type is as simple as adding to files to the source tree and rebuilding > the tools. Once that is done all the tools we ship support it. Of course. *You* are NOT the problem. That's great. The problem is always some knucklehead somewhere who doesn't care to fix *their* system. Nico -- From nobody Fri Jul 7 09:37:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F701316C5; Fri, 7 Jul 2017 09:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 HhRSBEW36Ft3; Fri, 7 Jul 2017 09:37:42 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF71129AAA; Fri, 7 Jul 2017 09:37:42 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 1F6DFC086D0C; Fri, 7 Jul 2017 09:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HfHTLw0Xajipqk WJUexbsofUDl0=; b=PMiMCnU69GThxmor1AE0iVA1ZJxwy5r7p4Y0jfKYDBeLLB 71Smoj2jKXwBC1sBsLPNUcSt1cuDzJ3d90cJI6thaiQXsNwni0f3/04lzhWXxbDF sKgi3SLRBzh6n3DSexbKC3sj0ldJC9bwlwzA8lK7GpentsljmS7Imu1Ris4zw= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 5BC08C086D08; Fri, 7 Jul 2017 09:37:41 -0700 (PDT) Date: Fri, 7 Jul 2017 11:37:39 -0500 From: Nico Williams To: Paul Vixie Cc: Mark Andrews , John C Klensin , dnsop , Phillip Hallam-Baker , IETF Rinse Repeat Message-ID: <20170707163738.GE3393@localhost> References: <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170707055315.GC3393@localhost> <595FA42A.7050604@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <595FA42A.7050604@redbarn.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 16:37:44 -0000 On Fri, Jul 07, 2017 at 08:09:30AM -0700, Paul Vixie wrote: > Nico Williams wrote: > >... > > > >I'm well aware that as to clients and servers, deploying new RR types is > >easy. The hard part is the management backend and UIs. Not all of them > >allow you to enter raw RDATA (hex-encoded or whatever). > > > >We've struggled with this in KITTEN WG. Deploying the URI RR type when > >you're using a hosting service can be anywhere from annoying (must enter > >raw RDATA) to impossible (the hosting service doesn't give a damn). I > >suppose it's just a matter of time; perhaps things have improved since > >we last looked. > > that would be a prior restraint, and bad for innovation. just like middle > boxes or the nearly universal assumption that ip means tcp or udp. i know > this kind of thinking is common. but there is a stark choice for all of us: > do all of our future protocol work on tcp/80 and make everything fit in > JSON, so that we can get our work done; or keep doing what the internet used > to mean, and eventually put enough stress on middle box makers, isp's, and > in your case dns hosting services, that they have to learn about the > internet rather than just the web. > > i know which future i'd rather live in. i also feel in-year pressure to get > my work done. i vacillate as to who gets to receive which burdens. I'm with you on this. I badly want to be able to use new RR types without further ado. I would prefer to push on the middleboxes and middlepeople -- but we need to do a better job of this altogether so that we don't have to wait a decade. We don't have a spec police, so all we can do is nag. Nico -- From nobody Fri Jul 7 09:46:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05F9131765; Fri, 7 Jul 2017 09:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 lqM2my8a6vRd; Fri, 7 Jul 2017 09:46:44 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB1913173B; Fri, 7 Jul 2017 09:46:44 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 302A5C086D08; Fri, 7 Jul 2017 09:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tkXLYYz+H2KIf+ 33XQ9dvYBEMns=; b=ZNznOIQKnltqn6TJbIffjH6CP9+n5t4IfDIIBhoP+KzPGD nA/m/bqKI5GeVjFSfp8bRVU2shwhaMKgYUt2T+fBLnGb3GdKJaDZGtbR2U/VQt1x np2W1o/zwJyp3rTfX1UHUJAsx/0R2Mlfia5CVNlSa9yY5y+CSEnGgwoIB9m+U= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 3EF6BC0028BA; Fri, 7 Jul 2017 09:46:43 -0700 (PDT) Date: Fri, 7 Jul 2017 11:46:41 -0500 From: Nico Williams To: Paul Vixie Cc: Mark Andrews , John C Klensin , dnsop , Phillip Hallam-Baker , IETF Rinse Repeat Message-ID: <20170707164639.GF3393@localhost> References: <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170707055315.GC3393@localhost> <595FA42A.7050604@redbarn.org> <20170707163738.GE3393@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170707163738.GE3393@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 16:46:46 -0000 On Fri, Jul 07, 2017 at 11:37:39AM -0500, Nico Williams wrote: > On Fri, Jul 07, 2017 at 08:09:30AM -0700, Paul Vixie wrote: > > Nico Williams wrote: > > >... > > > > ... > > > > i know which future i'd rather live in. i also feel in-year pressure to get > > my work done. i vacillate as to who gets to receive which burdens. > > I'm with you on this. [...] I should add too that in order to do better at pushing on middleboxes we need to acknowledge the problem. Please don't tell me to stop spreading the myth that it's difficult to deploy new RR types! Work with us to fix the problem, and recognize that it is largely a social one. If we ever want to use CLASSes to expand the RR type namespace, we'll definitely need even more support from clients/servers/providers. So it's worth considering that now rather than later, because we shouldn't want to have to go through this middlebox un-break exercise multiple times. I would even suggest that we immediately add such a new class or three just to be able to test compliance. This wouldn't preclude new classes that aren't IN RR type namespace extension classes. Nico -- From nobody Fri Jul 7 09:55:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032AC131777; Fri, 7 Jul 2017 09:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 YCt0BkIFOq9D; Fri, 7 Jul 2017 09:55:17 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB73131769; Fri, 7 Jul 2017 09:55:17 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 29843C0028BA; Fri, 7 Jul 2017 09:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Y2mfow/2aEnPdOy54Gra5zwUJN8=; b=cSQB3oqhF8/ 3/OHAYJiwPrJzyV9UQp7sAERg5/sDslJwrVFYSJ854Smdnlob+ebCGAl2ztiwqPk qSkDIVg5b3GgUIfV/ZFFeaDpKNGUypbmA81S4VfQ78dj7JIzQHZ3GCEypQ+Cobua zblOxcYChvLESMReTCISAFB4i1eMVTFw= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 5398BC086D0C; Fri, 7 Jul 2017 09:55:16 -0700 (PDT) Date: Fri, 7 Jul 2017 11:55:14 -0500 From: Nico Williams To: David Cake Cc: Randy Bush , dnsop , Paul Vixie , IETF Rinse Repeat Message-ID: <20170707165513.GG3393@localhost> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <33235E8D-147D-4178-BC45-DFC1E1C27B99@davecake.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <33235E8D-147D-4178-BC45-DFC1E1C27B99@davecake.net> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 16:55:19 -0000 On Fri, Jul 07, 2017 at 03:32:21PM +0200, David Cake wrote: > > On 5 Jul 2017, at 10:47 am, Randy Bush wrote: > >=20 > > i think avoiding icann is a red herring. if the draft in question ha= d > > done a decent job of exploring the taxa of needs for name resolution > > outside of the 'normal' topology, we would have the start of a base o= n > > which to discuss this. >=20 > If you have a single centralised root for your new class, you will > probably either recreate the problems of ICANN, or create one or more > of the problems that ICANN has very consciously tried to avoid. If > you have a system of name resolution that avoids the need for a > centralised root, you probably don=E2=80=99t need a new class to implem= ent it. > The few marginal cases that need to interact with the one root but not > be ICANN controlled are why we have the RFC 6761 process.=20 >=20 > I agree a taxa of needs that do not fit within those three cases would > have been useful.=20 Well, there's a) the rooted hierarchy of the public DNS (IN class), b) mDNS (which isn't really DNS, just a local discovery mechanism based on the DNS protocol), c) the HS class, which traditionally wasn't used in a federated manner (but maybe I'm wrong about that), so it doesn't need a rooted hierarchy, though it also could use one. (b) and (c) are niches, with no real place on the open, public Internet. One could use something like HS as an alternative to LDAP, say, but recall that the vision of a world of federated and open directories never materialized NOT because of limitations of DAP/LDAP, but because of confidentiality/ privacy considerations. Such a class would really need to use the same rooted hierarchy, and, really, the same root, as the public DNS IN class -- i.e., an IN RR type namespace extension class, so it's best to consider such a class in those terms rather than as a "directory class". I am having a very difficult time imagining, say, a peer-to-peer or web-of-trust DNS (other than mDNS). Perhaps my imagination fails me. A rooted hierarchy is and has been incredibly useful, and the simplest method of providing a consisten Internet to all users. It seems to me very unlikely that we'll ever move from that. At most we may have alternative roots, but a mostly common set of TLDs (e.g., as happens in many private (corporate) networks). Nico --=20 From nobody Fri Jul 7 11:18:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EF11317C2 for ; Fri, 7 Jul 2017 11:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.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 vrudpv5apgYt for ; Fri, 7 Jul 2017 11:18:45 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 600F5131803 for ; Fri, 7 Jul 2017 11:18:12 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id t186so20904192pgb.1 for ; Fri, 07 Jul 2017 11:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=INc4g4aQKmd8qjvTeOIoFypi3Nz/yXLa0WXXgnb3AD4=; b=sbK2trJB/uXopVoA7BurAuKp1jFllSvWPKoaPiZ+C0sjdRNOepOyry+GaCmJg7nGvj lpewim2LsOpkxQZJRIsdnU1eWlhI5ZBxcHj5V260hKdeQ2tDYsvSfXwcmyGzDxSv5oXZ e8EF+UT+ohUd6cKiGOHg9s5VFDc9dmt2OP7aWmBRaFPZc4B355v19QGL5mwt4kvue10a WM6G1ldDb0YhaZVH6MuEL2m4P3huDSQSdcxY9lAax8jgy43/z3jTP7XHtSCdIi5LvB16 dAi43ZTQZ/uG+mNHE/Hm00/N4gPSVmZ8Z+bH1rWaoTUKE061W59AziLCZKq+K8Kc6dNt v2cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=INc4g4aQKmd8qjvTeOIoFypi3Nz/yXLa0WXXgnb3AD4=; b=UJiB1BFIuZdWB8XUs3PLwoAHTHy2zqE1+nO5xlCiMv7zuF8CMLd2TYIJT/llQ+alzG g72CqCn6tTDvlo5tTFfY6+ozpSEyxQoAOSl0bZnHNzuGNQlevqFNNJAGXLQu/Au9lyv0 2hxClrDbuZb1nddimfiCLIigk/A+b1I+/Xi5Hql05QfjKvYtqAS1LV2eNIuV3aosg2KY JDbDDfaPGYzDdT4bXb8ZEWsRhSGETRKtRqIsBzSda3sor73F3p6BQEvELSFIJ9EHoJqh 1heUH1Wk+g5ZEpo+7gTMRzhI4SzCI7zot3YJn5Fpe4fgc5bwH8EOurQzSBlQAYh4LKs6 8F3A== X-Gm-Message-State: AIVw1116w6nFkScNc80OSRgL0ghC0TuNW1UbLtcePBji6hRf2mYK/Ks+ 01hrDQvCBQU+c//4 X-Received: by 10.84.215.135 with SMTP id l7mr4429955pli.194.1499451491804; Fri, 07 Jul 2017 11:18:11 -0700 (PDT) Received: from [192.168.7.50] (c-24-6-172-77.hsd1.ca.comcast.net. [24.6.172.77]) by smtp.gmail.com with ESMTPSA id s64sm10021276pfd.77.2017.07.07.11.18.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 11:18:10 -0700 (PDT) Date: Fri, 7 Jul 2017 09:32:09 -0700 From: David Conrad To: Nico Williams , Mark Andrews Cc: John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Rinse Repeat Message-ID: <61283000-0504-43f5-a0b0-65e48e399efc@Spark> In-Reply-To: <20170707065637.EB9C07DBDEF2@rock.dv.isc.org> References: <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170707055315.GC3393@localhost> <20170707065637.EB9C07DBDEF2@rock.dv.isc.org> X-Readdle-Message-ID: 61283000-0504-43f5-a0b0-65e48e399efc@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="595fd061_6b8b4567_624" Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:18:47 -0000 --595fd061_6b8b4567_624 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Mark, On Jul 6, 2017, 11:56 PM -0700, Mark Andrews , wrote: > > > Or you could stop trying to reinforce the myth that new RR types > > > are hard to deploy. They really aren't. Please stop trying to minimize the amount of work here. They really are. = Not for you, but for the folks who make domain names available for use by= non-technical types. > Then change domain hosting providers and tell them why or run you > own master server or use a service which allows for dynamic updates > which shouldn't care about the record types. There are plenty of > DNS providers that will slave content. The number of folks who even understand what you've written above, much l= ess can actually do it, is insignificant in the context of seeing signifi= cant adoption of new RRs. > As a DNS server vendor You need to look at the wider world. The DNS server side of deploying a new RR is the easiest part and while n= ecessary, it's no where even close to sufficient to getting a new RR depl= oyed. It's like trying to move the automobile industry to hydrogen fuel: = building a car that runs on hydrogen is easy, relatively speaking. Howeve= r to actually do anything useful with that car, you need need to modify t= he fuel delivery infrastructure, which is vastly harder, involves a vastl= y larger set of players, very few of which have any sort of financial inc= entive to make the change. Standard chicken-or-egg problem. ICANN funded John Levine to develop=C2=A0https://metacpan.org/release/JRL= EVINE/Net-DNS-Extlang-0.1 to try to make it easier to break the chicken-o= r-egg problem by hopefully giving the folks who provide the UIs by which = domain names are managed by non-geeks better tools. However, that's just = the first step -- the domain name managers still need to be encouraged to= use them. =C2=A0Pretending this is an easy problem isn't helping. Regards, -drc --595fd061_6b8b4567_624 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mark,

On Jul 6, 2017, 11:56 PM -0700, Mark Andrews <marka=40isc.org>, wro= te:
Or you could stop trying to re= inforce the myth that new RR types
are hard to deploy. They really aren't.

Please stop trying to minimize the amount of work here. They really are. = Not for you, but for the folks who make domain names available for use by= non-technical types.

Then change domain hosting pro= viders and tell them why or run you
own master server or use a service which allows for dynamic updates
= which shouldn't care about the record types. There are plenty of
DNS providers that will slave content.&=23160;

The number of folks who even understand what you've written above, m= uch less can actually do it, is insignificant in the context of seeing si= gnificant adoption of new RRs.&=23160;

As a DNS server vendor &=23160= ;

You need to look at the wider world.

The DNS server side of deploying a new RR is the easiest part and wh= ile necessary, it's no where even close to sufficient to getting a new RR= deployed. It's like trying to move the automobile industry to hydrogen f= uel: building a car that runs on hydrogen is easy, relatively speaking. H= owever to actually do anything useful with that car, you need need to mod= ify the fuel delivery infrastructure, which is vastly harder, involves a = vastly larger set of players, very few of which have any sort of financia= l incentive to make the change. Standard chicken-or-egg problem.

ICANN funded John Levine to develop&=23160;https://metacpan.org/rele= ase/JRLEVINE/Net-DNS-Extlang-0.1 to try to make it easier to break the ch= icken-or-egg problem by hopefully giving the folks who provide the UIs by= which domain names are managed by non-geeks better tools. However, that'= s just the first step -- the domain name managers still need to be encour= aged to use them. &=23160;Pretending this is an easy problem isn't helpin= g.

Regards,
-drc
--595fd061_6b8b4567_624-- From nobody Fri Jul 7 11:27:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387C13162F; Fri, 7 Jul 2017 11:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, 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=gmail.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 BKDZkK-TBt8T; Fri, 7 Jul 2017 11:27:46 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 941BD1275AB; Fri, 7 Jul 2017 11:27:46 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m84so1432175ita.0; Fri, 07 Jul 2017 11:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/RfGFmSWwIV6Va3Gv2F7w4L60uerI1klCPmqZbtIFtg=; b=AM1/OLJLfzTWwXVCLXMisolAjG8r+iEKJXWAsCuvcit5zNBACc2JfU50PRNvScnCtw ab/I0yznMVUkKysULeLUUGv715E3iodz4jM+Pnye36XZ3WbO2P/UyudPQzVD2FtxMKBE 6h2erVh90k+nxWahjYiWpJ5Np3bwdz45lLl3KtU7CN/8AlccdO164vjfzhKZZ9nljDLD HvvAAqpbDJxOlAFdUIh+p6fCA7J22m0Ga2cdtrRU8ce7YAJybAMIwmqalgA8J6Trpqgz ePYTFdKmqScMwT90sr8X95akprtyvq41zkkUW228UBm2wxUeBtAmEALbebWVY63t/y+4 9gag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/RfGFmSWwIV6Va3Gv2F7w4L60uerI1klCPmqZbtIFtg=; b=k2JWHSQt9HlMJO4NL4jLcITUbmXjNQYnPaBfVnCuinBw1WV+bfyBgtMCpsmRGOzx6U B4cc549PuZAaslF8brPiTOKrgZZ0IOpOuOC3HlBULA1p+C+lxiJ3BzDNF1TK0DZKIJcY H0huRbuerwAJtYbMWT1hqZ6oi8C5ZPwLoIdNywxAkRDonq2pWCWYSJwiCXVBLfO01+r6 7h07Ayb+9xP2XqX1r6IFjsmuW9bo/W5Q90m6+MR4thYih9pQm9Zk2UTxBaHiFYeXWcyy Wfhlps8DRmEzzKmJE/gMZaHwCyuD1SWawVpce4bfQt6rfWDL0ypyyMkn5gcnfTxpSExl v8NA== X-Gm-Message-State: AIVw113H/fA8qQrdcYdIzPd8E+DfrHhFMbbgh1RrBsrL8FIbt8oss8gj F3379SLy8wrtIGlVa9zPgWMkw4Emeg== X-Received: by 10.36.248.4 with SMTP id a4mr249978ith.69.1499452065951; Fri, 07 Jul 2017 11:27:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.18.170 with HTTP; Fri, 7 Jul 2017 11:27:45 -0700 (PDT) In-Reply-To: <20170707165513.GG3393@localhost> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <33235E8D-147D-4178-BC45-DFC1E1C27B99@davecake.net> <20170707165513.GG3393@localhost> From: william manning Date: Fri, 7 Jul 2017 11:27:45 -0700 Message-ID: To: Nico Williams Cc: David Cake , Randy Bush , dnsop , Paul Vixie , IETF Rinse Repeat Content-Type: multipart/alternative; boundary="94eb2c0b1cb4bfb7fa0553be63aa" Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:27:48 -0000 --94eb2c0b1cb4bfb7fa0553be63aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You need a better imagination then. mDNS is a crippled DNS implementation that was hobbled on purpose. HS was/is an entirely different addressing scheme that emerged from project Athena @ MIT. To the extent that when all you have been given is the IN class and it's associated rooted hierarchy, you first,second,&third inclination is to treat EVERYTHING as being easily integrated into that model. And the ietf is going to go right along with you. After all, when all you have is a hammer, everything looks like a nail. On Saturday, July 8, 2017, Nico Williams wrote: > On Fri, Jul 07, 2017 at 03:32:21PM +0200, David Cake wrote: > > > On 5 Jul 2017, at 10:47 am, Randy Bush > > wrote: > > > > > > i think avoiding icann is a red herring. if the draft in question ha= d > > > done a decent job of exploring the taxa of needs for name resolution > > > outside of the 'normal' topology, we would have the start of a base o= n > > > which to discuss this. > > > > If you have a single centralised root for your new class, you will > > probably either recreate the problems of ICANN, or create one or more > > of the problems that ICANN has very consciously tried to avoid. If > > you have a system of name resolution that avoids the need for a > > centralised root, you probably don=E2=80=99t need a new class to implem= ent it. > > The few marginal cases that need to interact with the one root but not > > be ICANN controlled are why we have the RFC 6761 process. > > > > I agree a taxa of needs that do not fit within those three cases would > > have been useful. > > Well, there's a) the rooted hierarchy of the public DNS (IN class), > b) mDNS (which isn't really DNS, just a local discovery mechanism based > on the DNS protocol), c) the HS class, which traditionally wasn't used > in a federated manner (but maybe I'm wrong about that), so it doesn't > need a rooted hierarchy, though it also could use one. (b) and (c) are > niches, with no real place on the open, public Internet. > > One could use something like HS as an alternative to LDAP, say, but > recall that the vision of a world of federated and open directories > never materialized NOT because of limitations of DAP/LDAP, but because > of confidentiality/ privacy considerations. Such a class would really > need to use the same rooted hierarchy, and, really, the same root, as > the public DNS IN class -- i.e., an IN RR type namespace extension > class, so it's best to consider such a class in those terms rather than > as a "directory class". > > I am having a very difficult time imagining, say, a peer-to-peer or > web-of-trust DNS (other than mDNS). Perhaps my imagination fails me. > > A rooted hierarchy is and has been incredibly useful, and the simplest > method of providing a consisten Internet to all users. It seems to me > very unlikely that we'll ever move from that. At most we may have > alternative roots, but a mostly common set of TLDs (e.g., as happens in > many private (corporate) networks). > > Nico > -- > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c0b1cb4bfb7fa0553be63aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You need a better imagination then. =C2=A0 mDNS is a crippled DNS implement= ation that was hobbled on purpose. =C2=A0 HS was/is an entirely different a= ddressing scheme that emerged from project Athena @ MIT.=C2=A0 To the exten= t that when all you have been given is the IN class and it's associated= rooted hierarchy, you first,second,&third inclination is to treat EVER= YTHING as being easily integrated into that model.=C2=A0 And the ietf is go= ing to go right along with you. =C2=A0 After all, when all you have is a ha= mmer, everything looks like a nail.

On Saturday, July 8, 2017, Nico = Williams <nico@cryptonector.com= > wrote:
On Fri, Jul 07, 2017 at 0= 3:32:21PM +0200, David Cake wrote:
> > On 5 Jul 2017, at 10:47 am, Randy Bush <randy@psg= .com> wrote:
> >
> > i think avoiding icann is a red herring.=C2=A0 if the draft in qu= estion had
> > done a decent job of exploring the taxa of needs for name resolut= ion
> > outside of the 'normal' topology, we would have the start= of a base on
> > which to discuss this.
>
> If you have a single centralised root for your new class, you will
> probably either recreate the problems of ICANN, or create one or more<= br> > of the problems that ICANN has very consciously tried to avoid.=C2=A0 = If
> you have a system of name resolution that avoids the need for a
> centralised root, you probably don=E2=80=99t need a new class to imple= ment it.
> The few marginal cases that need to interact with the one root but not=
> be ICANN controlled are why we have the RFC 6761 process.
>
> I agree a taxa of needs that do not fit within those three cases would=
> have been useful.

Well, there's a) the rooted hierarchy of the public DNS (IN class),
b) mDNS (which isn't really DNS, just a local discovery mechanism based=
on the DNS protocol), c) the HS class, which traditionally wasn't used<= br> in a federated manner (but maybe I'm wrong about that), so it doesn'= ;t
need a rooted hierarchy, though it also could use one.=C2=A0 (b) and (c) ar= e
niches, with no real place on the open, public Internet.

One could use something like HS as an alternative to LDAP, say, but
recall that the vision of a world of federated and open directories
never materialized NOT because of limitations of DAP/LDAP, but because
of confidentiality/ privacy considerations.=C2=A0 Such a class would really=
need to use the same rooted hierarchy, and, really, the same root, as
the public DNS IN class -- i.e., an IN RR type namespace extension
class, so it's best to consider such a class in those terms rather than=
as a "directory class".

I am having a very difficult time imagining, say, a peer-to-peer or
web-of-trust DNS (other than mDNS).=C2=A0 Perhaps my imagination fails me.<= br>
A rooted hierarchy is and has been incredibly useful, and the simplest
method of providing a consisten Internet to all users.=C2=A0 It seems to me=
very unlikely that we'll ever move from that.=C2=A0 At most we may have=
alternative roots, but a mostly common set of TLDs (e.g., as happens in
many private (corporate) networks).

Nico
--

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnsop
--94eb2c0b1cb4bfb7fa0553be63aa-- From nobody Fri Jul 7 11:41:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07BA128DE5; Fri, 7 Jul 2017 11:41: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 yu3pa78foC8V; Fri, 7 Jul 2017 11:41:28 -0700 (PDT) Received: from alexa-out-lv-02.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290FA126C0F; Fri, 7 Jul 2017 11:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1499452888; x=1530988888; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=FZElHdLr959RonMfR2E+2l2LoxaJjUcPuAQDhl3jHWM=; b=K4W6K2ReEEHrk3gEgBZRPMoQyMjE6lIa1HXVmGMtCzV9QpeKRSMipWJL kT/J6XsqhH46hapOR0PXKdywJPlwP8N9+GTUx6mJ4zcBuu9QNvCSW9CTn PYNKmNA7DJXmiFjfE3wgYEanjZ9gKL96MHW4FsQDttdpqKPRhWbVBEkuh 0=; X-IronPort-AV: E=Sophos;i="5.40,324,1496127600"; d="scan'208";a="454653" Received: from ironmsg04-l-new.qualcomm.com (HELO Ironmsg04-L.qualcomm.com) ([10.53.140.111]) by alexa-out-lv-02.qualcomm.com with ESMTP; 07 Jul 2017 11:41:27 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8584"; a="1383125604" X-MGA-submission: =?us-ascii?q?MDHtIBtne2XriEwECItyfgLXlYN6Ix2vXEmlF5?= =?us-ascii?q?JDfRquCNHVkGgI6roXfKQLIoaixN0pw9hu8o/3Ao4U8qyqQvyma2/nTt?= =?us-ascii?q?Y9C0yfYygSrb6QpfvMYFb0PdKxiMLWGJadH5WvPR57sG+uaSdsGUo3GK?= =?us-ascii?q?be?= Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jul 2017 11:41:27 -0700 Received: from [10.64.110.227] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 7 Jul 2017 11:41:26 -0700 From: Pete Resnick To: Mark Andrews CC: Nico Williams , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Date: Fri, 7 Jul 2017 13:41:24 -0500 Message-ID: In-Reply-To: <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:41:30 -0000 [Apologies for the re-send. Using the correct address.] On 6 Jul 2017, at 16:52, Mark Andrews wrote: > Or you could stop trying to reinforce the myth that new RR types > are hard to deploy. They really aren't. They actually get used > all the time. I'm running the latest version of MacOS Server. I can't get a new RR type into the UI. Even if I use the command line "dnsconfig" tool, I can't add a record of a type it doesn't know about; I only get A, AAAA, CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in the BIND configs that underly their implementation. And at that point I say, "New RR types are hard to deploy; not a myth." Telling me I can use a different operating system or not use a validating UI is not a reasonable response. The fact is the DNS doesn't provide a way for implementations to dynamically update the RR types to provide sensible UI; it's left as an exercise for each individual implementer. (Yes, I know about draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.) You can't much complain about the difficulty of deployment when the community won't provide the tools to make deployment easier. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Jul 7 12:14:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC8131690; Fri, 7 Jul 2017 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 N111kaPinebh; Fri, 7 Jul 2017 12:14:51 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A0313168F; Fri, 7 Jul 2017 12:14:51 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 7507EC086D10; Fri, 7 Jul 2017 12:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ztW/XQD1COjUjI oAitweYzDMliw=; b=Gdnm8OVof5gmfRMLwF7naF5WA5RehNdzU0UC/9x71L/mtH AjYmeFuNb5Anx+0EMvJJrKVyXAJarwaxRNJlxL6jjuJS9Et6Zjy9douPUWeCIZH0 KZW0MIhm1IILGJGUvH2QOj6dw17ce/4pqarUA3ANGuu/2JeMQa+yC/vESyM4Q= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id D49E1C086D0C; Fri, 7 Jul 2017 12:14:49 -0700 (PDT) Date: Fri, 7 Jul 2017 14:14:47 -0500 From: Nico Williams To: william manning Cc: David Cake , Randy Bush , dnsop , Paul Vixie , IETF Rinse Repeat Message-ID: <20170707191445.GH3393@localhost> References: <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <33235E8D-147D-4178-BC45-DFC1E1C27B99@davecake.net> <20170707165513.GG3393@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 19:14:53 -0000 On Fri, Jul 07, 2017 at 11:27:45AM -0700, william manning wrote: > You need a better imagination then. mDNS is a crippled DNS implementation > that was hobbled on purpose. HS was/is an entirely different addressing > scheme that emerged from project Athena @ MIT. To the extent that when all > you have been given is the IN class and it's associated rooted hierarchy, > you first,second,&third inclination is to treat EVERYTHING as being easily > integrated into that model. And the ietf is going to go right along with > you. After all, when all you have is a hammer, everything looks like a > nail. Did you read what I wrote?? The thing I'm having trouble imagining is distinct from the things that you list that I also listed (and then lecture about as if I had no idea what they were). A peer-to-peer DNS might be mDNS-like without whatever crippling you have in mind, but it's still difficult to imagine how to organize a coherent Internet around it. And as to web of trust, I don't see how that would work either. You decry my lack of imagination but provide none of your own. Nico -- From nobody Fri Jul 7 17:18:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B7613166A; Fri, 7 Jul 2017 17:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 N16c-wMtcCBa; Fri, 7 Jul 2017 17:18:29 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 94CB712F28C; Fri, 7 Jul 2017 17:18:29 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9DCE13493BB; Sat, 8 Jul 2017 00:18:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8684C16004A; Sat, 8 Jul 2017 00:18:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 730A8160067; Sat, 8 Jul 2017 00:18:26 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lQ0mXvBUlgc4; Sat, 8 Jul 2017 00:18:26 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id E49B516004A; Sat, 8 Jul 2017 00:18:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2FB117DFD520; Sat, 8 Jul 2017 10:18:25 +1000 (AEST) To: Pete Resnick Cc: Nico Williams , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> In-reply-to: Your message of "Fri, 07 Jul 2017 13:41:24 -0500." Date: Sat, 08 Jul 2017 10:18:25 +1000 Message-Id: <20170708001825.2FB117DFD520@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 00:18:31 -0000 In message , Pete Resnick writes: > [Apologies for the re-send. Using the correct address.] > > On 6 Jul 2017, at 16:52, Mark Andrews wrote: > > > Or you could stop trying to reinforce the myth that new RR types > > are hard to deploy. They really aren't. They actually get used > > all the time. > > I'm running the latest version of MacOS Server. I can't get a new RR > type into the UI. Even if I use the command line "dnsconfig" tool, I > can't add a record of a type it doesn't know about; I only get A, AAAA, > CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in the > BIND configs that underly their implementation. And at that point I say, > "New RR types are hard to deploy; not a myth." Telling me I can use a > different operating system or not use a validating UI is not a > reasonable response. Well use nsupdate. That also ships with the Mac. The version Apple ships is a little bit old but it can still handle unknown types and classes. It can also use SIG(0) or TSIG to sign the updates messages. It also supports the following types if I've matched the version of BIND correctly (BIND 9.8.3.P1). a, a6, aaaa, afsdb, apl, cert, cname, dhcid, dlv, dname, dnskey, ds, gpos, hinfo, hip, ipseckey, isdn, key, keydata, kx, loc, mb, md, mf, mg, minfo, mr, mx, naptr, ns, nsap, nsap-ptr, nsec, nsec3, nsec3param, null, nxt, ptr, px, rp, rrsig, rt, sig, soa, spf, srv, sshfp, tkey, tlsa, txt, unspec, wks, x25 [rock:~/git/bind9] marka% /usr/bin/nsupdate > update add xxxxx 0 class40 type9000 \# 1 00 > show Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTION: xxxxx. 0 CLASS40 TYPE9000 \# 1 00 > quit [rock:~/git/bind9] marka% uname -a Darwin rock.dv.isc.org 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64 [rock:~/git/bind9] marka% > The fact is the DNS doesn't provide a way for implementations to > dynamically update the RR types to provide sensible UI; it's left as an > exercise for each individual implementer. (Yes, I know about > draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.) You > can't much complain about the difficulty of deployment when the > community won't provide the tools to make deployment easier. Well BIND is designed to allow new types to be added easily. It may require recompiling rather than updating a text file but it is not beyond people to do because we see people doing just that. All the record types are defined in a single place and adding in a new type is usally as simple as cutting and pasting bits from the existing type definitions to make a new one. We also ship a tool which only purpose is to translate between unknown record format and known record format. You don't need to update you whole web api to add in a new type. Just update the tool. It also provides a list of known types it supports so you can use it to update the web api's list of supported types at runtime. [rock:~/git/bind9] marka% echo in a 1.2.3.4 | named-rrchecker -u CLASS1 TYPE1 \# 4 01020304 [rock:~/git/bind9] marka% [rock:~/git/bind9] marka% named-rrchecker -T | fmt A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX TXT RP AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS AAAA LOC NXT EID NIMLOC SRV ATMA NAPTR KX CERT A6 DNAME SINK APL DS SSHFP IPSECKEY RRSIG NSEC DNSKEY DHCID NSEC3 NSEC3PARAM TLSA SMIMEA HIP NINFO RKEY TALINK CDS CDNSKEY OPENPGPKEY CSYNC SPF UINFO UID GID UNSPEC NID L32 L64 LP EUI48 EUI64 URI CAA AVC TA DLV [rock:~/git/bind9] marka% Mark > pr > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Jul 8 05:04:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62A5126C22; Sat, 8 Jul 2017 05:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=gmail.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 UsYJwoBMKpfq; Sat, 8 Jul 2017 05:04:30 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 F1B851204DA; Sat, 8 Jul 2017 05:04:29 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id h22so37418055lfk.3; Sat, 08 Jul 2017 05:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=O8lcg9dLU4jaXcF4DTGemkf5CGH0HBwgmJyc9urUY6U=; b=HrMjyE91hU8nLYEDv4Hb1h2/ymaf032aM/Cf88UZ7LJWdCQjR+I49MB6NV3r0Qisfz yROk2tc5Tf2DucrpmpVfVeQqVsyrr/Sz8y4376g8iR3BxK+78/f1AUWbqY+Z9DzIVm9x /LjZjMqms2s4RJwbcg6hzAI/tkgD0oYHL7P/DBLd2COst5vjPrXP44zNiXXW/EKIdBOa +PXset+3iibrltg2YGGKDSjNnAAksaasrWazEVPGZtP4D66KVKShdLHQf6qThat5HCkF unCGKa3j/TUHp6rF18WzWCyVvUfGxTlqxTQRtwwhIk/PsF0GQUdhiVIYbhj/iLemUqnW kAiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=O8lcg9dLU4jaXcF4DTGemkf5CGH0HBwgmJyc9urUY6U=; b=cTDdwU1vq8l2Yq/Fzw7pNa7M+9y2AqQFL3V6Zt0kCzQEGWWvCGeqrRa42Q+GwB6P1F 6SzQzi1TvjgiBu14IXP3cGcP+5YAzuxaX+2MzR4ZqY1vwuqiX/pofJxQJr98rtpJN+uL +B/A/Z2WxpcIcmlUIk/IgI3yDRIGMpMcbeqA1mZGsO05BUcgM799X0jO5fB27VY5acHZ /Rl2LCd7VwW5k6K7D/ukbhBb15jYx0F0dkiSYGGvyHwrOkJPN0MlPNQsAMFolDKa32k7 D68nepZ/G1/E0WIE17L8glev4C7eIahd3INXMwuuHcpoRUJc8e3kEOBVh0Mr29Y3N/tG pFsA== X-Gm-Message-State: AKS2vOxtHqSSb+Cha6dswINneIUF6ioeI2Hm1dnMcZstSEwgeWwePtsd lXjzVqrclg/iaj2flWUnm5xbjmYCIA== X-Received: by 10.25.17.75 with SMTP id g72mr20381061lfi.122.1499515468193; Sat, 08 Jul 2017 05:04:28 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Sat, 8 Jul 2017 05:04:26 -0700 (PDT) In-Reply-To: <562EC659F89FA92A09CAC4DB@PSB> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> From: Phillip Hallam-Baker Date: Sat, 8 Jul 2017 08:04:26 -0400 X-Google-Sender-Auth: -jEDFB7gIHtktcQi93hlUf9SJac Message-ID: To: John C Klensin Cc: Paul Vixie , dnsop , IETF Rinse Repeat Content-Type: multipart/alternative; boundary="001a11401a18d125470553cd265c" Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 12:04:32 -0000 --001a11401a18d125470553cd265c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 6, 2017 at 11:15 AM, John C Klensin wrote: > > > --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker > wrote: > > > There are changes to the DNS that are practical and those that > > are not. For better or worse, I can't see any way that > > teaching DNS to use new classes makes any sense at this point. > > The only point at which it would have made sense was when > > internationalization happened. But the path chosen makes more > > sense. > > As the author of the I-D that proposed using a Class to deal > with internationalization, it would not have worked, and the two > important reasons are perhaps worth understanding. First, that > approach included a transition strategy that permitted legacy > clients and registrations to keep working in a way that users > would see as normal. But that strategy depends on CLASSes > sharing the same root and hierarchy. At Paul points out, that > interpretation of 1034/1035 is not universally accepted and > implemented. Second, IIR, we intended that the different CLASS > allow a different set of matching rule assumptions and > conditions. Because labels must generally be interpreted and > compared before CLASS values are accessed and, perhaps more > important, in optimization of databases, one probably needs > label types to do that, not CLASSes. And label types don't > have a good history. =E2=80=8BMy point was that all the reasons not to use class for internationalization are likely general and apply to any attempt to use class. > It seems to me that if people want to do anything new with DNS > > that they should use prefixes, new RRs or both as the > > mechanism, not the class which is limited anyway. > > > > DNS is not a full service directory. Nor does it need to be. A > > UDP packet is big enough for a link, a fingerprint and a > > digital signature. That is all that you ever need. > > As I think you know, I just love "all you will ever need" > statements about the Internet (and its predecessors) although my > favorite remains "we will never need more than 8 bits of address > space". =E2=80=8BThe question that always comes up in a directory service is how mu= ch service description information to put in the =E2=80=8Bdirectory and whethe= r the service itself should provide some of the description. DNS is irritatingly constraining when it comes to distributing information like a digital certificate. But we have managed to live in those constraints for the past 20 or so years after they started to be an issue. What you need and what you might want are different things. =E2=80=8BIf people find that they do need 'more than 8 bits', then =E2=80= =8BI guess we end up having to design DNS/2 protocol. But I think it unlikely we get there anytime soon. --001a11401a18d125470553cd265c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ju= l 6, 2017 at 11:15 AM, John C Klensin <john-ietf@jck.com> wr= ote:


--On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
<phill@hallamb= aker.com> wrote:

> There are changes to the DNS that are practical and those that
> are not. For better or worse, I can't see any way that
> teaching DNS to use new classes makes any sense at this point.
> The only point at which it would have made sense was when
> internationalization happened. But the path chosen makes more
> sense.

As the author of the I-D that proposed using a Class to deal
with internationalization, it would not have worked, and the two
important reasons are perhaps worth understanding.=C2=A0 =C2=A0First, that<= br> approach included a transition strategy that permitted legacy
clients and registrations to keep working in a way that users
would see as normal.=C2=A0 But that strategy depends on CLASSes
sharing the same root and hierarchy.=C2=A0 At Paul points out, that
interpretation of 1034/1035 is not universally accepted and
implemented.=C2=A0 Second, IIR, we intended that the different CLASS
allow a different set of matching rule assumptions and
conditions.=C2=A0 Because labels must generally be interpreted and
compared before CLASS values are accessed and, perhaps more
important, in optimization of databases, one probably needs
label types to do that, not CLASSes.=C2=A0 =C2=A0And label types don't<= br> have a good history.

=E2=80=8BMy point was that all the reasons= not to use class for internationalization are likely general and apply to = any attempt to use class.

> It seems to me that if people want to do anything new with DNS
> that they should use prefixes, new RRs or both as the
> mechanism, not the class which is limited anyway.
>
> DNS is not a full service directory. Nor does it need to be. A
> UDP packet is big enough for a link, a fingerprint and a
> digital signature. That is all that you ever need.

As I think you know, I just love "all you will ever need"<= br> statements about the Internet (and its predecessors) although my
favorite remains "we will never need more than 8 bits of address
space".

=E2=80=8BThe question that always comes up in a di= rectory service is how much service description information to put in the = =E2=80=8Bdirectory and whether the service itself should provide some of th= e description.
=
DNS is irr= itatingly constraining when it comes to distributing information like a dig= ital certificate. But we have managed to live in those constraints for the = past 20 or so years after they started to be an issue.

What you need and what you might want are dif= ferent things.


=E2=80=8BIf people find that they do need = 9;more than 8 bits', then =E2=80=8BI guess we end up having to design D= NS/2 protocol. But I think it unlikely we get there anytime soon.


--001a11401a18d125470553cd265c-- From nobody Sat Jul 8 09:05:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE1E129B72; Sat, 8 Jul 2017 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 DFjkZawNxUxb; Sat, 8 Jul 2017 09:05:05 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86F0127873; Sat, 8 Jul 2017 09:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1499529905; x=1531065905; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=C/YtHOKCp+1yWmIkJHw7H3uj3Imrt3EFdinJ+CoKWu4=; b=FsjpRpnHSeLyAYBlgIbNbqsoynLjF8rc35q5cQSMyCRa1YbMfDCJtT0D LD9FVUm5d12xXvQlEpEfznhAUqTS0htUNXuahcFIoBWhnvwc2/bN0rBuG lbIwCVMyYu36WhFGVIdr244FJLg73+mynWHW8sJzgRD1pzhuh/qRTLCrC c=; X-IronPort-AV: E=Sophos;i="5.40,329,1496127600"; d="scan'208";a="109989335" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by sabertooth01.qualcomm.com with ESMTP; 08 Jul 2017 09:05:04 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8585"; a="1402247209" X-MGA-submission: =?us-ascii?q?MDHQ+L3s0NEb7pK1EW4NTcei0QGSZiUiwzMYFX?= =?us-ascii?q?131AlYLHxHjCegMKiA9rU2RXqlmPKMooa6tVFiFe7+PhUvRXPov5M9Yz?= =?us-ascii?q?c25xlifZd/XgAjvBysxidP16/QlPtoRZ4pJLRgPYWqrFYj3h1cmDyJqY?= =?us-ascii?q?vj?= Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2017 09:05:04 -0700 Received: from [10.64.110.227] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 8 Jul 2017 09:05:03 -0700 From: Pete Resnick To: Mark Andrews CC: Nico Williams , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Date: Sat, 8 Jul 2017 11:05:01 -0500 Message-ID: In-Reply-To: <20170708001825.2FB117DFD520@rock.dv.isc.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170708001825.2FB117DFD520@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 16:05:07 -0000 On 7 Jul 2017, at 19:18, Mark Andrews wrote: > In message , > Pete Resnick writes: >> >> On 6 Jul 2017, at 16:52, Mark Andrews wrote: >> >>> Or you could stop trying to reinforce the myth that new RR types >>> are hard to deploy. They really aren't. They actually get used >>> all the time. >> >> I'm running the latest version of MacOS Server. I can't get a new RR >> type into the UI. Even if I use the command line "dnsconfig" tool, I >> can't add a record of a type it doesn't know about; I only get A, >> AAAA, >> CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in >> the >> BIND configs that underly their implementation. And at that point I >> say, >> "New RR types are hard to deploy; not a myth." Telling me I can use a >> different operating system or not use a validating UI is not a >> reasonable response. > > Well use nsupdate. That also ships with the Mac. Of course doing that likely means I'll have records that don't show up in the server UI. Not entirely thrilling. And I could accomplish exactly the same thing by directly editing the BIND config files, so I'm not sure what that gains me in terms of "not hard to deploy". >> The fact is the DNS doesn't provide a way for implementations to >> dynamically update the RR types to provide sensible UI; it's left as >> an >> exercise for each individual implementer. (Yes, I know about >> draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.) >> You >> can't much complain about the difficulty of deployment when the >> community won't provide the tools to make deployment easier. > > Well BIND is designed to allow new types to be added easily. It > may require recompiling rather than updating a text file but it is > not beyond people to do because we see people doing just that. ¬(∃𝑥𝐶(𝑥) → ∀𝑥𝐶(𝑥)) Just because you you see some people recompiling does not mean that all (or most, or a significant number) can. Set that aside, it is nowhere near reasonable for knowing how to recompile a piece of code to be required in order for me to add a new RR type. Set that aside, this is the epitome of "hard to deploy": Some implementations can't do it at all, some implementations you have to go hacking around in hidden config files, and some implementations you have to recompile the binary to get a reasonable UI experience. This is the problem with DNS being considered a system service rather than a user application. It's got both aspects. Until the user experience for configuring the DNS with a new RR type does not require the skills of someone able to recompile code, it is absolutely going to be the case that new RR types are hard to deploy, and calling it a myth is not helpful. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sat Jul 8 18:59:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0CF128D40; Sat, 8 Jul 2017 18:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uzvzUil72M9a; Sat, 8 Jul 2017 18:58:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 DDF1F127F0E; Sat, 8 Jul 2017 18:58:58 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E2F883493C9; Sun, 9 Jul 2017 01:58:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A293416003D; Sun, 9 Jul 2017 01:58:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 879EC160053; Sun, 9 Jul 2017 01:58:55 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id l7L6bkdQS1fJ; Sun, 9 Jul 2017 01:58:55 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 14DF116003D; Sun, 9 Jul 2017 01:58:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E5C877E07ADA; Sun, 9 Jul 2017 11:58:51 +1000 (AEST) To: Pete Resnick Cc: Nico Williams , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170708001825.2FB117DFD520@rock.dv.isc.org> In-reply-to: Your message of "Sat, 08 Jul 2017 11:05:01 -0500." Date: Sun, 09 Jul 2017 11:58:51 +1000 Message-Id: <20170709015851.E5C877E07ADA@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 01:59:00 -0000 In message , Pete Resnic k writes: > On 7 Jul 2017, at 19:18, Mark Andrews wrote: > > > In message , > > Pete Resnick writes: > >> > >> On 6 Jul 2017, at 16:52, Mark Andrews wrote: > >> > >>> Or you could stop trying to reinforce the myth that new RR types > >>> are hard to deploy. They really aren't. They actually get used > >>> all the time. > >> > >> I'm running the latest version of MacOS Server. I can't get a new RR > >> type into the UI. Even if I use the command line "dnsconfig" tool, I > >> can't add a record of a type it doesn't know about; I only get A, > >> AAAA, > >> CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in > >> the > >> BIND configs that underly their implementation. And at that point I > >> say, > >> "New RR types are hard to deploy; not a myth." Telling me I can use a > >> different operating system or not use a validating UI is not a > >> reasonable response. > > > > Well use nsupdate. That also ships with the Mac. > > Of course doing that likely means I'll have records that don't show up > in the server UI. Not entirely thrilling. And I could accomplish exactly > the same thing by directly editing the BIND config files, so I'm not > sure what that gains me in terms of "not hard to deploy". Given Macs can register their own addresses in the DNS using UPDATE I doubt that the strawman you are attempting to raise here happens and if it does log a bug with Apple. Log a bug with Apple that the tool doesn't support all known types and that it doesn't support unknown types. > >> The fact is the DNS doesn't provide a way for implementations to > >> dynamically update the RR types to provide sensible UI; it's left as > >> an > >> exercise for each individual implementer. (Yes, I know about > >> draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.) > >> You > >> can't much complain about the difficulty of deployment when the > >> community won't provide the tools to make deployment easier. > > > > Well BIND is designed to allow new types to be added easily. It > > may require recompiling rather than updating a text file but it is > > not beyond people to do because we see people doing just that. > > ¬(∃𝑥𝐶(𝑥) → ∀𝑥𝐶(𝑥)) > > Just because you you see some people recompiling does not mean that all > (or most, or a significant number) can. Set that aside, it is nowhere > near reasonable for knowing how to recompile a piece of code to be > required in order for me to add a new RR type. Set that aside, this is > the epitome of "hard to deploy": Some implementations can't do it at > all, some implementations you have to go hacking around in hidden config > files, and some implementations you have to recompile the binary to get > a reasonable UI experience. > > This is the problem with DNS being considered a system service rather > than a user application. It's got both aspects. Until the user > experience for configuring the DNS with a new RR type does not require > the skills of someone able to recompile code, it is absolutely going to > be the case that new RR types are hard to deploy, and calling it a myth > is not helpful. We supply user applications to manipulate the DNS. Those tools are capable of updating yet to be defined types. Putting a front end on those tools that takes the new type someone dreams up is easy. We also supply C libraries that can do the same thing. No one needs to wait to use a new type. There are python and perl tools available that can also send update messages. If you just want the new records to be a blob of text a shell script like this will convert the record to unknown format suitable to be used by nsupdate. % sh junk hello world \# 11 68656C6C6F20776F726C64 % cat junk read record hex=`printf "%s" "$record" | hexdump -ve '/1 "%02X"'` length=`printf "%s" "$hex" | wc -c` length=`expr $length / 2` echo '\#' $length $hex % You can create all DNS records similarly. Building them up field by field. One can do something similar in any scripting language. So no it isn't hard to use a new type. You just need to stop waiting for the stupid DNS hoster to do it for you and organise to do it yourself. > pr > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Jul 8 22:55:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F4F127698; Sat, 8 Jul 2017 22:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 qZBJ-rlU7iXB; Sat, 8 Jul 2017 22:55:31 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9AE12741D; Sat, 8 Jul 2017 22:55:31 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id EFA78C086D20; Sat, 8 Jul 2017 22:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=AD4NqTP0FFpFpi MtB9fcXamVPaM=; b=cDpIN+rezwd/nhsuPUJEm/fOZUbVtbOYdeIsOo7EsGuZRg EaK0zDHptTqlnHJtGBuS1BtKWOUuHQ3i7LJVaiToXF+APELpxcRCZYAoF4PNHdl6 CD7ZQV+N3UjVyrxvlftYgqR/2UJtp6TK+ij5ITYkOrbJerDavJBj/cwu4sfJI= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 4C8B0C086D0C; Sat, 8 Jul 2017 22:55:30 -0700 (PDT) Date: Sun, 9 Jul 2017 00:55:27 -0500 From: Nico Williams To: Mark Andrews Cc: Pete Resnick , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Message-ID: <20170709055526.GI3393@localhost> References: <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170708001825.2FB117DFD520@rock.dv.isc.org> <20170709015851.E5C877E07ADA@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170709015851.E5C877E07ADA@rock.dv.isc.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 05:55:33 -0000 On Sun, Jul 09, 2017 at 11:58:51AM +1000, Mark Andrews wrote: > One can do something similar in any scripting language. Sure. The people on this list can, and many others too. Still, all of us together are a tiny proportion of the users that would need to be able to. > So no it isn't hard to use a new type. You just need to stop waiting > for the stupid DNS hoster to do it for you and organise to do it > yourself. Stop. Don't tell us. Don't tell the customers. Start writing emails and making calls to hosting providers instead; get them to fix their crap. Make, publish, and keep up to date a list of viable providers. Nico -- From nobody Sun Jul 9 09:44:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D77412EB13; Sun, 9 Jul 2017 09:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 P3ONop8iIGrT; Sun, 9 Jul 2017 09:44:06 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C2812EAF7; Sun, 9 Jul 2017 09:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1499618646; x=1531154646; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=GsoJscYUGW266ZkEqVmDpnkDzh0Io6q2ODnO8JWntiI=; b=RUKGoNvIsG2uV7eTJrKo7lTsSXlPIz6ALBzI1Sdc3KuRRgP305yp2STH AvCjnV74+lsqVnpDgm7tU0tGBHKXlIlW3smhcNXeydJhpI0aXc46V6UI4 x/E/g/Pdco9e15gGt0vpSb4vPZznj/NRFnrISkbPzZAYPqKfjwFfMbbWu A=; X-IronPort-AV: E=Sophos;i="5.40,335,1496127600"; d="scan'208";a="111094214" Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by sabertooth02.qualcomm.com with ESMTP; 09 Jul 2017 09:44:05 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8586"; a="1406799185" X-MGA-submission: =?us-ascii?q?MDGlyaJpnhahzANAUX+TX1cQmzfjB57vHQdBjm?= =?us-ascii?q?YnjHtOuQhyj7FeSqcD0LUsQUqV9NvPH0Y2dQBeA8BhjxGbQ8H7X3n0mA?= =?us-ascii?q?LBtOaRcbO5rE0RN4L5JcXvZw+JuJtLbVfQN57Ttf+gw4ZMziDDy4cqVj?= =?us-ascii?q?XA?= Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2017 09:44:05 -0700 Received: from [10.64.97.228] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 9 Jul 2017 09:44:04 -0700 From: Pete Resnick To: Mark Andrews CC: Nico Williams , John C Klensin , dnsop , Phillip Hallam-Baker , Paul Vixie , IETF Date: Sun, 9 Jul 2017 11:44:02 -0500 Message-ID: In-Reply-To: <20170709015851.E5C877E07ADA@rock.dv.isc.org> References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170708001825.2FB117DFD520@rock.dv.isc.org> <20170709015851.E5C877E07ADA@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 16:44:08 -0000 On 8 Jul 2017, at 20:58, Mark Andrews wrote: > In message , > Pete Resnic > k writes: >> On 7 Jul 2017, at 19:18, Mark Andrews wrote: >> >>> Well use nsupdate. That also ships with the Mac. >> >> Of course doing that likely means I'll have records that don't show >> up >> in the server UI. Not entirely thrilling. And I could accomplish >> exactly >> the same thing by directly editing the BIND config files, so I'm not >> sure what that gains me in terms of "not hard to deploy". > > Given Macs can register their own addresses in the DNS using UPDATE... You mean an A or AAAA record, which the UI does support? > ...Log a bug with Apple that the > tool doesn't support all known types and that it doesn't support > unknown types. And in the meanwhile, you still say, "new RR types are not hard to deploy"? > We supply user applications to manipulate the DNS. Those tools are > capable of updating yet to be defined types. Putting a front end > on those tools that takes the new type someone dreams up is easy. To quote a favorite line of mine, I grant the point: If things were different, they wouldn't be the same. Creating these front ends apparently has not happened, so how does this address the point that new RR types are hard to deploy? > We also supply C libraries that can do the same thing. No one needs > to wait to use a new type. I refer the honourable gentleman to the answer I gave some moments ago. Sure, it would be easy to write code to make tools exist that would make it be easy to deploy. Those tools do not currently exist. It is therefore still hard to deploy. > There are python and perl tools available that can also send update > messages. I refer the honourable gentleman to the answer I gave some moments ago. > If you just want the new records to be a blob of text a shell script > like this will convert the record to unknown format suitable to be > used by nsupdate. > > % sh junk > hello world > \# 11 68656C6C6F20776F726C64 > % cat junk > read record > hex=`printf "%s" "$record" | hexdump -ve '/1 "%02X"'` > length=`printf "%s" "$hex" | wc -c` > length=`expr $length / 2` > echo '\#' $length $hex > % > > You can create all DNS records similarly. Building them up > field by field. > > One can do something similar in any scripting language. I think you have proved my point exceedingly well there. > So no it isn't hard to use a new type. Nobody said "use". The word was "deploy". Until a huge number of hosting providers and OS vendors and tool writers get their act together writ large (and that includes tool vendors who require recompiles and/or fun shell scripts in order to have a remotely sane UI experience), deployment of a new RR type is hard. > You just need to stop waiting > for the stupid DNS hoster to do it for you and organise to do it > yourself. That does not solve the deployment problem. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Jul 9 12:27:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6790012ECCE; Sun, 9 Jul 2017 12:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 tAGauVd3BRws; Sun, 9 Jul 2017 12:27:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4692812ECC3; Sun, 9 Jul 2017 12:27:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dUHr3-0003UD-5w; Sun, 09 Jul 2017 19:26:53 +0000 Date: Sun, 09 Jul 2017 21:26:43 +0200 Message-ID: From: Randy Bush To: Pete Resnick Cc: Mark Andrews , Phillip Hallam-Baker , IETF , dnsop , Paul Vixie , John C Klensin In-Reply-To: References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170708001825.2FB117DFD520@rock.dv.isc.org> <20170709015851.E5C877E07ADA@rock.dv.isc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 19:27:01 -0000 while i enjoy berating vendors for bugs and poor feature sets as much as the next person, well maybe more, it's a target rich environment. if we could come to agreement on what the right thing is, what we actually want here, we could at least beat them on the right vector. but as i said at the beginning, i am not even sure dns classes are the answer. this is exacerbated by the draft in question trying to shoot down the users' needs without even exploring them. and that is still my main issue. we're shooting down solutions when we have not yet defined the problem. 30c in praha today randy From nobody Sun Jul 9 18:14:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DF3129AEB; Sun, 9 Jul 2017 18:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Mk-26MkRcxiS; Sun, 9 Jul 2017 18:14:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 B262E126D05; Sun, 9 Jul 2017 18:14:31 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5979C3493D3; Mon, 10 Jul 2017 01:14:29 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4469916003A; Mon, 10 Jul 2017 01:14:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 30239160053; Mon, 10 Jul 2017 01:14:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nusaM9SBB0yk; Mon, 10 Jul 2017 01:14:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D367616003A; Mon, 10 Jul 2017 01:14:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3BE867E1FE36; Mon, 10 Jul 2017 11:14:26 +1000 (AEST) To: Randy Bush Cc: Pete Resnick , Phillip Hallam-Baker , IETF , dnsop , Paul Vixie , John C Klensin From: Mark Andrews References: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170708001825.2FB117DFD520@rock.dv.isc.org> <20170709015851.E5C877E07ADA@rock.dv.isc.org> In-reply-to: Your message of "Sun, 09 Jul 2017 21:26:43 +0200." Date: Mon, 10 Jul 2017 11:14:26 +1000 Message-Id: <20170710011426.3BE867E1FE36@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 01:14:33 -0000 In message , Randy Bush writes: > while i enjoy berating vendors for bugs and poor feature sets as much as > the next person, well maybe more, it's a target rich environment. if we > could come to agreement on what the right thing is, what we actually > want here, we could at least beat them on the right vector. a) For DNS tools to support unknown types and classes (RFC 3597). b) For DNS tools to add support for allocated data types within X months of them being assigned by IANA. Allocated types are supposed to have stable wire and presentation formats. for a reasonable value of X (<= 12?). > but as i said at the beginning, i am not even sure dns classes are the > answer. this is exacerbated by the draft in question trying to shoot > down the users' needs without even exploring them. and that is still my > main issue. we're shooting down solutions when we have not yet defined > the problem. > > 30c in praha today > > randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jul 10 09:07:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C111317C4; Mon, 10 Jul 2017 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Vy9bGSAE; dkim=pass (1024-bit key) header.d=yitter.info header.b=VEj+ZbcB 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 jSyqKXNJg9nl; Mon, 10 Jul 2017 09:07:22 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AB3129B05; Mon, 10 Jul 2017 09:07:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9B88EC03BA; Mon, 10 Jul 2017 16:06:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499702811; bh=yPpQhG0wMXoKCiTNTy6Jv+1bzGTmOqrlEWsaq50TTHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Vy9bGSAEIq+2EAHhkpNmRSh9k/DbMw6hS3qVfR7s/QdZfxWSF4awVAKlBnHS8sROH QVrSaWI8PquWQc+S48UcXD7eFZvN8rh8ig6nVRyQbNVsrBaJTpt5bgMoxoAquXAQLP AAYPZGj+hK7cjmt9v6iJo0PAvQJnOzHGElU4IOA0= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHtjGh4BbE-4; Mon, 10 Jul 2017 16:06:50 +0000 (UTC) Date: Mon, 10 Jul 2017 12:06:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499702810; bh=yPpQhG0wMXoKCiTNTy6Jv+1bzGTmOqrlEWsaq50TTHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=VEj+ZbcBDdUxnFhDKcvBPhr3AfryuKOX9/v42pd4HwZbaSYWFuR6JUT81ogrLv3EG p7kXO+UBS+h4Jq1rN56XWFIuueBM1bBmHB5//8zUzX059LTPz+fRilo41iQy3GiA6H ugVwB9PpWYXsxM8/tG2ZW8DGG8lgnu9G36uyPM4I= From: Andrew Sullivan To: ietf@ietf.org, dnsop@ietf.org Message-ID: <20170710160648.svrng2b4hppfsizb@mx4.yitter.info> References: <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170708001825.2FB117DFD520@rock.dv.isc.org> <20170709015851.E5C877E07ADA@rock.dv.isc.org> <20170710011426.3BE867E1FE36@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170710011426.3BE867E1FE36@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] new DNS classes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 16:07:24 -0000 On Mon, Jul 10, 2017 at 11:14:26AM +1000, Mark Andrews wrote: > b) For DNS tools to add support for allocated data types within X > months of them being assigned by IANA. Allocated types are > supposed to have stable wire and presentation formats. > > for a reasonable value of X (<= 12?). With all due respect, that sounds like you want to make some sort of expectation of people on the Internet -- one requiring that they spend time or money or both to solve a problem that they apparently don't have. If they _did_ have it, they would already be solving it. For instance, infrastructure operation on the Internet provides thin profit margins. If a customer requires a lot of attention or hand-holding then the profit margin on that customer can disappear pretty quickly. Therefore, it is of critical importance to have a lot of automated checking in place that ensures that the customer's expectations are met. Tools to smooth the rough edges need to be foolproof -- customers don't want to do "rocket science" or even "appliance science". The tools must not only to handle a user's input, but to be able to be pretty confident that it is going to do something like what they wanted it to do (or else give them a hint). Otherwise, the angry customer contacts support and wipes out the profit on them. The natural consequence of that is just that the more obscure RRs are just not going to be supported in those kinds of tools. The risk to companies' reputations and customer satisfaction is too great for the meagre reward. Is this bad for the Internet? Yes. But that's what you get in a system that depends on voluntary participation: sometimes other people don't want to play your game, and unless it seems like it will be rewarding enough most of them aren't even going to bother asking what the rules are. And that's just for RRTYPEs. There is no evidence whatever that a new CLASS is of any utility at all to anyone except maybe DNS nerds. It is ridiculous to claim that everyone else on the Internet is wrong and, if they would just do what we say, everything would be good. The Internet did not eat every other communication technology because people found it hard to follow the Official Rules Made Up By Netgods. It took over because it worked well enough for most people most of the time without too much effort. Everything actually deployed on the Internet scratches someone's itch. Adding support for stuff to the DNS is a hair shirt. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 10 10:50:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46FB12EB99 for ; Mon, 10 Jul 2017 10:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 V9ZHjtUvDBV1 for ; Mon, 10 Jul 2017 10:50:18 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 7AEC71315FF for ; Mon, 10 Jul 2017 10:50:17 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id e201so30518489ybb.1 for ; Mon, 10 Jul 2017 10:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r88VOM+R9C78ICDkJLNd4yGspJ0lYCR+FG1oMrt8R0Q=; b=AKIM6hBoj7/NFig4JpwUKDm/xJHElrPILKwHgwyzRpVJc2gWXj27HqblpeL/9Tldgx GC3MwVC+t80v1mxtEPpNdelpQR+Qxu8DpZw+hrOzPU8HErTJLzEPhLQY1TLS+HLpWykC Z4u3HznqfiWraQKYDYqnl03BvkPyC+FKaaX9UpeiLzGvgTG3hkXOz2rCaPGCggVhWUgr 08sb8tDAIdA4jCviMTdv0cfavezzpwarqxdnw8pUf+Ml+/QfCbMjY0a7P2CxK03FXCl+ rUiwS24oGoL10azRM4mcAe3bS2ESb5E3rsDmQ3CZgxjC+eihhk/hWLYO4fds2PvSEh/H xgzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r88VOM+R9C78ICDkJLNd4yGspJ0lYCR+FG1oMrt8R0Q=; b=Sk2Wei3VFvumvbrgc6w8zn4u4XPLCF82jbO/PlVS0R/2U60hNq5meMZrPkzfWP6oCw lfawPYEJs0CT19tZpIHfOqfVMGtszro6VlgRw7Dig8AebwGYSci0IspHBCzciWVpCIHe B9UfxKMkSP+msl2ul+kdFlsDG2et4958wYT+iRIL9OpPR2Of8ibliuZyPa/R6aPbY5kK JrBTxFKphqqI1CjXgdD6Pjhn4vTHQsnGM8ABHQnGG9UItZ/FHFLLvWyFZtP3VrVPmXb3 fx9voDbLAbRqn6BAROeJnpTDZB2mK2WFItT2YJs1EEoi+F4AuLSCfF1qZUOBY2YI8dRW 3PuQ== X-Gm-Message-State: AIVw111VmJORVHa1upXfueX5BNkbKYR3lFGJnFG2eZzeXEWYGyfzjCO1 m3JhAyBFh/PlaqIgwW+L1t2P27ClUrIT X-Received: by 10.37.35.198 with SMTP id j189mr16109487ybj.91.1499709016601; Mon, 10 Jul 2017 10:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.132 with HTTP; Mon, 10 Jul 2017 10:50:16 -0700 (PDT) In-Reply-To: References: From: Bob Harold Date: Mon, 10 Jul 2017 13:50:16 -0400 Message-ID: To: Shumon Huque Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113d40cc3390900553fa37c3" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 17:50:21 -0000 --001a113d40cc3390900553fa37c3 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque wrote: > Hi folks, > > We've posted a new draft on algorithm negotiation which we're hoping to > discuss at IETF99 (and on list of course). I've discussed this topic with > several folks at DNS-OARC recently. > > https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Algorithm Negotiation in DNSSEC > Authors : Shumon Huque > Haya Shulman > Filename : draft-huque-dnssec-alg-nego-00.txt > Pages : 9 > Date : 2017-07-03 > > Abstract: > This document specifies a DNS extension that allows a DNS client to > specify a list of DNSSEC algorithms, in preference order, that the > client desires to use. A DNS server upon receipt of this extension > can choose to selectively respond with DNSSEC signatures using the > most preferred algorithm they support. This mechanism may make it > easier for DNS zone operators to support signing zone data > simultaneously with multiple DNSSEC algorithms, without significantly > increasing the size of DNS responses. It will also allow an easier > way to transition to new algorithms while still retaining support for > older DNS validators that do not yet support the new algorithms. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-huque-dnssec-alg-nego/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 > https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-00 > > -- > Shumon Huque > > I like the idea. I am not an DNSSEC expert, but wondering in section 7, paragraph: In order to detect such attacks, the client SHOULD compare the zone signing algorithms listed in the zone's authenticated DNSKEY RRset, and the preferred list in the query that it sent, to the algorithms seen in the response signatures. If signatures by the most preferred algorithm they have in common have not been sent, this may indicate an algorithm downgrade attack. Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to would not be available for response signatures? And perhaps a really dumb off-topic question: I do not use DNSSEC yet, mostly due to time and effort, secondly due to concern over the additional size and processing. Is it possible for me to start with a new, rarely implemented, algorithm with shorter records, that most resolvers won't understand yet, and have those that don't understand it treat the zone as unsigned? Or will it break everything? (Section 5 sounds like it breaks) -- Bob Harold --001a113d40cc3390900553fa37c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <shuque@gmail.com> wrote:
Hi folks,

We've posted a new draft on algorith= m negotiation which we're hoping to discuss at IETF99 (and on list of c= ourse). I've discussed this topic with several folks at DNS-OARC recent= ly.


=
A New Internet-Draft is available from the on-line Inte= rnet-Drafts directories.


=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Algorithm Nego= tiation in DNSSEC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : Shumon Huque
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Haya Shulman
=C2=A0Filename =C2= =A0 =C2=A0 =C2=A0 =C2=A0: draft-huque-dnssec-alg-nego-00.txt
=C2=A0Pages =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : 9
= =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2017-07-03

Abstract:
=C2=A0 =C2=A0This document speci= fies a DNS extension that allows a DNS client to
=C2=A0 =C2=A0spe= cify a list of DNSSEC algorithms, in preference order, that the
= =C2=A0 =C2=A0client desires to use.=C2=A0 A DNS server upon receipt of this= extension
=C2=A0 =C2=A0can choose to selectively respond with DN= SSEC signatures using the
=C2=A0 =C2=A0most preferred algorithm t= hey support.=C2=A0 This mechanism may make it
=C2=A0 =C2=A0easier= for DNS zone operators to support signing zone data
=C2=A0 =C2= =A0simultaneously with multiple DNSSEC algorithms, without significantly
=C2=A0 =C2=A0increasing the size of DNS responses.=C2=A0 It will al= so allow an easier
=C2=A0 =C2=A0way to transition to new algorith= ms while still retaining support for
=C2=A0 =C2=A0older DNS valid= ators that do not yet support the new algorithms.

=
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-huque-dnssec= -alg-nego/

There are also htmlized versio= ns available at:

<= /div>
--=C2=A0
Shumon Huque


I like the idea.=C2=A0 I am not an = DNSSEC expert, but wondering in section 7, paragraph:

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;color:rgb(0,0,0)"> In = order to detect such attacks, the client SHOULD compare the zone signing algorithms listed in the zone's authenticated DNSKEY RRset, and the preferred list in the query that it sent, to the algorithms seen in the response signatures. If signatures by the most preferred algorithm they have in common have not been sent, this may indicate=C2= =A0
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0an algorithm downgrade atta= ck.

Can there be 'pre-pubished&#= 39; DNSKEY's that are not used for signing yet, to would not be availab= le for response signatures?

And perhaps a really d= umb off-topic question:
I do not use DNSSEC yet, mostly due to ti= me and effort, secondly due to concern over the additional size and process= ing.=C2=A0 Is it possible for me to start with a new, rarely implemented, a= lgorithm with shorter records, that most resolvers won't understand yet= , and have those that don't understand it treat the zone as unsigned?= =C2=A0 Or will it break everything? =C2=A0(Section 5 sounds like it breaks)=

--=C2=A0
Bob Harold

--001a113d40cc3390900553fa37c3-- From nobody Mon Jul 10 11:53:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BEC131865 for ; Mon, 10 Jul 2017 11:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 4kGTb9VmwopD for ; Mon, 10 Jul 2017 11:53:45 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 D30AB12EC3A for ; Mon, 10 Jul 2017 11:53:44 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id y70so52368531vky.3 for ; Mon, 10 Jul 2017 11:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YzQ6UtnL5a+yn8iePtUhY5hjiZ/JEpvDrrj6vZ63JtU=; b=D6coRsin154SUgggyvcaKcbTq8aovGv3apLRcjY37+3Y11fyjc57sxcJuu5kZBjSnP qX/x2J34xzTNU1yDwj+Jx918eJYUyF+pk7YBzVnobxbBnnEnAyYwVpowMfzRvmOTegj2 3ICjEq5VdBBOtCw8KctXsXUhMr8IULtl1fx4y2y1dK9aVmKwo4D4YKS3TMdzMjzWFzA5 jdPFOr13B4tgvtnN6aErsFje2gzNgHikuQU2Xji240dG/fo031b7WpYsZL0bn25mbKJY XtaGxGo7ubZ6NLt6QFE5jM0izGDlhVipk6W/7sw1UYtMhugQ/xKrJn1kbS9tyfkfOxhX jafw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YzQ6UtnL5a+yn8iePtUhY5hjiZ/JEpvDrrj6vZ63JtU=; b=Fp8kWghyKXV+0gsDmgDhcZfPzFMZ8vvaSP/xxpvUrhhOm5HanftD0zIxOHdjCledgd vC2y4VhNaANUZcUe8C05rexdojRxKrMzQ0eWsp3eEQtkAgqSUCx5BAWTNdCRrwlC9jSU qcPcxxFNgixNYR8lyD+/Kw081b5PTLjWGeGiI49eiBg6gI9RsqIxZx82TVm8QHRteMoB ngF2QQSz55fYbRJKwtDmi4OLbjq5iJXWAfiZHrvxFAucufTsw2ydBpvkSQR8gJ3PjvQl lRX2vUE3rhcHX1RHZObkXkpkkBM0Z1mcxgZm7TxJiMb3wz7ydm1Pt5ld/mEdOoOVnsBQ isRA== X-Gm-Message-State: AIVw112yMuDdnmX2R0l2yjGuN6tXjBsHKRU1vEu32pmJh4K5gRUVsJpR QTqZvWEbgDRRYSNVX73JWw65qdtVkw== X-Received: by 10.31.14.73 with SMTP id 70mr6765812vko.99.1499712824013; Mon, 10 Jul 2017 11:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 11:53:43 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Mon, 10 Jul 2017 14:53:43 -0400 Message-ID: To: Bob Harold Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114551aa23f88b0553fb1a43" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 18:53:47 -0000 --001a114551aa23f88b0553fb1a43 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 1:50 PM, Bob Harold wrote: > > On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque wrote: > >> Hi folks, >> >> We've posted a new draft on algorithm negotiation which we're hoping to >> discuss at IETF99 (and on list of course). I've discussed this topic with >> several folks at DNS-OARC recently. >> >> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 >> >> -- >> Shumon Huque >> >> > I like the idea. I am not an DNSSEC expert, but wondering in section 7, > paragraph: > > In order to detect such attacks, the client SHOULD compare the zone > signing algorithms listed in the zone's authenticated DNSKEY RRset, > and the preferred list in the query that it sent, to the algorithms > seen in the response signatures. If signatures by the most preferred > algorithm they have in common have not been sent, this may indicate > > an algorithm downgrade attack. > > Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to > would not be available for response signatures? > Hi Bob, Very good question Yes, there certainly can be. If the pre-published key's algorithm is higher strength than the others, then it could cause the resolver to mistakenly deduce an algorithm downgrade attack might be in progress. I think this argues that we really do need the new zone apex (active) algorithms list record - which we already were thinking of proposing - in the last paragraph of Section 7. And perhaps a really dumb off-topic question: > I do not use DNSSEC yet, mostly due to time and effort, secondly due to > concern over the additional size and processing. Is it possible for me to > start with a new, rarely implemented, algorithm with shorter records, that > most resolvers won't understand yet, and have those that don't understand > it treat the zone as unsigned? Or will it break everything? (Section 5 > sounds like it breaks) > (Only) Unknown algorithms will currently cause resolvers to treat the zone as unsigned (fail open). So, nothing will break, but resolvers that don't understand the new algorithm won't authenticate the signatures and the benefit of DNSSEC is lost. -- Shumon Huque --001a114551aa23f88b0553fb1a43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 1:50 PM, Bob Harold <rharolde@umich.edu> wrote:

On Tue, J= ul 4, 2017 at 11:42 AM, Shumon Huque <shuque@gmail.com> wrote= :
Hi = folks,

We've posted a new draft on algorithm negotia= tion which we're hoping to discuss at IETF99 (and on list of course). I= 've discussed this topic with several folks at DNS-OARC recently.
=


--=C2=A0
Shumon Huque

=

I like the idea.=C2=A0 I am not an DNSSEC e= xpert, but wondering in section 7, paragraph:

   In order to detect such attacks, the client SHOULD compare the zo=
ne
   signing algorithms listed in the zone's authenticated DNSKEY RRset,
   and the preferred list in the query that it sent, to the algorithms
   seen in the response signatures.  If signatures by the most preferred
   algorithm they have in common have not been sent, this may indicate=C2=
=A0
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0an algorithm downgrade atta= ck.

Can there be 'pre-pubished&#= 39; DNSKEY's that are not used for signing yet, to would not be availab= le for response signatures?

Hi Bob,

Very good question Yes, there cer= tainly can be. If the pre-published key's algorithm is higher strength = than the others, then it could cause the resolver to mistakenly deduce an a= lgorithm downgrade attack might be in progress. I think this argues that we= really do need the new zone apex (active) algorithms list record - which w= e already were thinking of proposing - in the last paragraph of Section 7.<= /div>

And perhaps a really du= mb off-topic question:
I do not use DNSSEC yet, mostly due to tim= e and effort, secondly due to concern over the additional size and processi= ng.=C2=A0 Is it possible for me to start with a new, rarely implemented, al= gorithm with shorter records, that most resolvers won't understand yet,= and have those that don't understand it treat the zone as unsigned?=C2= =A0 Or will it break everything? =C2=A0(Section 5 sounds like it breaks)

(Only) Unknown algori= thms will currently cause resolvers to treat the zone as unsigned (fail ope= n). So, nothing will break, but resolvers that don't understand the new= algorithm won't authenticate the signatures and the benefit of DNSSEC = is lost.

--=C2=A0
Shumon Huque

--001a114551aa23f88b0553fb1a43-- From nobody Mon Jul 10 13:12:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C953D12ECCE for ; Mon, 10 Jul 2017 13:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_TVD_MIME_EPI=0.01] autolearn=no 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 ysDA0cksUtU0 for ; Mon, 10 Jul 2017 13:12:17 -0700 (PDT) Received: from wittsend.com (romulus.wittsend.com [130.205.32.3]) (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 ADEEB13189D for ; Mon, 10 Jul 2017 13:12:12 -0700 (PDT) Received: from canyon.ip6.wittsend.com (canyon.ip6.wittsend.com [IPv6:2001:470:8:a48:3e97:eff:fe4d:9bc7]) (authenticated bits=0) by wittsend.com (8.15.2/8.15.2) with ESMTPSA id v6AKA2MX011627 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Jul 2017 16:10:02 -0400 Message-ID: <1499717103.5817.19.camel@WittsEnd.com> From: "Michael H. Warfield" Reply-To: mhw@wittsend.com To: Bob Harold , Shumon Huque Cc: "Michael H.Warfield" , "dnsop@ietf.org WG" Date: Mon, 10 Jul 2017 16:05:03 -0400 In-Reply-To: References: Organization: Thaumaturgy & Speculums Technology Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-BNVh4GXIVflUBCesnjIj" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 X-WittsEnd-MailScanner-Information: Please contact the ISP for more information X-WittsEnd-MailScanner-ID: v6AKA2MX011627 X-WittsEnd-MailScanner: Found to be clean X-WittsEnd-MailScanner-From: mhw@wittsend.com Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 20:12:21 -0000 --=-BNVh4GXIVflUBCesnjIj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2017-07-10 at 13:50 -0400, Bob Harold wrote: > On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque > wrote: > > Hi folks, ... > And perhaps a really dumb off-topic question: > I do not use DNSSEC yet, mostly due to time and effort, secondly due > to concern over the additional size and processing.=C2=A0 Is it possible > for me to start with a new, rarely implemented, algorithm with > shorter records, that most resolvers won't understand yet, and have > those that don't understand it treat the zone as unsigned?=C2=A0 Or will > it break everything? =C2=A0(Section 5 sounds like it breaks) There is not much at all involved in time or effort any more. I use to manually sign my zones but I've shift over to having "bind" just manage all my keysigning and I just update the zone and it happens. You just set up your initial keys and register your KSK (Key Signing Key) with your registraur (assuming they support it) and you should be good to go. Rolling your KSK's is still (cough) entertaining but not essential if you're just getting your feet wet.=20 Some registraurs support this and some don't. Some will support DNSsec for the zones but then require you to "self host" your DNS (optionally slaving from your master). I self host and always have. I also use Hurricane Electric for additional slaves. They've gotten much better at DNSsec though they won't manage it for their hosted zones.=20 DreamHost is another one that will support registration but you have to self host your master (which then becomes problematical if you want them to host your web site). If you want the hosting company to manage DNSsec for you, good luck. There are some registraurs (some very big ones) that still don't support DNSsec or only support it as a "premium" feature and you should just kick them to the curb. Over all, it's gotten a lot easier and really not a big deal. Biggest challenge is getting your IT department to spell DNSsec. :-P Mike > --=C2=A0 > Bob Harold --=20 Michael H. Warfield (AI4NB) | (706) 850-8770 |=C2=A0=C2=A0mhw@WittsEnd.com =C2=A0=C2=A0=C2=A0/\/\|=3Dmhw=3D|\/\/=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0| (678) 463-0932 |=C2=A0=C2=A0http://www.wittsend.c= om/mhw/ ARIN whois: ARIN-MHW9=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| An optimis= t believes we live in the best of all PGP Key: 0xC0EB9675674627FF | possible worlds.=C2=A0=C2=A0A pessimist is su= re of it! --=-BNVh4GXIVflUBCesnjIj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJZY93wAAoJEMDrlnVnRif/cM0H/iwZKJ+0c/HK2QClzfzXyNy1 SFwa3ULc4VP7+EZ4rYSbT4ILpVgS6P8/2D2+msVLTN40NLAc40oJ7GHJ0hRgFXC8 +0Lf3pyroDwqxETU3wni5XI7pAKIGv6cvfDkMNccV1Vs0ZXWT7T2wTiHqphOMHIS CmZD70sBdPJF6ROe61KlCRLyjjvNaSD6yoXztvxtB4n8Y9wajD6zDCplTlffSgdC SoGMtMAYDkCCkcI754eRoKq7R3wmedsEkjyVYKO49qH2eenK+9QnB/WQLkNWzyMW FxclABpxBKBeld/VrHfLVRKFlcHFOHJucIoDxYGGeXA6ju70sDBl9HvZpEuC5zs= =eP+i -----END PGP SIGNATURE----- --=-BNVh4GXIVflUBCesnjIj-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nobody Mon Jul 10 13:22:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104A61317C9 for ; Mon, 10 Jul 2017 13:22:41 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 s7lY-wyoxFV5 for ; Mon, 10 Jul 2017 13:22:39 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 F235912F258 for ; Mon, 10 Jul 2017 13:22:38 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id z22so61781595uah.1 for ; Mon, 10 Jul 2017 13:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2NZ5oWsczhHZyGTYOcNkUuMMuAXefBqqaJv6Pfw2Cq8=; b=cKh6SZaYK0vrGWxjExavo65zaOas2blSIsH6yLRHuRWwnyMlMF7izrbyfC9WUcQFH3 dkv553Mn4FitLxrMHaMLIjqU/vla7qxxVMGNYc/liX5pk2j1e0+OgEc0VoqBuVMT05kM +OewbFgiHO5P8z+Bb2NiHnNQEpuYOmkbcfz0CSRWNmWaYgTbIVuCoNwsT//c8QPNr5rk GYte/UwTPLQ72TN47nO/qLIDnJ10he/vs/UndUtJBZS6S9q1GrxKFL8Ph9LyE+EyY1TG yCkLr3jX438zcUVRmSYEmAQlVLbY3xkt/W51IXp1Ylvlu+wTjGlT4/S4AQCplL51sMW4 NRUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2NZ5oWsczhHZyGTYOcNkUuMMuAXefBqqaJv6Pfw2Cq8=; b=nzlbfa0T6xbvU+PfyW1emttae98h7zJQsVlrIxiCRXgAj13sXIeedXsojnNlw9k/Ll 0QDLTvc15CKDVVjZgIHrK4rpey75A2jzch0iWZ+denrHVzgw2BzF/jqycckN4JFXibKF Ez34bZz1lDM/wqcFDHOXawTpSVqnkXaCBq2AeqUETbLRD1NB1HYH9UhmM0JzH8lM2BxK gCJJpOXIZQXxwZHQzON3Y+sgh6F9geWylnSG+v+Bh63cCunMLP2WlNIw9LsQ3vTeK/Td lF6t33DQWpr0z9UyWNuijEm/tgPNqbhyCprPJUAtZ4nG43BR283utNlfxAU3K5biTzJH PCaQ== X-Gm-Message-State: AIVw1102KF289zr0MGfJZSOXBcd+OvyMwxttSrFizhlrmbel0G0OLRwS g4S9PJJ1VVbCTm225S9kgll11bVuCg== X-Received: by 10.176.93.2 with SMTP id u2mr9837518uaf.109.1499718158140; Mon, 10 Jul 2017 13:22:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 13:22:37 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Mon, 10 Jul 2017 16:22:37 -0400 Message-ID: To: Bob Harold Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="f40304362188144a330553fc58df" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 20:22:41 -0000 --f40304362188144a330553fc58df Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 2:53 PM, Shumon Huque wrote: > On Mon, Jul 10, 2017 at 1:50 PM, Bob Harold wrote: > >> >> On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque wrote: >> >>> Hi folks, >>> >>> We've posted a new draft on algorithm negotiation which we're hoping to >>> discuss at IETF99 (and on list of course). I've discussed this topic with >>> several folks at DNS-OARC recently. >>> >>> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 >>> >>> -- >>> Shumon Huque >>> >>> >> I like the idea. I am not an DNSSEC expert, but wondering in section 7, >> paragraph: >> >> In order to detect such attacks, the client SHOULD compare the zone >> signing algorithms listed in the zone's authenticated DNSKEY RRset, >> and the preferred list in the query that it sent, to the algorithms >> seen in the response signatures. If signatures by the most preferred >> algorithm they have in common have not been sent, this may indicate >> >> an algorithm downgrade attack. >> >> Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, >> to would not be available for response signatures? >> > > Hi Bob, > > Very good question Yes, there certainly can be. If the pre-published key's > algorithm is higher strength than the others, then it could cause the > resolver to mistakenly deduce an algorithm downgrade attack might be in > progress. I think this argues that we really do need the new zone apex > (active) algorithms list record - which we already were thinking of > proposing - in the last paragraph of Section 7. > Replying to my own message (sorry!) .. It occurs to me that RFC 4035 and RFC 6781 both say that zone data currently need to be signed by a key of each algorithm in the DNSKEY RRset. So perhaps you can't pre-publish a key of a new algorithm. This draft, if adopted, may also have to qualify some existing language (e.g. distinguishing an authoritative server _having_ signatures of each algorithm, from selectively _returning_ signatures of a specific algorithm, if signaled). -- Shumon Huque --f40304362188144a330553fc58df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 2:53 PM, Shumon Huque <shuque@gmail.com> = wrote:
On Mon, Jul 10, 2017 = at 1:50 PM, Bob Harold <rharolde@umich.edu> wrote:

On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <shuque@g= mail.com> wrote:
Hi folks,

<= div>We've posted a new draft on algorithm negotiation which we're h= oping to discuss at IETF99 (and on list of course). I've discussed this= topic with several folks at DNS-OARC recently.


--= =C2=A0
Shumon Huque


I like the idea.= =C2=A0 I am not an DNSSEC expert, but wondering in section 7, paragraph:

   In order to detec=
t such attacks, the client SHOULD compare the zone
   signing algorithms listed in the zone's authenticated DNSKEY RRset,
   and the preferred list in the query that it sent, to the algorithms
   seen in the response signatures.  If signatures by the most preferred
   algorithm they have in common have not been sent, this may indicate=C2=
=A0
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0an algorithm downgrade atta= ck.

Can there be 'pre-pubished&#= 39; DNSKEY's that are not used for signing yet, to would not be availab= le for response signatures?

Hi Bob,

Very good question Yes, th= ere certainly can be. If the pre-published key's algorithm is higher st= rength than the others, then it could cause the resolver to mistakenly dedu= ce an algorithm downgrade attack might be in progress. I think this argues = that we really do need the new zone apex (active) algorithms list record - = which we already were thinking of proposing - in the last paragraph of Sect= ion 7.

Replying to = my own message (sorry!) ..

It occurs to me that RF= C 4035 and RFC 6781 both say that zone data currently need to be signed by = a key of each algorithm in the DNSKEY RRset. So perhaps you can't pre-p= ublish a key of a new algorithm. This draft, if adopted, may also have to q= ualify some existing language (e.g. distinguishing an authoritative server = _having_ signatures of each algorithm, from selectively _returning_ signatu= res of a specific algorithm, if signaled).

--=C2= =A0
Shumon Huque

--f40304362188144a330553fc58df-- From nobody Mon Jul 10 14:00:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4616612F299 for ; Mon, 10 Jul 2017 14:00:49 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 mfngDpX6w7hy for ; Mon, 10 Jul 2017 14:00:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 7BC621318EC for ; Mon, 10 Jul 2017 14:00:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3x5yKf601dz37h; Mon, 10 Jul 2017 23:00:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1499720438; bh=65BkOoHZ8rJ+C6tMx5xeH/BpHWjwMKKYQr/FGaXK55A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CCqA8xbkaftph+Nkl2rRp0eJVit/IMPxcYqQHr3vaeD2ARlDKqOp5HUzoobjGjqYv RXJOYD8WbSagwxpfYTNHcymRK7pNKvknn/KjSz8HWsxgwtoq+npX1D2hgAMfWjGA0J GjekabARHmQ00YIlkR49InAEe2v4MbxB5zanIgAk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Po2MwX1l1hQ3; Mon, 10 Jul 2017 23:00:35 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 10 Jul 2017 23:00:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0285730AF11; Mon, 10 Jul 2017 17:00:33 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0285730AF11 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D8DDC40D3592; Mon, 10 Jul 2017 17:00:33 -0400 (EDT) Date: Mon, 10 Jul 2017 17:00:33 -0400 (EDT) From: Paul Wouters To: Shumon Huque cc: Bob Harold , "dnsop@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 21:00:49 -0000 On Mon, 10 Jul 2017, Shumon Huque wrote: > We've posted a new draft on algorithm negotiation which we're hoping > to discuss at IETF99 (and on list of course). I've discussed this > topic with several folks at DNS-OARC recently. > >     https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 I'm not a fan :) This means that DNS servers have to send responses with signatures of all algorithms that the requested data are signed with, which can result in significantly large responses. This seems to be a pretty small use case. And it is the only one mentioned in the introduction. It only affects zones that are in algorithm rollover, unless you want to run zones that permanently sign using multiple algorithms, but that's not a use case mentioned. For any caching nameserver with multiple clients, there will be no gain for the next 10 years, as it only takes 1 old client not using this option to cause the caching nameserver to refetch (adding more bandwidth usage) You explain all this is vulnerable to a downgrade attack. And the clients SHOULD (not MUST?) check the algorithms used in the DNSKEY RRset. If the client can do that, why bother with a new EDNS0 option to begin with? (I think the answer is "because an exiting DNSKEY might be in the DNSKEY RRset, but no longer in use" but that would also affect the downgrade attack then) Since you need to survive the DNSEY RRset size, most of the introduction explaining how this is to survive packet size matters at all, you still need to survive it. I don't think response size during a KSK algorithm roll is an issue that needs fixing. >> Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to >> would not be available for response signatures? > Very good question Yes, there certainly can be. If the pre-published key's > algorithm is higher strength than the others, then it could cause the resolver to > mistakenly deduce an algorithm downgrade attack might be in progress. I think this > argues that we really do need the new zone apex (active) algorithms list record - > which we already were thinking of proposing - in the last paragraph of Section 7. One would hope zones are migrated from "strong" to "even stronger" algorithms, and not from "weak" to "strong enough", so I don't think algorithm downgrade is ever an issue. This draft gives me a feeling it is really about something else, keeping long term dual signed zones out there. I don't think that we should aim for that to become commonplace. Paul From nobody Mon Jul 10 14:01:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDC01318EA for ; Mon, 10 Jul 2017 14:01:19 -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, HTML_MESSAGE=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 (1024-bit key) header.d=cloudflare.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 dKq4V7rIxFgY for ; Mon, 10 Jul 2017 14:01:18 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 EC0F61318D7 for ; Mon, 10 Jul 2017 14:01:17 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id d78so84653640qkb.1 for ; Mon, 10 Jul 2017 14:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oIEqbFP6i8JFQC3X/RT/N69vTIS5kLDuTvW2f0zocFg=; b=rgJB90LDr/rBfaP461oGnJkRTB5Zu669m80m+p8dWvbjiIosb64LY104YvDpwaYs0i rAeWH8lA6nUY6wYS9PHtZ4+t0sP549vlF8/2VjlPMfhOWV0eOPn5oCtxy+GN2NuuLYgj BUwUEVzkksksNqXuHTSSy1xj6BryEaoHcJVLk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oIEqbFP6i8JFQC3X/RT/N69vTIS5kLDuTvW2f0zocFg=; b=P7NZSBNMpH5Q8LJ9wlDey0ZUKnEVjJS+g4o0HB0XdjVTTikrpo3DAXv/UWj46Qm4X+ QPvRwVvZUpjSHBX1FkfGdD6GEKQUcr0dg1vVFn1rBva2hgV8GZ4DVVgMCstjdnXRzQZM eAFb6FY2/5b4x9+Qle6KBX/cNaDStogAKE8U2muu2kEBkqPVltjIPuoS1MSAULDFrM9m ec64DJhyiU5IDtD3i8wcZsXSSvCMeA7PM5FqeTD2H5SrJ9sKLFrnwA2HiyQdFwUq5Rk7 ZxoPMfFZaVNqrJpnO54GErH94nOR6XbnOs/W8UHE09BacvCuF+nuDeAwIqlsqY68NTXw NVNw== X-Gm-Message-State: AIVw112Pq0gqoffO5Jhg58SM49MEbg+W7RdvXQqUd7/XEMWoRZ9zrkIj EbF6G9ciBZ3BEs1h1RqE71ICpQ1qayMa++3V0g== X-Received: by 10.55.53.202 with SMTP id c193mr6075934qka.232.1499720476851; Mon, 10 Jul 2017 14:01:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.136 with HTTP; Mon, 10 Jul 2017 14:01:16 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Mon, 10 Jul 2017 17:01:16 -0400 Message-ID: To: Shumon Huque Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1146f28e4926a00553fce23f" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 21:01:20 -0000 --001a1146f28e4926a00553fce23f Content-Type: text/plain; charset="UTF-8" Shumon, In section 5 your draft says: If an Authoritative Server has no algorithms in common with the Preferred Algorithms list in the incoming query, it MUST send back a SERVFAIL response (Response Code 2). This response MUST contain the list of algorithms supported by the server in the EDNS0 Preferred Algorithms option. This is a HORRIBLE violation of the DNSSEC spirit. All validators are supposed to fail to open when they can not validate algorithm the signature is generated by. Section 6 This is hopeless algorithm, that goes against the justification of the document. basically it may force validating resolvers to fetch the answers multiple times for each TTL; once without DNSSEC, then for first algorithm, then for all algorithms ==> right now validating resolvers only fetch once with DNSSEC enabled. This is a HORRIBLE violation of the DNSSEC spirit. All validators are supposed to fail to open when they can not validate algorithm the signature is generated by. overall this draft main idea: DNS publishers should sign with more algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set ==> better for DDoS Olafur On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque wrote: > Hi folks, > > We've posted a new draft on algorithm negotiation which we're hoping to > discuss at IETF99 (and on list of course). I've discussed this topic with > several folks at DNS-OARC recently. > > https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Algorithm Negotiation in DNSSEC > Authors : Shumon Huque > Haya Shulman > Filename : draft-huque-dnssec-alg-nego-00.txt > Pages : 9 > Date : 2017-07-03 > > Abstract: > This document specifies a DNS extension that allows a DNS client to > specify a list of DNSSEC algorithms, in preference order, that the > client desires to use. A DNS server upon receipt of this extension > can choose to selectively respond with DNSSEC signatures using the > most preferred algorithm they support. This mechanism may make it > easier for DNS zone operators to support signing zone data > simultaneously with multiple DNSSEC algorithms, without significantly > increasing the size of DNS responses. It will also allow an easier > way to transition to new algorithms while still retaining support for > older DNS validators that do not yet support the new algorithms. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-huque-dnssec-alg-nego/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 > https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-00 > > -- > Shumon Huque > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --001a1146f28e4926a00553fce23f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Shumon,=C2=A0

In section 5 your d= raft says:=C2=A0
   If an Authoritati=
ve Server has no algorithms in common with the
   Preferred Algorithms list in the incoming query, it MUST send back a
   SERVFAIL response (Response Code 2).  This response MUST contain the
   list of algorithms supported by the server in the EDNS0 Preferred
   Algorithms option.


This is a HORRIBLE violation of the DNSSEC spirit. All validators are sup= posed to fail to open when they can not validate algorithm the signature is= generated by.=C2=A0

Section 6=C2=A0
This is hopeless algorithm, that goes against the justification of the d= ocument.=C2=A0
basically it may force validating resolvers to fet= ch the answers multiple times for each TTL; once without DNSSEC, then for f= irst algorithm, then for all algorithms =3D=3D> right now validating res= olvers only fetch once with DNSSEC enabled.=C2=A0

=
This is a HORRIBLE violation of the DNSSEC spirit. All valid= ators are supposed to fail to open when they can not validate algorithm the= signature is generated by.=C2=A0

overall this dra= ft main idea: DNS publishers should sign with more algorithms, =3D=3D=3D>= ; this means more keys in DNSKEY set i.e. larger DNSKEY set =3D=3D> bett= er for DDoS =C2=A0

Olafur



On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <<= a href=3D"mailto:shuque@gmail.com" target=3D"_blank">shuque@gmail.com&g= t; wrote:
Hi folk= s,

We've posted a new draft on algorithm negotiation= which we're hoping to discuss at IETF99 (and on list of course). I'= ;ve discussed this topic with several folks at DNS-OARC recently.



A New Internet-Draft is available from the on-line Internet-Drafts d= irectories.


=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Algorithm Negotiation in = DNSSEC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : Shumon Huque
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Haya Shulman
=C2=A0Filename =C2=A0 =C2=A0 = =C2=A0 =C2=A0: draft-huque-dnssec-alg-nego-00.txt
=C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 9
= =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2017-07-03
=
Abstract:
=C2=A0 =C2=A0This document specifies a D= NS extension that allows a DNS client to
=C2=A0 =C2=A0specify a l= ist of DNSSEC algorithms, in preference order, that the
=C2=A0 = =C2=A0client desires to use.=C2=A0 A DNS server upon receipt of this extens= ion
=C2=A0 =C2=A0can choose to selectively respond with DNSSEC si= gnatures using the
=C2=A0 =C2=A0most preferred algorithm they sup= port.=C2=A0 This mechanism may make it
=C2=A0 =C2=A0easier for DN= S zone operators to support signing zone data
=C2=A0 =C2=A0simult= aneously with multiple DNSSEC algorithms, without significantly
= =C2=A0 =C2=A0increasing the size of DNS responses.=C2=A0 It will also allow= an easier
=C2=A0 =C2=A0way to transition to new algorithms while= still retaining support for
=C2=A0 =C2=A0older DNS validators th= at do not yet support the new algorithms.


The IETF datatracker status page for this draft is:

There are also htmlized versions avai= lable at:
<= /div>

--= =C2=A0
Shumon Huque


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--001a1146f28e4926a00553fce23f-- From nobody Mon Jul 10 14:59:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3D413191A for ; Mon, 10 Jul 2017 14:59:22 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2GZaM12Hd1LH for ; Mon, 10 Jul 2017 14:59:20 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 F233112F27C for ; Mon, 10 Jul 2017 14:59:19 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id w19so63637962uac.0 for ; Mon, 10 Jul 2017 14:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jkK5Oj0KWG4Chw2ZwBEmUKgepQ5fsF8/fieMb5AlUQU=; b=RuGSNsXUeNuQCQdHky9b+1SgUZkvYYC8y49I5tg/L+CBNIxtjF8FCooDlBpHQVUHrl 01LSZUg4UMaDQg38vhkg5wJHcmtrOl8yn4k3GKLklwPr4RX9v7bXHPwtmEGblIvxC2dJ 8x9avKOPVr2Aw4Gu3BnHmeK2qqpwYWr0ixeUUpFhcABvwgTW7dg2tOAuGVoE3S+IlSGR ilKo+fRzwOBqess9bJPUl8vqzwGU1FV3ioNkzg64GPmWvrKBF1rWYwgvkga66bNSHBlJ rpV4BVhpIjMzYUXhcToGxNuU7rdNjRgLLGuweTs2FLBSgeGk2l//4BsVUNaFvOZ4Oydl MGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jkK5Oj0KWG4Chw2ZwBEmUKgepQ5fsF8/fieMb5AlUQU=; b=s3kIjiff9mfc1H8CIBMOl+oKBPVTYqq+UJwlwoQwwLyeqKtoyfqaKk6FVe3XZWn+9a ts+ELnyOpKc6H/eabLvS9prohvLWMWZ8WtAyOi+NoCJWE8EWlLRVCWaFw1QBc5a8JcQg qNDECnKdUfiYEt2Y9yr2ZtJH0h2DyBv7zXLGKwRoN+2IiSpl4lV/BOZqFmACA3SGX9V+ 4KHzbuNn0dyswAFaOCP7FN2giWkeG4Xg4Z+Zh9oF518E4zNkRaTwKU7SwpvxeZbvms+L LH2FMpHWBBLPtl6J7o7n8i+w5hhtSfoy4YN9+UYmPp5Bf/5MVNHiujDYcz24m5TLRn0b Cfcw== X-Gm-Message-State: AIVw1102ydhZZRF2gSNumanoqN7QLrrbustZfWZRzhdfahKaCKn7Kxz9 nhgFRPV/ZAy9qa/0DTTko6lmOZzvPQ== X-Received: by 10.176.86.21 with SMTP id y21mr8812806uaa.72.1499723959092; Mon, 10 Jul 2017 14:59:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 14:59:18 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Mon, 10 Jul 2017 17:59:18 -0400 Message-ID: To: Paul Wouters Cc: Bob Harold , "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="f403045dd5b0d7d11d0553fdb193" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 21:59:23 -0000 --f403045dd5b0d7d11d0553fdb193 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 5:00 PM, Paul Wouters wrote: > On Mon, 10 Jul 2017, Shumon Huque wrote: > > We've posted a new draft on algorithm negotiation which we're hoping >> to discuss at IETF99 (and on list of course). I've discussed this >> topic with several folks at DNS-OARC recently. >> >> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 >> > > I'm not a fan :) > > This means that DNS servers have to send responses with signatures > of > all algorithms that the requested data are signed with, which can > result in significantly large responses. > > This seems to be a pretty small use case. And it is the only one > mentioned in the introduction. It only affects zones that are in > algorithm rollover, unless you want to run zones that permanently sign > using multiple algorithms, but that's not a use case mentioned. > Perhaps we didn't explain it clearly enough, so let me give you a concrete example: My zone is currently signed with 2048-bit RSASHA256. I want to offer signatures with Ed448 (or some other new algorithm) also, so that newer validators can take advantage of it. However, I want to be able to continue to support the current population of validators that don't support Ed448 until a sufficient amount of time has passed where they have all been upgraded - this could be some number of years. I also don't want to double sign the zone and return multiple signatures in the responses, because they might be fragmented and cause timeouts and retransmissions at the client (validator) end. I could truncate those responses and prompt them to re-query over TCP, but then again I have caused an unnecessary failed roundtrip and have incurred additional processing costs associated with TCP, and maybe I haven't scaled up my authoritative infrastructure sufficiently to deal with that. I also don't want to deploy only Ed448 and cause my zone to be instantly treated as unsigned by the vast majority of resolvers. Obviously, because I've nullified the security benefit of DNSSEC, but also because I have application security protocols, like DANE, that critically depend on DNSSEC authentication, for which this would pose a grave security risk. So the goal is not to have them "permanently" signed with multiple algorithms, but for a defined transition period, which may not be very short. At that point, the older algorithm would be withdrawn -- so algorithm rollover, but over an extended period. For any caching nameserver with multiple clients, there will be no gain > for the next 10 years, as it only takes 1 old client not using this > option to cause the caching nameserver to refetch (adding more bandwidth > usage) > > You explain all this is vulnerable to a downgrade attack. And the > clients SHOULD (not MUST?) check the algorithms used in the DNSKEY > RRset. Yes, that should have been a MUST (I made a note of that already for the next revision). > Since you need to survive the DNSEY RRset size, most of the introduction > explaining how this is to survive packet size matters at all, you still > need to survive it. > Of course there are initial costs. The goal is longer term - the benefits will increase with more adoption over time. There will be a lot of large responses initially, which will decrease over time. > I don't think response size during a KSK algorithm roll is an issue that > needs fixing. > > Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to >>> would not be available for response signatures? >>> >> > Very good question Yes, there certainly can be. If the pre-published key's >> algorithm is higher strength than the others, then it could cause the >> resolver to >> mistakenly deduce an algorithm downgrade attack might be in progress. I >> think this >> argues that we really do need the new zone apex (active) algorithms list >> record - >> which we already were thinking of proposing - in the last paragraph of >> Section 7. >> > > One would hope zones are migrated from "strong" to "even stronger" > algorithms, and not from "weak" to "strong enough", so I don't think > algorithm downgrade is ever an issue. > Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is the butt of jokes in the larger security community. > > This draft gives me a feeling it is really about something else, keeping > long term dual signed zones out there. I don't think that we should > aim for that to become commonplace. See the first example I gave. We're not trying to surreptitiously sneak in a use case. -- Shumon Huque --f403045dd5b0d7d11d0553fdb193 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 5:00 PM, Paul Wouters <paul@nohats.ca> wrot= e:
On Mon, 10 Jul 2017, = Shumon Huque wrote:

We've posted a new draft on algorithm negotiation which we're hopin= g
to discuss at IETF99 (and on list of course). I've discussed this
topic with several folks at DNS-OARC recently.

=C2=A0 =C2=A0 https://tools.ietf.org/html/= draft-huque-dnssec-alg-nego-00

 I'm not a fan :)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This means that DNS servers have to send respon= ses with signatures of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 all algorithms that the requested data are sign= ed with, which can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 result in significantly large responses.

This seems to be a pretty small use case. And it is the only one
mentioned in the introduction. It only affects zones that are in
algorithm rollover, unless you want to run zones that permanently sign
using multiple algorithms, but that's not a use case mentioned.

Perhaps we didn't explain it clearly enoug= h, so let me give you a concrete example:

My zone = is currently signed with 2048-bit RSASHA256. I want to offer signatures wit= h Ed448 (or some other new algorithm) also, so that newer validators can ta= ke advantage of it. However, I want to be able to continue to support the c= urrent population of validators that don't support Ed448 until a suffic= ient amount of time has passed where they have all been upgraded - this cou= ld be some number of years.

I also don't want = to double sign the zone and return multiple signatures in the responses, be= cause they might be fragmented and cause timeouts and retransmissions at th= e client (validator) end. I could truncate those responses and prompt them = to re-query over TCP, but then again I have caused an unnecessary failed ro= undtrip and have incurred additional processing costs associated with TCP, = and maybe I haven't scaled up my authoritative infrastructure sufficien= tly to deal with that.

I also don't want to de= ploy only Ed448 and cause my zone to be instantly treated as unsigned by th= e vast majority of resolvers. Obviously, because I've nullified the sec= urity benefit of DNSSEC, but also because I have application security proto= cols, like DANE, that critically depend on DNSSEC authentication, for which= this would pose a grave security risk.

So the goa= l is not to have them "permanently" signed with multiple algorith= ms, but for a defined transition period, which may not be very short. At th= at point, the older algorithm would be withdrawn -- so algorithm rollover, = but over an extended period.

For any caching nameserver with multiple clients, there will be no gain
for the next 10 years, as it only takes 1 old client not using this
option to cause the caching nameserver to refetch (adding more bandwidth usage)

You explain all this is vulnerable to a downgrade attack. And the
clients SHOULD (not MUST?) check the algorithms used in the DNSKEY
RRset.

Yes, that should have been a MUST (= I made a note of that already for the next revision).
=C2=A0
Since you need to survive the DNSEY RRset size, most of the introduction explaining how this is to survive packet size matters at all, you still
need to survive it.

Of course there are= initial costs. The goal is longer term - the benefits will increase with m= ore adoption over time. There will be a lot of large responses initially, w= hich will decrease over time.
=C2=A0
I don't think response size during a KSK algorithm roll is an issue tha= t
needs fixing.

Can there be 'pre-pubished' DNSKEY's that are not used for sign= ing yet, to
would not be available for response signatures?

Very good question Yes, there certainly can be. If the pre-published key= 9;s
algorithm is higher strength than the others, then it could cause the resol= ver to
mistakenly deduce an algorithm downgrade attack might be in progress. I thi= nk this
argues that we really do need the new zone apex (active) algorithms list re= cord -
which we already were thinking of proposing - in the last paragraph of Sect= ion 7.

 One would hope zones are migrated from "strong" to "even str= onger"
algorithms, and not from "weak" to "strong enough", so = I don't think
algorithm downgrade is ever an issue.

R= eally? RSA1024 is still widely deployed, and is frequently why DNSSEC is th= e butt of jokes in the larger security community.
=C2=A0

This draft gives me a feeling it is really about something else, keeping long term dual signed zones out there. I don't think that we should
aim for that to become commonplace.

See the= first example I gave. We're not trying to surreptitiously sneak in a u= se case.=C2=A0

--=C2=A0
Shumon Huque

--f403045dd5b0d7d11d0553fdb193-- From nobody Mon Jul 10 15:16:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3E13192D for ; Mon, 10 Jul 2017 15:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 Br0U4sBivsAT for ; Mon, 10 Jul 2017 15:16:55 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 1C11D13190C for ; Mon, 10 Jul 2017 15:16:55 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id y70so55127886vky.3 for ; Mon, 10 Jul 2017 15:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ARm66Pyr5HNRMFFeMChG4vQpvstTgo9+41FqtJIhQrM=; b=dEKJ0vKUOKZfsXG6yS4hk57cu0wS/LWqF9YXzIVe7Jheo35pfGOz1ynW1QMzY52IIe 9c/iNaXlPdQW36hCccvWg1bakph6wUzfpRHIeO12lwNb1rJS6s67vSVo/w3pGWe7Kq7u zAoeN4vJGmx5fCN1M5b/HpiAuLlTLPcxgAfVPLY20Jn3gFUyR+9U7HMUhqKptjoK/Qge u/GI/dCmQhmQwJwI0Hqr0zbr8oY85EfPI982WtleIGvi/BoBf7DJC3NbZmGO0APucj28 vgcJNO5w/GO00JX1o1ilGx22bl9nHa1F1or+fD7wF+jMTKznGS7SK1sobaptBD3l86uj Ywww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ARm66Pyr5HNRMFFeMChG4vQpvstTgo9+41FqtJIhQrM=; b=tU2hsoIWI1sAKn6/mISUo8RJoPmA3zW/mDvjV4JQXjaD7Ke/pYmlhDjN8i8G6sCFx5 3XWqdI6K5TxlBSiq7oMoY3k6OxMFh+vdceybv+llSw4LzXeFfGXIh8lpddvHCA1jelxj +pqxdXEPSgNtgwRgMizJzauBshziOKF70QRMMX58GN6oRUTGL9JctkplzFVjGbK091X+ QR9e1LpsVlfy/ML91m/SS4Cy9hj9c1ghLBiXgr05TNKQW2HzR2h6tsQ4HlSRGNVyDJta YuEHwougWQbhAInjMWCzgBFO1h3WI48Xy0TIcDKe9FIIE2B+FEeeThDgAsXnHRoHYa4e XwGw== X-Gm-Message-State: AIVw113Au6xs/bs0n47ThKhQDmi3K1Em+fyrmAk6Dm8bl27VCV504Tsx Srv/zzFASUFuO0FSldgxNugz/V+i8Q== X-Received: by 10.31.181.145 with SMTP id e139mr5906585vkf.69.1499725014249; Mon, 10 Jul 2017 15:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 15:16:53 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Mon, 10 Jul 2017 18:16:53 -0400 Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11439b7abc379c0553fdf056" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 22:16:57 -0000 --001a11439b7abc379c0553fdf056 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 10, 2017 at 5:01 PM, =C3=93lafur Gu=C3=B0mundsson wrote: > Shumon, > > In section 5 your draft says: > > If an Authoritative Server has no algorithms in common with the > Preferred Algorithms list in the incoming query, it MUST send back a > SERVFAIL response (Response Code 2). This response MUST contain the > list of algorithms supported by the server in the EDNS0 Preferred > Algorithms option. > > > > This is a HORRIBLE violation of the DNSSEC spirit. All validators are > supposed to fail to open when they can not validate algorithm the signatu= re > is generated by. > As I tried to explain in my previous note to Paul Wouters - fail open is horrible for DANE. Protocols can evolve. If DNSSEC had algorithm negotiation from the beginning, fail open would not have been necessary. This fail open behavior frequently takes people not in the DNSSEC club by complete surprise. I've lost track of how many "WTF" moments I've had to explain to other people about this behavior. This proposed behavior change is also signaled, not unilateral. But let's debate ... Section 6 > This is hopeless algorithm, that goes against the justification of the > document. > basically it may force validating resolvers to fetch the answers multiple > times for each TTL; once without DNSSEC, then for first algorithm, then f= or > all algorithms =3D=3D> right now validating resolvers only fetch once wit= h > DNSSEC enabled. > There has to be some initial fallback behavior with costs. This is not uncommon in new protocols. Think about longer term benefits. > This is a HORRIBLE violation of the DNSSEC spirit. All validators are > supposed to fail to open when they can not validate algorithm the signatu= re > is generated by. > See previous discussion. > > overall this draft main idea: DNS publishers should sign with more > algorithms, =3D=3D=3D> this means more keys in DNSKEY set i.e. larger DNS= KEY set > =3D=3D> better for DDoS > DNSSEC already has a DDoS reputation - this isn't going to make things that much worse. Also DNSSEC has already been way surpassed in this area by NTP/SNMP etc. What we should be working on is deployment of proper protocol level mitigations, like Cookies, etc. --=20 Shumon Huque --001a11439b7abc379c0553fdf056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 5:01 PM, =C3=93lafur Gu=C3=B0mundsson <olafur@clou= dflare.com> wrote:
Shumon,=C2=A0

In section 5 your draft say= s:=C2=A0
   If a=
n Authoritative Server has no algorithms in common with the
   Preferred Algorithms list in the incoming query, it MUST send back a
   SERVFAIL response (Response Code 2).  This response MUST contain the
   list of algorithms supported by the server in the EDNS0 Preferred
   Algorithms option.


This is a HORRIBLE violation of the DNSSEC spirit. A= ll validators are supposed to fail to open when they can not validate algor= ithm the signature is generated by.=C2=A0

As I tried to explain in my previous note to Paul Wo= uters - fail open is horrible for DANE. Protocols can evolve. If DNSSEC had= algorithm negotiation from the beginning, fail open would not have been ne= cessary. This fail open behavior frequently takes people not in the DNSSEC = club by complete surprise. I've lost track of how many "WTF" = moments I've had to explain to other people about this behavior. This p= roposed behavior change is also signaled, not unilateral. But let's deb= ate ...

Section 6=C2=A0
This is hopeless algorithm, that goes = against the justification of the document.=C2=A0
basically it may= force validating resolvers to fetch the answers multiple times for each TT= L; once without DNSSEC, then for first algorithm, then for all algorithms = =3D=3D> right now validating resolvers only fetch once with DNSSEC enabl= ed.=C2=A0

There has to be= some initial fallback behavior with costs. This is not uncommon in new pro= tocols. Think about longer term benefits.
=C2=A0
This is a HORRIBLE violation= of the DNSSEC spirit. All validators are supposed to fail to open when the= y can not validate algorithm the signature is generated by.=C2=A0

See previous discussion.
=C2=A0

=
overall this draft main idea: DNS publishers should sign with mo= re algorithms, =3D=3D=3D> this means more keys in DNSKEY set i.e. larger= DNSKEY set =3D=3D> better for DDoS=C2=A0
=

DNSSEC already has a DDoS reputation - this isn't g= oing to make things that much worse. Also DNSSEC has already been way surpa= ssed in this area by NTP/SNMP etc. What we should be working on is deployme= nt of proper protocol level mitigations, like Cookies, etc.
=C2= =A0
--=C2=A0
Shumon Huque

--001a11439b7abc379c0553fdf056-- From nobody Mon Jul 10 15:41:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79645131846 for ; Mon, 10 Jul 2017 15:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 19p56qwkHL2P for ; Mon, 10 Jul 2017 15:41:11 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 43269127180 for ; Mon, 10 Jul 2017 15:41:11 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id EBFDB24AE15; Mon, 10 Jul 2017 22:41:00 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id F413B160041; Mon, 10 Jul 2017 22:41:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DCCAA16006E; Mon, 10 Jul 2017 22:41:04 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FhPkSZgJqSOP; Mon, 10 Jul 2017 22:41:04 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 34D9E160041; Mon, 10 Jul 2017 22:41:04 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EDB357E3CB92; Tue, 11 Jul 2017 08:41:02 +1000 (AEST) To: Shumon Huque Cc: Paul Wouters , Bob Harold , "dnsop@ietf.org WG" From: Mark Andrews References: In-reply-to: Your message of "Mon, 10 Jul 2017 17:59:18 -0400." Date: Tue, 11 Jul 2017 08:41:02 +1000 Message-Id: <20170710224102.EDB357E3CB92@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 22:41:14 -0000 In message , Shumon Huque writes: > On Mon, Jul 10, 2017 at 5:00 PM, Paul Wouters wrote: > > > On Mon, 10 Jul 2017, Shumon Huque wrote: > > > > We've posted a new draft on algorithm negotiation which we're hoping > >> to discuss at IETF99 (and on list of course). I've discussed this > >> topic with several folks at DNS-OARC recently. > >> > >> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 > >> > > > > I'm not a fan :) > > > > This means that DNS servers have to send responses with signatures > > of > > all algorithms that the requested data are signed with, which can > > result in significantly large responses. > > > > This seems to be a pretty small use case. And it is the only one > > mentioned in the introduction. It only affects zones that are in > > algorithm rollover, unless you want to run zones that permanently sign > > using multiple algorithms, but that's not a use case mentioned. > > > > Perhaps we didn't explain it clearly enough, so let me give you a concrete > example: > > My zone is currently signed with 2048-bit RSASHA256. I want to offer > signatures with Ed448 (or some other new algorithm) also, so that newer > validators can take advantage of it. However, I want to be able to continue > to support the current population of validators that don't support Ed448 > until a sufficient amount of time has passed where they have all been > upgraded - this could be some number of years. It will take a number of years. > I also don't want to double sign the zone and return multiple signatures in > the responses, because they might be fragmented and cause timeouts and > retransmissions at the client (validator) end. I could truncate those > responses and prompt them to re-query over TCP, but then again I have > caused an unnecessary failed roundtrip and have incurred additional > processing costs associated with TCP, and maybe I haven't scaled up my > authoritative infrastructure sufficiently to deal with that. Just send the large UDP messages up to the advertised EDNS UDP size. Just make sure that your end correctly handles ICMP PTB messages and doesn't have stupid firewall rules (or othe equipement) that drop your fragmented replies. If your equipement can't handle ICMP PTB, fragment at sizes that won't generate PTB responses / don't set DF on the packets and set your TCP segment sizes so that they won't generate ICMP PTB. Let the other end deal with their broken/misconfigured equipment. Its not your job to get the answers through their broken equipement. All you are doing is penalising those that have working equipement by forcing them to use TCP when UDP would be sufficient. All that does is shift packet size issues to TCP. Slow validation will get them to fix their equipement. > I also don't want to deploy only Ed448 and cause my zone to be instantly > treated as unsigned by the vast majority of resolvers. Obviously, because > I've nullified the security benefit of DNSSEC, but also because I have > application security protocols, like DANE, that critically depend on DNSSEC > authentication, for which this would pose a grave security risk. For some reason there is this insane rush to use Ed448 before even the major crypto providors have shipped releases which support it. Get support into major packages then use it in production. Yes, we are working on adding it to BIND. Name servers get upgraded. > So the goal is not to have them "permanently" signed with multiple > algorithms, but for a defined transition period, which may not be very > short. At that point, the older algorithm would be withdrawn -- so > algorithm rollover, but over an extended period. > > For any caching nameserver with multiple clients, there will be no gain > > for the next 10 years, as it only takes 1 old client not using this > > option to cause the caching nameserver to refetch (adding more bandwidth > > usage) > > > > You explain all this is vulnerable to a downgrade attack. And the > > clients SHOULD (not MUST?) check the algorithms used in the DNSKEY > > RRset. > > > Yes, that should have been a MUST (I made a note of that already for the > next revision). > > > > Since you need to survive the DNSEY RRset size, most of the introduction > > explaining how this is to survive packet size matters at all, you still > > need to survive it. > > > > Of course there are initial costs. The goal is longer term - the benefits > will increase with more adoption over time. There will be a lot of large > responses initially, which will decrease over time. > > > > I don't think response size during a KSK algorithm roll is an issue that > > needs fixing. > > > > Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to > >>> would not be available for response signatures? > >>> > >> > > Very good question Yes, there certainly can be. If the pre-published key's > >> algorithm is higher strength than the others, then it could cause the > >> resolver to > >> mistakenly deduce an algorithm downgrade attack might be in progress. I > >> think this > >> argues that we really do need the new zone apex (active) algorithms list > >> record - > >> which we already were thinking of proposing - in the last paragraph of > >> Section 7. > >> > > > > One would hope zones are migrated from "strong" to "even stronger" > > algorithms, and not from "weak" to "strong enough", so I don't think > > algorithm downgrade is ever an issue. > > > > Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is > the butt of jokes in the larger security community. Which is solved by not allowing key generators to generate small keys. This isn't a algorithm roll issue. > > This draft gives me a feeling it is really about something else, keeping > > long term dual signed zones out there. I don't think that we should > > aim for that to become commonplace. > > See the first example I gave. We're not trying to surreptitiously sneak in > a use case. > > -- > Shumon Huque > > --f403045dd5b0d7d11d0553fdb193 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > >
On M= > on, Jul 10, 2017 at 5:00 PM, Paul Wouters < mailto:paul@nohats.ca" target=3D"_blank">paul@nohats.ca> wrot= > e:
eft:1px #ccc solid;padding-left:1ex">On Mon, 10 Jul 2017, = > Shumon Huque wrote:
>
>
x #ccc solid;padding-left:1ex"> > We've posted a new draft on algorithm negotiation which we're hopin= > g
> to discuss at IETF99 (and on list of course). I've discussed this
> topic with several folks at DNS-OARC recently.
>
> =C2=A0 =C2=A0 -nego-00" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/= > draft-huque-dnssec-alg-nego-00
>
>
> I'm not a fan :)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This means that DNS servers have to send respon= > ses with signatures of
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 all algorithms that the requested data are sign= > ed with, which can
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 result in significantly large responses.
>
> This seems to be a pretty small use case. And it is the only one
> mentioned in the introduction. It only affects zones that are in
> algorithm rollover, unless you want to run zones that permanently sign
> using multiple algorithms, but that's not a use case mentioned.
ockquote>

Perhaps we didn't explain it clearly enoug= > h, so let me give you a concrete example:

My zone = > is currently signed with 2048-bit RSASHA256. I want to offer signatures wit= > h Ed448 (or some other new algorithm) also, so that newer validators can ta= > ke advantage of it. However, I want to be able to continue to support the c= > urrent population of validators that don't support Ed448 until a suffic= > ient amount of time has passed where they have all been upgraded - this cou= > ld be some number of years.

I also don't want = > to double sign the zone and return multiple signatures in the responses, be= > cause they might be fragmented and cause timeouts and retransmissions at th= > e client (validator) end. I could truncate those responses and prompt them = > to re-query over TCP, but then again I have caused an unnecessary failed ro= > undtrip and have incurred additional processing costs associated with TCP, = > and maybe I haven't scaled up my authoritative infrastructure sufficien= > tly to deal with that.

I also don't want to de= > ploy only Ed448 and cause my zone to be instantly treated as unsigned by th= > e vast majority of resolvers. Obviously, because I've nullified the sec= > urity benefit of DNSSEC, but also because I have application security proto= > cols, like DANE, that critically depend on DNSSEC authentication, for which= > this would pose a grave security risk.

So the goa= > l is not to have them "permanently" signed with multiple algorith= > ms, but for a defined transition period, which may not be very short. At th= > at point, the older algorithm would be withdrawn -- so algorithm rollover, = > but over an extended period.

_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= > 1ex"> > For any caching nameserver with multiple clients, there will be no gain
> for the next 10 years, as it only takes 1 old client not using this
> option to cause the caching nameserver to refetch (adding more bandwidth > > usage)
>
> You explain all this is vulnerable to a downgrade attack. And the
> clients SHOULD (not MUST?) check the algorithms used in the DNSKEY
> RRset.

Yes, that should have been a MUST (= > I made a note of that already for the next revision).
=C2=A0 >
px #ccc solid;padding-left:1ex"> > Since you need to survive the DNSEY RRset size, most of the introduction > > explaining how this is to survive packet size matters at all, you still
> need to survive it.

Of course there are= > initial costs. The goal is longer term - the benefits will increase with m= > ore adoption over time. There will be a lot of large responses initially, w= > hich will decrease over time.
=C2=A0
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= > ft:1ex"> > I don't think response size during a KSK algorithm roll is an issue tha= > t
> needs fixing.
>
>
x #ccc solid;padding-left:1ex">
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Can there be 'pre-pubished' DNSKEY's that are not used for sign= > ing yet, to
> would not be available for response signatures?
>
>
>
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Very good question Yes, there certainly can be. If the pre-published key= > 9;s
> algorithm is higher strength than the others, then it could cause the resol= > ver to
> mistakenly deduce an algorithm downgrade attack might be in progress. I thi= > nk this
> argues that we really do need the new zone apex (active) algorithms list re= > cord -
> which we already were thinking of proposing - in the last paragraph of Sect= > ion 7.
>
>
> One would hope zones are migrated from "strong" to "even str= > onger"
> algorithms, and not from "weak" to "strong enough", so = > I don't think
> algorithm downgrade is ever an issue.

R= > eally? RSA1024 is still widely deployed, and is frequently why DNSSEC is th= > e butt of jokes in the larger security community.
=C2=A0
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= > ccc solid;padding-left:1ex"> >
> This draft gives me a feeling it is really about something else, keeping > > long term dual signed zones out there. I don't think that we should
> aim for that to become commonplace.

See the= > first example I gave. We're not trying to surreptitiously sneak in a u= > se case.=C2=A0

--=C2=A0
Shumon Huque v>

> > --f403045dd5b0d7d11d0553fdb193-- > > > --===============7925457567352458756== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --===============7925457567352458756==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jul 10 15:55:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B7013193E for ; Mon, 10 Jul 2017 15:55:36 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 4moH3YhzkuB6 for ; Mon, 10 Jul 2017 15:55:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C4A0413193D for ; Mon, 10 Jul 2017 15:55:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3x60t90wC4z1Gp; Tue, 11 Jul 2017 00:55:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1499727329; bh=p+7xd8YEK/RVs7nkxFJODAtd4znwafrR31LYWFGS6d8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=c/rBTqXtVqk7ZJMISFYSDhzIImEld+kCtbqouwSTLPDw9rayHaTisp0OcS955+QJk Qfh91crfpF4iFcmx3GZ+W5eZLN2Nx4goBjZK4h915IP6KGpP+wYaTUa+DPPStHyIaB FGfkA2kOAaDmQke/1ZnvriUzzgvSOcazQRfxakrU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jUNrWcfbsGl3; Tue, 11 Jul 2017 00:55:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Jul 2017 00:55:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id ADCAF30AF11; Mon, 10 Jul 2017 18:55:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca ADCAF30AF11 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9809640D3592; Mon, 10 Jul 2017 18:55:25 -0400 (EDT) Date: Mon, 10 Jul 2017 18:55:25 -0400 (EDT) From: Paul Wouters To: Shumon Huque cc: "dnsop@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 22:55:36 -0000 On Mon, 10 Jul 2017, Shumon Huque wrote: > Perhaps we didn't explain it clearly enough, so let me give you a concrete example: > > My zone is currently signed with 2048-bit RSASHA256. I want to offer signatures with Ed448 (or some other new algorithm) also, so that > newer validators can take advantage of it. However, I want to be able to continue to support the current population of validators that > don't support Ed448 until a sufficient amount of time has passed where they have all been upgraded - this could be some number of years. > > I also don't want to double sign the zone and return multiple signatures in the responses, because they might be fragmented and cause > timeouts and retransmissions at the client (validator) end. I could truncate those responses and prompt them to re-query over TCP, but > then again I have caused an unnecessary failed roundtrip and have incurred additional processing costs associated with TCP, and maybe I > haven't scaled up my authoritative infrastructure sufficiently to deal with that. > > I also don't want to deploy only Ed448 and cause my zone to be instantly treated as unsigned by the vast majority of resolvers. Obviously, > because I've nullified the security benefit of DNSSEC, but also because I have application security protocols, like DANE, that critically > depend on DNSSEC authentication, for which this would pose a grave security risk. > > So the goal is not to have them "permanently" signed with multiple algorithms, but for a defined transition period, which may not be very > short. At that point, the older algorithm would be withdrawn -- so algorithm rollover, but over an extended period. Okay, that explains it better. but does also confirm you basically want to be permanently in this state. Because every few years you will have new fancy algorithms. As a community we should really roll out updated algorithms faster and deprecate obsoleted algorithms faster. > Of course there are initial costs. The goal is longer term - the benefits will increase with more adoption over time. There will be a lot > of large responses initially, which will decrease over time. But then why not depend on adoption of (and deprecation of) old signing algorithms? > One would hope zones are migrated from "strong" to "even stronger" > algorithms, and not from "weak" to "strong enough", so I don't think > algorithm downgrade is ever an issue. > > Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is the butt of jokes in the larger security community. You are mixing up keysize and algorithm rollover :P RSA is not broken, and safe to use, preferably at 2048 key size. No double signing or algorithm signaling is needed to go from RSA1024 to RSA2048 :) also: https://www.internetsociety.org/doc/state-dnssec-deployment-2016 "The overwhelming majority (~99%) of TLDs use 2048 bit keys" I can't find a statistics URL for all domains (secspider seems to have changed and I cannot find the RSA key sizes per domain anymore) but I'm pretty sure 1024 will be on the decline. Anyway, my point is that we should not have 20 sexy algorithms, but only a very limited set of a few algorithms that we all agree are strong enough. We shouldn't enter into negotiations of prefered crypto algorithms between auth and recursive servers. And once opendnssec algorithm rollover is available from stable distributions, I think we will see most zones go from RSASHA1 to RSASHA256 or ECDSA. Paul From nobody Mon Jul 10 16:15:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4313193D for ; Mon, 10 Jul 2017 16:15:56 -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] 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 Qb0JVJaC7Mp4 for ; Mon, 10 Jul 2017 16:15:55 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 CFCED1276AF for ; Mon, 10 Jul 2017 16:15:55 -0700 (PDT) Received: from [169.254.189.188] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6ANF8oN092819 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Jul 2017 16:15:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.189.188] From: "Paul Hoffman" To: "Peter van Dijk" Cc: dnsop@ietf.org Date: Mon, 10 Jul 2017 16:15:52 -0700 Message-ID: In-Reply-To: <2D02BDF5-FE9B-4E77-A561-5E0988AEBCF9@powerdns.com> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <2D02BDF5-FE9B-4E77-A561-5E0988AEBCF9@powerdns.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:15:57 -0000 On 3 Jul 2017, at 1:48, Peter van Dijk wrote: > Hello, > > On 1 Jul 2017, at 23:40, internet-drafts@ietf.org wrote: > >> Abstract: >> The DNS is defined in literally dozens of different RFCs. The >> terminology used by implementers and developers of DNS protocols, and >> by operators of DNS systems, has sometimes changed in the decades >> since the DNS was first defined. This document gives current >> definitions for many of the terms used in the DNS in a single >> document. >> >> This document will be the successor to RFC 7719, and thus will >> obsolete RFC 7719. It will also update RFC 2308 and RFC 3758. > > s/3758/3757/ Yeeps! Fixed in the source for the next update. Thanks! --Paul Hoffman From nobody Mon Jul 10 16:44:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3851120726 for ; Mon, 10 Jul 2017 16:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 fWBfpu-N7xqw for ; Mon, 10 Jul 2017 16:43:59 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 176231200ED for ; Mon, 10 Jul 2017 16:43:59 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id r125so56506870vkf.1 for ; Mon, 10 Jul 2017 16:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QhvEKy1PcCrcHLoF2lpNi2QcyG8x8naEGnoZhlSiKig=; b=tWoicQ6wR5744usG5OMmyo5HUVNG2Locy+Xi1uRsVsnMVbYNcOroI1iTPOLsOA+7wI UXdrEO23sMY2ee3FBxO4IUOuSHN770draHWLAqq88ryUYDNInK+EDqO3S+WT05KuyuoN E1rufo1yWwsg1uLXAYwetJ5nywd/TYuqNpQQdkQfgn/a0wHTHKhz0pOgb269BFrnLCdl UF6hrzLwREHLSVaziXb/VmIQmlIO4wadCJ1Lzkwl6Zb692SDdu3PZGULNUE73Abuqlcm MKuRxxKR/KKkQFeRBpXlZr14OErTjCV9KWhjAoLTvDKjsf/yxMPjYuQXyNVBgXh+A/f2 Wm6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QhvEKy1PcCrcHLoF2lpNi2QcyG8x8naEGnoZhlSiKig=; b=o1PyJiFBM/up37QaV+lpJZxI/hKzlfYRdfPgt1F7hYZlpAOQyY/jfiGG9DezLvlv9F jl/bm83RHU7AuGg6Ofc5qR/7NfAfpbLi4ZbL9dAXCZSesnM5+9n9y3vpVKypXOZgbYEQ qjBDy21BOcWfrHvbbFbWUolc6Jtpmbw6brb4wkN42fSL5wOnR/Hc5iEyI9Ma6uMlLZ7x 9wWEP32AhEv5VnQwJt14Pvb7a2igSzRZSY8KEHwL5x9s+NVYaVjwlwoReUEV79038xer ZrRXSm3yydM8W2dHV04l+/SnQjE6PDl0PlTV6BJBVCV2DxIVXH1HQRhFAZ3UWVOLxdpZ t42w== X-Gm-Message-State: AIVw111/q/7wmiOxhpfbfd13gPbuFhJp6ZDwcgwBZz5gidCgAfmsAW6n hCaPZhjCWJefsun8yyZcc/cuderQgvAgxL4= X-Received: by 10.31.136.9 with SMTP id k9mr8955631vkd.50.1499730238095; Mon, 10 Jul 2017 16:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 16:43:57 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Mon, 10 Jul 2017 19:43:57 -0400 Message-ID: To: Paul Wouters Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11441d7419c4840553ff2835" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:44:02 -0000 --001a11441d7419c4840553ff2835 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 6:55 PM, Paul Wouters wrote: > On Mon, 10 Jul 2017, Shumon Huque wrote: > >> >> So the goal is not to have them "permanently" signed with multiple >> algorithms, but for a defined transition period, which may not be very >> short. At that point, the older algorithm would be withdrawn -- so >> algorithm rollover, but over an extended period. >> > > Okay, that explains it better. but does also confirm you basically want > to be permanently in this state. Because every few years you will have > new fancy algorithms. As a community we should really roll out updated > algorithms faster and deprecate obsoleted algorithms faster. I certainly agree with that goal. In practice it is hard to achieve given the vast population of DNS software and the long tail of feature adoption. Of course there are initial costs. The goal is longer term - the benefits >> will increase with more adoption over time. There will be a lot >> of large responses initially, which will decrease over time. >> > > But then why not depend on adoption of (and deprecation of) old signing > algorithms? That would be ideal. Again desire vs reality. In this case, the earlier deployers of multiple algorithms are bearing the costs, and would expect to gain the benefits of selective signature delivery slowly over time. Of course they are imposing costs in terms of larger responses on everyone else too, but they would be doing that even without this feature. This feature is really looking longer term - and hoping to prepare us better for the introduction of new algorithms in the future. If this gets implemented, even if no-one initially uses it, we might be prepared for future iterations of new algorithms (like various post quantum algorithms or something else). > One would hope zones are migrated from "strong" to "even stronger" >> algorithms, and not from "weak" to "strong enough", so I don't think >> algorithm downgrade is ever an issue. >> >> Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is >> the butt of jokes in the larger security community. >> > > You are mixing up keysize and algorithm rollover :P > I was mainly disputing your remark about hoping there are no "weak" algorithms :-) I realize that keysize upgrade could address this, but so also could rolling to a stronger algorithm like ECDPSAP256. > RSA is not broken, and safe to use, preferably at 2048 key size. No double > signing or algorithm signaling is needed to go from RSA1024 to RSA2048 :) > > also: https://www.internetsociety.org/doc/state-dnssec-deployment-2016 > > "The overwhelming majority (~99%) of TLDs use 2048 bit keys" > > I can't find a statistics URL for all domains (secspider seems to have > changed and I cannot find the RSA key sizes per domain anymore) but I'm > pretty sure 1024 will be on the decline. > You're only as strong as your weakest link. The weak link in almost all deployed DNSSEC paths today is RSA1024. Your 2048-bit figure is for KSKs. Most zone data is signed with RSA1024. Here are my current stats of TLD keysize distribution: Key Signing Keys (KSK): 1024 bits: 1 (0.0%) 1280 bits: 5 (0.2%) 1536 bits: 1 (0.0%) 2048 bits: 2022 (98.8%) 4096 bits: 17 (0.8%) Zone Signing Keys (ZSK): 1024 bits: 1566 (69.7%) 1048 bits: 2 (0.1%) 1152 bits: 5 (0.2%) 1280 bits: 537 (23.9%) 2048 bits: 138 (6.1%) So roughly 70% of TLDs sign zone data with RSA1024. > Anyway, my point is that we should not have 20 sexy algorithms, but only > a very limited set of a few algorithms that we all agree are strong enough. Yes, I am in total agreement. We should as few strong ones as possible. But that's still more than one. Some crypto folks are now advocating for new protocols, define only one cipher family and don't negotiate. But in reality, deployed protocols that evolved over time have many, and correspondingly have a cipher negotiation mechanism. TLS has something on the order of 100 cipher suites last time I looked. -- Shumon Huque. --001a11441d7419c4840553ff2835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 6:55 PM, Paul Wouters <paul@nohats.ca> wrot= e:
On Mon, 10 Jul 2017, Shumon Huque wrote:

So the goal is not to have them "permanently" signed with multipl= e algorithms, but for a defined transition period, which may not be very short. At that point, the older algorithm would be withdrawn -- so algorith= m rollover, but over an extended period.

 Okay, that explains it better. but does also confirm you basically want
to be permanently in this state. Because every few years you will have
new fancy algorithms. As a community we should really roll out updated
algorithms faster and deprecate obsoleted algorithms faster.

I certainly agree with that goal. In practice it is hard = to achieve given the vast population of DNS software and the long tail of f= eature adoption.=C2=A0

Of course there are initial costs. The goal is longer term - the benefits w= ill increase with more adoption over time. There will be a lot
of large responses initially, which will decrease over time.

 But then why not depend on adoption of (and deprecation of) old signing
algorithms?

That would be ideal. Again desi= re vs reality. In this case, the earlier deployers of multiple algorithms a= re bearing the costs, and would expect to gain the benefits of selective si= gnature delivery slowly over time. Of course they are imposing costs in ter= ms of larger responses on everyone else too, but they would be doing that e= ven without this feature.

This feature is really l= ooking longer term - and hoping to prepare us better for the introduction o= f new algorithms in the future. If this gets implemented, even if no-one in= itially uses it, we might be prepared for future iterations of new algorith= ms (like various post quantum algorithms or something else).
=C2= =A0
=C2=A0 =C2=A0 =C2=A0 One would hope zones are migrated from "strong&qu= ot; to "even stronger"
=C2=A0 =C2=A0 =C2=A0 algorithms, and not from "weak" to "str= ong enough", so I don't think
=C2=A0 =C2=A0 =C2=A0 algorithm downgrade is ever an issue.

Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is t= he butt of jokes in the larger security community.

 You are mixing up keysize and algorithm rollover :P
I was mainly disputing your remark about hoping there are no &= quot;weak" algorithms :-)=C2=A0

I realize tha= t keysize upgrade could address this, but so also could rolling to a strong= er algorithm like ECDPSAP256.
=C2=A0
RSA is not broken, and safe to use, preferably at 2048 key size. No double<= br> signing or algorithm signaling is needed to go from RSA1024 to RSA2048 :)
also: https://www.internetsociety.or= g/doc/state-dnssec-deployment-2016

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The overwhelming majority (~99%) of TLDs = use 2048 bit keys"

I can't find a statistics URL for all domains (secspider seems to have<= br> changed and I cannot find the RSA key sizes per domain anymore) but I'm=
pretty sure 1024 will be on the decline.

You're only as strong as your weakest link. The weak link in almost a= ll deployed DNSSEC paths today is RSA1024. Your 2048-bit figure is for KSKs= . Most zone data is signed with RSA1024. Here are my current stats of TLD k= eysize distribution:

Key Signing Keys (KSK):<= /div>
1024 bits: 1 (0.0%)
1280 bits: 5 (0.2%)
1536 = bits: 1 (0.0%)
2048 bits: 2022 (98.8%)
4096 bits: 17 (0= .8%)

Zone Signing Keys (ZSK):
1024 bits:= 1566 (69.7%)
1048 bits: 2 (0.1%)
1152 bits: 5 (0.2%)
1280 bits: 537 (23.9%)
2048 bits: 138 (6.1%)
=

So roughly 70% of TLDs sign zone data with RSA1024.
=C2=A0
Anyway, my point is that we should not have 20 sexy algorithms, but only a very limited set of a few algorithms that we all agree are strong enough.=

Yes, I am in total agreement. We should as= few strong ones as possible. But that's still more than one.

Some crypto folks are now advocating for new protocols, def= ine only one cipher family and don't negotiate. But in reality, deploye= d protocols that evolved over time have many, and correspondingly have a ci= pher negotiation mechanism. TLS has something on the order of 100 cipher su= ites last time I looked.

--=C2=A0
Shumon= Huque.

--001a11441d7419c4840553ff2835-- From nobody Mon Jul 10 16:51:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0789D120726 for ; Mon, 10 Jul 2017 16:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 spd7Z9cR8WnY for ; Mon, 10 Jul 2017 16:51:03 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 5CC4B1200ED for ; Mon, 10 Jul 2017 16:51:03 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id 191so56062563vko.2 for ; Mon, 10 Jul 2017 16:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=32zCYeKJABNimkRrTE7d7wldwISYx7AXbBGUBjvk4To=; b=sBul9GuR+OyYtmgT7Yu2hSV99yajUwOV3IfBizA+IQztQaUMqGf8OSG9kw9JY7RpBO HgdzL4QpKYr4kYOxceFhyYV2aUMDWLx0YRm3z98JenfD4zw4XzEVpnNzSFPh6K+QW+cZ 2FjmnKwYd3WDaB2/95oaoSLmoWz3SavDHq6dayUzayGnsOdQVhm/FYYHIyHhdCyOHO56 rv2waB+wxN0NsSJVVGwpa5HL8iq8aUQwRPsey2Esr5M2JANZXA8NX4Kh1KNKmyK39wLH 1Ye9KEc4Lwxdc1g8yaiqtfH6413PNraFqlZFaeeqNkGKnbL7O9OEvP4zrFc5IvvUe3xn hinA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=32zCYeKJABNimkRrTE7d7wldwISYx7AXbBGUBjvk4To=; b=DxZFovCM7j2iuixaPhNYFuvhDCfIhEw+6Q4XP3ODhBYL02p7zbRhdNfcEzL6BZaJQ1 HJomfzSpNxEg1rFrTRrHQXE7W79xMPNwghI63mlM5E7QR9C388gqECXU89bnIfAFIMmd U37wWi66WFZmWBaGNU4Sr13Hgm1Vor/ma/XLX6/nCxmRQQD34Icbuolbcc0my9gTyEvy bAdjE//sj2MEpKI3G/8rXcdmnu2/mMBQJIR7nYjwJvZSDRcTIu7Q2n2Y4GajyMSdJzPd SyIQccEqT8Twy2+/+eXXAz7HArcsQgqEKCyeJwuSHoYgEblThxDqH9WIMUa59p4FkDgH 87Tg== X-Gm-Message-State: AIVw110qZzRygechGT3dMq/vs2liYCFwYQPXPpcB5ZAmyGvrit1BWE/e D90CFF8Z1F/cFCGRmXqUJC7uOm8lxQ== X-Received: by 10.31.233.3 with SMTP id g3mr9142684vkh.91.1499730662516; Mon, 10 Jul 2017 16:51:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 16:51:01 -0700 (PDT) In-Reply-To: <20170710224102.EDB357E3CB92@rock.dv.isc.org> References: <20170710224102.EDB357E3CB92@rock.dv.isc.org> From: Shumon Huque Date: Mon, 10 Jul 2017 19:51:01 -0400 Message-ID: To: Mark Andrews Cc: Paul Wouters , Bob Harold , "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c0949e865ee600553ff410c" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:51:05 -0000 --94eb2c0949e865ee600553ff410c Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 6:41 PM, Mark Andrews wrote: > > > > I also don't want to deploy only Ed448 and cause my zone to be instantly > > treated as unsigned by the vast majority of resolvers. Obviously, because > > I've nullified the security benefit of DNSSEC, but also because I have > > application security protocols, like DANE, that critically depend on > DNSSEC > > authentication, for which this would pose a grave security risk. > > For some reason there is this insane rush to use Ed448 before even > the major crypto providors have shipped releases which support it. > Get support into major packages then use it in production. Yes, > we are working on adding it to BIND. Name servers get upgraded. > Hi Mark, This was a hypothetical example that I thought might come up for some in the future. I wasn't describing my personal plans, so don't rush to implement Ed448 on my account! :-) -- Shumon Huque --94eb2c0949e865ee600553ff410c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 6:41 PM, Mark Andrews <marka@isc.org> wrote:=

> I also don't want to deploy only Ed448 and cause my zone to be ins= tantly
> treated as unsigned by the vast majority of resolvers. Obviously, beca= use
> I've nullified the security benefit of DNSSEC, but also because I = have
> application security protocols, like DANE, that critically depend on D= NSSEC
> authentication, for which this would pose a grave security risk.

For some reason there is this insane rush to use Ed448 before even the major crypto providors have shipped releases which support it.
Get support into major packages then use it in production.=C2=A0 Yes,
we are working on adding it to BIND.=C2=A0 Name servers get upgraded.

Hi Mark,

This was a= hypothetical example that I thought might come up for some in the future. = I wasn't describing my personal plans, so don't rush to implement E= d448 on my account! :-)

--=C2=A0
Shumon = Huque

--94eb2c0949e865ee600553ff410c-- From nobody Tue Jul 11 00:18:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46641319B6 for ; Tue, 11 Jul 2017 00:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 O2QjPOXmPeea for ; Tue, 11 Jul 2017 00:18:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 B2D021319B4 for ; Tue, 11 Jul 2017 00:18:09 -0700 (PDT) Received: from [192.168.3.103] (unknown [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id DDB346091C; Tue, 11 Jul 2017 09:18:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1499757488; bh=LdxOZrRWe1m0RjX8EH5+S2+E/aA7DsjFeByu12qLGew=; h=To:From:Date; b=AfWSDIbOvltWUIR6T2miIDt3P9JOqvFd507l7rB7/9424bZGyGfWZ0z4voouleN6q ZL7PqHT5VGgekKxuetISQYngM3C7LKfUF/VJv+dm6uw3y5aRj7kJcoqqEFKlMNJ7Qg BSrkCx2M/oKrsLRV63HuUSbHzd/JNVeY8ObK64cg= To: dnsop@ietf.org References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> Date: Tue, 11 Jul 2017 09:17:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149912520399.16222.12738253224617069728@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 07:18:13 -0000 Hello dnsop, reading throught the latest version, I object to the proposed TLV format. I feel that implications from switch to non-RR format are underestimated and following e-mail attempts to explain why I believe it is a bad idea. Please accept my apology for such long e-mail. Overview -------- 1. Parsing the new format itself is not the hard because it is similar to other rdata, even though not very same (see below). 2. The hard part is integration into rest of the program and "wider ecosystem" including all the bells and whistles. This includes: - from_wire/to_wire conversion - from_string/to_string conversion - ability to log and process those logs - support in traffic analysis tools - support in data formats used for storing DNS messages It is *very important* to consider that there is plenty of software which do not need to understand DNS semantics but just DNS message format (message collectors, statistic tools etc.). 3. We need to keep in mind that introducing very new format (instead of using structure) change affects not only servers and resolvers but everything in DNS ecosystem, *including data formats* used to store messages. Can we represent messages with the new format in dnstap, C-DNS, and all the DNS_in_JSON flavors? If not, how should we handle this problem? Why it is harder to implement it everywhere that it seems --------------------------------------------------------- The main reason is that every DNS software already has its own set of utility functions for operating on RR format. Switching over to a TLV format gets more complicated when we start speaking about logging/filtering and other integration aspects because will have to include new conditions in all code paths as well. Why is this so different from adding new RR type? New RR type and new TLV format surely need new code for en/decoding, but again, this is the easy part. The main problem integration with everything else. Normal RR processing already has all the abstraction and APIs ready, including all sorts of utility functions. I.e. existing message matching code will have to be extended with if (opcode == SESSION_SIGNALING) { // comparison function for SS } else { // comparison function for normal data } Similarly when it comes to logging, it is not just calling log_rr() anymore. It is now if (opcode == SESSION_SIGNALING) { // log function for SS } else { // log function for normal data } I will try to describe an example with python-dns library (because it is small and easy to read, it would be the very same for e.g. Knot resolver): If we used normal RR format, it is just matter of dropping one file (e.g. rdtypes/class/SS.py) with methods for en/decoding. The existing infrastructure of the library would take care of all the message parsing (incl. handling of malformed/truncated messages etc.), printing, comparison, logging etc. and all this "integration" is "for free" because the libraries already have it for everything in RR format. [In fact, when we talk about normal RR format, we might not even need to write the en/decoders! Right now we are working on an prototype implementation of https://tools.ietf.org/html/draft-levine-dnsextlang-07 which generates en/decoders "for free".] By diverting from RR format we will lose all this. For example in CZ.NIC we are maintaining several tools which do not need to "understand" semantics of DNS messages but have to parse them. All these would have to be modified. RR-based format will "just work" with these because support for uknown RR types is already there. Of course, there needs to be code to do the actual session logic, but re-use of existing infrastructure allows developers to focus on the session logic and not on re-inventing the integration. Why TLV format is not effective as fool-proof measure ----------------------------------------------------- DNS servers should already be returning NOTIMP for unknown opcodes already so it should be sufficient counter-measure to avoid getting records into caches etc. In any case, the new TLV format does not prevent people from doing mistakes (or attacks) and sending SS data along with non-SS data, i.e. there has to be code to handle these error cases regardless of format. If we can agree on the previous point, i.e. necessity to handle bad messages anyway, we are left with problems related to caching/AXFR. This gets us to the very same situation as with OPT RR which has similar semantics and definitelly should not get into cache/AXFR, etc. I.e. similar measures can be re-used insted of inventing new ones. Conclusion ---------- If we consider that there is plenty of software reading DNS traffic, e.g. for doing statistics, testing software which read/generate DNS messages etc., the new TLV format is unnecessairly hard to implement in rest of the DNS ecosystem. Sticking to standard format would solve this particular problem. Thank you for your time and attention. Petr Špaček @ CZ.NIC On 4.7.2017 01:40, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : DNS Session Signaling > Authors : Ray Bellis > Stuart Cheshire > John Dickinson > Sara Dickinson > Allison Mankin > Tom Pusateri > Filename : draft-ietf-dnsop-session-signal-03.txt > Pages : 27 > Date : 2017-07-03 > > Abstract: > This document defines a new Session Signaling OPCODE used to > communicate persistent "per-session" operations, expressed using > type-length-value (TLV) syntax, and defines an initial set of TLVs > used to manage session timeouts and termination. This mechanism is > intended to reduce the overhead of existing "per-packet" signaling > mechanisms with "per-message" semantics as well as defining new > signaling operations not defined in EDNS(0). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-03 > > > 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 Tue Jul 11 00:34:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EECE1319BB for ; Tue, 11 Jul 2017 00:34:19 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CPBD6ExVavq1 for ; Tue, 11 Jul 2017 00:34:16 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCBD124D37 for ; Tue, 11 Jul 2017 00:34:16 -0700 (PDT) Received: from [10.40.6.70] (unknown [111.205.113.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2EFBC61FF3; Tue, 11 Jul 2017 07:34:14 +0000 (UTC) Date: Tue, 11 Jul 2017 07:34:12 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----HPOXWAIERH5PWOXF9I1SKCYU4X06LC" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org,=?UTF-8?Q?Petr_=C5=A0pa=C4=8Dek?= CC: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: P Vix Message-ID: <757B489C-2CA5-4B92-B8BF-71991E0A7B68@redbarn.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 07:34:20 -0000 ------HPOXWAIERH5PWOXF9I1SKCYU4X06LC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 On July 11, 2017 3:17:57 PM GMT+08:00, "Petr =C5=A0pa=C4=8Dek" wrote: >Hello dnsop, > >reading throught the latest version, I object to the proposed TLV >format=2E > >I feel that implications from switch to non-RR format are >underestimated >and following e-mail attempts to explain why I believe it is a bad >idea=2E >Please accept my apology for such long e-mail=2E > > >Overview >-------- >1=2E Parsing the new format itself is not the hard because it is similar >to other rdata, even though not very same (see below)=2E > >2=2E The hard part is integration into rest of the program and "wider >ecosystem" including all the bells and whistles=2E > >This includes: >- from_wire/to_wire conversion >- from_string/to_string conversion >- ability to log and process those logs >- support in traffic analysis tools >- support in data formats used for storing DNS messages > >It is *very important* to consider that there is plenty of software >which do not need to understand DNS semantics but just DNS message >format (message collectors, statistic tools etc=2E)=2E > >3=2E We need to keep in mind that introducing very new format (instead of >using structure) change affects not only >servers and resolvers but everything in DNS ecosystem, *including data >formats* used to store messages=2E > >Can we represent messages with the new format in dnstap, C-DNS, and all >the DNS_in_JSON flavors? If not, how should we handle this problem? > > >Why it is harder to implement it everywhere that it seems >--------------------------------------------------------- >The main reason is that every DNS software already has its own set of >utility functions for operating on RR format=2E Switching over to a TLV >format gets more complicated when we start speaking about >logging/filtering and other integration aspects because will have to >include new conditions in all code paths as well=2E > >Why is this so different from adding new RR type? New RR type and new >TLV format surely need new code for en/decoding, but again, this is the >easy part=2E > >The main problem integration with everything else=2E Normal RR processing >already has all the abstraction and APIs ready, including all sorts of >utility functions=2E > >I=2Ee=2E existing message matching code will have to be extended with >if (opcode =3D=3D SESSION_SIGNALING) { > // comparison function for SS >} else { > // comparison function for normal data >} > >Similarly when it comes to logging, it is not just calling log_rr() >anymore=2E It is now >if (opcode =3D=3D SESSION_SIGNALING) { > // log function for SS >} else { > // log function for normal data >} > > >I will try to describe an example with python-dns library (because it >is >small and easy to read, it would be the very same for e=2Eg=2E Knot >resolver): > >If we used normal RR format, it is just matter of dropping one file >(e=2Eg=2E rdtypes/class/SS=2Epy) with methods for en/decoding=2E The exis= ting >infrastructure of the library would take care of all the message >parsing >(incl=2E handling of malformed/truncated messages etc=2E), printing, >comparison, logging etc=2E and all this "integration" is "for free" >because the libraries already have it for everything in RR format=2E > >[In fact, when we talk about normal RR format, we might not even need >to >write the en/decoders! Right now we are working on an prototype >implementation of >https://tools=2Eietf=2Eorg/html/draft-levine-dnsextlang-07 >which generates en/decoders "for free"=2E] > >By diverting from RR format we will lose all this=2E > > >For example in CZ=2ENIC we are maintaining several tools which do not >need >to "understand" semantics of DNS messages but have to parse them=2E All >these would have to be modified=2E RR-based format will "just work" with >these because support for uknown RR types is already there=2E > >Of course, there needs to be code to do the actual session logic, but >re-use of existing infrastructure allows developers to focus on the >session logic and not on re-inventing the integration=2E > > > >Why TLV format is not effective as fool-proof measure >----------------------------------------------------- >DNS servers should already be returning NOTIMP for unknown opcodes >already so it should be sufficient counter-measure to avoid getting >records into caches etc=2E > >In any case, the new TLV format does not prevent people from doing >mistakes (or attacks) and sending SS data along with non-SS data, i=2Ee= =2E >there has to be code to handle these error cases regardless of format=2E > >If we can agree on the previous point, i=2Ee=2E necessity to handle bad >messages anyway, we are left with problems related to caching/AXFR=2E >This >gets us to the very same situation as with OPT RR which has similar >semantics and definitelly should not get into cache/AXFR, etc=2E I=2Ee=2E >similar measures can be re-used insted of inventing new ones=2E > > >Conclusion >---------- >If we consider that there is plenty of software reading DNS traffic, >e=2Eg=2E for doing statistics, testing software which read/generate DNS >messages etc=2E, the new TLV format is unnecessairly hard to implement in >rest of the DNS ecosystem=2E Sticking to standard > format would solve this particular >problem=2E > > >Thank you for your time and attention=2E > >Petr =C5=A0pa=C4=8Dek @ CZ=2ENIC > >On 4=2E7=2E2017 01:40, internet-drafts@ietf=2Eorg wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >directories=2E >> This draft is a work item of the Domain Name System Operations of the >IETF=2E >>=20 >> Title : DNS Session Signaling >> Authors : Ray Bellis >> Stuart Cheshire >> John Dickinson >> Sara Dickinson >> Allison Mankin >> Tom Pusateri >> Filename : draft-ietf-dnsop-session-signal-03=2Etxt >> Pages : 27 >> Date : 2017-07-03 >>=20 >> Abstract: >> This document defines a new Session Signaling OPCODE used to >> communicate persistent "per-session" operations, expressed using >> type-length-value (TLV) syntax, and defines an initial set of TLVs >> used to manage session timeouts and termination=2E This mechanism >is >> intended to reduce the overhead of existing "per-packet" signaling >> mechanisms with "per-message" semantics as well as defining new >> signaling operations not defined in EDNS(0)=2E >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker=2Eietf=2Eorg/doc/draft-ietf-dnsop-session-signal/ >>=20 >> There are also htmlized versions available at: >> https://tools=2Eietf=2Eorg/html/draft-ietf-dnsop-session-signal-03 >> >https://datatracker=2Eietf=2Eorg/doc/html/draft-ietf-dnsop-session-signal= -03 >>=20 >> A diff from the previous version is available at: >> https://www=2Eietf=2Eorg/rfcdiff?url2=3Ddraft-ietf-dnsop-session-signal= -03 >>=20 >>=20 >> 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=2Eietf=2Eorg= =2E >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp=2Eietf=2Eorg/internet-drafts/ > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------HPOXWAIERH5PWOXF9I1SKCYU4X06LC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1

On July 11, 2= 017 3:17:57 PM GMT+08:00, "Petr =C5=A0pa=C4=8Dek" <petr=2Espac= ek@nic=2Ecz> wrote:
Hello dnsop,

reading throught the latest =
version, I object to the proposed TLV format=2E

I feel that impl=
ications from switch to non-RR format are underestimated
and following=
 e-mail attempts to explain why I believe it is a bad idea=2E
Please a=
ccept my apology for such long e-mail=2E


Overview
---=
-----
1=2E Parsing the new format itself is not the hard because it is=
 similar
to other rdata, even though not very same (see below)=2E

2=2E The hard part is integration into rest of the program and "=
;wider
ecosystem" including all the bells and whistles=2E
This includes:
- from_wire/to_wire conversion
- from_string/t=
o_string conversion
- ability to log and process those logs
- sup=
port in traffic analysis tools
- support in data formats used for stor=
ing DNS messages

It is *very important* to consider that there i=
s plenty of software
which do not need to understand DNS semantics but=
 just DNS message
format (message collectors, statistic tools etc=2E)=
=2E

3=2E We need to keep in mind that introducing very new forma=
t (instead of
using <owner,class,TTL,rrtype,rdata> structure) ch=
ange affects not only
servers and resolvers but everything in DNS ecos=
ystem, *including data
formats* used to store messages=2E

C=
an we represent messages with the new format in dnstap, C-DNS, and all
the DNS_in_JSON flavors? If not, how should we handle this problem?
<=
br />
Why it is harder to implement it everywhere that it seems
<=
hr />
The main reason is that every DNS software already has its own s=
et of
utility functions for operating on RR format=2E Switching over t=
o a TLV
format gets more complicated when we start speaking about
logging/filtering and other integration aspects because will have to
=
include new conditions in all code paths as well=2E

Why is this =
so different from adding new RR type? New RR type and new
TLV format s=
urely need new code for en/decoding, but again, this is the
easy part=
=2E

The main problem integration with everything else=2E Normal =
RR processing
already has all the abstraction and APIs ready, includin=
g all sorts of
utility functions=2E

I=2Ee=2E existing messa=
ge matching code will have to be extended with
if (opcode =3D=3D SESSI=
ON_SIGNALING) {
    // comparison function for SS
} else {
 =
   // comparison function for normal data
}

Similarly when =
it comes to logging, it is not just calling log_rr()
anymore=2E It is =
now
if (opcode =3D=3D SESSION_SIGNALING) {
    // log function fo=
r SS
} else {
    // log function for normal data
}

I will try to describe an example with python-dns library (because=
 it is
small and easy to read, it would be the very same for e=2Eg=2E =
Knot resolver):

If we used normal RR format, it is just matter o=
f dropping one file
(e=2Eg=2E rdtypes/class/SS=2Epy) with methods for en/decoding=2E The existing
infrastruct=
ure of the library would take care of all the message parsing
(incl=2E=
 handling of malformed/truncated messages etc=2E), printing,
compariso=
n, logging etc=2E and all this "integration" is "for free&qu=
ot;
because the libraries already have it for everything in RR format=
=2E

[In fact, when we talk about normal RR format, we might not =
even need to
write the en/decoders! Right now we are working on an pro=
totype
implementation of https://tools=2Eietf=2Eorg/html/draft-levine-dnse=
xtlang-07
which generates en/decoders "for free"=2E]

By diverting from RR format we will lose all this=2E

For example in CZ=2ENIC we are maintaining several tools which do not ne=
ed
to "understand" semantics of DNS messages but have to par=
se them=2E All
these would have to be modified=2E RR-based format will=
 "just work" with
these because support for uknown RR types =
is already there=2E

Of course, there needs to be code to do the =
actual session logic, but
re-use of existing infrastructure allows dev=
elopers to focus on the
session logic and not on re-inventing the inte=
gration=2E



Why TLV format is not effective as fool-p=
roof measure

DNS servers should already be returning NOTIM=
P for unknown opcodes
already so it should be sufficient counter-measu=
re to avoid getting
records into caches etc=2E

In any case,=
 the new TLV format does not prevent people from doing
mistakes (or at=
tacks) and sending SS data along with non-SS data, i=2Ee=2E
there has =
to be code to handle these error cases regardless of format=2E

I=
f we can agree on the previous point, i=2Ee=2E necessity to handle bad
messages anyway, we are left with problems related to caching/AXFR=2E This=

gets us to the very same situation as with OPT RR which has similarsemantics and definitelly should not get into cache/AXFR, etc=2E I=2Ee=
=2E
similar measures can be re-used insted of inventing new ones=2E

Conclusion
----------
If we consider that there is=
 plenty of software reading DNS traffic,
e=2Eg=2E for doing statistics=
, testing software which read/generate DNS
messages etc=2E, the new TL=
V format is unnecessairly hard to implement in
rest of the DNS ecosyst=
em=2E Sticking to standard
<owner,class,TTL,rrtype,rdata> format=
 would solve this particular problem=2E


Thank you for your=
 time and attention=2E

Petr Špa=C4=8Dek  @  CZ=2ENIC

On 4=2E7=2E2017 01:40, internet-drafts@ietf=2Eorg wrote:
 
 A New Internet-Draft is =
available from the on-line Internet-Drafts directories=2E
 This draft =
is a work item of the Domain Name System Operations of the IETF=2E
          Title           : DNS Session Signaling
         Authors =
        : Ray Bellis
                           Stuart Cheshire
 =
                          John Dickinson
                           Sa=
ra Dickinson
                           Allison Mankin
          =
                 Tom Pusateri
  Filename        : draft-ietf-dnsop-ses=
sion-signal-03=2Etxt
  Pages           : 27
  Date            : 2=
017-07-03
 
 Abstract:
    This document defines a new Sessi=
on Signaling OPCODE used to
    communicate persistent "per-sessi=
on" operations, expressed using
    type-length-value (TLV) synta=
x, and defines an initial set of TLVs
    used to manage session timeo=
uts and termination=2E  This mechanism is
    intended to reduce the o=
verhead of existing "per-packet" signaling
    mechanisms wi=
th "per-message" semantics as well as defining new
    signa=
ling operations not defined in EDNS(0)=2E
 
 
 The IETF data=
tracker status page for this draft is:
 https://datatracker=2Eie=
tf=2Eorg/doc/draft-ietf-dnsop-session-signal/
 
 There are al=
so htmlized versions available at:
 https://tools=2Eietf=2Eorg/htm=
l/draft-ietf-dnsop-session-signal-03
 https://datatr=
acker=2Eietf=2Eorg/doc/html/draft-ietf-dnsop-session-signal-03
  A diff from the previous version is available at:
 ht=
tps://www=2Eietf=2Eorg/rfcdiff?url2=3Ddraft-ietf-dnsop-session-signal-03
 
 
 Please note that it may take a couple of minutes from=
 the time of submission
 until the htmlized version and diff are avail=
able at tools=2Eietf=2Eorg=2E
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp=
://ftp=2Eietf=2Eorg/int=
ernet-drafts/


DNSOP mailing listDNSOP@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/dnsop

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------HPOXWAIERH5PWOXF9I1SKCYU4X06LC-- From nobody Tue Jul 11 04:05:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057E912ECC7 for ; Tue, 11 Jul 2017 04:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 63RMaU6N0FwA for ; Tue, 11 Jul 2017 04:05:44 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 8577412869B for ; Tue, 11 Jul 2017 04:05:44 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id 16so98534282qkg.2 for ; Tue, 11 Jul 2017 04:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RN0qNGBHD8IUCWxlPCM7a6zfdgX2xK8t5/NVzmetNdg=; b=qLBBQTnRk+gmL6LrE8mloZ9Dfg9vOJgvlw5aaHvAX10a11uh/cF65EqEzjF8yptNnz /oXrzOhuKDE1VlPB7Pn617hEQHBQb93MTVBj9uORx/AzrHzqILv2Q4m2aS+TyIbKtz+y j9qUKmRMtCinIMghbzKxbOsYQRMOsSVhM1Xt3YJn61EJen61tKEar1ZQx7SJCXOH1ruk iVOcYbIvt6GtVn1bKWsvvugj+rmJSdFblsFV0AnW8jCtTw5uRfpHxdgb6GmfSyw4Rhsk M8r7rwh1bokTf1KePmIlhi3PDAdiLxqX9Y1XaluTlWKHqPnI/tGxYNXwykwDpkw6rNew bNmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RN0qNGBHD8IUCWxlPCM7a6zfdgX2xK8t5/NVzmetNdg=; b=QfzqNS1QYsqcppsJpOifq5UjZ6w3tRbMBzi0FJfLvmdIM7HSYpsuHV3qBOesg1pN/K 9SiakEVDzc6TEDxEu9pVwAIeWw8a8mKZstJbezHDbT6b5Fo3vjK59NWSWo1hDHdPHEWe vm9yi/ysQHpmXGnDkOSME6Sk4EQYhUBYm/ry538A/3JK8xiI0y1/3jydBfZ6ICYBZ4yZ VEmodE88FopFWzl5sAR7f04iGcK4GnD/tGx68IctwJyY2Yw0CvdHRyL5DZIyzwMfws+K WNpMYz9/0fjXfNITf4rK3axVpZr5jwo6kZpoEdpqDsQsNb5GP2vTI0LQNIWEFLhuo3lB 7UPA== X-Gm-Message-State: AIVw111VOLFk7BB6dmP4m+ymG9M29esi+DKM+tAmS5bPymoGD7ylWgAN csimpFlv7LOmXwdwNfum7Q== X-Received: by 10.200.40.34 with SMTP id 31mr10391918qtq.22.1499771143646; Tue, 11 Jul 2017 04:05:43 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t43sm11658484qth.30.2017.07.11.04.05.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 04:05:42 -0700 (PDT) From: Ted Lemon Message-Id: <3554CD07-1088-4378-ACC8-83E4E8E767D5@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D4F03DAC-72B7-4930-A2C8-D47941054EA6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 07:05:41 -0400 In-Reply-To: Cc: Shumon Huque , "dnsop@ietf.org WG" To: Paul Wouters References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 11:05:46 -0000 --Apple-Mail=_D4F03DAC-72B7-4930-A2C8-D47941054EA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 10, 2017, at 6:55 PM, Paul Wouters wrote: > Okay, that explains it better. but does also confirm you basically = want > to be permanently in this state. Because every few years you will have > new fancy algorithms. As a community we should really roll out updated > algorithms faster and deprecate obsoleted algorithms faster. Just a reminder: a few years we were talking about how to bootstrap = trust on devices that had been on the shelf for longer than the life of = the root key. Now you are proposing that we roll algorithms faster = than that. I'm not saying you're wrong, but there are operational = implications to this position. --Apple-Mail=_D4F03DAC-72B7-4930-A2C8-D47941054EA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 10, 2017, at 6:55 PM, Paul Wouters <paul@nohats.ca> = wrote:
Okay, that explains = it better. but does also confirm you basically want
to be permanently in this state. Because every = few years you will have
new fancy = algorithms. As a community we should really roll out updated
algorithms faster and deprecate obsoleted = algorithms faster.

Just a reminder: a few years we were talking about how to = bootstrap trust on devices that had been on the shelf for longer than = the life of the root key.   Now you are proposing that we roll = algorithms faster than that.   I'm not saying you're wrong, but = there are operational implications to this position.

= --Apple-Mail=_D4F03DAC-72B7-4930-A2C8-D47941054EA6-- From nobody Tue Jul 11 04:23:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785C212F4B2 for ; Tue, 11 Jul 2017 04:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 FHGcAb2vB1kM for ; Tue, 11 Jul 2017 04:23:50 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 48D92128BC8 for ; Tue, 11 Jul 2017 04:23:50 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p21so99187891qke.3 for ; Tue, 11 Jul 2017 04:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=k+gdvuXvbJqYsdIoijuKS7kF0WNw5gLV1hKxh+J0cHg=; b=a2+6se5NE5YCtQgSIgmGggO9X11yDpgWarDtwJ79cFC8bOuZw81/EcfbwrjZCDpt3Y 9xmjCy7MaqO5TCMcPuw+CzPGpZv03djRF5/UC1m7Ad1y1UCa6jPIDTAxXIL3wcJo4Wpt ygMLU0/Ml86H1BKs7RD1MWAMZoOEknPSquYeIpecwJ+QLKpUlchnzghUMXlZp1FrHkvC WvPPkYr7qN3EpSNmACwoZLPPXl3uliXFr+LcN8usOMmCaaMw/uE7dtsEz44Se9DsuDob mqztP4ipj6dVoqFiX37VYltLayfSym5Gv3novnIj6+7wHw/vJ7oUYmJQx2UbYUYJgUHw L+oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=k+gdvuXvbJqYsdIoijuKS7kF0WNw5gLV1hKxh+J0cHg=; b=GPlspcgaUTTLiM2HlexYQGSl2k6nR8ZodTsRbg1wuQXke+Ij4bs9aYGP2jk6+kOSXd 3F9BM/Km8u8xmv+AVibvLpbAElLL29kNVaYxz5xg0D17053hr6G+DYS9p6ikdwW87obm cp7wbORSMVFFeSwBt/htmXvjtdCRSyXg3sObbS4cNsgPiS3Lq6GpFQ8FeHG1vggq5ZP3 4FqKkUsDqLC9ElyGx8ovVLte+wPYdc6uCOdF7t3Uru+FeTVVO/nErGjk3aJP5ABFy5nN UPgkhR8CT5TPzN2ABy+aX+172cjt5efgR/+0K5x25MuJswa1IWOgUIgX1Dh8GOMFXbxa c8Pg== X-Gm-Message-State: AIVw112orVngpOaH/ipPSJcE91arAKgAya+Ayim3F0brE6b+LKtsVVDg ECpHvhJO8Nu5YvFi X-Received: by 10.200.43.58 with SMTP id 55mr10417035qtu.202.1499772229379; Tue, 11 Jul 2017 04:23:49 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n11sm11734178qtf.45.2017.07.11.04.23.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 04:23:48 -0700 (PDT) From: Ted Lemon Message-Id: <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4B419D93-83DC-40C7-90E0-A431A18CC0B9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 07:23:47 -0400 In-Reply-To: <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> Cc: dnsop@ietf.org, =?utf-8?B?T25kxZllaiBTdXLDvQ==?= To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 11:23:52 -0000 --Apple-Mail=_4B419D93-83DC-40C7-90E0-A431A18CC0B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 11, 2017, at 3:17 AM, Petr =C5=A0pa=C4=8Dek = wrote: > I feel that implications from switch to non-RR format are = underestimated > and following e-mail attempts to explain why I believe it is a bad = idea. > Please accept my apology for such long e-mail. Petr, with all due respect, I did not see a counter-proposal here, and = your comments seem to reflect a misunderstanding of what = session-signaling is. In fact, the opposite of what you said is true: if this were done as a = normal query with EDNS0-like encapsulation, _then_ we would see = problems, because session signaling messages would look more like DNS = queries, and less like control messages. This is not a desirable = quality. It's true that, for example, the DNS packet compression format would = have to deal with this specially, but that would also be true if this = were done EDNS0-style. It's true that packet dumpers would have to = deal with this specially, but that's also true if it's done EDNS0-style. = Etc. It may be that there is a good point in your argument somewhere, but at = the moment, I don't see one. E.g., in your python example, yes, if = this were an RR, not being able to plop it into your RR-handling switch = would suck. But it's not an RR, doesn't have the semantics of an RR, = and if you plop it into your RR-handling switch, you're probably getting = the semantics wrong. So if you want to make this case, I think you need to be more specific = about why this is a problem: when I think about how to implement this = (which I have done, because I'm using it for dnssd), what you are = advocating seems harder, not easier, than what is currently being = proposed. --Apple-Mail=_4B419D93-83DC-40C7-90E0-A431A18CC0B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 11, 2017, at 3:17 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> = wrote:
I feel that = implications from switch to non-RR format are underestimated
and following e-mail attempts to explain why I = believe it is a bad idea.
Please accept my = apology for such long e-mail.

Petr, with all due respect, I did not see a = counter-proposal here, and your comments seem to reflect a = misunderstanding of what session-signaling is.

In fact, the opposite of what you said = is true: if this were done as a normal query with EDNS0-like = encapsulation, _then_ we would see problems, because session signaling = messages would look more like DNS queries, and less like control = messages.  This is not a desirable quality.

It's true that, for example, the DNS = packet compression format would have to deal with this specially, but = that would also be true if this were done EDNS0-style.   It's true = that packet dumpers would have to deal with this specially, but that's = also true if it's done EDNS0-style.   Etc.

It may be that there is a good point in = your argument somewhere, but at the moment, I don't see one.   = E.g., in your python example, yes, if this were an RR, not being able to = plop it into your RR-handling switch would suck.   But it's not an = RR, doesn't have the semantics of an RR, and if you plop it into your = RR-handling switch, you're probably getting the semantics = wrong.

So if = you want to make this case, I think you need to be more specific about = why this is a problem: when I think about how to implement this (which I = have done, because I'm using it for dnssd), what you are advocating = seems harder, not easier, than what is currently being = proposed.

= --Apple-Mail=_4B419D93-83DC-40C7-90E0-A431A18CC0B9-- From nobody Tue Jul 11 11:01:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C425B12778E for ; Tue, 11 Jul 2017 11:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=gmail.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 jL1kK7Hw0W5E for ; Tue, 11 Jul 2017 11:01:20 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 8AB68131772 for ; Tue, 11 Jul 2017 11:01:20 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id d78so11295463qkb.1 for ; Tue, 11 Jul 2017 11:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yFoMAozpbLy1q3QsmD2sJg+7tiH5qpPvaJJ7PWAglRY=; b=RVJ7gI3pl+/T1ruK6h1ry8iD6hmxN7Dl75HuVzHw8PQ7cZf6s/fRpAIc5/cdlL3R86 tc7VKNbweKW/UjZ+5MdsW/7UohMVR6EDZuxcr9+fZyK8WzIwADKEAy+5VZs9fSs/VTqy ODm7vLKMs2c56GncY6cdeVbnf3GXHJ6q6hyFthivblxtwCK0zb6DpFSuIQlAZfc4Kujj x+aOguk5Hpd5T+XlYn3PB3EPTurALVzjnzozr5ZBobQHdfqy4CVpb1DLVH4IWVtscZ65 8+igvwgZzrkUqTXywyOycMwRSO3+wPL/uM5duFqcxAPcti97vzFDMt0NfJnUwIxx8dMA mL4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yFoMAozpbLy1q3QsmD2sJg+7tiH5qpPvaJJ7PWAglRY=; b=ghUp/LOcjW27pyf7pSmRJsRoUCBjp7CFTYggkHEbQtJh9l8qtxM2OJsMOXStsRGc+A nwCj3zFJ8KJQac9XeXBfWjHOY6FXJVrnK4dabPxP/z+O0u8kxX/86m9jrQ8fDj219ztY IuINA6fFmHJqmaPadv9aqXTWoTVMksvhTTruOPep8jVQIH2rDRbUp6msiOjtflDrlQ9g afkuSA5WgbB56U4UkUvIcKnmM8I5Ky/u3/3ushV5Y7VZzqb1he5rduti3FKXMsaqFLP/ J1Gqw2Ih2F2PimR/PwjTKp2l9U7HwO1K4+tnW07/uw/wYU63b0b5LtgtVIMwN3QRwppU +SBw== X-Gm-Message-State: AIVw113L/4tCNFzcloEYaiSfBp3PsO8VoYwIM39UuTrL78lSEyWNAyz9 ZYtNspCm9YgQBq3iO2iAujXtZM9VePkMSLc= X-Received: by 10.55.123.131 with SMTP id w125mr1440416qkc.177.1499796079515; Tue, 11 Jul 2017 11:01:19 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Tue, 11 Jul 2017 11:01:18 -0700 (PDT) In-Reply-To: <22866.37576.448814.454933@gro.dd.org> References: <22866.37576.448814.454933@gro.dd.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 11 Jul 2017 11:01:18 -0700 X-Google-Sender-Auth: 9N34prZP-YFn51qJpwPxDOHbjHw Message-ID: To: Dave Lawrence Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 18:01:26 -0000 At Tue, 27 Jun 2017 13:15:52 -0400, Dave Lawrence wrote: > > Also, it's not clear to me why the TTL is set to 1 second. Since > > it's actually expired, a zero TTL seems to be a more sensible choice > > here (a similar feature of unbound uses a zero TTL). If there's a > > specific reason to avoid 0, it would be better to explain it > > explicitly. > > Added to document: > > "1 second was chosen because historically 0 second TTLs have been > problematic for some implementations. It not only sidesteps those > potential problems with no practical negative consequence, it would > also rate limit further queries from any client that is honoring the > TTL, such as a forwarding resolver." Okay. > > - Section 4 > > > >> Canonical Name (CNAME) records mingled in the expired cache with > >> other records at the same owner name can cause surprising results. > [...] > > I suspect this is quite specific to internal implementation details > > of BIND, [...] it's probably better to clarify it's specific to a > > particular implementation architecture. > > I struggled with how to incorporate this feedback, because I felt like > it was already pretty clear that I was discussing BIND specifically. > In the end the only change I made specifically about this was to say > "The version of BIND" instead of just "BIND", because I'm not even > sure whether it would be an issue in the latest versions. I also > swapped the sequence of events around to match the real incident that > happened (A was received first, then later CNAME, versus the original > doc saying CNAME then A). My memory on this topic is already quite vague, but I guess I had this impression since this paragraph begins with a generic sentence without mentioning a particular implementation. I'm not necessarily opposed to the current text, but if I were to suggest something, I might say: This was observed with an initial implementation in BIND when a hostname changed from having an IPv4 Address (A) record to a CNAME, and could happen for other implementations depending on how they manage cached data. In this suggested text I've made two unrelated changes: - s/, where a hostname changed/when a hostname changed/ sine the original phrase was a bit confusing to me (it could read as if it talked about something about the BIND implementation, but it's actually talking about in which case the problem happens). - fixing typo: s/record.to/record to/ You'll at least need to fix this one even if the other part of the suggestion is rejected. -- JINMEI, Tatuya From nobody Tue Jul 11 11:37:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35BB131798 for ; Tue, 11 Jul 2017 11:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 O5A-5FL8LPoS for ; Tue, 11 Jul 2017 11:37:19 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2362131795 for ; Tue, 11 Jul 2017 11:37:19 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 4A1453F441; Tue, 11 Jul 2017 14:37:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22885.6877.223960.68909@gro.dd.org> Date: Tue, 11 Jul 2017 14:37:17 -0400 From: Dave Lawrence To: dnsop In-Reply-To: References: <22866.37576.448814.454933@gro.dd.org> Archived-At: Subject: Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 18:37:22 -0000 Jinmei writes: > In this suggested text I've made two unrelated changes: > > - s/, where a hostname changed/when a hostname changed/ > sine the original phrase was a bit confusing to me (it could read as > if it talked about something about the BIND implementation, but it's > actually talking about in which case the problem happens). > - fixing typo: s/record.to/record to/ > You'll at least need to fix this one even if the other part of the > suggestion is rejected. Both done in the pending draft, which I hope to post after a call for adoption. (I'd caught the latter right after submitting. Isn't that the way it always is?) From nobody Wed Jul 12 06:38:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79FD1318DB for ; Wed, 12 Jul 2017 06:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 j2pHQog-Nb9J for ; Wed, 12 Jul 2017 06:38:07 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 2A07113189B for ; Wed, 12 Jul 2017 06:38:06 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id 84so7071726ybe.0 for ; Wed, 12 Jul 2017 06:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0UM2BdRLgpntrGwq3jBk8Qm2uqRYX9BvsEssOrUWmc4=; b=Mk33blAWStLsuaYrO8ldUu260/1VRWZwi6WY+wPd2YXumwCDEuz7yb23o5r8+N43AB Z9lDkmi3UdTSDaCCy0so4IGmWGBycgD5G2vqNUlH5XqjaLSF0ZtP0yZ6LA29hhhbRrdj 1rfUQ2B+w8wEYCA/w1rlYXObqsd3O5GwxZNy8rnJjBjLtaCUPsxor/xwu3Qxj92on9ZL 7zOFmJAaRzfAcVXp7aS54zc/c4lCTwRl2lSInTdNynrANtqc5MuOr1wwxv6/Ka6wZqaE dwoirkWoRjOBnFbR9rfIj8KOwOOmlqn67buAXQQHeLU0epgmcWXim50Px+dvK2mgnLLt pkmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0UM2BdRLgpntrGwq3jBk8Qm2uqRYX9BvsEssOrUWmc4=; b=H61T+d6+aesi3/z/7rgbWMfDpKPU4ibzgjlNwpbrUyal7SR0If/v9GInIDwiySKQ7S ma7EHZI1aPqbLQf66luwQJYra7YdNYhIGZNQS1rQTivBJv/Ny1pXXPaktQWPlMVQYXnY msUJODh8YJQ+sBOop0T9bEgQvCRstJCO9BeohkDSYl8uwDKR2mOSppoGQrpjJGImJctA HFCjM8ZXh6fRxBLHKVPfQLM5gWbBpxUw76HOSk682Rl56eD+/Tag6kxrLsag4zmdpWut f6xb1AwdJXafDjpI3H33OoHD8HSbYCT25eY5YHzP3ldpD2lvXaIUIl+jnq6iD1EnCZzH iEUg== X-Gm-Message-State: AIVw113ewoBCSLo4c9G05dO757d2DEx9cxmuFcZ3dEkzBIOpgSTSvIBJ espePfSVDXwN4SOOMLkd4OAEvBwNm8tLjwQ= X-Received: by 10.37.170.148 with SMTP id t20mr822366ybi.5.1499866686206; Wed, 12 Jul 2017 06:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.132 with HTTP; Wed, 12 Jul 2017 06:38:05 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118C87C98@eusaamb107.ericsson.se> References: <149864318298.18209.9110331798587720209.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118C87C98@eusaamb107.ericsson.se> From: Bob Harold Date: Wed, 12 Jul 2017 09:38:05 -0400 Message-ID: To: Daniel Migault Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c19dbc20ad15605541eedba" Archived-At: Subject: Re: [DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 13:38:10 -0000 --94eb2c19dbc20ad15605541eedba Content-Type: text/plain; charset="UTF-8" On Wed, Jun 28, 2017 at 6:13 AM, Daniel Migault wrote: > Hi, > > Please find a new version for the DNSSEC validators requirements. Our > understanding is that the current version has considered all received > comments. > > We appreciate your comments and feed backs. > > Yours, > Daniel > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 28, 2017 11:46 AM > To: Edward Lewis ; Daniel Migault < > daniel.migault@ericsson.com>; Dan York ; york@isoc.org < > york@isoc.org> > Subject: New Version Notification for draft-mglt-dnsop-dnssec-valida > tor-requirements-05.txt > > > A new version of I-D, draft-mglt-dnsop-dnssec-valida > tor-requirements-05.txt > has been successfully submitted by Daniel Migault and posted to the IETF > repository. > > Name: draft-mglt-dnsop-dnssec-validator-requirements > Revision: 05 > Title: DNSSEC Validators Requirements > Document date: 2017-06-27 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/internet- > drafts/draft-mglt-dnsop-dnssec-validator-requirements-05.txt > Status: https://datatracker.ietf.org/ > doc/draft-mglt-dnsop-dnssec-validator-requirements/ > Htmlized: https://tools.ietf.org/html/d > raft-mglt-dnsop-dnssec-validator-requirements-05 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-mglt-dnsop-dnssec-validator-requirements-05 > Diff: https://www.ietf.org/rfcdiff? > url2=draft-mglt-dnsop-dnssec-validator-requirements-05 > > Abstract: > DNSSEC provides data integrity and source authentication to a basic > DNS RRset. Given a RRset, a public key and a signature, a DNSSEC > validator checks the signature, time constraints, and other, local, > policies. In case of mismatch the RRSet is considered illegitimate > and is rejected. > > Accuracy in DNSSEC validation, that is, avoiding false positives and > catching true negatives, requires that both the signing process and > validation process adhere to the protocol, which begins with external > configuration parameters. This document describes requirements for a > validator to be able to perform accurate validation. > > 5. Trust Anchor Datastore "A company "Example" may for address all its devices" probably should be: "A company "Example" may address all its devices" -- Bob Harold --94eb2c19dbc20ad15605541eedba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Jun 28, 2017 at 6:13 AM, Daniel Migault <daniel.migault@= ericsson.com> wrote:
Hi,

Please find a new version for the DNSSEC validators requirements. Our under= standing is that the current version has considered all received comments.<= br>
We appreciate your comments and feed backs.

Yours,
Daniel

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, June 28, 2017 11:46 AM
To: Edward Lewis <edward.lewis@icann.org>; Daniel Migault <daniel.migault@ericsson.com<= /a>>; Dan York <yo= rk@isoc.org>; yor= k@isoc.org <york@= isoc.org>
Subject: New Version Notification for draft-mglt-dnsop-dnssec-validato= r-requirements-05.txt


A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-0= 5.txt
has been successfully submitted by Daniel Migault and posted to the IETF re= pository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-dnsop-dnssec-valid= ator-requirements
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNSSEC Validators Requirements
Document date:=C2=A0 2017-06-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-mglt-dnsop-dnssec-validator-requirements-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-dnsop= -dnssec-validator-requirements/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-valid= ator-requirements-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mgl= t-dnsop-dnssec-validator-requirements-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-mglt-dnsop-dnssec-validator-requirements-05

Abstract:
=C2=A0 =C2=A0DNSSEC provides data integrity and source authentication to a = basic
=C2=A0 =C2=A0DNS RRset.=C2=A0 Given a RRset, a public key and a signature, = a DNSSEC
=C2=A0 =C2=A0validator checks the signature, time constraints, and other, l= ocal,
=C2=A0 =C2=A0policies.=C2=A0 In case of mismatch the RRSet is considered il= legitimate
=C2=A0 =C2=A0and is rejected.

=C2=A0 =C2=A0Accuracy in DNSSEC validation, that is, avoiding false positiv= es and
=C2=A0 =C2=A0catching true negatives, requires that both the signing proces= s and
=C2=A0 =C2=A0validation process adhere to the protocol, which begins with e= xternal
=C2=A0 =C2=A0configuration parameters.=C2=A0 This document describes requir= ements for a
=C2=A0 =C2=A0validator to be able to perform accurate validation.


5. Trust= Anchor Datastore
&quo= t;A company "Example" may for address all its devices"= ;
probably should be:
"A company "Exa= mple" may address all its devices"

--=C2=A0
Bob Harold


--94eb2c19dbc20ad15605541eedba-- From nobody Wed Jul 12 10:35:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660591316A8 for ; Wed, 12 Jul 2017 10:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 SRBuRL2oj3T7 for ; Wed, 12 Jul 2017 10:35:30 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6DC131549 for ; Wed, 12 Jul 2017 10:35:30 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 92FB2251FD; Wed, 12 Jul 2017 10:35:29 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Cc: Michael StJohns , dnsop@ietf.org References: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> Date: Wed, 12 Jul 2017 10:35:28 -0700 In-Reply-To: (Wes Hardaker's message of "Thu, 06 Jul 2017 11:53:47 -0700") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 17:35:31 -0000 Mike, > The value in 6 regardless of what it is is the wrong value for > revocation. revocationPublicationWaitTime is basically > EarliestDateAttackFails + queryInterval + slop. Revocations take > place immediately. You can delay them only as long as you have old > valid signed RRSets. So in short, the advice in 5011 section 6.6 step 3: 3. After 30 days, stop publishing the old, revoked keys and remove any corresponding DS records in the parent. Has nothing to do with a needed wait time (because keys are revoked immediately) but rather the above 30 days is really just a suggested time for operational practice? In 2.4.2 you have: The remove hold-down time is 30 days. This parameter is solely a key management database bookeeping parameter. Failure to remove information about the state of defunct keys from the database will not adversely impact the security of this protocol, but may end up with a database cluttered with obsolete key information. Which seems to back this up (though I'm not convinced that there is no security ramifications of having old trust anchors around; else why delete them?) So in the 5011-security-considerations draft, I agree with your point that the right amount of time to wait should be changed to replayTime + queryInterval + slop. Thanks for pointing that out. (though it's worth noting that replayTime + queryInterval can be longer than 30 days). -- Wes Hardaker USC/ISI From nobody Thu Jul 13 10:03:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D563C131483 for ; Thu, 13 Jul 2017 10:03:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=umich.edu 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 vYFw66otpqx4 for ; Thu, 13 Jul 2017 10:03:53 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 F00911201F8 for ; Thu, 13 Jul 2017 10:03:52 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id n205so18956676yba.1 for ; Thu, 13 Jul 2017 10:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y26tpthqtl+SMk+1xp0OvnzmCJnqSWURr0rTXU84ic0=; b=e3VvLSkaOq5UxYLtSdnpqhAqKQD9uOhds9nc9Vzwwk9m8pILgrSUTZmkPwCWKCdYfH g4PZ1oJqg9Oigsfh27/7ZGTCblHV4h0WQHqxDhaehIkP76aBtvMkjze05SPhatu/yJcq smloc4b8q0lNsNSQzX+jGLSBkjzxbFkgifSP9YhF9IXaL0bbjna9g6/Fwx3ht8gpMEjW K1SJR1lecr4haJ6V3D7LxkgeNj7nEir19uhfFd4hr8zzkheSPdGB4ayjH7G/2YwD+KHp X9tc2Zk7p9ybU7Cr37dYYHNCnmayrDQxzKLZgeDh9uKk4a3Sda0a7IQBGmAd0OvOzE32 Fp2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y26tpthqtl+SMk+1xp0OvnzmCJnqSWURr0rTXU84ic0=; b=kbI8VsPOSDSURBqPCffyAJxbieQt8kc+zGj8V4CSyxGS02n1/kR1H2TNkvn8IEkDdh A02Zmwrm2nDE162z+z9Vcb65Z+mEr1q58N8pDpNOQ7o72ymmx3ioNKBqA8sCwehJhMcr jC9JUihe8ngfASSWSrwwh1MmwE63fceSNwPXUBmdFTullCKiL2NyDMFSgqH0iNqgv1Ys bOfSaGbyu48iLLj4RgUfV4li33AsU7hToFFmO3ndoy928mV+HmL/yugtJpXwD62PKYdG vaEVhhRL1uahq42pa4oKQ2DWtNGiQPL1ueMxB9mFjQsGcZ/0pPJr9RQA1eLadPvFmkrc /JcQ== X-Gm-Message-State: AIVw112GwZsqzosxqj6bWTAdTQq8WSx06I/qaK2c/OTRa6H20fwokxVU Spdcu0TOfmFAUWjRw5yO3zvojGIn1NEV X-Received: by 10.129.128.134 with SMTP id q128mr2764126ywf.305.1499965431909; Thu, 13 Jul 2017 10:03:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.132 with HTTP; Thu, 13 Jul 2017 10:03:51 -0700 (PDT) In-Reply-To: <4889c9c7-cda4-9685-ed88-7ae9143b4348@isc.org> References: <149908772964.4070.2471656184158486415.idtracker@ietfa.amsl.com> <4889c9c7-cda4-9685-ed88-7ae9143b4348@isc.org> From: Bob Harold Date: Thu, 13 Jul 2017 13:03:51 -0400 Message-ID: To: Ray Bellis Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c036164bea7e6055435eac2" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 17:03:56 -0000 --94eb2c036164bea7e6055435eac2 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 3, 2017 at 9:31 AM, Ray Bellis wrote: > Following feedback and discussion on this draft I've updated it to use a > META RR rather than an EDNS option. > > This simplifies questions about adding an OPT RR if one wasn't already > in the proxied packet. It also avoids (some) issues with TSIG / SIG(0). > > This RR now contains the entire 5-tuple of src/dest address and port > (and protocol) and not just the source IP address - the rationale for > this is explained in the draft. > > As I won't be present for DNSOP in Prague this is due to be presented by > Peter van Dijk, one of my two new co-authors. > > Ray > > -------- Forwarded Message -------- > > A new version of I-D, draft-bellis-dnsop-xpf-02.txt > has been successfully submitted by Ray Bellis and posted to the > IETF repository. > > Name: draft-bellis-dnsop-xpf > Revision: 02 > Title: DNS X-Proxied-For > Document date: 2017-07-03 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-02.txt > Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ > Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-xpf-02 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-xpf-02 > Diff: https://www.ietf.org/rfcdiff? > url2=draft-bellis-dnsop-xpf-02 > > Abstract: > It is becoming more commonplace to install front end proxy devices in > front of DNS servers to provide (for example) load balancing or to > perform transport layer conversions. > > This document defines a meta resource record that allows a DNS server > to receive information about the client's original transport protocol > parameters when supplied by trusted proxies. > > 3.4. Presentation Format Since this is a "meta" RR that cannot appear in master format zone files no presentation format is defined. Could you please define a Presentation Format so that "dig" and similar tools use a consistent format? -- Bob Harold --94eb2c036164bea7e6055435eac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Jul 3, 2017 at 9:31 AM, Ray Bellis <ray@isc.org> wrote:
Following feedback and d= iscussion on this draft I've updated it to use a
META RR rather than an EDNS option.

This simplifies questions about adding an OPT RR if one wasn't already<= br> in the proxied packet.=C2=A0 It also avoids (some) issues with TSIG / SIG(0= ).

This RR now contains the entire 5-tuple of src/dest address and port
(and protocol) and not just the source IP address - the rationale for
this is explained in the draft.

As I won't be present for DNSOP in Prague this is due to be presented b= y
Peter van Dijk, one of my two new co-authors.

Ray

-------- Forwarded Message --------

A new version of I-D, draft-bellis-dnsop-xpf-02.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bellis-dnsop-xpf
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS X-Proxied-For
Document date:=C2=A0 2017-07-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://too= ls.ietf.org/html/draft-bellis-dnsop-xpf-02
Htmlized:
https://datatracker.ietf.org/doc= /html/draft-bellis-dnsop-xpf-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-bellis-dnsop-xpf-02

Abstract:
=C2=A0 =C2=A0It is becoming more commonplace to install front end proxy dev= ices in
=C2=A0 =C2=A0front of DNS servers to provide (for example) load balancing o= r to
=C2=A0 =C2=A0perform transport layer conversions.

=C2=A0 =C2=A0This document defines a meta resource record that allows a DNS= server
=C2=A0 =C2=A0to receive information about the client's original transpo= rt protocol
=C2=A0 =C2=A0parameters when supplied by trusted proxies.







--94eb2c036164bea7e6055435eac2-- From nobody Thu Jul 13 13:12:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB6E129562 for ; Thu, 13 Jul 2017 13:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 439ySQCrxgU8 for ; Thu, 13 Jul 2017 13:12:35 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668B9128C81 for ; Thu, 13 Jul 2017 13:12:34 -0700 (PDT) Received: from [46.227.151.81] (port=51099 helo=Barbaras-MacBook-Pro.local) by hydrogen.portfast.net ([188.246.200.2]:587) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dVkTN-0002pm-Dk (Exim 4.72) for dnsop@ietf.org (return-path ); Thu, 13 Jul 2017 21:12:29 +0100 To: dnsop@ietf.org References: <149908772964.4070.2471656184158486415.idtracker@ietfa.amsl.com> <4889c9c7-cda4-9685-ed88-7ae9143b4348@isc.org> From: Ray Bellis Message-ID: <5141f031-0f8e-7c71-43b4-bfc39e841e80@bellis.me.uk> Date: Thu, 13 Jul 2017 21:12:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 20:12:38 -0000 On 13/07/2017 18:03, Bob Harold wrote: > 3.4. Presentation Format > Since this is a "meta" RR that cannot appear in master format > zone files no presentation format is defined. > > Could you please define a Presentation Format so that "dig" and similar > tools use a consistent format? Ah, yes - good point! thanks, Ray From nobody Fri Jul 14 10:43:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0A413144F for ; Fri, 14 Jul 2017 10:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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=gmail.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 cmH9aGjxuYeT for ; Fri, 14 Jul 2017 10:43:10 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 5F7DB131455 for ; Fri, 14 Jul 2017 10:43:10 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id d78so81015500qkb.1 for ; Fri, 14 Jul 2017 10:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=pmSmIRn0qvNY72a8Q8WI+HGcb/iuhudjZsL0fDK9E1g=; b=Io2QpDRN5VGP4d9KGHmV6KInn5e5I4YTRf/KreGPOueW0Sqjl5vVwlkkDI1H+LXr0M JiHlH+Bdx4B6k5nkGjJA74zpThnWjOo05xXXMI27eLXg9HQHKYeYNxY0n+1owo80w80o A6uHLoCo4lZAguxO9nV0V0INs/JoVrMT39U1SUfWP5Jzm+bt8tDMhpbK7+1opegE3g8e jAJ3mWVGi9/d7FbixchyDR7RnAf01ki2gwDwxbzBwD1ehPNDrKGVx2OCjX4eorTCMjk5 AslOMSHiBJOT4jh81koySUylDuayzYfM08s0JTJ0sHXBLy7qTcBR5tptANyG3bodLCTt BAOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=pmSmIRn0qvNY72a8Q8WI+HGcb/iuhudjZsL0fDK9E1g=; b=NpP/HMW6mUZXPyRmWZevD2pq2QgE2IPaa0iBvLXSJWViey+UQjwmKxau0W+iRmoKV9 XcFByEn0DpmY1HSjMJ02lovvlWT29jTWBuRivTm56qao2Su5DMbm9rseLzBEFfhYxdZk vUiusyE/Aag9VtY+7jv4U4vL8DYg1FNRMsoYFG2lwaecZSXbtBPu+xC6lctS6pCKOFVf wqetfajsnImAH6PTYDO8UQAFSiNsUZLqvufUASFeSuDIsjt5jbDvOgnvJerkBLYRDsuI fhhR1crmfgFH7ubnUmap0ffXsofl2ToTWLZpqk9TSFFR8dmSNj6tUlHPtOup3Nn/GreP 8D0w== X-Gm-Message-State: AIVw110M7eSk2ygIrXld5JTqqfL+Fy/xlcGcxCetV/bfKR4fOA+azBnS 3u+G8i8/C7ZYijh4tP15xI9YKBA5TyCC6U4= X-Received: by 10.55.185.6 with SMTP id j6mr12195125qkf.14.1500054189183; Fri, 14 Jul 2017 10:43:09 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Fri, 14 Jul 2017 10:43:08 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 14 Jul 2017 10:43:08 -0700 X-Google-Sender-Auth: PvSgcxmQ5bnCWYfu28muLlBMVGY Message-ID: To: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [DNSOP] comments on draft-muks-dnsop-dns-opportunistic-refresh-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 17:43:13 -0000 I've read draft-muks-dnsop-dns-opportunistic-refresh-00. In short my current impression is: "interesting but not yet very convincing idea". High-level comments: It's an interesting idea. However, depending on its main motivation I'm not sure how effective it is. As it's listed in the dnsop agenda https://datatracker.ietf.org/meeting/99/agenda/dnsop/ with draft-tale-dnsop-serve-stale, it may mainly intend to be a mitigation in case the authoritative server of a popular name becomes unreachable. But, for this proposal to be effective in that case, the resolver would have to query other names in the same zone periodically. I'm not sure if we can generally assume that in cases where it matters (for example, for the "twitter.com" zone the resolver may only query for "twitter.com"). Also, the target zone needs to be generally stable, so for example it's not very effective if the zone is quite frequently updated. I can imagine some popular zones are frequently updated, e.g., for load balancing purposes. For example, in my quick experiments the SOA serial of the facebook.com zone changes quite rapidly. On the other hand I wonder some other popular zones may not rely on SOA serials to keep its authoritative servers up to date (i.e., they may not use the standard zone transfer mechanism to distribute the latest version of zones to secondaries). I can also think of a corner case where this approach doesn't work well: assume a zone that changes very frequently and its serial can wrap quite quickly. unlike secondary authoritative servers that are supposed to be notified reasonably timely via NOTIFY, a resolver may not be able to notice intermediate changes quickly enough and incorrectly assumes the zone hasn't changed when the serial has actually wrapped around. It's easy to dismiss such a case as unrealistic, but as a formal protocol I don't think we should ignore these cases too casually. Given these observations, I'd first like to understand specifically for what purpose under which assumptions this proposal is deemed to be useful. At this moment it's not very convincing to me. Some specific comments on the draft text follow: - Section 4.3 Upon receiving a positive response containing an SOA RR and a valid ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's serial number with the RRs in the answer. I believe the resolver should also associate the zone name. Perhaps that's the intent, but it's not very clear from this description. So it would be better to say so more explicitly. - Section 4.3: what if the response contains a ZONESERIAL option but there's no SOA in the additional (or authority) section? - Section 4.5 o An authoritative server receiving a misconfigured ZONESERIAL option in a query SHOULD return a FORMERR response. o A resolver receiving a misconfigured ZONESERIAL option in a response MUST NOT interpret the serial number in any SOA RR in that response as an indication of zone freshness. It's not clear what "misconfigured" means. It would help if this could be more specific. - Section 5 I'd suggest revising the format diagram as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ ! OPTION-CODE ! OPTION-LENGTH ! +-------------+-+---------------+-------------------------------+ | Reserved |R| +-------------+-+ with the following description: Reserved A 7-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. R 1-bit request/acknowledge flag. This bit MUST be clear in requests [...same as the original text] The main motivation for this suggestion is that "Bit 7 of this field" in the original text might sound a bit ambiguous. Even if it can be considered reasonably clear per common sense, I think it'd still be helpful if we specify the position in the diagram. Also, in the suggested text the reserved area is just called "reserved" instead of calling the entire 8 bits "flags". Not a strong opinion, but I think it's better as we might want to use some of the reserved area for non-flag type of data. -- JINMEI, Tatuya From nobody Fri Jul 14 11:12:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4916129B64 for ; Fri, 14 Jul 2017 11:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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=gmail.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 9ucYfHH90Eyl for ; Fri, 14 Jul 2017 11:12:33 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 71FCE128B8F for ; Fri, 14 Jul 2017 11:12:33 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id v17so75815692qka.3 for ; Fri, 14 Jul 2017 11:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=w/u2iJonSngrr3JidQS2smeSEgf+w688inZjpxLuFuc=; b=AJhQt5tpqC8fVrY1oaZxQfi4/LtKemaADskd49I/MonRRQHyVuc9zUfyW+hmvfrP7+ 8qoDyk8Sxjg7z7oJn/xuHKma/7JnTJ6bJaOfNc/YgGZrqHyNtd/g8aS62xH40IxR7Gs3 4rnBpZzwMDmPnf8kkO/tbvoUASshunOPQkfQ0ZkZ2QWRIBHwdXK2xEPShnFi7xYN9uVJ y+DbRxtuwo6IrfRulxybzFBtuZ74B2hHq60p2lba+ephsw23grB4VebZtgiuL7kFVHg/ a8iBjkUPuJCMtuUBIJ2gE3B2klPwV+S58zZI5/P9+I3KUnQnv0oEL2kXFkwwSNuz0CWR ZaLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=w/u2iJonSngrr3JidQS2smeSEgf+w688inZjpxLuFuc=; b=Zn3ao/a9jMhY6Cuc8OaZGLdoLX3pD00NZ5/ROL/8HUOMsCwzFMPBx+4QpcO5Tlq7Lh WlKjbfk251bgzBELn6HmRk7SAfsw1cU8YRdJkR6x8RcxYfilhDowc9/XvF77OTBzFeF5 eFFGhaUgTL+9ewhZrDLKQQ8pNp6gT5q5djSpOb+exvUs+erFwlYDM/yIsua/sp+W0RpB 5aMRE9g0OMD01fMzcZYbG0FzPWQ/+c/NbzAsXmx7403pvPggt8YcK+aLUZz7LYiMY3px 2N358bH5yUo7/mH6V+nFPm8UfpO/4Lz08fJ0q0B3Mc/TLBg3wB9UdyiUTK1+gu7/ejiw dw4w== X-Gm-Message-State: AIVw112jVwIGeSgmgVtBUBBLd3Cwkk77D3zT3OtTIAZaMHFgk43KplmD jGP8bRlzt0PhOtuozu1aCdsW4zZgSAX+9zk= X-Received: by 10.55.150.134 with SMTP id y128mr13208082qkd.29.1500055952402; Fri, 14 Jul 2017 11:12:32 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Fri, 14 Jul 2017 11:12:31 -0700 (PDT) In-Reply-To: <8FFF06E9-59D8-4033-B914-43E9C1DE16E8@powerdns.com> References: <20170407181139.GB66383@isc.org> <8FFF06E9-59D8-4033-B914-43E9C1DE16E8@powerdns.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 14 Jul 2017 11:12:31 -0700 X-Google-Sender-Auth: mrVwE0YJZ71tMnj64BHnX9y22nM Message-ID: To: Peter van Dijk Cc: dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 18:12:35 -0000 At Mon, 03 Jul 2017 11:23:01 +0200, "Peter van Dijk" wrote: > > In that sense I see some disparity with the > > ALIAS record of Amazon Route53, one of the earliest (and probably > > largest) players of the idea: > > - Supporting other types of records than AAAA and A > > - Allowing different target names for different types > > As I replied to John Levine, we do not feel this is prudent at this > stage. Operational experience with ANAME, once standardised and > deployed, would be a good basis for another draft that is more > extensive, like having a type bitmap - this would support both these > features. > > > I don't know how critical these are for existing R53 ALIAS users, but > > depending on that ANAME may not be able to be successful in practice. > > Outside of R53, most implementations appear to be similar. That=E2=80=99s= a > pretty decent installed base that we can try to convert! I'm no by means an advocate of R53-ALIAS, but I suspect its deployment base as an ALIAS variant is too big to ignore. If we just keep ignoring them with the wish of eventual conversion, I'm afraid it's quite possible that we'll end up having two (or more) incompatible variants, each has a non-negligible size of deployment. IMO we should more explicitly try to avoid that situation. In that sense I'd like to suggest contacting someone at Amazon to see if they are interested in developing an interoperable standard version of ALIAS. With such efforts and hopefully some hope to have the possibility of having more compatible deployments, I have no problem with deferring extensions itself. -- JINMEI, Tatuya From nobody Sat Jul 15 08:47:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5612EB43 for ; Sat, 15 Jul 2017 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 zKGFMuW1ULBF for ; Sat, 15 Jul 2017 08:47:31 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 84110126BF0 for ; Sat, 15 Jul 2017 08:47:31 -0700 (PDT) Received: from jurassic (unknown [115.117.169.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id CED1956A0034; Sat, 15 Jul 2017 15:47:27 +0000 (GMT) Date: Sat, 15 Jul 2017 21:17:23 +0530 From: Mukund Sivaraman To: =?utf-8?B?56We5piO6YGU5ZOJ?= Cc: dnsop Message-ID: <20170715154723.GA11347@jurassic> References: 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.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] comments on draft-muks-dnsop-dns-opportunistic-refresh-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 15:47:34 -0000 Hi Jinmei Thank you for the review. Some replies are below. On Fri, Jul 14, 2017 at 10:43:08AM -0700, 神明達哉 wrote: > I've read draft-muks-dnsop-dns-opportunistic-refresh-00. In short my > current impression is: "interesting but not yet very convincing idea". > > High-level comments: > > It's an interesting idea. However, depending on its main motivation > I'm not sure how effective it is. As it's listed in the dnsop agenda > https://datatracker.ietf.org/meeting/99/agenda/dnsop/ with > draft-tale-dnsop-serve-stale, it may mainly intend to be a mitigation > in case the authoritative server of a popular name becomes > unreachable. But, for this proposal to be effective in that case, the > resolver would have to query other names in the same zone > periodically. I'm not sure if we can generally assume that in cases > where it matters (for example, for the "twitter.com" zone the resolver > may only query for "twitter.com"). > > Also, the target zone needs to be generally stable, so for example > it's not very effective if the zone is quite frequently updated. I > can imagine some popular zones are frequently updated, e.g., for load > balancing purposes. For example, in my quick experiments the SOA > serial of the facebook.com zone changes quite rapidly. > > On the other hand I wonder some other popular zones may not rely on > SOA serials to keep its authoritative servers up to date (i.e., they > may not use the standard zone transfer mechanism to distribute the > latest version of zones to secondaries). I don't know how it got clubbed together with draft-tale-dnsop-serve-stale as serving a similar purpose. It seems to be a misunderstanding. The scheme was considered to reduce queries from a resolver, when possible for a zone that has a last-modified timestamp or serial as an identifier following an ordered sequence that identifies a whole zone at a particular time. To avoid implementation and operational complexity, we decided to use the SOA serial as this identifier. This will not suit every operator case (esp. if the SOA serial is not maintained at all by custom nameservers that generate answers on-the-fly), so the scheme is optional on the server-side (auth). However, e.g., for a BIND master and slaves using the regular RBTDB, it can be configured on by default. That it might sometimes help the case where auth service is non-functional may be a side effect, but this is not the goal. > I can also think of a corner case where this approach doesn't work > well: assume a zone that changes very frequently and its serial can > wrap quite quickly. unlike secondary authoritative servers that are > supposed to be notified reasonably timely via NOTIFY, a resolver may > not be able to notice intermediate changes quickly enough and > incorrectly assumes the zone hasn't changed when the serial has > actually wrapped around. It's easy to dismiss such a case as > unrealistic, but as a formal protocol I don't think we should ignore > these cases too casually. On the master, if an SOA serial is updated very frequently, overflows, wraps around and counts upward to exactly match the previous serial, would the slave notice it during a refresh? It wouldn't, and so even regular queries to the slave may result in old stale data being served. In the case of this scheme, as it is optional, it would be up to the operator to decide based on the risk of quick wraparound. I agree that the corner cases should be explored thoroughly. > Given these observations, I'd first like to understand specifically > for what purpose under which assumptions this proposal is deemed to be > useful. At this moment it's not very convincing to me. I'm including some comments from previous discussion among the authors from several weeks ago: -------- > 1. A delegation-centric zone. Queries to such a zone would not benefit > from this scheme, as we explicitly rule out its use for NS records. For zones such as TLDs, the update rate would also be too high for this draft to be useful. > 2. A tiny zone, comprising little more than an A/AAAA record for www, > an MX record, and NS records. Under these circumstances, a resolver > is only going to do a minimal number of lookups to the zone, so is > unlikely to get a lot of benefit by extending TTLs. There are other categories of zones that lie between these two. Even in the above case, in a validating resolver, every A/AAAA fetch would require a corresponding DNSKEY fetch to validate RRSIGs, so this draft would save at least one fetch when the previously cached DNSKEY's TTL had expired. There are several popular zones like facebook.com, apple.com, google.com, etc. where people/apps lookup more than one name's address within that zone. At an ISP's resolver, such lookups are continuous. Then, there are small-to-medium sized businesses such as isc.org which have address lookups for www, mail, git, jabber, asterisk, etc. where the zone content is mostly static. Almost every business that runs its own services such as email, web apps, etc. would include multiple names having address records at the least. Then there are service-specific records. I'm sure it can be demonstrated with a zone such as isc.org as an example, at an office with multiple people and machines such as ISC's 950 Charter Street office address, how a single lookup by one person/machine would help follow-up lookups for other names+records by other people/machines. -------- > Some specific comments on the draft text follow: > > - Section 4.3 > > Upon receiving a positive response containing an SOA RR and a valid > ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's > serial number with the RRs in the answer. > > I believe the resolver should also associate the zone name. Perhaps > that's the intent, but it's not very clear from this description. > So it would be better to say so more explicitly. > > - Section 4.3: what if the response contains a ZONESERIAL option but > there's no SOA in the additional (or authority) section? In this case, it would be broken behavior and one can assume FORMERR parsing the reply message. This should be documented. > - Section 4.5 > > o An authoritative server receiving a misconfigured ZONESERIAL > option in a query SHOULD return a FORMERR response. > > o A resolver receiving a misconfigured ZONESERIAL option in a > response MUST NOT interpret the serial number in any SOA RR in > that response as an indication of zone freshness. > > It's not clear what "misconfigured" means. It would help if this > could be more specific. Yes it should be rephrased as it would not be a configuration mistake. > - Section 5 > > I'd suggest revising the format diagram as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-------------------------------+-------------------------------+ > ! OPTION-CODE ! OPTION-LENGTH ! > +-------------+-+---------------+-------------------------------+ > | Reserved |R| > +-------------+-+ > > with the following description: > > Reserved A 7-bit unused field. It MUST be initialized to > zero by the sender and MUST be ignored by the > receiver. > > R 1-bit request/acknowledge flag. This bit MUST be > clear in requests [...same as the original text] > > The main motivation for this suggestion is that "Bit 7 of this > field" in the original text might sound a bit ambiguous. Even if > it can be considered reasonably clear per common sense, I think it'd > still be helpful if we specify the position in the diagram. Also, > in the suggested text the reserved area is just called "reserved" > instead of calling the entire 8 bits "flags". Not a strong opinion, > but I think it's better as we might want to use some of the reserved > area for non-flag type of data. +1. I'm also used to LSB being 0 and MSB being 7, so the current text is confusing. Mukund From nobody Sun Jul 16 02:22:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3A512F280 for ; Sun, 16 Jul 2017 02:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 12XT4joQpYEK for ; Sun, 16 Jul 2017 02:21:56 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E5848127058 for ; Sun, 16 Jul 2017 02:21:55 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id t70so16673920wmt.0 for ; Sun, 16 Jul 2017 02:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ISZkNSDRTozujSdjlp1jsezB+4DJOu0vVX/WPIM9Lys=; b=PQ1qwFlBdSozabXAuH41CeURsG8KjGpa1w6rJtM4KXdLObHxlVdGm7xffk9KRMWFym dXxgqVdmuTACaPTkvslRG0y7JfWsqFrFOhcFSWJ/28uy5+d11PF3w4Ot6+o6HxOjUuOb I2gTutOj3m6H7q0g+Z2yYnCJFHi7bT+RkULuQqizy6tj9FY+1HlNwfO+Dyv/Ldr1Zh6p K71Z8tOsL46JnpMKxbZx1cmP6YJNPOBejmZunnnGtI79Sqm4n1auA81EIvHvB4yM7s8q 7UxrIiUay10RYdb8RW1dog0a201LcE7W15GHF988yZAakF9o8mRpbmQ+KK4aWUScU2sk Py9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ISZkNSDRTozujSdjlp1jsezB+4DJOu0vVX/WPIM9Lys=; b=huybnOfWo0dwAAtlT2UxywbinvhjMJSfjDXSsz43jRHLjerv8apa87t2BP22C9Na+P qCQgGL2oYdDyIrpBBBoHTe+4vX7KrpZP/XS51pFv05vfpGx4IzFO/C8jJpqD1esicwd/ Bd1bMGCD3oTtg2HhQ3NubRcZhgugPkfSmo0IVuh1DSsTo2a7UB1/7hismsiJJC3Fhuzc rZgAarBYMpcNiNv/CsYWTA7MdMA4xN8drXwPXis0DcNjokDNG9+Z3aOYMfSLbJK3vfo7 T1iUUiaAMlv/68jnIkdqQj/L598QKnjA/y21AgZB5Of6v5QKoe4WQFVfTcDRV9lJrwzs d5kA== X-Gm-Message-State: AIVw1133MKnEW8ZE7auQBsbyEw8p0TUp4jd7NlM5am1+kbbdBGSOzkwC cDiLq9tiW9JqS7vzu9M= X-Received: by 10.28.158.11 with SMTP id h11mr1023130wme.88.1500196914132; Sun, 16 Jul 2017 02:21:54 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:9422:6544:1cd4:352c? ([2001:67c:370:128:9422:6544:1cd4:352c]) by smtp.gmail.com with ESMTPSA id b195sm15261913wmf.0.2017.07.16.02.21.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 02:21:53 -0700 (PDT) To: Wes Hardaker Cc: dnsop@ietf.org References: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> From: Michael StJohns Message-ID: <77997330-f10c-22b3-4683-68e6d2a37cc0@nthpermutation.com> Date: Sun, 16 Jul 2017 05:21:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 09:21:57 -0000 On 7/12/2017 1:35 PM, Wes Hardaker wrote: > Mike, > >> The value in 6 regardless of what it is is the wrong value for >> revocation. revocationPublicationWaitTime is basically >> EarliestDateAttackFails + queryInterval + slop. Revocations take >> place immediately. You can delay them only as long as you have old >> valid signed RRSets. > So in short, the advice in 5011 section 6.6 step 3: > > 3. After 30 days, stop publishing the old, revoked keys and remove > any corresponding DS records in the parent. > > Has nothing to do with a needed wait time (because keys are revoked > immediately) but rather the above 30 days is really just a suggested > time for operational practice? In your "prevent the add of a new trust anchor" attack, you only need to intercept one query/response pair over a period of queryInterval + EarliestDateAttackFails. In the "prevent revocation" attack, you need to intercept ALL query/response pairs for at least 30 days (in the example - that's 60 Q/Rs) - quite a bit harder and pretty much impossible to do widespread. Also, 6.6 talks about deletion of a subordinate trust point by revoking all the trust anchors - depending on the behavior of the resolver (which I had many arguments about with various vendors), trust will generally be traced through the new DS record(s) with the absence of the old trust anchor key in the DNSKEY RRSet so the presence (or absence) of the "revoked" key in the resolver's trust anchor set is mostly a non-issue once the DS is published. Given that I can think of only a few possible subordinate trust points and none of them will probably ever be deleted, I probably wouldn't change this guidance. If we were going to change the guidance, it wouldn't be as simple as the publish new trust anchor model - you would need to consider the expiration of the Parent DS (if any) as well as expiration of the child DNSKEY RRSet in picking a new value. > > In 2.4.2 you have: > > The remove hold-down time is 30 days. This parameter is solely a key > management database bookeeping parameter. Failure to remove > information about the state of defunct keys from the database will > not adversely impact the security of this protocol, but may end up > with a database cluttered with obsolete key information. > > Which seems to back this up (though I'm not convinced that there is no > security ramifications of having old trust anchors around; else why > delete them?) Nope - two different parameters with the same value. The first was a publication guidance, the above was simple database management guidance for the resolver. > > So in the 5011-security-considerations draft, I agree with your point > that the right amount of time to wait should be changed to replayTime + > queryInterval + slop. Thanks for pointing that out. (though it's worth > noting that replayTime + queryInterval can be longer than 30 days). > If you mean that replayTime ~= last validity date/time of the old DNSKey RRSet with the to be removed keys - then yes. But please be clear and precise in how you define this term in the document. From nobody Sun Jul 16 06:51:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FDA12F28A for ; Sun, 16 Jul 2017 06:51:03 -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] 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 bFj2sMsT51LM for ; Sun, 16 Jul 2017 06:51:01 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 9F09F1200FC for ; Sun, 16 Jul 2017 06:51:01 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id C491931CA9; Sun, 16 Jul 2017 15:50:58 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id 494AFEC0BB8; Sun, 16 Jul 2017 15:49:08 +0200 (CEST) Date: Sun, 16 Jul 2017 15:49:08 +0200 From: Stephane Bortzmeyer To: Richard Gibson Cc: dnsop@ietf.org Message-ID: <20170716134908.GB5654@laperouse.bortzmeyer.org> References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 13:51:04 -0000 On Mon, Jul 03, 2017 at 07:22:14PM -0400, Richard Gibson wrote a message of 289 lines which said: > * Communicate aggregation of IP addresses into prefixes (i.e., the > irrelevance of least-significant bits in ip-address values) with new > "client-prefix-length-ipv4" and "client-prefix-length-ipv6" and > "server-prefix-length-ipv4" and "server-prefix-length-ipv6" file > preamble configuration options. Yes, it is very important in privacy-conscious settings, when you want to blur the data. From nobody Sun Jul 16 06:51:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186241200FC for ; Sun, 16 Jul 2017 06:51:03 -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] 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 9NiHTIyGDs0W for ; Sun, 16 Jul 2017 06:51:01 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 AE973129B35 for ; Sun, 16 Jul 2017 06:51:01 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id B5DB231CE6; Sun, 16 Jul 2017 15:50:58 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id 63F23EC0BB8; Sun, 16 Jul 2017 15:44:53 +0200 (CEST) Date: Sun, 16 Jul 2017 15:44:53 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20170716134453.GA5654@laperouse.bortzmeyer.org> References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149907291397.4998.8059630450980375262@ietfa.amsl.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [DNSOP] C-DNS at the Hackathon (Was: I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 13:51:04 -0000 On Mon, Jul 03, 2017 at 02:08:34AM -0700, internet-drafts@ietf.org wrote a message of 45 lines which said: > Title : C-DNS: A DNS Packet Capture Format > Filename : draft-ietf-dnsop-dns-capture-format-03.txt Jim Hague and myself worked at the IETF 99 hackathon on C-DNS, producing a proof-of-concept DNSTAP-to-C-DNS translator This raised some issues. There is a semantic mismatch between dnstap and C-DNS. C-DNS makes most information mandatory, dnstap accepts that you omit almost everything. (The current dnstap-to-C-DNS converter solves the problem by generating dummy values, such as all-zeroes for IP addresses.) Should C-DNS be more lax? Some people would prefer the security of konwing everything is there, some may have the problem that the information is unknown on the beginning. May be having two profiles of C-DNS, a "Full" where almost everything is mandatory, a "Partial" where a lot of things are optional? (Tools could refuse to convert "Partial" C-DNS files to pcap.) Many arrays in the spec syntactically allow empty arrays (Block.queries, BlockTables.ip-address, etc). When the field is optional (BlockTables.qrr), it means there are two ways to omit the array: not having the field at all, and having the field going to an empty array. Is it a good thing to have both? When the field is mandatory (BlockTables.classtype), what is the use of an empty array? Note that we cannot refer to an empty array: the draft says 'An index value of 0 is reserved to mean "not present".' but it is not accepted by the current tools (Compactor). Is the tool wrong? I find no way to indicate in C-DNS the bailiwick of the response, or the fact that it was a cache hit or miss in the resolvers. These are two important information in dnstap, that you cannot get by sniffing the traffic. May be related to the "private extensions" discussion ? As already mentioned in , the fact that keys are always integers and not the strings used in the description is not obvious. A warning would be welcome. There is no mention of the CBOR encoding of the maps and arrays. Can a C-DNS producer use at will indefinite or definite lengths? Should it be explicit in the draft or do we think that "Read RFC 7049, you CBOR n00b" is enough? Should we have an "advice to implementers" section? For instance, if a C-DNS producer runs for a long time and then crashes, losing the opportunity to add a CBOR break at the end of an array, the file becomes corrupted (pcap does not have this problem). Is it worth a warning? From nobody Sun Jul 16 08:10:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AADA129AF9 for ; Sun, 16 Jul 2017 08:10:34 -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=gmail.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 St-CTNXg1Ft0 for ; Sun, 16 Jul 2017 08:10:33 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 D3E541200C5 for ; Sun, 16 Jul 2017 08:10:32 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 70so17566324wmo.1 for ; Sun, 16 Jul 2017 08:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:reply-to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=DcsIykS0xVDYtDlsSh9iQELOMeTv2/GK3rPTY9hFH0w=; b=K0zGdC4eSKeZW1CMyezxi7yph9ZWoPjBZR35PEhJdMFWwz2cYIGN1RswRhRPb+ETkD DEVgNCx89T1Bg8N10Jis1qfhKGiB8d7v813sCEym0QDLQd9j/YG34TlgymND7luLhyqS bL4/VtoJDovK1AlOZRlamO1OZzmZS/rO5usvqrfO6267izKDozd8G3ayvnriLVwbDMxO MwJicK7bqLRuwYrVZiwt0NUmHVbsoevbrna+c8+2E1LEhh+2AdVBqePXrjgtBrUaC7PI 4aV/aqVTQRFclxpu5EUXf1lqo6PvXJHYfALAKTbB+NxOyk0q+ZzTGnTCBL5mXfbt4DsY 8dQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:reply-to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=DcsIykS0xVDYtDlsSh9iQELOMeTv2/GK3rPTY9hFH0w=; b=DBlbj8bMMOZgleQSiuM0wePeHyq3E8NaCe9zIlRRDBfI8CUUXYDqEujqR/4VmuURih 8GsG7XG+dr/wGjU1rKaFrJNjlHytyNMbUd1mfjGzN1vi0NcFe+CA7mjV9oJ7Vp76M3dr /RRIVpr8BIj991UeRT3+cM2PJ4f+RbN19ZGbRYbDY95DqykmTl40xM9nTRDXFlVMc6OG lJsK2lBQWuTCxzRpqoVFBudTLzJVP+Pw1+GY9p9LcRpjq+GHXerJ5JxWmek9IlE++J+3 c0IFkuHANgb3AGgrDC8M5yZthhyUmtFxy7hqQ2BEfEn0VgpDqmTIB6vI+6ZBhbyFRaxq 8F7w== X-Gm-Message-State: AIVw112dNpZlj/BKMx0UZbqDruZRm9iEIe/Z/W942bRu2Cem3fR5LOpU xo52IwKORURJXOfE X-Received: by 10.28.150.142 with SMTP id y136mr1645205wmd.51.1500217831345; Sun, 16 Jul 2017 08:10:31 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com ([2001:67c:370:128:7cbe:ff58:98d8:e7ec]) by smtp.googlemail.com with ESMTPSA id 1sm7488854wmn.32.2017.07.16.08.10.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 08:10:30 -0700 (PDT) To: dnsop Reply-To: "dnsop-chairs@ietf.org" From: Tim Wicinski Message-ID: Date: Sun, 16 Jul 2017 17:10:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Minute Takers, Jabber Scribes and Slides request for DNSOP X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 15:10:34 -0000 All Putting out a call for folks to take minutes at DNSOP on Tuesday (and possibly Thursday), as well as Jabber Scribe. If you can please drop the chairs a note. Also, if you are presenting, we would like to see slides by Tomorrow afternoon, or a good excuse as to why. Thanks and see you all Tuesday Afternoon tim From nobody Sun Jul 16 19:36:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7EC129A97 for ; Sun, 16 Jul 2017 19:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, 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=gmail.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 lCLsMc-hoLaI for ; Sun, 16 Jul 2017 19:35:58 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 49C3A126B6E for ; Sun, 16 Jul 2017 19:35:58 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id p73so47271948qka.2 for ; Sun, 16 Jul 2017 19:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JwhXzqtDtMn6xBFjAjThKeMoRF7oVt152VMWypDiFj8=; b=YpsWSK+EGrZ6MdlekaBZ2owjYVhoNrgVAYDc3/5r5HpFB8euFAp7PUifE8riGryc7m EULiAOGqevI35dDq3k/mwfZiREhpdf3EeqIPTf3m2q6ykFTuLnrfyKSgXFG40v9p6kg7 DV6nGDEaf2tjWatcKDJSFFTA2GFsqbYLRyPqYHw1pQ2FoG8fX+4J4v60uWOXuMtOUuIC op5bAf2EJk5Kc3EeckS/MgxKeVPao6+yPfp+B+w0jnRLz+04fl6h431vMQB5/D4kZk49 E2FwDEEEhGLYr4UWVOGtY2MeN+NskOnv+OeQ5uJ4tiIH09faWpyXKHulB9MaK3YXxSli /PQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JwhXzqtDtMn6xBFjAjThKeMoRF7oVt152VMWypDiFj8=; b=r7DdL02K+0lna3ITPTmd0M06DFAHTITQ71dQRUPY9JAXE1bPOzHUmmI8YcZ/Lz2/1p Cnrinu2XXhigPqhV2SKI89ib6pz0ia5nBGHWnWFCUOExvUwR4DwvFp6nXnfUxXd6xehR Mg0eIsHMU0LnvfsyhzrMZsA1kXqO6+3DW3Bq4kFu+pkucr5vWIXhddn8zV5eg26HFGtF uHd99Z8kOx6qz7zjW+grdZwgm2eeZTih0iscsmPa7Pcc+P2TFeIRM2vrE6mcBCbw/E5t D8hJXmF3UjG3sLR/JL3+Tx+PTgziZuofICYJSOF9reQucjkNhv58MCLYSobsVN2YCIOl kPbg== X-Gm-Message-State: AIVw1105kjp25yf1V7rDaqCdsu2tIHO2XkuWByp3f0cIatJYxGhnBPLv enJHHiofpLHw4FLaDJuvn3+50pR/gI4E X-Received: by 10.55.24.41 with SMTP id j41mr5130019qkh.114.1500258957085; Sun, 16 Jul 2017 19:35:57 -0700 (PDT) MIME-Version: 1.0 References: <150025655295.32691.13544492065984079858.idtracker@ietfa.amsl.com> In-Reply-To: <150025655295.32691.13544492065984079858.idtracker@ietfa.amsl.com> From: Lanlan Pan Date: Mon, 17 Jul 2017 02:35:46 +0000 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a1142e8703550b905547a42af" Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 02:36:00 -0000 --001a1142e8703550b905547a42af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Following discussion on previous version draft, we have some updates. 1) Focus on *GeoIP-enabled* Authoritative Nameserver: Section-1 , Appendix Geo-IP Example . 2) Clarify the difference between *path calculation* (Data Provider) and *tailored DNS response* (Authoritative Nameserver), which are offen obfuscated at CDN scenario: Section-1.1 . Your comments are appreciated. Regards, Lanlan & Yu ---------- Forwarded message --------- From: Date: 2017=E5=B9=B47=E6=9C=8817=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8A=E5=8D= =889:55 Subject: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt To: Pan Lanlan , Yu Fu A new version of I-D, draft-pan-dnsop-edns-isp-location-02.txt has been successfully submitted by Lanlan Pan and posted to the IETF repository. Name: draft-pan-dnsop-edns-isp-location Revision: 02 Title: ISP Location in DNS Queries Document date: 2017-07-17 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-pan-dnsop-edns-isp-location-02.t= xt Status: https://datatracker.ietf.org/doc/draft-pan-dnsop-edns-isp-location/ Htmlized: https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-pan-dnsop-edns-isp-location-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-pan-dnsop-edns-isp-location-02 Abstract: Nowadays, many Authoritative Nameservers support GeoIP feature, they guess the user's geolocation by the client subnet of EDNS Client Subnet (ECS) or by the source IP address of DNS query, return tailor DNS response based on the user's geolocation. However, ECS raises some privacy concerns because it leaks client subnet information on the resolution path to the Authoritative Nameserver. This document is inspired by EDNS Client Subnet (ECS), describes an improved solution for GeoIP-enabled Authoritative Nameservers, defines an EDNS ISP Location (EIL) extension to address the privacy problem of ECS, tries to find the right balance between privacy improvement and user experience optimization. EIL is defined to convey isp location < COUNTRY, AREA, ISP > information that is relevant to the DNS message. It will directly provide the same sufficient information for the GeoIP-enabled Authoritative Nameserver as ECS, to decide the response without guessing geolocation of the IP address. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a1142e8703550b905547a42af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2) Clarify the difference be= tween path calculation (Data Provider) and tailored DNS response<= /b> (Authoritative Nameserver), which are offen obfuscated at CDN scenario:= Section-1.1.

Your= comments are appreciated.

Regards,

Lanlan & Yu

---------- Forwarded message ----= -----
From: <internet-dr= afts@ietf.org>
Date: 2017=E5=B9=B47=E6=9C=8817=E6=97=A5=E5=91=A8= =E4=B8=80 =E4=B8=8A=E5=8D=889:55
Subject: New Version Notification for d= raft-pan-dnsop-edns-isp-location-02.txt
To: Pan Lanlan <abbypan@gmail.com>, Yu Fu <fuyu@cnnic.cn>



A new version of I-D, draft-pan-dnsop-edns-isp-location-02.txt
has been successfully submitted by Lanlan Pan and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-pan-dnsop-edns-isp-loca= tion
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ISP Location in DNS Queries
Document date:=C2=A0 2017-07-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 19
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-pan-dnsop= -edns-isp-location-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-pan-dnsop-edns-isp-location/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-pan-dnsop-edns-isp-= location-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-pan-dnsop-edns-= isp-location-02

Abstract:
=C2=A0 =C2=A0Nowadays, many Authoritative Nameservers support GeoIP feature= , they
=C2=A0 =C2=A0guess the user's geolocation by the client subnet of EDNS = Client
=C2=A0 =C2=A0Subnet (ECS) or by the source IP address of DNS query, return = tailor
=C2=A0 =C2=A0DNS response based on the user's geolocation.=C2=A0 Howeve= r, ECS raises
=C2=A0 =C2=A0some privacy concerns because it leaks client subnet informati= on on
=C2=A0 =C2=A0the resolution path to the Authoritative Nameserver.

=C2=A0 =C2=A0This document is inspired by EDNS Client Subnet (ECS), describ= es an
=C2=A0 =C2=A0improved solution for GeoIP-enabled Authoritative Nameservers,=
=C2=A0 =C2=A0defines an EDNS ISP Location (EIL) extension to address the pr= ivacy
=C2=A0 =C2=A0problem of ECS, tries to find the right balance between privac= y
=C2=A0 =C2=A0improvement and user experience optimization.

=C2=A0 =C2=A0EIL is defined to convey isp location < COUNTRY, AREA, ISP = >
=C2=A0 =C2=A0information that is relevant to the DNS message.=C2=A0 It will= directly
=C2=A0 =C2=A0provide the same sufficient information for the GeoIP-enabled<= br> =C2=A0 =C2=A0Authoritative Nameserver as ECS, to decide the response withou= t
=C2=A0 =C2=A0guessing geolocation of the IP address.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
=E8=87=B4=E7=A4=BC= =C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
=
--001a1142e8703550b905547a42af-- From nobody Mon Jul 17 02:01:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ABA12EBFA for ; Mon, 17 Jul 2017 02:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 hcIHRFXpntFP for ; Mon, 17 Jul 2017 02:01:55 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE72126E3A for ; Mon, 17 Jul 2017 02:01:55 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id BCCB53F441; Mon, 17 Jul 2017 05:01:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22892.32000.730535.635648@gro.dd.org> Date: Mon, 17 Jul 2017 05:01:52 -0400 From: Dave Lawrence To: Lanlan Pan Cc: dnsop In-Reply-To: References: <150025655295.32691.13544492065984079858.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:01:57 -0000 Have you had any feedback from authority server implementers who are interested in using this? I'm having a hard time picturing many CDNs wanting to switch, in no small part because geo is not the only goal of mapping. The < COUNTRY, AREA, ISP > tuple that is defined is insufficient. From nobody Mon Jul 17 02:41:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479DA129417 for ; Mon, 17 Jul 2017 02:41:14 -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, URIBL_BLOCKED=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 Oo1Sj_ANIrsi for ; Mon, 17 Jul 2017 02:41:13 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 2D4CB127337 for ; Mon, 17 Jul 2017 02:41:13 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A659D31C83; Mon, 17 Jul 2017 11:41:11 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id 59A1CEC0AE3; Mon, 17 Jul 2017 11:34:15 +0200 (CEST) Date: Mon, 17 Jul 2017 11:34:15 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20170717093415.GA7150@laperouse.bortzmeyer.org> References: <149907291397.4998.8059630450980375262@ietfa.amsl.com> <20170716134453.GA5654@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170716134453.GA5654@laperouse.bortzmeyer.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] C-DNS at the Hackathon (Was: I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:41:14 -0000 On Sun, Jul 16, 2017 at 03:44:53PM +0200, Stephane Bortzmeyer wrote a message of 58 lines which said: > Jim Hague and myself worked at the IETF 99 hackathon on C-DNS, > producing a proof-of-concept DNSTAP-to-C-DNS translator > This raised > some issues. And if you want the gory details on the code: http://www.bortzmeyer.org/c-dns-tests.html From nobody Mon Jul 17 23:42:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A3D131CD1 for ; Mon, 17 Jul 2017 23:42:04 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NqiiOUU13D3v for ; Mon, 17 Jul 2017 23:42:02 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 8E779131C41 for ; Mon, 17 Jul 2017 23:42:02 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id n42so8685886qtn.0 for ; Mon, 17 Jul 2017 23:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q2PE/igUBVpm7XSfuPxxhx2S5A9xNy6jO4wInGt9Ew4=; b=okOla6e2lk7jSHCGfZuk4ZKy1qwD3m+Je2NTcLDBsMF3xzS3ImywmfEiHE5/YWQWX1 c3qXmyVpMp4CQwlxhMrhUx+YE0n30WPT966oXD9EVlodauncfKu9ZkVaPR1bvOVcaWsb PCOxj8JbErt1QDT/6igFwZTiiXPk8w460dTfWp5LJi+/FORroOmR/qAGhX6z715Mgo5L iJPxe6G/KC8RpHlZLTcu3nuGgPZT6AqEEN7+AC5yBQ95eaMHVh4bTnP3GKFMv98X5mgC IpQAy28P7TT3cvadFBv62bBXDkHyyAl417ce93Cq51n9M7p3yZVw9wQPuK1SXq5LIN/u wYaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q2PE/igUBVpm7XSfuPxxhx2S5A9xNy6jO4wInGt9Ew4=; b=UddOysuBgx6AktkRwN1ag41M9S+TJfPve0KTkMMOHqtck3RKLCZfbxJ7mG0ZHh2SYM Jbwtprwtf9ntx/NGbECF2EbZm1V1BUBu84aqzmOp6TzhLXV1EnUw61vmA2dE5sBKFLen cIbVI7hDM9GZ4AukuC0Ht4Yx8BoGZDEQsfbZfkw9JATR0Dq7DnVtqgVxfvLSNUBbL/Qj gK5S3/+FcWp9SECRhYzOSSX3Jgc2VFlXBGMyALYRB5m0RxKiiBjoFeg6Ij3xJ+LElYCU CgxaIr6MRpa4r6xLrlCYx0H2EobexhQ5i0+fPZWuwB5fiUUuWVhaiFO+8gEt6fzNvIrN Z+GQ== X-Gm-Message-State: AIVw111qyNmt+/ziZtE8YJz4jCFeuWM5ej4F75lMsiRV2JQryREEgPgj P1Luiye5o5VcHOnfET3dzSSBK/z/nxEM X-Received: by 10.200.43.58 with SMTP id 55mr199766qtu.202.1500360121757; Mon, 17 Jul 2017 23:42:01 -0700 (PDT) MIME-Version: 1.0 References: <150025655295.32691.13544492065984079858.idtracker@ietfa.amsl.com> <22892.32000.730535.635648@gro.dd.org> In-Reply-To: <22892.32000.730535.635648@gro.dd.org> From: Lanlan Pan Date: Tue, 18 Jul 2017 06:41:51 +0000 Message-ID: To: Dave Lawrence Cc: dnsop Content-Type: multipart/alternative; boundary="001a11c13b4417b484055491d0b8" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 06:42:04 -0000 --001a11c13b4417b484055491d0b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for your feedback, :-) Dave Lawrence =E4=BA=8E2017=E5=B9=B47=E6=9C=8817=E6=97=A5=E5= =91=A8=E4=B8=80 =E4=B8=8B=E5=8D=885:01=E5=86=99=E9=81=93=EF=BC=9A > Have you had any feedback from authority server implementers who are > interested in using this? > We plan to contact authoritative server implementers and public recursive implementers, for further realistic using, welcome cooperation. I'm having a hard time picturing many CDNs wanting to switch, in no > small part because geo is not the only goal of mapping. The > < COUNTRY, AREA, ISP > tuple that is defined is insufficient. > Not "switch to", but we can try to add *an alternative solution* for GeoIP-enabled Authoritative Nameserver *with user privacy concern*. CDN can do all analysis based on client ip *without ECS and EIL*, because it is data provider, every client will visit. The < COUNTRY, AREA, ISP > tuple *can be sufficient for GeoIP-enabled Authoritative Nameserver*, because the Authoritative Nameserver map client ip into geolocation, and then return the tailored response based on geolocation, such as Appendix A. GeoIP-enabled Nameservers Example . More details in Section 1.1 Path Calculation and Tailored DNS Response . --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a11c13b4417b484055491d0b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thanks for your feedback, :-)<= br>

Dave Lawrence = <tale@dd.org>=E4=BA=8E2017=E5=B9= =B47=E6=9C=8817=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=885:01=E5=86=99= =E9=81=93=EF=BC=9A
Have you had any= feedback from authority server implementers who are
interested in using this?
We plan to contact authorita= tive server implementers and public recursive implementers, for further rea= listic using, welcome cooperation.

I'm having a hard time picturing many CDNs wanting to switch, in no
small part because geo is not the only goal of mapping.=C2=A0 The
< COUNTRY, AREA, ISP > tuple that is defined is insufficient.
Not "switch to", but we can try to add an altern= ative solution for GeoIP-enabled Authoritative Nameserver=C2=A0 with= user privacy concern.
CDN can do all analysis based on c= lient ip without ECS and EIL, because it is data provider, every cli= ent will visit.

The < COUNTRY, AREA, ISP > tuple can be sufficient for GeoIP-enabled A= uthoritative Nameserver, because the Authoritative Nameserver map clien= t ip into geolocation, and then return the tailored response based on geolo= cation, such as=C2=A0 Appendix A. GeoIP-enabled Nameservers Ex= ample.
--
=E8=87= =B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pa= n Lanlan
--001a11c13b4417b484055491d0b8-- From nobody Tue Jul 18 02:47:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE4A131DD1 for ; Tue, 18 Jul 2017 02:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_SOFTFAIL=0.665] autolearn=no 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 Ky4ff3JLMGfu for ; Tue, 18 Jul 2017 02:47:00 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 644DC131A93 for ; Tue, 18 Jul 2017 02:47:00 -0700 (PDT) Received: from jurassic (unknown [115.118.30.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 39B8856A04AF; Tue, 18 Jul 2017 09:46:57 +0000 (GMT) Date: Tue, 18 Jul 2017 15:16:54 +0530 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20170718094654.GA31988@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:47:01 -0000 Hi all There are still many popular unsigned zones, many of which don't look like they will be signed soon due to operational and other reasons. Will you give some thought and reply with your opinion on NSEC/NSEC3 for unsigned zones requiring the DNS COOKIE option in transmission, that can be used with draft-ietf-dnsop-nsec-aggressiveuse? Mukund From nobody Tue Jul 18 04:34:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E504D131838 for ; Tue, 18 Jul 2017 04:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 vLGjwKRZGeZH for ; Tue, 18 Jul 2017 04:34:30 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C05E131B06 for ; Tue, 18 Jul 2017 04:34:30 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6IBHwLn047420; Tue, 18 Jul 2017 13:17:58 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707181117.v6IBHwLn047420@givry.fdupont.fr> From: Francis Dupont To: Mukund Sivaraman cc: dnsop@ietf.org In-reply-to: Your message of Tue, 18 Jul 2017 15:16:54 +0530. <20170718094654.GA31988@jurassic> Date: Tue, 18 Jul 2017 13:17:58 +0200 Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:34:32 -0000 In your previous mail you wrote: > There are still many popular unsigned zones, many of which don't look > like they will be signed soon due to operational and other reasons. > > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > unsigned zones requiring the DNS COOKIE option in transmission, that can > be used with draft-ietf-dnsop-nsec-aggressiveuse? => I can't parse your message: - unsigned zones have no zone keys - DNS cookie was designed to give a return routability proof for the client, not the server - there is no NSEC/NSEC3 in an unsigned zone Perhaps you mean to return a synthesized NSEC/NSEC3 and the DNS COOKIE is as usual required to avoid amplification DoS. But what will be the signing key (including on the client side) and what to put in the NSEC/NSEC3? Perhaps this applies only to authoritative servers of the (unsigned) zone? It seems easier to remember that DNSSEC offers proofs for denial of existence. Regards Francis.Dupont@fdupont.fr From nobody Tue Jul 18 04:41:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CBE131DF8 for ; Tue, 18 Jul 2017 04:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 bT8G3d1uf3GG for ; Tue, 18 Jul 2017 04:41:44 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A01A9131DF4 for ; Tue, 18 Jul 2017 04:41:42 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:48564) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXQsk-000IFY-fC (Exim 4.89) (return-path ); Tue, 18 Jul 2017 12:41:38 +0100 Date: Tue, 18 Jul 2017 12:41:38 +0100 From: Tony Finch To: Francis Dupont cc: Mukund Sivaraman , dnsop@ietf.org In-Reply-To: <201707181117.v6IBHwLn047420@givry.fdupont.fr> Message-ID: References: <201707181117.v6IBHwLn047420@givry.fdupont.fr> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:41:46 -0000 Francis Dupont wrote: > It seems easier to remember that DNSSEC offers proofs for denial of existence. Yes. Surely we don't want to make the DNS even more complicated just to undemine one of the positive features of DNSSEC. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Southeasterly 5 to 7, occasionally gale 8 in west. Moderate becoming rough, occasionally very rough for a time in west. Rain later. Good, occasionally poor later. From nobody Tue Jul 18 04:44:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67320131DF7 for ; Tue, 18 Jul 2017 04:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 2r7Z7UG2gA41 for ; Tue, 18 Jul 2017 04:44:49 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2873B131DE7 for ; Tue, 18 Jul 2017 04:44:49 -0700 (PDT) Received: from dhcp-8e9b.meeting.ietf.org (dhcp-8e9b.meeting.ietf.org [31.133.142.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 6C5FD2421527; Tue, 18 Jul 2017 11:44:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <201707181117.v6IBHwLn047420@givry.fdupont.fr> Date: Tue, 18 Jul 2017 12:44:46 +0100 Cc: Mukund Sivaraman , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6F247E60-3FBE-4BC4-8E7C-27C042AF7CC5@rfc1035.com> References: <201707181117.v6IBHwLn047420@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:44:50 -0000 > On 18 Jul 2017, at 12:17, Francis Dupont = wrote: >=20 > It seems easier to remember that DNSSEC offers proofs for denial of = existence. Except when it doesn't. :-) RFC5155 includes opt-in. From nobody Tue Jul 18 04:57:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2262F1288B8 for ; Tue, 18 Jul 2017 04:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_SOFTFAIL=0.665] autolearn=no 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 Vx3aFfERLevf for ; Tue, 18 Jul 2017 04:57:45 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id E914512785F for ; Tue, 18 Jul 2017 04:57:44 -0700 (PDT) Received: from jurassic (unknown [115.118.30.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 9E0B056A04AF; Tue, 18 Jul 2017 11:57:42 +0000 (GMT) Date: Tue, 18 Jul 2017 17:27:39 +0530 From: Mukund Sivaraman To: Francis Dupont Cc: dnsop@ietf.org Message-ID: <20170718115739.GA32524@jurassic> References: <20170718094654.GA31988@jurassic> <201707181117.v6IBHwLn047420@givry.fdupont.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201707181117.v6IBHwLn047420@givry.fdupont.fr> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:57:46 -0000 Hi Francis On Tue, Jul 18, 2017 at 01:17:58PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > > There are still many popular unsigned zones, many of which don't look > > like they will be signed soon due to operational and other reasons. > > > > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > > unsigned zones requiring the DNS COOKIE option in transmission, that can > > be used with draft-ietf-dnsop-nsec-aggressiveuse? > > => I can't parse your message: > - unsigned zones have no zone keys NSEC needs no keys, only their RRSIGs would which wouldn't exist in unsigned zones. In this case the unsigned NSEC would also not be part of the zone (it would have to be synthesized and maintained outside the zone). > - DNS cookie was designed to give a return routability proof for the client, > not the server > - there is no NSEC/NSEC3 in an unsigned zone > Perhaps you mean to return a synthesized NSEC/NSEC3 and the DNS COOKIE is > as usual required to avoid amplification DoS. This was discussed during the ISC 2017 all-hands; I don't remember if you were in the meeting when we discussed it (I think the meeting topic was about DoS mitigation measures). Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix entire zones, when it was discussed, Mark Andrews suggested that requiring DNS COOKIE to further reduce the chance of cache poisoning (more than source port randomization and random message ID) could be a reasonable idea to think about. > But what will be the signing key (including on the client side) and > what to put in the NSEC/NSEC3? Perhaps this applies only to authoritative > servers of the (unsigned) zone? > It seems easier to remember that DNSSEC offers proofs for denial of existence. Mukund From nobody Tue Jul 18 05:14:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE69131DF4 for ; Tue, 18 Jul 2017 05:14:09 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S3QNYIjVwRgi for ; Tue, 18 Jul 2017 05:14:08 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 2978C131B31 for ; Tue, 18 Jul 2017 05:13:58 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id a10so26843668wrd.0 for ; Tue, 18 Jul 2017 05:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=88wm0EyWOlaSpW7xAy+foDS6Asxq3lrkbXab34ZhgIE=; b=cYs2iOqKsiHNKqR1eXUau6qYrr3sTSQXZpBwRNirLP8tfIfSYbx7xfPA4Wm/NfKIsV wh0PfSFgb8whuWksIR53iB3ixsHpMq2XCAD8hM7A448gbx7nJg8EwTJ+6HeRnyUTzr2h 82MqGfCtCmVKuooeAnp+XTg0VV/Q58TCuJqwmkGj7SdvSBqRSs+XFxy4qV4QHRMEbWEi Ln86Ayyz7LxQtqWdgrOh8O2yf15JmlhBC79HBvnTxH5ZYP4v53fdZqUXFLVv0nOhvk78 nl2xchyS660VvQqrCzpKNvcoiBkwjUn1JiQO7cxhPbHCQ2nTXQj06c8TDLu6le4yF7/D DNYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=88wm0EyWOlaSpW7xAy+foDS6Asxq3lrkbXab34ZhgIE=; b=Bh/uoMAp3dmraEyN3WwFuAkXe7h9BotYHQx5x0Fv6A9SQ6dRE6z3ctA2IYoHyP2N16 gPw5MCzqsXd3jK7JCg7gZmooERoVw4Ui2KI+LX/WZKNhRKCaytS16LXo6wWom5Csa8Hu 15Y6ZwjxG2SoITqM0ZAXCdxo3j8F4UL8VA9gJUBSx1N9w09T+c3fGnjnJ4ho8RM15Phg jxKcxamjiLdYWZ8Ej73wNx3LOadl8iVHGX3D7/PZD54u/asAtXpxG1Xf+ZyB0MVwJtKA SgTecKTS79F32wAxgdzrLrhnfuo8kVUw64AzkmosQ2eQRvhdSd78fypKQDBdQkPDoHur hq7A== X-Gm-Message-State: AIVw111TObeIOGZgoeZBmswCzp96/RERKdIFuOj6GGMnJuGURgQ3EKUB D92z1EUFS27oueGcUl4= X-Received: by 10.28.136.147 with SMTP id k141mr2011296wmd.14.1500380036321; Tue, 18 Jul 2017 05:13:56 -0700 (PDT) Received: from dhcp-8904.meeting.ietf.org (dhcp-8904.meeting.ietf.org. [31.133.137.4]) by smtp.gmail.com with ESMTPSA id p13sm3739854wma.8.2017.07.18.05.13.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:13:55 -0700 (PDT) To: dnsop@ietf.org From: Suzanne Woolf Message-ID: Date: Tue, 18 Jul 2017 08:13:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F195C6DEAA8682EA3DCC406D" Archived-At: Subject: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:14:10 -0000 This is a multi-part message in MIME format. --------------F195C6DEAA8682EA3DCC406D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear colleagues, As you might recall, we had a call for adoption for draft-vixie-dns-rpz just before IETF 98 in March. We had a lively discussion and decided to adopt the document for further work in the WG as an Informational RFC. However, the chairs then discovered we’d made a mistake in adopting the draft with the copyright that reserved rights in derivative works to the original authors. This isn’t allowed for a Working Group document (see RFC5378, Section 3.3). We’ve talked since then with the authors about how we might move forward with the draft. They had concerns, which had already been discussed on the list, about some of the views of the WG on the applicability of RPZ. We believe we’ve found a way forward that meets their concerns and the needs of the WG. We propose that: 1. The draft adopts the following language in the Introduction: This document describes an existing and widely deployed method by which a security policy can be applied to DNS responses, possibly causing an end system to receive responses that do not correspond to actual DNS zone content. Such policy-based responses might prevent access to selected HTTP servers, or redirect users to "walled gardens", or block objectionable email, or otherwise defend against DNS content deemed malicious by the RDNS operator and the end-user. This method describes its policy using a specially formatted DNS Zone called a Response Policy Zone (RPZ), and is an instance of a more general mechanism called a "DNS Firewall." Like other mechanisms called "firewalls," response policy zones (RPZ) can be used to block both wanted as well as unwanted data. RPZ ought not be used to interfere with data desired by recipients. In other words, RPZ should be deployed only with the permission of every affected RDNS end-users. This document does not recommend the use of RPZ in any particular situation or instead of other mechanisms including those more commonly called "firewalls." This document lacks an applicability statement for that reason, and because it merely describes a currently common practice, without recommending or criticising that practice. By design and expectation, response policy zones (RPZ) must be seen as a defensive and virtuous tool, or it will either not be used, or will be bypassed by end-users. 2. We had already limited the the scope of the document to describing the current protocol, with any discussion of proposed changes left to a later document if people want to do that work. That limitation stands. The intended document status is Informational. 3. The copyright is changed to the standard boilerplate required for a WG draft. If this is acceptable to the WG, we’ll keep the new draft with these changes as a WG draft. If not, the draft will be dropped as a WG item. The authors can seek publication of the document as an independent submission or outside of the RFC series. If you have a comment on this, please make it succinctly and soon. thanks, Suzanne & TIm --------------F195C6DEAA8682EA3DCC406D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear colleagues,


As you might recall, we had a call for adoption for draft-vixie-dns-rpz just before IETF 98 in March. We had a lively discussion and decided to adopt the document for further work in the WG as an Informational RFC.

However, the chairs then discovered we’d made a mistake in adopting the draft with the copyright that reserved rights in derivative works to the original authors. This isn’t allowed for a Working Group document (see RFC5378, Section 3.3).

We’ve talked since then with the authors about how we might move forward with the draft. They had concerns, which had already been discussed on the list, about some of the views of the WG on the applicability of RPZ.

We believe we’ve found a way forward that meets their concerns and the needs of the WG. We propose that:

1. The draft adopts the following language in the Introduction:

This document describes an existing and widely deployed method by which a security policy can be applied to DNS responses, possibly causing an end system to receive responses that do not correspond to actual DNS zone content. Such policy-based responses might prevent access to selected HTTP servers, or redirect users to "walled gardens", or block objectionable email, or otherwise defend against DNS content deemed malicious by the RDNS operator and the end-user.

This method describes its policy using a specially formatted DNS Zone called a Response Policy Zone (RPZ), and is an instance of a more general mechanism called a "DNS Firewall." Like other mechanisms called "firewalls," response policy zones (RPZ) can be used to block both wanted as well as unwanted data.  RPZ ought not be used to interfere with data desired by recipients. In other words, RPZ should be deployed only with the permission of every affected RDNS end-users.

This document does not recommend the use of RPZ in any particular situation or instead of other mechanisms including those more commonly called "firewalls."  This document lacks an applicability statement for that reason, and because it merely describes a currently common practice, without recommending or criticising that practice. By design and expectation, response policy zones (RPZ) must be seen as a defensive and virtuous tool, or it will either not be used, or will be bypassed by end-users.

2. We had already limited the the scope of the document to describing the current protocol, with any discussion of proposed changes left to a later document if people want to do that work. That limitation stands. The intended document status is Informational.

3. The copyright is changed to the standard boilerplate required for a WG draft.


If this is acceptable to the WG, we’ll keep the new draft with these changes as a WG draft. 

If not, the draft will be dropped as a WG item. The authors can seek publication of the document as an independent submission or outside of the RFC series.

If you have a comment on this, please make it succinctly and soon.


thanks,
Suzanne & TIm
--------------F195C6DEAA8682EA3DCC406D-- From nobody Tue Jul 18 05:31:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADA6131948 for ; Tue, 18 Jul 2017 05:30:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 e-II0XJXPSeA for ; Tue, 18 Jul 2017 05:30:56 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 48218131748 for ; Tue, 18 Jul 2017 05:30:56 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id e199so10833282pfh.2 for ; Tue, 18 Jul 2017 05:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PRvyHTt2DBf16muBUJVBLOAwHEHZywwjiCJsX1EzDbQ=; b=tibd4x/S7JgSdjv68ouGA9gpHzRC0CliicoWSWRjFXLNOBeJ1lFj+Jq4Ev7/P4lRiy fcMDxSpXsjdFv76WGelkyn5zjVs9cb8aP/KMjJU0eQEAXMcPDUNLBnAyMth0ccPVSGLM unfm0kSTAL8suQYpfTSG1Ui/V23h5E1xL4kMeZ0YcDGvlFsPXdJzSO3Cizdu4KGJHC2z oeNhYKvVytCUweP9hpTu/U22uGpZNEgIAm9RFP/1AXOVAcU9sFW1WGduzDetEKmF44vk tPiH4H8tqFAhVZgeR63v23JJfLPQystm6rasrVG8N5LkUih6wPBiPnIwF3N6+2cWNNmy FQoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PRvyHTt2DBf16muBUJVBLOAwHEHZywwjiCJsX1EzDbQ=; b=obUfo+th3Tvc+E7yspmfualpFQzR+BqEN4H6ELh0dNCTSzsBprmncrt9EBbaIvy3EJ C+xggQ4ifYzHLV0P395fpiW4XXH7xZYzi3+iXtAYUfQP1qWMIPY1BUj0wsyHiGVr4W7e s0FrjE1SO84A5mm8y9qt+3xeLE2jtfXjRQR5YZGSwwcg6Y2OAP+d35HxHqSSPUbc1718 mbZPQDIZ4LWmGS5ZGOFSoRar8t4dNCrmGPgR9FppuwfDrVPuO3npjmvtSIxgMPaXepvD WmolU2TfKYq+u8Nk8mY5RSxzHkeiRQQn7I65RXVHws2D/lNQFn9XZ1fQAY6KGphxtYKI 7kXw== X-Gm-Message-State: AIVw1122BNaFyF9c5nWslWye1dNC3RSXsxEycEjbXG8x5YhELHKkq1Y4 +yX58GxEbMCNSaJibowqfMziPhRbrD2h X-Received: by 10.84.231.16 with SMTP id f16mr1483983plk.131.1500381055682; Tue, 18 Jul 2017 05:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 05:30:15 -0700 (PDT) In-Reply-To: References: From: Ted Lemon Date: Tue, 18 Jul 2017 14:30:15 +0200 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="f40304360182da2092055496af8a" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:30:59 -0000 --f40304360182da2092055496af8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the working group doesn't get to work on it, it seems more appropriate to publish it as an ISE document. This is what has been done in similar cases in the past. On Tue, Jul 18, 2017 at 2:13 PM, Suzanne Woolf wrote: > Dear colleagues, > > As you might recall, we had a call for adoption for draft-vixie-dns-rpz > just before IETF 98 in March. We had a lively discussion and decided to > adopt the document for further work in the WG as an Informational RFC. > > However, the chairs then discovered we=E2=80=99d made a mistake in adopti= ng the > draft with the copyright that reserved rights in derivative works to the > original authors. This isn=E2=80=99t allowed for a Working Group document= (see > RFC5378, Section 3.3). > > We=E2=80=99ve talked since then with the authors about how we might move = forward > with the draft. They had concerns, which had already been discussed on th= e > list, about some of the views of the WG on the applicability of RPZ. > > We believe we=E2=80=99ve found a way forward that meets their concerns an= d the > needs of the WG. We propose that: > > 1. The draft adopts the following language in the Introduction: > > This document describes an existing and widely deployed method by which a > security policy can be applied to DNS responses, possibly causing an end > system to receive responses that do not correspond to actual DNS zone > content. Such policy-based responses might prevent access to selected HTT= P > servers, or redirect users to "walled gardens", or block objectionable > email, or otherwise defend against DNS content deemed malicious by the RD= NS > operator and the end-user. > > This method describes its policy using a specially formatted DNS Zone > called a Response Policy Zone (RPZ), and is an instance of a more general > mechanism called a "DNS Firewall." Like other mechanisms called > "firewalls," response policy zones (RPZ) can be used to block both wanted > as well as unwanted data. RPZ ought not be used to interfere with data > desired by recipients. In other words, RPZ should be deployed only with t= he > permission of every affected RDNS end-users. > > This document does not recommend the use of RPZ in any particular > situation or instead of other mechanisms including those more commonly > called "firewalls." This document lacks an applicability statement for > that reason, and because it merely describes a currently common practice, > without recommending or criticising that practice. By design and > expectation, response policy zones (RPZ) must be seen as a defensive and > virtuous tool, or it will either not be used, or will be bypassed by > end-users. > > > 2. We had already limited the the scope of the document to describing the > current protocol, with any discussion of proposed changes left to a later > document if people want to do that work. That limitation stands. The > intended document status is Informational. > > 3. The copyright is changed to the standard boilerplate required for a WG > draft. > > > If this is acceptable to the WG, we=E2=80=99ll keep the new draft with th= ese > changes as a WG draft. > > If not, the draft will be dropped as a WG item. The authors can seek > publication of the document as an independent submission or outside of th= e > RFC series. > > If you have a comment on this, please make it succinctly and soon. > > > thanks, > Suzanne & TIm > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --f40304360182da2092055496af8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the working group doesn't get to work on it, it see= ms more appropriate to publish it as an ISE document. =C2=A0 This is what h= as been done in similar cases in the past.
=
On Tue, Jul 18, 2017 at 2:13 PM, Suzanne Woo= lf <suzworldwide@gmail.com> wrote:
=20 =20 =20

Dear colleagues,


As you might recall, we had a call for adoption for=C2=A0draft-vixie-dns-rpz just before IETF 98 in March. We had a lively discussion and decided to adopt the document for further work in the WG as an Informational RFC.

However, the chairs then discovered we=E2=80=99d made a mistake in adopting the draft with the copyright that reserved rights in derivative works to the original authors. This isn=E2=80=99= t allowed for a Working Group document (see RFC5378, Section 3.3).

We=E2=80=99ve talked since then with the authors about how we might move forward with the draft. They had concerns, which had already been discussed on the list, about some of the views of the WG on the applicability of RPZ.

We believe we=E2=80=99ve found a way forward that meets their concerns and the needs of the WG. We propose that:

1. The draft adopts the following language in the Introduction:

This document describes an existing and widely deployed method by which a security policy can be applied to DNS responses, possibly causing an end system to receive responses that do not correspond to actual DNS zone content. Such policy-based responses might prevent access to selected HTTP servers, or redirect users to "walled gardens", or= block objectionable email, or otherwise defend against DNS content deemed malicious by the RDNS operator and the end-user.

This method describes its policy using a specially formatted DNS Zone called a Response Policy Zone (RPZ), and is an instance of a more general mechanism called a "DNS Firewall." Like other mechanisms called "firewalls,&quo= t; response policy zones (RPZ) can be used to block both wanted as well as unwanted data.=C2=A0 RPZ ought not be used to interfere with data desired by recipients. In other words, RPZ should be deployed only with the permission of every affected RDNS end-users.

This document does not recommend the use of RPZ in any particular situation or instead of other mechanisms including those more commonly called "firewalls." =C2= =A0This document lacks an applicability statement for that reason, and because it merely describes a currently common practice, without recommending or criticising that practice. By design and expectation, response policy zones (RPZ) must be seen as a defensive and virtuous tool, or it will either not be used, or will be bypassed by end-users.

2. We had already limited the the scope of the document to describing the current protocol, with any discussion of proposed changes left to a later document if people want to do that work. That limitation stands. The intended document status is Informational.

3. The copyright is changed to the standard boilerplate required for a WG draft.


If this is acceptable to the WG, we=E2=80=99ll keep the new draft with these changes as a WG draft.=C2=A0

If not, the draft will be dropped as a WG item. The authors can seek publication of the document as an independent submission or outside of the RFC series.

If you have a comment on this, please make it succinctly and soon.


thanks,
Suzanne & TIm

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--f40304360182da2092055496af8a-- From nobody Tue Jul 18 05:32:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59308131DE3 for ; Tue, 18 Jul 2017 05:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 I9bk7GkmKnuU for ; Tue, 18 Jul 2017 05:32:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 29E1D131748 for ; Tue, 18 Jul 2017 05:32:38 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5] (unknown [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5]) by mail.nic.cz (Postfix) with ESMTPSA id 73C106226E for ; Tue, 18 Jul 2017 14:32:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500381156; bh=ui+OD3uvk4wTpsCS/s9lc6EY34fOuHuGIXZecqu6uT4=; h=To:From:Date; b=bmU2Foisn9xlgsOj9V366M984BvIx76VR84Jau3wp3CXgoxutnPbzVC20vMhaTAE7 mXCNDxakZxRSr5JRYT6/UD4TnfC4IOxR0R81XloEF1ETdYyUovR2FUyO/lHg6lTKCL Xjha8wep+6K1IcW/wdvfsdzEQI+SUI49OBanPxlg= To: dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <927b199d-ff76-b0da-0297-2d6869af8ed2@nic.cz> Date: Tue, 18 Jul 2017 14:32:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:32:40 -0000 On 18.7.2017 14:13, Suzanne Woolf wrote: > Dear colleagues, > > > As you might recall, we had a call for adoption for draft-vixie-dns-rpz > just before IETF 98 in March. We had a lively discussion and decided to > adopt the document for further work in the WG as an Informational RFC. > > However, the chairs then discovered we’d made a mistake in adopting the > draft with the copyright that reserved rights in derivative works to the > original authors. This isn’t allowed for a Working Group document (see > RFC5378, Section 3.3). > > We’ve talked since then with the authors about how we might move forward > with the draft. They had concerns, which had already been discussed on > the list, about some of the views of the WG on the applicability of RPZ. > > We believe we’ve found a way forward that meets their concerns and the > needs of the WG. We propose that: > > 1. The draft adopts the following language in the Introduction: > > This document describes an existing and widely deployed method by > which a security policy can be applied to DNS responses, possibly > causing an end system to receive responses that do not correspond to > actual DNS zone content. Such policy-based responses might prevent > access to selected HTTP servers, or redirect users to "walled > gardens", or block objectionable email, or otherwise defend against > DNS content deemed malicious by the RDNS operator and the end-user. > > This method describes its policy using a specially formatted DNS > Zone called a Response Policy Zone (RPZ), and is an instance of a > more general mechanism called a "DNS Firewall." Like other > mechanisms called "firewalls," response policy zones (RPZ) can be > used to block both wanted as well as unwanted data. RPZ ought not > be used to interfere with data desired by recipients. In other > words, RPZ should be deployed only with the permission of every > affected RDNS end-users. > > This document does not recommend the use of RPZ in any particular > situation or instead of other mechanisms including those more > commonly called "firewalls." This document lacks an applicability > statement for that reason, and because it merely describes a > currently common practice, without recommending or criticising that > practice. By design and expectation, response policy zones (RPZ) > must be seen as a defensive and virtuous tool, or it will either not > be used, or will be bypassed by end-users. > > > 2. We had already limited the the scope of the document to describing > the current protocol, with any discussion of proposed changes left to a > later document if people want to do that work. That limitation stands. > The intended document status is Informational. > > 3. The copyright is changed to the standard boilerplate required for a > WG draft. > > > If this is acceptable to the WG, we’ll keep the new draft with these > changes as a WG draft. > > If not, the draft will be dropped as a WG item. The authors can seek > publication of the document as an independent submission or outside of > the RFC series. > > If you have a comment on this, please make it succinctly and soon. I'm fine with Informational document describing the existing version of RPZ. My hope that working on that as WG item will help to improve the text so it is unambiguous. Improvements to the protocol can be done later on. -- Petr Špaček @ CZ.NIC From nobody Tue Jul 18 05:35:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430B1131DFC for ; Tue, 18 Jul 2017 05:35:37 -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] 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 6f0pLiSogMKI for ; Tue, 18 Jul 2017 05:35:36 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 43778131DB2 for ; Tue, 18 Jul 2017 05:35:36 -0700 (PDT) Received: from [10.47.60.34] (dhcp-9976.meeting.ietf.org [31.133.153.118]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6ICYj3v016187 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Jul 2017 05:34:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host dhcp-9976.meeting.ietf.org [31.133.153.118] claimed to be [10.47.60.34] From: "Paul Hoffman" To: "Mukund Sivaraman" Cc: dnsop@ietf.org Date: Tue, 18 Jul 2017 14:35:31 +0200 Message-ID: <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> In-Reply-To: <20170718094654.GA31988@jurassic> References: <20170718094654.GA31988@jurassic> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:35:37 -0000 On 18 Jul 2017, at 11:46, Mukund Sivaraman wrote: > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > unsigned zones requiring the DNS COOKIE option in transmission, that can > be used with draft-ietf-dnsop-nsec-aggressiveuse? Of what value is the result? Is it worth the hassle for the zone admin? --Paul Hoffman From nobody Tue Jul 18 05:35:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F45131E0B for ; Tue, 18 Jul 2017 05:35:58 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aZ9yk-14TqEY for ; Tue, 18 Jul 2017 05:35:56 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 A9167131DE8 for ; Tue, 18 Jul 2017 05:35:55 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id w4so26898536wrb.2 for ; Tue, 18 Jul 2017 05:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=zaUL86XZRIqc5KAEh3ylJz4N+xjemza6FRoHd2/D/ew=; b=WVPU9do5cIP8Yy8JJl06UyGWC6TO8oqreJXsW4fJm5emPGLBs00ii6GO3nx+2i7FVf 4n6FPZ1J4GHP6NjzWZiP8yBNPfsiyv81JaIqEA3bg6sWnrikdQY+t8wKtVSzSp+SkP3Q Px+CPqzQ+4muIUy4DBEyp6Wd9XNd9xXDb5pmu1sS0bQE+DMa+XIKCR/W20DaMNekbsbT aLOEjAr8YrIAeC9OkY/HIyTdVks4++N36xwTiVFae1LvB8zvfQPHjPIpdkfFDTLR+38d 8tQvVMjYA2hUvaXZ4Hlxrw9oGLxOeChpwA6BUHci/WoNRbGvyeTA08XMF9tLfokOyPUj a1Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=zaUL86XZRIqc5KAEh3ylJz4N+xjemza6FRoHd2/D/ew=; b=nJDSB1pOeyDyDKJKUYvbcX5zeS//cwVcgAq7/TpWzLHZeZ48STf8D4724ILJZnD/6D 7QiJ/zGI3A72A5Jk22hsNYd7pb+djMosUNOwoFmcHXypzu/+5N/qomOywM+7JDy6E1u6 rvNMclaKvT3s4i4hwFuNDq5uqwfCVKCj9i4bgCxx3OV0AuIymdb7OjhrHyGX5qJ/CbFB HpLypRFK9XlgpbDNdY5t/4Xou9SMbkwEnAZvvH3gWKBf4ywIMjAz0wMYp4sn3QnwIkPO dk0XIpuWbrEQ1RTK9QV4YNSC1jCd82vc9w/AnoWj8ETV4UP4r+q5rMLQK0GtpoQXJ8TZ baAw== X-Gm-Message-State: AIVw113PQk2jisAMVIu3OBAM4fMJtWneaqgIFhba4PHJ9Bp29xAU8x8i A+OTjwxTBbpkzekkFzo= X-Received: by 10.28.130.132 with SMTP id e126mr1653244wmd.107.1500381353577; Tue, 18 Jul 2017 05:35:53 -0700 (PDT) Received: from dhcp-8904.meeting.ietf.org ([2001:67c:370:128:2c3e:2bed:84a7:da01]) by smtp.gmail.com with ESMTPSA id i136sm13128809wmf.33.2017.07.18.05.35.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:35:52 -0700 (PDT) To: dnsop@ietf.org References: From: Suzanne Woolf Message-ID: Date: Tue, 18 Jul 2017 08:35:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1A78F7133EE5704309F9785B" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:35:58 -0000 This is a multi-part message in MIME format. --------------1A78F7133EE5704309F9785B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, The working group does get to work on it. The specific suggested wording was about the scope of the document, which the chairs felt was consistent with what the WG had already decided about the document: that they were willing to work on it as an Informational description of the existing protocol. This is why the original boilerplate wasn't acceptable for a WG document, and the authors have agreed to change it in order for it to be kept as a WG document. Suzanne On 7/18/17 8:30 AM, Ted Lemon wrote: > If the working group doesn't get to work on it, it seems more > appropriate to publish it as an ISE document. This is what has been > done in similar cases in the past. > > On Tue, Jul 18, 2017 at 2:13 PM, Suzanne Woolf > wrote: > > Dear colleagues, > > > As you might recall, we had a call for adoption > for draft-vixie-dns-rpz just before IETF 98 in March. We had a > lively discussion and decided to adopt the document for further > work in the WG as an Informational RFC. > > However, the chairs then discovered wed made a mistake in > adopting the draft with the copyright that reserved rights in > derivative works to the original authors. This isnt allowed for a > Working Group document (see RFC5378, Section 3.3). > > Weve talked since then with the authors about how we might move > forward with the draft. They had concerns, which had already been > discussed on the list, about some of the views of the WG on the > applicability of RPZ. > > We believe weve found a way forward that meets their concerns and > the needs of the WG. We propose that: > > 1. The draft adopts the following language in the Introduction: > > This document describes an existing and widely deployed method > by which a security policy can be applied to DNS responses, > possibly causing an end system to receive responses that do > not correspond to actual DNS zone content. Such policy-based > responses might prevent access to selected HTTP servers, or > redirect users to "walled gardens", or block objectionable > email, or otherwise defend against DNS content deemed > malicious by the RDNS operator and the end-user. > > This method describes its policy using a specially formatted > DNS Zone called a Response Policy Zone (RPZ), and is an > instance of a more general mechanism called a "DNS Firewall." > Like other mechanisms called "firewalls," response policy > zones (RPZ) can be used to block both wanted as well as > unwanted data. RPZ ought not be used to interfere with data > desired by recipients. In other words, RPZ should be deployed > only with the permission of every affected RDNS end-users. > > This document does not recommend the use of RPZ in any > particular situation or instead of other mechanisms including > those more commonly called "firewalls." This document lacks > an applicability statement for that reason, and because it > merely describes a currently common practice, without > recommending or criticising that practice. By design and > expectation, response policy zones (RPZ) must be seen as a > defensive and virtuous tool, or it will either not be used, or > will be bypassed by end-users. > > > 2. We had already limited the the scope of the document to > describing the current protocol, with any discussion of proposed > changes left to a later document if people want to do that work. > That limitation stands. The intended document status is Informational. > > 3. The copyright is changed to the standard boilerplate required > for a WG draft. > > > If this is acceptable to the WG, well keep the new draft with > these changes as a WG draft. > > If not, the draft will be dropped as a WG item. The authors can > seek publication of the document as an independent submission or > outside of the RFC series. > > If you have a comment on this, please make it succinctly and soon. > > > thanks, > Suzanne & TIm > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --------------1A78F7133EE5704309F9785B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi,

The working group does get to work on it. The specific suggested wording was about the scope of the document, which the chairs felt was consistent with what the WG had already decided about the document: that they were willing to work on it as an Informational description of the existing protocol.


This is why the original boilerplate wasn't acceptable for a WG document, and the authors have agreed to change it in order for it to be kept as a WG document.


Suzanne


On 7/18/17 8:30 AM, Ted Lemon wrote:
If the working group doesn't get to work on it, it seems more appropriate to publish it as an ISE document. This is what has been done in similar cases in the past.

On Tue, Jul 18, 2017 at 2:13 PM, Suzanne Woolf <suzworldwide@gmail.com> wrote:

Dear colleagues,


As you might recall, we had a call for adoption fordraft-vixie-dns-rpz just before IETF 98 in March. We had a lively discussion and decided to adopt the document for further work in the WG as an Informational RFC.

However, the chairs then discovered wed made a mistake in adopting the draft with the copyright that reserved rights in derivative works to the original authors. This isnt allowed for a Working Group document (see RFC5378, Section 3.3).

Weve talked since then with the authors about how we might move forward with the draft. They had concerns, which had already been discussed on the list, about some of the views of the WG on the applicability of RPZ.

We believe weve found a way forward that meets their concerns and the needs of the WG. We propose that:

1. The draft adopts the following language in the Introduction:

This document describes an existing and widely deployed method by which a security policy can be applied to DNS responses, possibly causing an end system to receive responses that do not correspond to actual DNS zone content. Such policy-based responses might prevent access to selected HTTP servers, or redirect users to "walled gardens", or block objectionable email, or otherwise defend against DNS content deemed malicious by the RDNS operator and the end-user.

This method describes its policy using a specially formatted DNS Zone called a Response Policy Zone (RPZ), and is an instance of a more general mechanism called a "DNS Firewall." Like other mechanisms called "firewalls," response policy zones (RPZ) can be used to block both wanted as well as unwanted data. RPZ ought not be used to interfere with data desired by recipients. In other words, RPZ should be deployed only with the permission of every affected RDNS end-users.

This document does not recommend the use of RPZ in any particular situation or instead of other mechanisms including those more commonly called "firewalls." This document lacks an applicability statement for that reason, and because it merely describes a currently common practice, without recommending or criticising that practice. By design and expectation, response policy zones (RPZ) must be seen as a defensive and virtuous tool, or it will either not be used, or will be bypassed by end-users.

2. We had already limited the the scope of the document to describing the current protocol, with any discussion of proposed changes left to a later document if people want to do that work. That limitation stands. The intended document status is Informational.

3. The copyright is changed to the standard boilerplate required for a WG draft.


If this is acceptable to the WG, well keep the new draft with these changes as a WG draft.

If not, the draft will be dropped as a WG item. The authors can seek publication of the document as an independent submission or outside of the RFC series.

If you have a comment on this, please make it succinctly and soon.


thanks,
Suzanne & TIm

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop




_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--------------1A78F7133EE5704309F9785B-- From nobody Tue Jul 18 05:40:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DC9131DE3 for ; Tue, 18 Jul 2017 05:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DwCXbhpNdtaQ for ; Tue, 18 Jul 2017 05:40:26 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 843D0131B4B for ; Tue, 18 Jul 2017 05:40:26 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id 12so27645506wrb.1 for ; Tue, 18 Jul 2017 05:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=+B7iO8SheFZhnfgw1EKGA8991Nrj/NbAw87xJa52EB0=; b=LSlj9FC2HxvK56nTxS50GDhUXaYxe2oO7OESyXVpqJl+JeWRSEVoUkce9+wSHY0oK8 inEbOKgT8RvJbjn7oa68tUGHn50bOHvPagLKKc6rC8qZOo8vohAAFcFpGHwBX9jvjFCy ZZy4DeTboBwy9t+r5i/BuhVbjfwQg/vF86YKUZcFAn8o7fL2Szjwe2Bml704zjsQOzgU NAG6yXeiNtTvl1BF9CNdfCTumU+pupoBgWk0UHVxZpoX8cxj3XIrmnZUw0Q3tEEZFqeR 31bGa4kQWkTs82uBZTlxflEQp3aEkczVAq6Q+3tWVqkups+H+2m6afFxo5RPFxqbH65P BZ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=+B7iO8SheFZhnfgw1EKGA8991Nrj/NbAw87xJa52EB0=; b=meRMOmK+Pbt/leWUhAf+2ncMBB2xX+NbvIe/Z7ggRKIl0rODjO0TCnSgxetHgpwJ2Q GZxZoX8P7e6Nrqx6WiM0+H7u6D0ub9TeYx6YpBjXsH3gRSeL8cEodPh1N/Cnze8ATngw GRj0FBw4lDl3SCeq2lqi+yEbjWCMtiaweTN+W9p4XQBw4F9oU7gwPVIGfiDkjzVzlYvz oiaJkQdVNw9128/ioCZhzjcIiroq6LBUTYprgbr8vaCJughJYVAlWgLrFtdlfEbFF5OU dj+z3YPzRm3g15nDx1NFECchCRBodTFuM8B2bWc/DrqCiDaqhwlrHqzTDBZqDpza2TiG 5tbA== X-Gm-Message-State: AIVw110uzwW1OkJY5DxJvi3c/0iDA3QqLoO94GBi4C3l9U6lQRZj0NsO WteSsgQKVPIaVjxybvU= X-Received: by 10.28.130.132 with SMTP id e126mr1667346wmd.107.1500381624721; Tue, 18 Jul 2017 05:40:24 -0700 (PDT) Received: from dhcp-8904.meeting.ietf.org ([2001:67c:370:128:2c3e:2bed:84a7:da01]) by smtp.gmail.com with ESMTPSA id 22sm2892786wru.29.2017.07.18.05.40.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:40:23 -0700 (PDT) To: dnsop@ietf.org From: Suzanne Woolf Message-ID: Date: Tue, 18 Jul 2017 08:40:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] still need jabber scribe and minute taker X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:40:28 -0000 Hi, We still need jabber scribe and minute taker volunteers for the DNSOP meeting in the next time slot, 15:50-17:50 today. If you don't volunteer now, we'll just have to ask again in the meeting.... much thanks, your chairs From nobody Tue Jul 18 05:41:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3162131DE3 for ; Tue, 18 Jul 2017 05:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xkfvuL1-Zzso for ; Tue, 18 Jul 2017 05:41:16 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 7BA47131B37 for ; Tue, 18 Jul 2017 05:41:16 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id a10so27917759wrd.0 for ; Tue, 18 Jul 2017 05:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=m1//1LCuZEJaZ6jVBtSjeiFMy/DcE8IDgecNQnMthIA=; b=cUoPVWa59odpUM1w4h9jM+0C3XoG2mUS31qO/1IdxdG1p9e+GP8FDIhIYFFQgMvI1m 5/rd0LYTR+XU8jverkfoj1lAh2cthtjsDbPmV2T3VNW9RfgOmH9aIhIQJpBtUk/XpveN yrGJ9Vz9HnebVwsuFzKwlBHqSkYOUSYLcvxmbqGZURevo8uBSNnUOZMBh3UWPmVFZNYJ 5YmLmNBT4NNRiSEElXVtaGiCY/ajnImCrngzXQGrR8YFC00iRy6hiMusopfIpCULhIrM Z+06WM5Q1UkqfucCF3Cu6CjX363oFYqbpKeCk51hlIDk5rJ+eKW/3pbri0Xe/wUrgdg2 KSyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=m1//1LCuZEJaZ6jVBtSjeiFMy/DcE8IDgecNQnMthIA=; b=l4mJNzFjUzVBdWB1JpoywHqxwPKBX0VPXEbU/Mwbmm0fEZViqvlAJ9Jz/Ze/cY+B2K BsEHkDkiKZA79Cb1FFn9TZD+KbDjMctISZ5xy+wli7Lctu+mRfQKp/ylWzkvIbC4fDzP wMxl5FmeAy19v0e0eEmGNH8EHjPJAHE1FoS2tzUHLyOgx1RBaHW8eHDjw1Cn8yqnANq0 NlgFvkiattcg33JjlhwL1GE50jsnBoef8Wv5qwtxDZw6JPt7yuL2P56Kp2GhM0FhEECK xeAtSqlwNrlISlLGJzgxdDhhgJeLNdV94nNSQuR03HcHFs/t3+QHvgeHG0gr6rturtMb /Diw== X-Gm-Message-State: AIVw113K6Jp5TNu8UMcnwdsXGkACYGFhM8WNlqMJs7dxWS15FfNR+Ybe SxrmYm51iMvnL2kbVhA= X-Received: by 10.28.71.133 with SMTP id m5mr2035737wmi.97.1500381674690; Tue, 18 Jul 2017 05:41:14 -0700 (PDT) Received: from dhcp-8904.meeting.ietf.org ([2001:67c:370:128:2c3e:2bed:84a7:da01]) by smtp.gmail.com with ESMTPSA id m26sm3197813wrm.4.2017.07.18.05.41.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:41:14 -0700 (PDT) To: dnsop@ietf.org References: <927b199d-ff76-b0da-0297-2d6869af8ed2@nic.cz> From: Suzanne Woolf Message-ID: <4e8b6d25-b2fc-45d8-5150-f8b28d01cac4@gmail.com> Date: Tue, 18 Jul 2017 08:41:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <927b199d-ff76-b0da-0297-2d6869af8ed2@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:41:18 -0000 Hi, On 7/18/17 8:32 AM, Petr Špaček wrote: > I'm fine with Informational document describing the existing version of > RPZ. My hope that working on that as WG item will help to improve the > text so it is unambiguous. Improvements to the protocol can be done > later on. > Thank you-- this is exactly the intent. Suzanne From nobody Tue Jul 18 05:42:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7A4131DE3 for ; Tue, 18 Jul 2017 05:42:06 -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] 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 TKkUDnP0zhDc for ; Tue, 18 Jul 2017 05:42:05 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 562E4131B4B for ; Tue, 18 Jul 2017 05:42:05 -0700 (PDT) Received: from [10.47.60.34] (dhcp-9976.meeting.ietf.org [31.133.153.118]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6ICfEiv016451 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Jul 2017 05:41:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host dhcp-9976.meeting.ietf.org [31.133.153.118] claimed to be [10.47.60.34] From: "Paul Hoffman" To: dnsop@ietf.org Date: Tue, 18 Jul 2017 14:42:01 +0200 Message-ID: <4B2B2D27-7E24-41BC-93B7-D33FAF783BD6@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:42:06 -0000 If the WG still gets to freely edit the document while adhering to "describes an existing and widely deployed method", this seems like a good way forwards. --Paul Hoffman From nobody Tue Jul 18 05:43:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9CB131B0A for ; Tue, 18 Jul 2017 05:43:39 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 d8vh4V2I5ukk for ; Tue, 18 Jul 2017 05:43:37 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 BF108129B10 for ; Tue, 18 Jul 2017 05:43:37 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id k14so12277840pgr.0 for ; Tue, 18 Jul 2017 05:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=53f4EJ0ayr6TtrgNpOQ8nU8i+0ZR7Quhz7ajRkCcaPw=; b=Ir4jbahZzNJk7/SlWHhcWBlVx8goLeGQbI6U33l57OVKi8Cv8q191UPlCOyws8pUJR 5x9Qcy+bP7EL7pT/+FAv+FHzklXXC8JQrnQ+U49g+oZ4g0yG3Q3AocxbG2c538/djbJT eGM+fool05U+v2Ksj6/NPapOECJbEAgg45skguD1xywGQIyTyynIvXPIcAcSC5m3pZMa muf7odp35tCvmOD1Ik7NGVkR4XZVkYmErms99x8k4iHDEbCUhvFhicyu5xPMjMaAjf7P yP6FYWtcCinIdRbtm8zjPw6ypiM9IgXjZxqkde2i3wR/kgTKG+YD8iokaDVBJnjL6yfI 7quQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=53f4EJ0ayr6TtrgNpOQ8nU8i+0ZR7Quhz7ajRkCcaPw=; b=IrVSzVrm1w9mI3zA0ISupBoP/ZBDncZjcxb48ivJ+zu/QGCmuW6f/uqc2TKIfNEM2V IZRdq2kKq+YgrDWiB8DlebbWZ9h7tkHmqMWt0MmY/kEe/Kc4kcDfzG+Zxxlhkg9TivqK 6Cl5TdJ6jXTnW0aqxEFoxz5Q62wnkK29ozaGm4qeBf6sZlYoSlAgJAglP+d7/Zt82ra/ LTfLMiAvqfaAbE/KnqIx++RDd5jLYzl33RLFjp/3bkQU1lER1H0bayhcm6c1rc0La814 Gvwlpr1YWbI5JpTLRt5tvB2/VthP4foyTcB1ef0V8ixt6ShMOK3hI6yOcjr7KvmQ9O0U j8Lw== X-Gm-Message-State: AIVw111rzyme+FErPTIOrgduFhXUFGjcoXdJQbePK74e7CG/xoM8R5Dy F0TyKVghDdMIZW9S3dUha5Cy5/Cxc2nJ X-Received: by 10.99.114.82 with SMTP id c18mr1607995pgn.32.1500381817372; Tue, 18 Jul 2017 05:43:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 05:42:56 -0700 (PDT) In-Reply-To: <4B2B2D27-7E24-41BC-93B7-D33FAF783BD6@vpnc.org> References: <4B2B2D27-7E24-41BC-93B7-D33FAF783BD6@vpnc.org> From: Ted Lemon Date: Tue, 18 Jul 2017 14:42:56 +0200 Message-ID: To: Paul Hoffman Cc: dnsop WG Content-Type: multipart/alternative; boundary="f403045c7724409ee2055496dd9c" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:43:39 -0000 --f403045c7724409ee2055496dd9c Content-Type: text/plain; charset="UTF-8" Okay, sorry, that wasn't really clear. Possible reading comprehension problem on my part. :] On Tue, Jul 18, 2017 at 2:42 PM, Paul Hoffman wrote: > If the WG still gets to freely edit the document while adhering to > "describes an existing and widely deployed method", this seems like a good > way forwards. > > --Paul Hoffman > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f403045c7724409ee2055496dd9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, sorry, that wasn't really clear. =C2=A0 Possible= reading comprehension problem on my part. =C2=A0 :]

On Tue, Jul 18, 2017 at 2:42 PM, P= aul Hoffman <paul.hoffman@vpnc.org> wrote:
If the WG still gets to freely edit the document while= adhering to "describes an existing and widely deployed method", = this seems like a good way forwards.

--Paul Hoffman


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--f403045c7724409ee2055496dd9c-- From nobody Tue Jul 18 05:51:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C872012EC46 for ; Tue, 18 Jul 2017 05:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_SOFTFAIL=0.665] autolearn=no 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 r4tyFhGmOe1h for ; Tue, 18 Jul 2017 05:51:01 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0B129B10 for ; Tue, 18 Jul 2017 05:51:01 -0700 (PDT) Received: from jurassic (unknown [115.118.30.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 7349656A04AF; Tue, 18 Jul 2017 12:50:58 +0000 (GMT) Date: Tue, 18 Jul 2017 18:20:56 +0530 From: Mukund Sivaraman To: Paul Hoffman Cc: dnsop@ietf.org Message-ID: <20170718125056.GA7982@jurassic> References: <20170718094654.GA31988@jurassic> <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:51:02 -0000 Hi Paul On Tue, Jul 18, 2017 at 02:35:31PM +0200, Paul Hoffman wrote: > On 18 Jul 2017, at 11:46, Mukund Sivaraman wrote: > > > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > > unsigned zones requiring the DNS COOKIE option in transmission, that can > > be used with draft-ietf-dnsop-nsec-aggressiveuse? > > Of what value is the result? Is it worth the hassle for the zone admin? It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned zones. A zone admin would not have to do anything operationally except enable/disable the feature. Dealing with water torture and some other attacks have had several band-aid approaches that don't always work well in practice. The most promising (and what feels correct) is draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned zones. Mukund From nobody Tue Jul 18 06:02:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EB8131B51 for ; Tue, 18 Jul 2017 06:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 u-u4JNFs3FlQ for ; Tue, 18 Jul 2017 06:02:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 05EB7131B0A for ; Tue, 18 Jul 2017 06:02:49 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5] (unknown [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5]) by mail.nic.cz (Postfix) with ESMTPSA id 1453B62284 for ; Tue, 18 Jul 2017 15:02:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500382968; bh=xkXKlushCseWszEXM3iypty3EzfE98UK8VTXl7qg0o0=; h=To:From:Date; b=IYVSrRUJ+Hns5SodKqbcR2Db6t6EViNgiq66y9KmvseclKSG9QFUtaSBYvvEuAkSN AwsVaf1eLpFq6M9sa9mZIiKXXyABB91KXnfKX4U4zKRNKgO3PGuO54nLo1etd+YEEM abCj6r4Ov2zyyeoxOxjfNC/KAMUqB9j87r61a1Eg= To: dnsop@ietf.org References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz> Date: Tue, 18 Jul 2017 15:02:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:02:54 -0000 On 11.7.2017 13:23, Ted Lemon wrote: > On Jul 11, 2017, at 3:17 AM, Petr Špaček > wrote: >> I feel that implications from switch to non-RR format are underestimated >> and following e-mail attempts to explain why I believe it is a bad idea. >> Please accept my apology for such long e-mail. > > Petr, with all due respect, I did not see a counter-proposal here, and > your comments seem to reflect a misunderstanding of what > session-signaling is. > > In fact, the opposite of what you said is true: if this were done as a > normal query with EDNS0-like encapsulation, _then_ we would see > problems, because session signaling messages would look more like DNS > queries, and less like control messages. This is not a desirable quality. > > It's true that, for example, the DNS packet compression format would > have to deal with this specially, but that would also be true if this > were done EDNS0-style. It's true that packet dumpers would have to > deal with this specially, but that's also true if it's done EDNS0-style. > Etc. Let me clarify that I'm not insisting specifically on EDNS0. From my perspective anything which does not deviate from current wire format is okay. > It may be that there is a good point in your argument somewhere, but at > the moment, I don't see one. E.g., in your python example, yes, if > this were an RR, not being able to plop it into your RR-handling switch > would suck. But it's not an RR, doesn't have the semantics of an RR, > and if you plop it into your RR-handling switch, you're probably getting > the semantics wrong. This might be key to the the misunderstanding: I'm not talking about semantics at all. What I object to is the proposed wire format, not the semantics. The fact that bytes are stored in format compatible with RR (RFC 1035 section 4.1.3) is not related to its semantics. > So if you want to make this case, I think you need to be more specific > about why this is a problem: when I think about how to implement this > (which I have done, because I'm using it for dnssd), what you are > advocating seems harder, not easier, than what is currently being proposed. I'm trying to explain that deviance from RR format (RFC 1035 section 4.1.3) will force parties in the DNS ecosystem to implement support for the new wire format even though they are not interested in session signaling at all. For a lot of cases it would be sufficient if SS data could be treated as one of many "unknown RR types" (RFC 3597). For example tools for statistics would work, the capture formats would not need special extensions for SS, etc. We can discuss this in depth during dnsop session today. -- Petr Špaček @ CZ.NIC From nobody Tue Jul 18 06:14:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D3313167D for ; Tue, 18 Jul 2017 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 OgReVNEb1jvv for ; Tue, 18 Jul 2017 06:14:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 29C9312EB8C for ; Tue, 18 Jul 2017 06:14:06 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5] (unknown [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5]) by mail.nic.cz (Postfix) with ESMTPSA id A822B6226C for ; Tue, 18 Jul 2017 15:14:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500383644; bh=bPVr/CuRKVI7H+hCaQeqk8+3XQHbdwC2Gim22U6rpWk=; h=To:From:Date; b=TrWUiPU2KXj4RlOCu70Bn/ww+6yob1+y1cHY65Ny9TiPPNfr4dDG1nNaNcadCWoel HuS8i/K6R+jVbqSdclKxbrCQOL9SZ7lV8hWFQyl8SYs6bXVaiTMyI4CPmRVW/O/xmq pXp3DescAy5HFkkw/6rFGgKY2DV+8m0J8Of7NXQg= To: dnsop@ietf.org References: <20170718094654.GA31988@jurassic> <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> <20170718125056.GA7982@jurassic> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <24c25fc8-af41-07bd-15b0-306aa5da3f22@nic.cz> Date: Tue, 18 Jul 2017 15:14:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170718125056.GA7982@jurassic> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:14:08 -0000 On 18.7.2017 14:50, Mukund Sivaraman wrote: > Hi Paul > > On Tue, Jul 18, 2017 at 02:35:31PM +0200, Paul Hoffman wrote: >> On 18 Jul 2017, at 11:46, Mukund Sivaraman wrote: >> >>> Will you give some thought and reply with your opinion on NSEC/NSEC3 for >>> unsigned zones requiring the DNS COOKIE option in transmission, that can >>> be used with draft-ietf-dnsop-nsec-aggressiveuse? >> >> Of what value is the result? Is it worth the hassle for the zone admin? > > It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned > zones. A zone admin would not have to do anything operationally except > enable/disable the feature. > > Dealing with water torture and some other attacks have had several > band-aid approaches that don't always work well in practice. The most > promising (and what feels correct) is > draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned > zones. For me this is an incentive to get more zones signed, not to add kludges just for unsigned ones. There surely are "operational and other reasons" not to sign zone associated with some cost. Signing and serving signed zone have cost_1 and serving unsigned zone has cost_2 (which needs to incorporate cost of attacks mitigated by DNSSEC). Eventually cost_2 of serving unsigned zone might get high enough so solving "operational and other reasons" might be cheaper than cost_1 paying for signing and serving signed zone. I would wait for that. -- Petr Špaček @ CZ.NIC From nobody Tue Jul 18 06:19:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8451812EC57 for ; Tue, 18 Jul 2017 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 sbugEBuiJIv0 for ; Tue, 18 Jul 2017 06:19:47 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 C8D7112EC3F for ; Tue, 18 Jul 2017 06:19:46 -0700 (PDT) Received: from [172.20.11.195] (unknown [88.208.89.131]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 072E6B328 for ; Tue, 18 Jul 2017 15:19:45 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1500383985; bh=WWedVUURWrKfG3b++MK3Ynwpxnf1gvjmCxt34eBLVW8=; h=Subject:To:References:From:Date:In-Reply-To; b=TxZ6jZYMR0QSNc2cxEUR4VTUoimq54btK5AR9dmnK+rsk3rgZGl/dEecqh+paHw2y 0UjIsKQ8FNJUgr1ahUu5ldzenN7ji8uJdIXN+HCdsv7IMbDwS6G706P9GZGgCAuHkc hfWzbRHXJN3JW8vNfsjcHEeTGokuC7KdE03Wl13E= To: dnsop@ietf.org References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> From: Willem Toorop Message-ID: <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> Date: Tue, 18 Jul 2017 15:19:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149592096439.3966.11385984990945858242@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:19:48 -0000 I support trying to come up with a standards solution for alias names at the apex. But.... The dependency on online signing is a little more then just a technical issue. Currently the zone owner, the holder of the domain name, is the one having control over the zone content and as such also the one deciding who may sign her zone. She may choose to delegate this to a DNS operator, or she may decide to sign the zone herself and let the DNS operator serve the signed zone. Currently all DNS Resource Records support the "offline" domain-name holder signed zones mode of DNSSEC. There is another provisioning oriented resource record: DNAME. For DNAME, it is described how validators can verify that the followed referral matches. The same thing should be done for ANAME. It would be a new DNSSEC feature that need to be supported by the DNSSEC validators. There has been an earlier instance of the introduction of a new DNSSEC feature: NSEC3. The introduction of a DNSSEC compatible ANAME should be done the same way as how NSEC3 was introduced: introduce new algorithm numbers that indicate ANAME support. We currently have 12 DNSSEC algorithms. The introduction of a new feature could list these same algorithm from number 17 up to 29, with the indication that it supports the new DNSSEC features, ANAME would be one of them. NSEC5 another maybe? Op 27-05-17 om 23:36 schreef internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Address-specific DNS Name Redirection (ANAME) > Authors : Evan Hunt > Peter van Dijk > Anthony Eden > Filename : draft-ietf-dnsop-aname-00.txt > Pages : 10 > Date : 2017-05-27 > > Abstract: > This document defines the "ANAME" DNS RR type, to provide similar > functionality to CNAME, but only redirects type A and AAAA queries. > Unlike CNAME, an ANAME can coexist with other record types. The > ANAME RR allows zone owners to redirect queries for apex domain names > in a standards compliant manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-aname-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-00 > > > 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/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Tue Jul 18 07:14:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662A81286B2 for ; Tue, 18 Jul 2017 07:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=GfkV+Q6Q; dkim=pass (1024-bit key) header.d=yitter.info header.b=jpxmc6Eb 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 2TrGTLgE264q for ; Tue, 18 Jul 2017 07:13:59 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58A112706D for ; Tue, 18 Jul 2017 07:13:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D4620BD996 for ; Tue, 18 Jul 2017 14:13:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500387208; bh=Rnfbyiqn4r10hja/ZLLuG/jjC50bRIYqxGOPwnfiUwU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GfkV+Q6QrA5A0QnPMMbcclEMec1lEV4h3jLKCbC/ubzkjOgpOnk3XC4m69UtGUhT5 NnCZZHgQt46yA65hEdsc0iB9oV0xu+rORzEnUfMuzgljiBRTsHuI23zUEITxgAFSE7 tandLjPtm8omR8YVhcZoJZchIUepaxBJ7+SFlpkM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kghadL9VTC-S for ; Tue, 18 Jul 2017 14:13:27 +0000 (UTC) Date: Tue, 18 Jul 2017 10:13:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500387207; bh=Rnfbyiqn4r10hja/ZLLuG/jjC50bRIYqxGOPwnfiUwU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jpxmc6EbEJosfP/C0Ef8t81xZKXGMvSpiCsScNOoMLYRJBb0BfzdwXjC+byb8Ig1L TbFwStgnOr4sqn05dT1tRJ224zBwzYrsuxkfhwiVE1xYMu+ffoaM8i+WWGZYiFZlQb Onm1bfsUL9/aZ6B2uTqMuzEDfMbkLBw8a+Hz70Yk= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170718141325.xjlxdv3474wv7zrm@mx4.yitter.info> References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:14:01 -0000 Dear colleagues, I managed to delete instead of sending my note on this topic earlier today, and my brain is sufficiently soft that I couldn't just re-type it out. Nevertheless, On Tue, Jul 18, 2017 at 03:19:44PM +0200, Willem Toorop wrote: > I support trying to come up with a standards solution for alias names at > the apex. But.... I agree with this, and > The dependency on online signing is a little more then just a technical > issue. also this. > Currently all DNS Resource Records support the "offline" domain-name > holder signed zones mode of DNSSEC. There is another provisioning > oriented resource record: DNAME. For DNAME, it is described how > validators can verify that the followed referral matches. The same thing > should be done for ANAME. The problem is that DNAME has another feature that ANAME (and other things like BNAME) can't: RFC 6672 gives the reasons why all validators must also be able to cope with DNAME. This was a fact (or maybe accident) of history. It is just not true of ANAME, and that means that much of section 3 of the I-D is far too weak. It needs to say that, if you can't sign online, then you will break DNSSEC. It is very strange for us to suggest this, but I think there are only two options: either DNSSEC means we can never do any more aliasing, or else we have to accept that some kinds of innovation in the DNS is going to break DNSSEC sometimes, and allow zone operators to decide whether they want to break validation (and therefore lose the connections) or whether they want to serve everyone. Alternatively, of course, we can follow the multiple-algorithm approach that others have suggested. This has the disadvantage of bloating the DNSKEY RRset for anyone who wants to use these features, of course, so it is also not free. I'm also slightly concerned about this at the end of 3.3: The type bit map SHOULD only include address types which are known to exist at the Is the advice really to ask for both and then incorporate what is known? That seems maybe safer advice. I also wonder whether the document would be easier to understand if it were broken up into smaller chunks dealing separately with the authorities, intermediates, and stubs. It could be that nobody else find these items too tangled in the current I-D, but if others do I can propose text. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 18 07:46:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6D129B19 for ; Tue, 18 Jul 2017 07:46:16 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 wWlBkz8YEPz9 for ; Tue, 18 Jul 2017 07:46:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C76FA127136 for ; Tue, 18 Jul 2017 07:46:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xBjdx1j6Bz1km; Tue, 18 Jul 2017 16:46:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1500389173; bh=PqEei39Ai2EA6qdBjMiGP1JW6wQRWjOm6TIChlWiA0w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UcavDyLxta4+0kjDhwK01Kp8AW1gKSbcI47/0V0MsPwkCevmwAO/BK2T0ytPzAThO kSFibe5Andf7oPSNPepVds5ycFLnx7PrRpfd2XmfdXKzrns9l5sXFiij8JNpTL6uhK FQtw97dmwt4cvVwk8oDT2XCLzE+fQnILGfEAqNRc= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id B8fuE3IbQPFf; Tue, 18 Jul 2017 16:46:12 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 18 Jul 2017 16:46:12 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4E8642D52D1; Tue, 18 Jul 2017 10:46:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4E8642D52D1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4965840D3592; Tue, 18 Jul 2017 10:46:11 -0400 (EDT) Date: Tue, 18 Jul 2017 10:46:11 -0400 (EDT) From: Paul Wouters To: Suzanne Woolf cc: dnsop@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:46:17 -0000 On Tue, 18 Jul 2017, Suzanne Woolf wrote: > If this is acceptable to the WG, we’ll keep the new draft with these changes as a WG draft.  I'm okay with this approach. Paul From nobody Tue Jul 18 09:09:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367B6128DE5 for ; Tue, 18 Jul 2017 09:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 CaG6hOKEB-Vj for ; Tue, 18 Jul 2017 09:09:02 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 675F41287A0 for ; Tue, 18 Jul 2017 09:09:02 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42547) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXV3U-000fT6-eT (Exim 4.89) (return-path ); Tue, 18 Jul 2017 17:09:00 +0100 Date: Tue, 18 Jul 2017 17:09:00 +0100 From: Tony Finch To: Willem Toorop cc: dnsop@ietf.org In-Reply-To: <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> Message-ID: References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:09:04 -0000 Willem Toorop wrote: > > The dependency on online signing is a little more then just a technical > issue. I need to review the draft properly, but I do not think ANAME should require any online signing. In my view an authoritative server which does online signing and on-demand record synthesis is a master server. You can make all your public authoritative servers into masters if you like, but it must not be required. If (like me) you have a more traditional setup then ANAME is an instruction to the master server about zone maintenance, saying that it needs to periodically update the sibling A and AAAA records, similar to periodic re-signing, or as if some script were periodically `nsupdate`ing the records. The secondary servers can continue to work the same as they do now, but they'll work better if they know about some helpful additional section rules for ANAME. (That is basically how my bodged-up ANAME implementation works, in my zone provisioning scripts.) The other kind of DNS server that might be able to do something useful with ANAME is a recursive server, so it could co-operate nicely with authoritative servers that are playing clever tricks. But the rDNS will have to be careful about not breaking downstream validators. Say (for example) my zone has: dotat.at. ANAME www.chiark.greenend.org.uk. dotat.at. RRSIG ANAME dotat.at. A 212.13.197.229 dotat.at. RRSIG A dotat.at. AAAA 2001:ba8:1e3:: dotat.at. RRSIG AAAA A client queries its resolver for dotat.at A, but chiark has renumbered, so the client gets a response from the ANAME-aware resolver like below. A validating ANAME-aware client can see it should use the additional address 212.13.197.231 in preference to the address in the answer. ; ANSWER dotat.at. A 212.13.197.229 dotat.at. RRSIG A ; ADDITIONAL dotat.at. AAAA 2001:ba8:1e3:: dotat.at. RRSIG AAAA dotat.at. ANAME www.chiark.greenend.org.uk. dotat.at. RRSIG ANAME www.chiark.greenend.org.uk. A 212.13.197.231 www.chiark.greenend.org.uk. RRSIG A www.chiark.greenend.org.uk. AAAA 2001:ba8:1e3:: www.chiark.greenend.org.uk. RRSIG AAAA Note that neither the resolver nor the client needs any algorithm updates to avoid being confused by this additional information; they just need a code update so that they are able to make good use of it. If the resolver knows the client is DNSSEC-oblivious then it can do the substitution itself and return a simple answer like this: dotat.at. A 212.13.197.231 Validating but ANAME-oblivious resolvers won't get to enjoy clever latency minimization tricks. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode East Sole, Lundy, Fastnet, Irish Sea: Easterly becoming cyclonic 4 or 5, increasing 6 or 7 at times. Slight or moderate. Fair then thundery showers, fog patches later. Moderate or good, occasionally very poor later. From nobody Tue Jul 18 11:02:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33769131B66 for ; Tue, 18 Jul 2017 11:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=NMm1kR2w; dkim=pass (1024-bit key) header.d=yitter.info header.b=fF/WZuy7 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 rxJn_YCn_zRY for ; Tue, 18 Jul 2017 11:02:06 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595A3131A66 for ; Tue, 18 Jul 2017 11:02:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8E24DBD996 for ; Tue, 18 Jul 2017 18:01:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500400895; bh=ioWRzELjJ9npbQvU3ZtLVkWNxPLvyLwHvW8aZOGWpHM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NMm1kR2w9vLqEItKZiZhQ+CYhjUffrLxYZOwwCTwJhk44E3+cJh42JGbfIT3pxwof iW6XMKlOMwjNWB1VX9i0S/L1gysloGgNeuXQoH0wxd1Bg2czxPT7dzmvpKt33oFDqV +WGuqq8SqTZFJbGuGdIBIXMeaA783p0ppna4WjAQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R8OJ9hKzGtE for ; Tue, 18 Jul 2017 18:01:34 +0000 (UTC) Date: Tue, 18 Jul 2017 14:01:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500400894; bh=ioWRzELjJ9npbQvU3ZtLVkWNxPLvyLwHvW8aZOGWpHM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fF/WZuy7KoyaDk1V/3xAi4GY94DQNm0Ykv33+oDgPF2mP4Pqg/lxgO6BPTG00Ve4F r4ps27Lrirc86o8xI/nDIJfuJmg4nMoUgFli7N9J6OTafQEAmQSm4JJI7peiyIVlnk ADnae3uo6ndS1BoJIHNBGfD/tYEBaNi+rCUINaD8= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170718180128.omffg7ce5kbhoqjr@mx4.yitter.info> References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:02:08 -0000 Hi, On Tue, Jul 18, 2017 at 05:09:00PM +0100, Tony Finch wrote: > In my view an authoritative server which does online signing and on-demand > record synthesis is a master server. You can make all your public > authoritative servers into masters if you like, but it must not be > required. > > If (like me) you have a more traditional setup then ANAME is an > instruction to the master server about zone maintenance, saying that it > needs to periodically update the sibling A and AAAA records, similar to > periodic re-signing, or as if some script were periodically `nsupdate`ing > the records. The secondary servers can continue to work the same as they > do now, but they'll work better if they know about some helpful additional > section rules for ANAME. I think I (at least mostly) agree. One possible way to sort out these bits of potential confusion is to break the problem up into conceptual parts, so that one can see the way that they work together. One part is, "How do you give this instruction to the master server(s)?" It covers representation in the master file format, what a master is supposed to do on input, how to refresh the data, and so on. A second part is, "How do you give this instruction to a slave?". This covers transferring zones, the trade-offs in handing the slaves the ANAME vs the "resolved" records, refresh timers and so on. DNSSEC considerations at least are split between these, which suggests to me that these topics could be covered by one document in two parts; but these are nevertheless separate and separable functional questions. A third part has to do with downstream resolvers and caches and so on. This is really a separate problem: how to handle ANAME-aware vs ANAME-unaware systems, the consequences of an ANAME-unaware cache ending up with an ANAME in the cache, the effects of having an A and not AAAA in cache, &c &c. A fourth part, which might be yet a separate problem or might be the same document, is what this all looks like from a stub and what happens when there are chains of forwarders and caches and so on with a mix of ANAME-awareness and -obliviousness. I still think that in addition a clear description of why this is hard would be helpful. The troublesome thing about Stupid DNS Tricks is that they're always >80% there, and all the really hard parts are in that last <20%, and the difficulties in those <20% cases are manifold and completely unexpected when you think in the abstract cases. The people who worked through all the gnarly problems of caches and the interaction with DNSSEC already went through this once (I came in at the tail end and mercifully missed most of that), but we're about to revisit those problems for a different set of questions. I think we need to understand why this is more complicated than it looks, and I think any future implementer will need a clear guide to that also. ### WARNING: IETF ADMINISTRATIVE WRANGLING AHEAD ### Since there's been talk about an interim, it strikes me that the current issue is the sort of specific topic that deserves one. But I also wonder whether this isn't bumping up pretty hard against the DNSOP charter, and whether this mightn't be a case where we put together a tightly focussed statement of work that gets chartered as a WG, with a plan never to meet (or to meet only as "part of" a DNSOP meeting or something like that), if only to avoid pain and misery when the documents describing all this go to IETF LC. I am not interested even a little bit in making more administrative overhead, but I'm very much interested in avoiding a "this is off charter" discussion during IETF LC should we get there. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 18 13:24:34 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6918C131BF2; Tue, 18 Jul 2017 13:24:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 13:24:33 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 20:24:33 -0000 The DNSOP WG has placed draft-woodworth-bulk-rr in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ From nobody Tue Jul 18 14:08:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06CA12EC23 for ; Tue, 18 Jul 2017 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 QhTIc9F_3fSz for ; Tue, 18 Jul 2017 14:08:17 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A029E12EB5F for ; Tue, 18 Jul 2017 14:08:17 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39584) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXZj5-000e2J-eK (Exim 4.89) (return-path ); Tue, 18 Jul 2017 22:08:15 +0100 Date: Tue, 18 Jul 2017 22:08:15 +0100 From: Tony Finch To: Andrew Sullivan cc: dnsop@ietf.org In-Reply-To: <20170718180128.omffg7ce5kbhoqjr@mx4.yitter.info> Message-ID: References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> <20170718180128.omffg7ce5kbhoqjr@mx4.yitter.info> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 21:08:20 -0000 Andrew Sullivan wrote: > > I think I (at least mostly) agree. One possible way to sort out these > bits of potential confusion is to break the problem up into conceptual > parts, so that one can see the way that they work together. One part > is, "How do you give this instruction to the master server(s)?" It > covers representation in the master file format, what a master is > supposed to do on input, how to refresh the data, and so on. Yes. > A second part is, "How do you give this instruction to a slave?". This > covers transferring zones, the trade-offs in handing the slaves the > ANAME vs the "resolved" records, refresh timers and so on. The only compatible option here is to transfer the signed resolved records, and have the secondary behave the same as now, except for a small amount of extra additional section processing. All dynamic behaviour has to happen on a master. If you think you have a secondary that's editing and/or resigning your zone, what you actually have is a master which happens to use another DNS server as its data source, rather than a zone file or database. > A third part has to do with downstream resolvers and caches and so on. > This is really a separate problem: how to handle ANAME-aware vs > ANAME-unaware systems, the consequences of an ANAME-unaware cache > ending up with an ANAME in the cache, It should be just the same as any other new RR type. > the effects of having an A and not AAAA in cache, &c &c. It should be just the same as now. > A fourth part, which might be yet a separate problem or might be the > same document, is what this all looks like from a stub and what happens > when there are chains of forwarders and caches and so on with a mix of > ANAME-awareness and -obliviousness. I think that if the transmission through the resolver forwarding chain is done by putting extra records in the additional section, then it should be self-healing. Downstream ANAME-aware resolvers can (if necessary) do extra ANAME-related queries through an ANAME-oblivious upstream. > I still think that in addition a clear description of why this is hard > would be helpful. I think it can be made reasonably simple :-) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fisher, Northeast German Bight: Northwest veering east 4 or 5, decreasing 3 for a time. Slight or moderate. Fair. Moderate or good. From nobody Tue Jul 18 14:35:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700D2131AA6 for ; Tue, 18 Jul 2017 14:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 ocBQWXT98vHT for ; Tue, 18 Jul 2017 14:35:17 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1A4131A7C for ; Tue, 18 Jul 2017 14:35:17 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 374931807FE70 for ; Tue, 18 Jul 2017 21:35:16 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 90, 9, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:152:355:379:599:854:967:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1534:1537:1561:1593:1594:1711:1714:1730:1747:1777:1792:2393:2525:2553:2560:2563:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3867:3871:3872:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:5007:7652:7903:8985:9025:10004:10400:10848:11232:11658:11914:12043:12109:12114:13069:13311:13357:13894:14181:14721:14764:14777:21080:21366:21433:21528:21627:30022:30054:30090:30091, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, LUA_SUMMARY:none X-HE-Tag: slope78_6826df6414e41 X-Filterd-Recvd-Size: 1244 Received: from [192.168.9.54] (p57AA8E8E.dip0.t-ipconnect.de [87.170.142.142]) (Authenticated sender: avri@doria.org) by omf03.hostedemail.com (Postfix) with ESMTPA for ; Tue, 18 Jul 2017 21:35:15 +0000 (UTC) Reply-To: avri@acm.org To: dnsop@ietf.org References: From: avri doria Message-ID: <0d48a306-a6f2-79be-985c-b97531d49170@acm.org> Date: Tue, 18 Jul 2017 23:35:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 170718-2, 07/18/2017), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 21:35:18 -0000 > On Tue, 18 Jul 2017, Suzanne Woolf wrote: > >> If this is acceptable to the WG, we’ll keep the new draft with these >> changes as a WG draft. It is fine with me. avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Tue Jul 18 20:17:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF28012783A for ; Tue, 18 Jul 2017 20:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 I1jIJcN0qv1j for ; Tue, 18 Jul 2017 20:17:00 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 42407126D05 for ; Tue, 18 Jul 2017 20:17:00 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 6EF0624AE08; Wed, 19 Jul 2017 03:15:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E0A6116004C; Wed, 19 Jul 2017 03:15:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CC6AC160054; Wed, 19 Jul 2017 03:15:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KiAlwVh8nNnm; Wed, 19 Jul 2017 03:15:39 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2EA1F16004C; Wed, 19 Jul 2017 03:15:39 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 05E1B7EA7FA6; Wed, 19 Jul 2017 13:15:36 +1000 (AEST) To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop@ietf.org From: Mark Andrews References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com> <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz> In-reply-to: Your message of "Tue, 18 Jul 2017 15:02:47 +0200." <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz> Date: Wed, 19 Jul 2017 13:15:35 +1000 Message-Id: <20170719031536.05E1B7EA7FA6@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 03:17:02 -0000 In message <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz>, =?UTF-8?B?UGV0ciDFoHBhxI1law==?= writes: > On 11.7.2017 13:23, Ted Lemon wrote: > > On Jul 11, 2017, at 3:17 AM, Petr paek > > wrote: > >> I feel that implications from switch to non-RR format are > underestimated > >> and following e-mail attempts to explain why I believe it is a bad > idea. > >> Please accept my apology for such long e-mail. > > > > Petr, with all due respect, I did not see a counter-proposal here, and > > your comments seem to reflect a misunderstanding of what > > session-signaling is. > > > > In fact, the opposite of what you said is true: if this were done as a > > normal query with EDNS0-like encapsulation, _then_ we would see > > problems, because session signaling messages would look more like DNS > > queries, and less like control messages. This is not a desirable > quality. > > > > It's true that, for example, the DNS packet compression format would > > have to deal with this specially, but that would also be true if this > > were done EDNS0-style. It's true that packet dumpers would have to > > deal with this specially, but that's also true if it's done EDNS0-style. > > Etc. > > Let me clarify that I'm not insisting specifically on EDNS0. From my > perspective anything which does not deviate from current wire format is > okay. > > > > It may be that there is a good point in your argument somewhere, but at > > the moment, I don't see one. E.g., in your python example, yes, if > > this were an RR, not being able to plop it into your RR-handling switch > > would suck. But it's not an RR, doesn't have the semantics of an RR, > > and if you plop it into your RR-handling switch, you're probably getting > > the semantics wrong. > > This might be key to the the misunderstanding: > > I'm not talking about semantics at all. What I object to is the proposed > wire format, not the semantics. The fact that bytes are stored in format > compatible with RR (RFC 1035 section 4.1.3) is not related to its > semantics. > > > So if you want to make this case, I think you need to be more specific > > about why this is a problem: when I think about how to implement this > > (which I have done, because I'm using it for dnssd), what you are > > advocating seems harder, not easier, than what is currently being > proposed. > I'm trying to explain that deviance from RR format (RFC 1035 section > 4.1.3) will force parties in the DNS ecosystem to implement support for > the new wire format even though they are not interested in session > signaling at all. Hogwash. Servers which are unaware of the opcode will return NOTIMP or FORMERR depending on how forward thinking the developer was. If you have a packet dumper YOU ALREADY HAVE TO ACCOUNT FOR THIS. There are ZERO guarentees that a packet addresses to/from port 53 is a DNS packet. If your packet dumper can't handle these then it is already broken. If you are just proxying DNS messages this should be transparent. If the proxy is parsing the message then it returns NOTIMP or FORMERR. > For a lot of cases it would be sufficient if SS data could be treated as > one of many "unknown RR types" (RFC 3597). For example tools for > statistics would work, the capture formats would not need special > extensions for SS, etc. > > We can discuss this in depth during dnsop session today. > > -- > Petr paek @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 19 00:03:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA65A12EA53 for ; Wed, 19 Jul 2017 00:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 XBIlaYS7Pvlj for ; Wed, 19 Jul 2017 00:03:21 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 71A62129A96 for ; Wed, 19 Jul 2017 00:03:19 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id u4so4302308uaa.1 for ; Wed, 19 Jul 2017 00:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=mmIcVIuNLIkv2Syv6E75OKhFbqMD4hFDTM/0876puPk=; b=vJbaoRbnxmXekJl4PpvjKoYrBCJ826jj8hkK/+qA9E30/GVZtzqa9QU7+QfxUtZ9FN nbbd04UjW1SwGSanLcvo6SREZ9Kd4/0HzLK9k5hQqRqPRkVFDVBp4FX5wazmhYMQEwRh CGVg5SkK9GoG4SoLBtRAMannUuDNuppATlCHANY03LWyOQVhWkH1GY99ATClGmNZN1Xy F4WL6o8kqVQhvZhJeRahezj/PFzBKQn+shm7od4jVyXrTHshAT+tRFs6+3TnSBUQebOs /BaesA6DR9b+PASNRE5Ok5Ok7D/ApjKUugLQHm/IRLnvL0FWHJluaR4jhgzk5Lt0ZU7G 7DJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=mmIcVIuNLIkv2Syv6E75OKhFbqMD4hFDTM/0876puPk=; b=RXij9SpNrmNR7XRgAhCuPYIUDgZzbcQNI0fdMVxCi/Npqj+eYOhP8wC8fQB+MgHRTd 81LKVcQjpRnnWd1Vq3nrVEkRnNyerL8BqrsgJsSwn2/te7St4rAN+P14btz7HCg7qeDq 9czGr8EXpYwwsOxs0VfktMEbQ1yDXfDk45GJ/icwUc4X8O/KxeJf+Oq8hNFLSgfJuegL fTgwk272Imk/+9hlrpJfdsX3hh+kfsSWfJDcsi9EtumL3iUfa/KwjoTTeVhw9IX/1tK+ ZjTDlwCiZZ3Ucb1lGF5pMV20TGG1xZ/evuVGwrqtTRuvZiDQw2RV2bHCtLVSAzAnoJpR sbjg== X-Gm-Message-State: AIVw113gB7/oKI/ZKqil/0e0CbHF/wtes/GamEf0fLA3MORi8xfpP6JW Ra9inbweLQ8diYqsHoqXxJe7beIv1yxsV2Q= X-Received: by 10.176.69.132 with SMTP id u4mt871958uau.137.1500447798327; Wed, 19 Jul 2017 00:03:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Wed, 19 Jul 2017 00:03:17 -0700 (PDT) X-Originating-IP: [2001:67c:1232:144:6948:8365:3314:dc75] In-Reply-To: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> From: George Michaelson Date: Wed, 19 Jul 2017 09:03:17 +0200 Message-ID: Cc: dnsop WG , dnsop-chairs , draft-woodworth-bulk-rr@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:03:23 -0000 Read, support. This is a useful addition to document how to do something. Now, the 'outer' question of the value of reverse-DNS label binding, thats a different conversation. I can well imagine a bunch of bikeshed-painting, but lets focus on this as a technique for specifying programmatic population of a zone? I like it. So yea. I think we should have this. G On Tue, Jul 18, 2017 at 10:24 PM, IETF Secretariat wrote: > > The DNSOP WG has placed draft-woodworth-bulk-rr in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed Jul 19 00:23:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC43D131467 for ; Wed, 19 Jul 2017 00:22:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 j9vlFzLk_5Jo for ; Wed, 19 Jul 2017 00:22:57 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 41FD912EE45 for ; Wed, 19 Jul 2017 00:22:57 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s70so14155300pfs.0 for ; Wed, 19 Jul 2017 00:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JGgud/jU9fgcM9PyCyx+kPOKmIDFLu+/C+Mz/4ckVEU=; b=H1t41Q4/Ek5CAVELu/u5DdRZkxx/YUkg0x+sbxjaASULahX8bOn5TGfCx841lxEwPt val/rn6uo2iI2yv6DipdeXfrjTMpcilUXUoX9bt8SQpTkUaFVTdhC6ag6PU20tFCyoZh lML1be9O4QkZYzdFlicYeSAlYafJgCA6iT6+PfiuVRURn4kGfJlgOqIlrBhZySPjTjPk llKO+kB6t2x+2wGUYTOauCMlhUCEREJepr5zaibGplJv7FtafXHz4Dz9wzEHc7e/g5LC uDpLUNZczy0Y+orxNAZyo/pAN5EsAnI9ncVWruyYJFtslURvwOpdXE8XIzLqWytZTRPN QZSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JGgud/jU9fgcM9PyCyx+kPOKmIDFLu+/C+Mz/4ckVEU=; b=Id39E/jNSDXsnYtik/ytiD+4M8HYsoV2NNFYjhywyxDfEdSFeL9C4rh9dZCnV2SuKT 234Wkw+cZhhjUSVS3SDWlgH917J/9G8nX3CO+xbh0o5UsSvnwQJWBEKu2IR1g/wPC5If 41G5kldW4catmdTdy+TQH7TaGuB0fz7SgL1JmrlPD0Nfer8ENF3ZHkSFnnHUr/QAa7D/ Lz/rgR/0C5y0bfWXY7bObI0LnlNns1R/h3WHZA2V7eNnjuHvXwEiGHrGNu4c1qo3TrGD d5cU8RjjzRzNtAANwZueQ0Ss5uW2fxjSJPMkLC/xGof1/N/zvgCtubs63Lf971G2CHdD ZULg== X-Gm-Message-State: AIVw112d9kCrLUD2C56641/cVWGM0DEiBmRHK9IXFW6ojyV2VtcZGyl2 dQcjfk3dUf0VHMpFfFYBFTDVqa9lg4eSE9I= X-Received: by 10.98.15.71 with SMTP id x68mr1667911pfi.176.1500448976462; Wed, 19 Jul 2017 00:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 00:22:16 -0700 (PDT) From: Ted Lemon Date: Wed, 19 Jul 2017 09:22:16 +0200 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="001a1137741e3f02840554a68009" Archived-At: Subject: [DNSOP] Ordering requirement in draft-dnsop-session-signal X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:22:59 -0000 --001a1137741e3f02840554a68009 Content-Type: text/plain; charset="UTF-8" I was about to send this in a private message to Tom and Stuart on this topic, but I think it's actually the discussion that the working group needs to have about this, so I'm sending it here instead. The proposal we were discussing was whether to just drop the ordering requirement. I think that it actually makes a lot of sense for session signaling to impose an ordering constraint. It's a lot less useful if you can't be sure that a session signaling message will be applied to subsequent messages that are sent. It's true that we could put IDs on TLVs in messages that are session signaling messages, and, by doing so, effectively make messages idempotent, but to do it correctly, you still need a queue: if a subscribe message arrives after the unsubscribe that cancels it, the result can't be that you are subscribed. So in practice if you get an unsubscribe for an unrecognized ID, you have to remember that ID and then ignore the subscribe that follows it with the same ID. But more importantly, if a query to which a session signal was intended to apply follows the session signal on the way out, but arrives at the recipient (could be a client or server) before the session signal, it will be processed differently than if it arrives after. That doesn't make sense. We could say that session signaling messages do not contain state changes, and hence this can't ever happen, but that substantially reduces the utility of session signaling. We could also say that if a session signaling message applies to a message that follows it, the two messages should be tied together somehow, which would work for my use case, but I don't think it generalizes. This does complicate implementation for DNS-over-QUIC, but I think that's kind of too bad--if you are doing DNS-over-QUIC, you're going to need to be able to queue messages. If the queue gets really big, you have a problem with your connection: it would be better to drop it than to try to process messages out of order. I mentioned at the microphone that we should also consider whether non-session-signaling messages need to be processed in order. I believe the answer is that they need not be processed in order. We should just make that explicit, if it isn't already mentioned in the document (I didn't think to check last time I read the document). Finally, the question was raised whether "in order" means "in order of receipt" or "in order of transmission." I think the only interesting meaning of "in order" is "in order of transmission," and we need to have a way to signal that order: each session signaling message needs to have a sequence number, and the sequence numbers on session signaling messages need to be strictly monotonically increasing with wraparound. To make this work, QUIC encapsulateion has to encapsulate *every* message with a sequence number: if it's not a session signaling message, the sequence number doesn't increase, because we don't care about order in that case. Messages that are received that have a sequence number larger than the number of the most recently received session signaling message are queued until that message is received, whether they are session signaling messages or normal messages. This is only necessary for QUIC: TCP already ensures ordered delivery. --001a1137741e3f02840554a68009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was about to send this in a private message to Tom = and Stuart on this topic, but I think it's actually the discussion that= the working group needs to have about this, so I'm sending it here ins= tead. =C2=A0 The proposal we were discussing was whether to just drop the o= rdering requirement.

I think that it actually make= s a lot of sense for session signaling to impose an ordering constraint. = =C2=A0 It's a lot less useful if you can't be sure that a session s= ignaling message will be applied to subsequent messages that are sent.

It's true that we could put IDs on TLVs in message= s that are session signaling messages, and, by doing so, effectively make m= essages idempotent, but to do it correctly, you still need a queue: if a su= bscribe message arrives after the unsubscribe that cancels it, the result c= an't be that you are subscribed. =C2=A0 So in practice if you get an un= subscribe for an unrecognized ID, you have to remember that ID and then ign= ore the subscribe that follows it with the same ID.

But more importantly, if a query to which a session signal was intended t= o apply follows the session signal on the way out, but arrives at the recip= ient (could be a client or server) before the session signal, it will be pr= ocessed differently than if it arrives after. =C2=A0 That doesn't make = sense. =C2=A0 We could say that session signaling messages do not contain s= tate changes, and hence this can't ever happen, but that substantially = reduces the utility of session signaling. =C2=A0 We could also say that if = a session signaling message applies to a message that follows it, the two m= essages should be tied together somehow, which would work for my use case, = but I don't think it generalizes.

This does co= mplicate implementation for DNS-over-QUIC, but I think that's kind of t= oo bad--if you are doing DNS-over-QUIC, you're going to need to be able= to queue messages. =C2=A0 If the queue gets really big, you have a problem= with your connection: it would be better to drop it than to try to process= messages out of order.

I mentioned at the microph= one that we should also consider whether non-session-signaling messages nee= d to be processed in order. =C2=A0 I believe the answer is that they need n= ot be processed in order. =C2=A0 We should just make that explicit, if it i= sn't already mentioned in the document (I didn't think to check las= t time I read the document).

Finally, the question= was raised whether "in order" means "in order of receipt&qu= ot; or "in order of transmission." =C2=A0 I think the only intere= sting meaning of "in order" is "in order of transmission,&qu= ot; and we need to have a way to signal that order: each session signaling = message needs to have a sequence number, and the sequence numbers on sessio= n signaling messages need to be strictly monotonically increasing with wrap= around. =C2=A0 To make this work, QUIC encapsulateion has to encapsulate every=C2=A0message with a sequence number: if it's not a session s= ignaling message, the sequence number doesn't increase, because we don&= #39;t care about order in that case.

Messages that= are received that have a sequence number larger than the number of the mos= t recently received session signaling message are queued until that message= is received, whether they are session signaling messages or normal message= s.

This is only necessary for QUIC: TCP already en= sures ordered delivery.
--001a1137741e3f02840554a68009-- From nobody Wed Jul 19 00:58:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F091D131C08 for ; Wed, 19 Jul 2017 00:58:46 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 rFzDYWyKgveF for ; Wed, 19 Jul 2017 00:58:44 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9A490131BFE for ; Wed, 19 Jul 2017 00:58:44 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xC8YG47DWz4H; Wed, 19 Jul 2017 09:58:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1500451122; bh=a+qfUwU8DIiD0n435vLKmGRT0ePjGo+05+1qIZQmn1k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MWSlI1vrEGgMS1ufhlu4NnNJ9PAQ15iu1QlPiyrK8EJfWoHG6zGRMmCRyCPHqk1gk 2eoy4XPc3t1bYw6k2wPr4dmqr42d0kuYZfyCwhAHn8Lxsu9sKxOOQVwUqTg03/Ts4P TfQ8+rwJ+ctq5ctjbv45+/5uEkYc8FTyrAl8WLIA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NpVxMg_yIMfR; Wed, 19 Jul 2017 09:58:41 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 19 Jul 2017 09:58:41 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id B4EC74025B; Wed, 19 Jul 2017 03:58:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id B200A3F46B; Wed, 19 Jul 2017 03:58:39 -0400 (EDT) Date: Wed, 19 Jul 2017 03:58:38 -0400 (EDT) From: Paul Wouters To: George Michaelson cc: dnsop WG In-Reply-To: Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:58:47 -0000 On Wed, 19 Jul 2017, George Michaelson wrote: > Read, support. This is a useful addition to document how to do something. > > Now, the 'outer' question of the value of reverse-DNS label binding, > thats a different conversation. I can well imagine a bunch of > bikeshed-painting, but lets focus on this as a technique for > specifying programmatic population of a zone? I like it. I kind of disagree. We are adding something to DNS that's not just a new RRTYPE. It requires code changes and has a deployment and long tail. If the only result is that anti-spammers are no longer checking reverse PTR records, we end up with a feature in DNS that has no use, and the anti-spammers using another method to determine "inferior" IP addresses. DNS will be the only party left with some legacy complication. I would feel much better if there would be some real use csases to justify adding special code to DNS that will instantly become obsolete. Paul From nobody Wed Jul 19 01:33:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1597131C29 for ; Wed, 19 Jul 2017 01:33:56 -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, URIBL_BLOCKED=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 JaQrs9KTpcTe for ; Wed, 19 Jul 2017 01:33:55 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479AB131C2A for ; Wed, 19 Jul 2017 01:33:55 -0700 (PDT) Received: from [31.133.129.135] (unknown [IPv6:2001:67c:370:128:6d30:fc56:f7e2:69d]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 3B9A11BCE3; Wed, 19 Jul 2017 10:33:52 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Wed, 19 Jul 2017 10:33:47 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:33:57 -0000 Hello Suzanne, On 18 Jul 2017, at 14:13, Suzanne Woolf wrote: > If this is acceptable to the WG, we’ll keep the new draft with these > changes as a WG draft. Yes please! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Wed Jul 19 01:43:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836E3131C3D for ; Wed, 19 Jul 2017 01:43:01 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 DxemkK2ek-eC for ; Wed, 19 Jul 2017 01:42:59 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 C0CF7131C41 for ; Wed, 19 Jul 2017 01:42:58 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id k71so2115514wrc.2 for ; Wed, 19 Jul 2017 01:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=x0RvkLsUpv6wvqR+F8XLmxvA8DHLSUWsB89DNAGv6ow=; b=iEy/89i4AbmaNvwOCc17g1LJ6WDyakQJJ5SFGC6GOcvrPBFtXteX6v3swQ+YNxNBKH QDGFfacj93wQ9TW3NGjn7kMva0nsTFl16dgGOHBX6/mdUW7fnsVVyYKM6q1pTY6GwyfF 0PVbU9JcqnBCyKfnROCkuK1GVx+OtG7Z1A1DfTKybomT4CUg13fLBvsISoinBU+imtWY Z393yXaGAdCK+nj5XhMIR0vQ1SZ+j6iLfpPwc+M6QOBpi1CC2ESdwWe1MXhluEE6CbI6 aFgbn5LCBmyVodo3nCX992puSGx/8v9Bv1JuDyuL2ncN71Co2a71OtTv2iVf5pQazs3t IWJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=x0RvkLsUpv6wvqR+F8XLmxvA8DHLSUWsB89DNAGv6ow=; b=kmDRv6CLvaidMLk28n7oX4WnJUqMVFZK0DZ+3lXOKrK++xr/ayEr8nXJ+F7sGCx2pJ llnT1s9OGuHncYGqKuj7GHUq+MLq+WCMNeTMpjKx4RYrV6Ve3jFAmS76nOR3M8Q1u08/ LOKd6E5XVQeoACuIosQ2uJiS2kfbN0ivVrCUwuszuYSJabHytWCkIOU29Q+0MVhtwAaW qmbscEAnOZbizpfCTaTBv6US/ANOm+4klZCUM0KG45e/JtQ8QrJj2cm2VihzPe21jqzV 7I8OYEVUzEIuLjPLqVZ9/sUlCWmSNscv9GaZL5xlkHzFpyD+X2cCAVgFqwRFWrWIy8b1 rRtA== X-Gm-Message-State: AIVw110Xs5MIg1u1NiEKgRwucgdG7d5AZMUd3iS0ZXlrYI85dWIBE4IV J07MRsvlZKXCOzQfKEY= X-Received: by 10.223.128.177 with SMTP id 46mr3407626wrl.150.1500453776951; Wed, 19 Jul 2017 01:42:56 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:84df:4ec:c1b6:21a4? ([2001:67c:370:128:84df:4ec:c1b6:21a4]) by smtp.gmail.com with ESMTPSA id s2sm8144306wmb.27.2017.07.19.01.42.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 01:42:56 -0700 (PDT) From: Michael StJohns To: Wes Hardaker Cc: dnsop@ietf.org References: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> <77997330-f10c-22b3-4683-68e6d2a37cc0@nthpermutation.com> Message-ID: Date: Wed, 19 Jul 2017 04:42:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <77997330-f10c-22b3-4683-68e6d2a37cc0@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:43:01 -0000 On date time vs intervals - I finally realized why Wes and I are somewhat disconnected on this. 5011 was written as the protocol for the resolver and is totally interval driven. (E.g. query and retry timers are set and fire based on when the resolver performs an action). This document is being written for the zone publishers, and the process of publication is task driven and has humans as protocol element timers. The actual publication of a DNSSEC RRSIG is divorced from both the date/time of creation and the RRSig's actual inception and expiration dates. While there is a defined interval between inception and expiration, expiration occurs at a fixed point in time and that point in time is independent from the interval between publication and receipt by the client. In other words - the correct (or at least better and less subject to being misunderstood) way of describing the various points in time the publisher should do something is by referencing the fixed point in time (expiration) where both publisher and client agree that something happens and then figuring other fixed points in time from that point. Or to restate it again - "A publisher must wait until June 5th 2010" will always evaluate to the same date and time regardless of who calculates it and when they calculate it; "A publisher must wait 30 days" will not. So : " publicationAddWaitInterval :: = MAX (30 Days, originalTTL of NEW DNSKEY RRSet) + MAX ( all calculated queryIntervals for OLD and new RRSets) + addSlopInterval queryInterval ::= MAX (1 hour, MIN ( 15 days, .5 * expirationInterval DNSKey RRSet, .5 * originalTTL DNSKey RRSet) ) expirationInterval :: = expirationDate - inceptionDate addSlopInterval ::= 2 * MAX(originalTTL of any DNSKEY RRSet valid during the transition process) The publicationAddWaitDateTime is the date and time on which the publisher can assume that most of the 5011 capable resolvers have accomplished the addition of the new trust anchor to their trust anchor sets. That date is the addHoldDownTimeInterval AFTER the latest in time signature expiration date of any RRSet without the new key. This includes both published and unpublished RRSets. Publishers should refrain from creating or publishing DNSKEY RRSets signed exclusively by a new key until after this date. Specifically, the inception date of such an RRSig should be later than the publicationAddWaitDateTime" The addHoldDownTimeInterval above differs from what is in 5.1 section 2.4.1 in that this is the publishers view of when the new trust anchor is accepted by the resolver which may differ from a specific resolvers view (due to when things are actually sent and received). Section 2.4.1 has to be combined with the text in section 2.2 which states that the key isn't added until after the next time it is seen after the expiration of the add hold down. Also, the queryInterval term of this calculation should be the maximum of any DNSKEY RRSet seen during the transition - it's possible that the publisher may reduce the intervals or increase the intervals between RRSets and this provides the publisher with the worst case value that any given resolver should be using. Let's not confuse resolver numbers with publisher numbers and spend a bit of time to get the language clear correct and implementable. Mike From nobody Wed Jul 19 01:56:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37B9131C34 for ; Wed, 19 Jul 2017 01:56:50 -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] 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 wX8YXwYhSG24 for ; Wed, 19 Jul 2017 01:56:49 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 09E67131C3C for ; Wed, 19 Jul 2017 01:56:49 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 48F1731C83; Wed, 19 Jul 2017 10:56:46 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id 9728DEC0B1C; Wed, 19 Jul 2017 10:49:42 +0200 (CEST) Date: Wed, 19 Jul 2017 10:49:42 +0200 From: Stephane Bortzmeyer To: Shumon Huque Cc: "dnsop@ietf.org WG" Message-ID: <20170719084942.GA18413@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:56:50 -0000 On Tue, Jul 04, 2017 at 11:42:56AM -0400, Shumon Huque wrote a message of 108 lines which said: > We've posted a new draft on algorithm negotiation which we're hoping to > discuss at IETF99 For the discussion on thursday: > In contrast, many other security protocols, like TLS, IKE, SSH and > others, support an algorithm or cipher suite negotiation mechanism TLS and SSH are end-to-end. Not the DNS, and it makes things more complicated (see section 6). > because fragments are often blocked by network security devices. by STUPID AND BROKEN network security devices. Otherwise, you do not put the blame where it belongs. > As can be readily seen from the RSA to ECDSA transition, very few > zones have transitioned from RSA to ECDSA, True, but not for the reasons of the response size. Both for my employer's zones and for my own personal zones, the big issue is the lack of support in tools like HSMs, the difficulty of algorithm rollover, and the fact that tools like OpenDNSSEC don't make it easy. So, we have apparently a disagreement on the basic diagnostic. > the resolver has selectively cached signatures of a subset of > algorithms supported by the zon How does it know? I mean, in the response from the authoritative server, nothing indicates if the signatures are a subset or not. Suppose I send the list ECDSA;RSA, and I receive only ECDSA signatures. How the resolver/cache would now if it was a complete list? > but prefers algorithms known to be supported for the name, Again, where does this knowledge come from? From nobody Wed Jul 19 02:04:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD29F131C53 for ; Wed, 19 Jul 2017 02:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kbxtGZyOdXu4 for ; Wed, 19 Jul 2017 02:04:44 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 5048512ECC0 for ; Wed, 19 Jul 2017 02:04:42 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w126so95868355wme.0 for ; Wed, 19 Jul 2017 02:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:reply-to:message-id:date:user-agent:mime-version :content-language; bh=f8jc12fIgaf118XLwK/lIdi/rbu0H17IPWJxBo04mOU=; b=LhvduocehaVVQrp5LcGWhlCTMrMMAcYh6ouuCdj+Uh+MG6WW52vIgVKtp2alYmavY5 LTPoyQqmRpfcZWSTawDvfdCYNodMHFLzi7ZJOhee7z+/dJZFCTmjsu9sU2xX8uyjj/Ld KHq9GiRCxkgA0XGAbUKFU3zRjoqP315Y/vpFrmC+VaqmkqOgo0dYPEOhbwxbrvlYLjle wD9TBnRmK7xa9e60niXaMAZWzOzpI8tnuGvzWznDuFOQuSXPn+kMGOC0ee9CY0gEIMvn JP0f5SYUjIH0rlolqnDEbuVfHYvnYFQwBcBCearZsjWTZe3ZTsIJ9IOjMEOtOiv0D9vF mykg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:reply-to:message-id:date :user-agent:mime-version:content-language; bh=f8jc12fIgaf118XLwK/lIdi/rbu0H17IPWJxBo04mOU=; b=TGdQTyhbO0uFCAB4/5kAmW7+7e2vc6YtUj5SyJlgCHgI3c05P6kHe+UUXy0LFCmSd8 lgS2xY0GovtH8rLPt9Ggr+XGsvnsBaij72xZqDCqRA7WyZQHEss1n4YUUxXl8hYhbpTs ty6RzVUCU6FQIieFLFZnVUhHY6X3PbS/i9v/HYRPblKNJoctOd92BUiQoNacob2OChxk 0xTEZj86xk2kAVVTOnpqdd9it/TImlRDlzgK32ZZnfN/mOQPIyzVcGLesWj1mgrmtila f7dIaStvX1QKK6HgoSO3nxXpbI9kTlzue2PdihkI3oyobvcxD7rkBYsghfm/tVz84hX+ FlWw== X-Gm-Message-State: AIVw111AeXvr7P5Gb6rowB/JIOaXeor3bKv3z8Z7R++3ZjsGJrfd7oFE gHaqsOiY2QDRso6nTIU= X-Received: by 10.80.160.198 with SMTP id 64mr5048312edo.177.1500455080694; Wed, 19 Jul 2017 02:04:40 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com ([2001:67c:370:128:e561:9e1c:d4b4:8121]) by smtp.googlemail.com with ESMTPSA id l3sm3574975edc.32.2017.07.19.02.04.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 02:04:39 -0700 (PDT) To: dnsop From: Tim Wicinski Reply-To: "dnsop-chairs@ietf.org" Message-ID: <2561eca1-82eb-4b88-c1dc-de6b2fa31434@gmail.com> Date: Wed, 19 Jul 2017 11:04:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------AFA5BD6B4A5BE27C98F5D2FA" Content-Language: en-US Archived-At: Subject: [DNSOP] Draft Minutes from DNSOP Session I X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:04:49 -0000 This is a multi-part message in MIME format. --------------AFA5BD6B4A5BE27C98F5D2FA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks to Paul Hoffman for capturing the conversations during this session. Please take a look and if you spot any errors please get in touch with the chairs: https://www.ietf.org/proceedings/99/minutes/minutes-99-dnsop-02.txt thanks tim/suzanne --------------AFA5BD6B4A5BE27C98F5D2FA Content-Type: text/plain; charset=UTF-8; name="dnsop-ietf99-minutes-1.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dnsop-ietf99-minutes-1.txt" ZG5zb3AtaWV0Zjk5LW1pbnV0ZXMtMS50eHQKCkROU09QIFdHClR1ZXNkYXkgMTggSnVseSAy MDE3LCAxNTo1MC0xNzo1MCBDRVNUIChVVEMrMikKQ29uZ3Jlc3MgSGFsbCBJSQpUaW0gV2lj aW5za2kgPHRqdy5pZXRmQGdtYWlsLmNvbT4sIFN1emFubmUgV29vbGYgPHN1endvcmxkd2lk ZUBnbWFpbC5jb20+Ck1pbnV0ZXMgdGFrZW4gYnkgUGF1bCBIb2ZmbWFuClRleHQgZnJvbSB0 aGUgc2xpZGVzIGlzIG5vdCByZXByb2R1Y2VkIGhlcmUKClVwZGF0ZXMgb2YgT2xkIFdvcmsK ICAgIExvdCBpbiB0aGUgcXVldWUKClRTSUcgdnVsbmVyYWJpbGl0eQogICAgRE5TIHZlbmRv cnMgZ290IHRvZ2V0aGVyIG9uIFN1bmRheSB0byB0YWxrIGluZm9ybWFsbHkKICAgIERlY2lk ZWQgdGhhdCB0aGVyZSBuZWVkZWQgdG8gdXBkYXRlIFJGQyAyODQ1CiAgICBSRkMgMjg0NSBk b2Vzbid0IGNvdmVyIGFsbCB0aGUgY2FzZXMKICAgIFdpbGwgc3RhcnQgb24gYSAtYmlzIHZl cnNpb24KCmRyYWZ0LWlldGYtZG5zb3AtdGVybWlub2xvZ3ktYmlzOyBQYXVsIEhvZmZtYW4K ICAgIE5vIHNsaWRlcwogICAgV2lsbCBiZSBicmluZ2luZyB1cCB0b3BpY3MgdGhhdCB3ZXJl IHB1bnRlZCBpbiBSRkMgNzcxOQogICAgV2FudHMgbG90cyBtb3JlIHJldmlldwogICAgUGxl YXNlIG9wZW4gaXNzdWVzIG9uIHRoZSBHaXRIdWIgcmVwbyAoYnV0IFBhdWwgd2lsbCBlbmR0 ZXIgdGhlbSBpZiB0aGV5IGNvbWUgZnJvbSB0aGUgbWFpbGluZyBsaXN0KQoKZHJhZnQtaWV0 Zi1kbnNvcC1kbnMtY2FwdHVyZS1mb3JtYXQ6IEppbSBIYWd1ZQogICAgUGF1bDogV2hhdCBp cyB0aGUgcmVhc29uIGZvciB0aGluZ3MgYmVpbmcgbWFuZGF0b3J5PwogICAgICAgIEppbSBI OiBUbyBtYWtlIHJlY29uc3RydWN0aW9uIHBvc3NpYmxlCiAgICAgICAgICAgIFRoYXQncyB0 aGUgb25seSBvbmUKICAgIEppbSBSZWlkOiBBbnkgbmV3cyBvbiBJUFI/CiAgICAgICAgSmlt IEg6IENvcHlyaWdodCBpcyBmcm9tIElDQU5OLCB0YWxrIHRvIFRlcnJ5IE1hbmRlcnNvbgog ICAgU3RlcGhhbmUgQm9ydHptZXllcjogTWF5YmUgaGF2ZSB0d28gcHJvZmlsZXMsIG9uZSB3 aXRoIG1hbmRhdG9yeSBvbmUgd2l0aCBub3RoaW5nIG1hbmRhdG9yeQogICAgICAgIEppbSBI OiBNYXliZSBuZWVkIG1vcmUgdGhhbiB0d28sIGJ1dCB3ZSBjYW4ndCBrbm93IHRoYXQgbm93 CiAgICAgICAgICAgIE5lZWQgdG8gaGFuZGxlIG9wdGlvbmFsIGRhdGEgaW4gc29tZSBvdGhl ciBtZWFucwogICAgUm95IEFyZW5kczogSGFwcHkgdXNlciBvZiB0aGUgZm9ybWF0CiAgICAg ICAgSXMgdGhlcmUgYSBtYWlsaW5nIGxpc3Q/CiAgICAgICAgSmltIEg6IFVzZSB0aGUgZG5z LXN0YXRzIG1haWxpbmcgbGlzdAogICAgICAgIFNhcmEgRGlja2Vuc29uOiBXYW50cyB0byBz ZWUgbW9yZSB0cmFmZmljIG9uIHRoZSBETlNPUCBtYWlsaW5nIGxpc3Qgb2Ygc3BlY2lmaWMg dXNlIGNhc2VzCgpkcmFmdC1pZXRmLWRuc29wLXJmYzUwMTEtc2VjdXJpdHktY29uc2lkZXJh dGlvbnM6IFdlcyBIYXJkYWtlcgogICAgTWlrZSBTdC4gSm9obnM6ICIzMCBkYXlzIiBpcyB1 c2VkIHR3aWNlIGluIFJGQyA1MDExIGZvciBkaWZmZXJlbnQgdGhpbmdzCiAgICBNaWtlOiBU aGUgc3VtIG9mIGEgd2FsbCBjbG9jayB0aW1lIGFuZCBhbiBpbnRlcnZhbCBpcyBhIHdhbGwg Y2xvY2sgdGltZQogICAgV2FycmVuIEtVbWFyaTogV2UgYXJlIG5vdCAiYWRkaW5nIiBhbnl0 aGluZwogICAgT2xhZnVyIEd1ZG11bmRzc29uOiBUaGlzIGlzIHdvcnN0IGNhc2UgdGltZXMK ICAgIFRpbTogVXNlZCBpbnRlcnZhbCB0aW1lcyBpbiBhbiBlYXJsaWVyIFJGQwogICAgU3V6 YW5uZTogVGhpcyBjb3VsZCBiZSByZWFkeSBmb3IgV0cgTGFzdCBDYWxsCgpkcmFmdC1pZXRm LWRuc29wLWFuYW1lOiBQZXRlciB2YW4gRGlqawogICAgT25kcmVqIFN1cnk6IEZpbmRzIHRo ZSBkcmFmdCBjb25mdXNpbmcKICAgICAgICBQZXRlcjogQWdyZWVzIHRoYXQgdGhlIGRyYWZ0 IGhhcyBncm93biBpbiBiYWQgd2F5cywgYW5kIHdpbGwgZml4CiAgICBTdGVwaGFuZTogVGhp cyBpcyBqdXN0IGZvciBIVFRQLCBidXQgc3VwcG9ydHMgdGhlIGRyYWZ0IGFueXdheQogICAg QmVubm8gT3ZlcmVpbmRlcjogSGFzIGEgY29uY2VybiB0aGF0IHdoZW4gdGhlIHpvbmUgb3du ZXIgaXMgbm90IHRoZSB6b25lIG9wZXJhdG9yCiAgICAgICAgV2FudHMgYSBzZWN1cml0eSBj b25zaWRlcmF0aW9uIGFib3V0IG9ubGluZSBzaWduaW5nIGJlY2F1c2Ugb2YgdGhlIGRpZmZl cmVuY2UKICAgICAgICBQZXRlcjogV2UgYXJlIHN0cmV0Y2hpbmcgdGhlIGRlZmluaXRpb24g b2YgIm9mZmxpbmUiLCBzaG91bGQgYmUgZml4ZWQKICAgIEpvaG4gTGV2aW5lOiBOZXZlciB3 YW50cyB0byBkbyBvbmxpbmUgc2lnbmluZywgaG9wZXMgdGhhdCB0aGlzIGNhbiBzZXR0bGUg aXQKICAgICAgICBIYXMgYSBjb25jZXJuIHRoYXQgcGVvcGxlIHdpbGwgd2FudCBTUlYgcmVj b3JkcyBhbmQvb3IgTVggYW5kIHdvdWxkIHdhbnQgdG8gc3dlZXAgdGhlbSBpbiBhcyB3ZWxs CiAgICAgICAgUGV0ZXI6IFRoYXQgd291bGQgdGFrZSB0aGUgZHJhZnQgZnVydGhlciBmcm9t IHRoZSBjdXJyZW50CiAgICBPbmRyZWogPzogRG9lc24ndCBsaWtlIHRoZSBpZGVhIG9mIG9u bGluZSBzaWduaW5nIGZvciBldmVyeXRoaW5nCiAgICAgICAgV291bGQgcHJlZmVyIGRyYWZ0 IHdhcyBtb3JlIGV4cGxpY2l0IHRoYXQgeW91IGRvbid0IG5lZWQgdG8gZG8gaXQKICAgIEFu ZHJldyBTdWxsaXZhbjogQ29uY2VybmVkIHRoYXQgcGVvcGxlIGFyZSBzYXlpbmcgdGhhdCBp dCBpcyB0b28gY29tcGxleAogICAgICAgIERvY3VtZW50IHNob3VsZCBzYXkgd2h5IHRoaXMg aXMgaGFyZAogICAgICAgIFRoaXMgd2lsbCBoZWxwIGV4cGxhaW4gdGhlIHRyYWRlb2ZmcyB0 aGF0IHdlcmUgY2hvc2VuLCBnZXQgcXVpY2tlciBjb252ZXJnZW5jZQoKZHJhZnQtaWV0Zi1k bnNvcC1zZXNzaW9uLXNpZ25hbDogU2FyYSBEaWNraW5zb24KICAgIENocmlzdGlhbiBIdWl0 ZW1hOiBRVUlDIGRvZXMgbm90IGd1YXJhbmVlIHRoZSBvcmRlciwgYnV0IG5laXRoZXIgZG9l cyBVRFAKICAgIFN0dWFydCBDaGVzaGlyZTogVGhlcmUgbWF5IGJlIG9wZXJhdGlvbnMgdGhh dCBjcmVhdGUgc3RhdGUgdGhhdCBtdXN0IGJlIGRvbmUgYmVmb3JlIGZvbGxvd2luZyBvbmVz CiAgICBDaHJpc3RpYW46IENhbiBkbyB0aGlzIGluIGRpZmZlcmVudCB3YXlzCiAgICBTdHVh cnQ6IFB1c2ggbm90aWZpY2F0aW9uIG5lZWQgb3JkZXJpbmcKICAgICAgICBJZiB3ZSB1c2Ug YSB0cmFuc3BvcnQgdGhhdCBnaXZlcyBvcmRlcmluZwogICAgICAgIENocmlzdGlhbjogWW91 IGFyZSBtYW5kYXRpbmcgYSBzZXF1ZW5jaW5nIHRyYW5zcG9ydAogICAgVGVkIExlbW9uOiBT ZXNzaW9uIHNpZ25hbGx5IGNhcnJpZXMgc3RhdGUKICAgICAgICBZb3UgZWl0aGVyIGhhdmUg b3JkZXIsIG9yIG5vdAogICAgICAgIFNhcmE6IFdlIG5lZWQgdG8gbWFrZSB0aGlzIGNsZWFy ZXIKICAgIEFuZHJldzogVGhlcmUgd2VyZSBvdGhlciB1c2VzIGZvciB0aGlzCiAgICAgICAg TWF5YmUgdXNlIEROUyBVcGRhdGUgdHlwZSBvcmRlcmluZwogICAgUGV0ciDFoHBhxI1lazog VGhpcyBpcyBETlMgdjEgdW5kZXIgdGhpcyBuZXcgdmVyc2lvbgogICAgT25kcmVqIFM6IFRv cm4gYWJvdXQgdGhlIG5ldyBmb3JtYXQKICAgICAgICBQZW9wbGUgd2hvIGFyZSBub3QgaGVy ZSB3b24ndCBrbm93IGFib3V0IHRoZSBuZXcgZm9ybWF0CiAgICAgICAgQnV0IGJyZWFraW5n IHRoaXMgYmFycmllciB3b3VsZCBsZXQgdXMgZml4IHRoaW5ncyB0aGF0IHdlIGRpZCB3cm9u ZyBpbiB0aGUgcGFzdAogICAgICAgIERvZXNuJ3QgbGlrZSBicmVha2luZyBhbGwgZXh0ZW5z aW9ucyBieSAiSSdsbCBkbyBpdCBhcyBhIFRMViBhcyB3ZWxsIgogICAgVGVkOiBEdXBsaWNh dGlvbiBpcyBhIHJlYWwgaXNzdWUKICAgICAgICBFRE5TMCBzdWNrcywgaXQgaXMgaGFyZCB0 byB3b3JrIHdpdGgsIGl0IGlzIGFuIFJSCiAgICAgICAgVGhpcyBpcyBmb3IgcmVwcmVzZW50 aW5nIHRoaW5ncyBub3QgYW4gUlIKICAgICAgICBUb3RhbGx5IGZsZXhpYmxlIGZvcm1hdAog ICAgICAgIFlvdSB3b3VsZCBoYXZlIHRvIGJlIHJlYWxseSBicm9rZW4gaWYgeW91IHRyaWVk IHRvIHBhcnNlIHRoaXMgYXMgRE5TCiAgICBNYXR0IFBvdW5zZXR0OiBUTFZzIHNlcGFyYXRl IHRoZSBjb250cm9sIHBsYW5lIGZyb20gZGF0YSBwbGFuZSwgd2hpY2ggaXMgZ29vZAogICAg ICAgIENvbmNlcm5lZCB3aXRoIGVtYmVkZGluZyBETlMgbWVzc2FnZXMgaW4gVExWcwogICAg ICAgIFNvcnQgb2YgYSBsYXllciB2aW9sYXRpb24KICAgIFN0dWFydDogVGhvdWdodCB3ZSB3 ZXJlIGVtYnJhY2luZyB0aGlzIGRvY3VtZW50LCBub3QgY2hhbmdpbmcgaXQKICAgICAgICBB biBFRE4wIGlzIG5laXRoZXIgYW4gUlIgbm9yIG5vdCBhbiBSUgogICAgICAgIFRoZSBXaXJl c2hhcmsgZGVjb2RlciBoYXMgdG8gZGlzcGxheSBkaWZmZXJlbnQgdGhpbmdzIGZvciB0aGF0 IHJlY29yZAogICAgICAgICAgICBDYWNoZXMgbmVlZCB0byBrbm93IG5vdCB0byB1c2UgdGhl IFRUTAogICAgRnJhbmNpcyBEdXBvbnQ6IFRoaXMgaXMgYSB0b3RhbGx5IG5ldyBwcm90b2Nv bCwgYW5kIHN0YXJ0IGZyb20gc2NyYXRjaAogICAgICAgIFNvIGRvbid0IHJldXNlIGFueXRo aW5nCiAgICBUb20gUHVzaXRlcmk6IExpa2VzIHRoZSBUTFYgZm9ybWF0IGJlY2F1c2UgaXQg bWFrZXMgeW91IHRoaW5rIHNlcGFyYXRlbHkKICAgIFN1emFubmU6IEdvb2QgZm9kZGVyIGZv ciBhbiBpbnRlcmltCiAgICBUaW06IFdlIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgcGVvcGxl IHNlZSB0aGF0IHdlJ3JlIG1ha2luZyBicmVha2FnZQoKZHJhZnQtd29vZHdvcnRoLWJ1bGst cnI6IERhdmlkIExhd3JlbmNlCiAgICBQZXRlciB2RDogQlVMSyBkb2Vzbid0IHdvcmsgZm9y IHNlY29uZGFyaWVzCiAgICBSYWxmIFdlYmVyOiBUaGlzIGhhcyBzb21lIG9kZCBzaWRlLWVm ZmVjdHMKICAgIFBhdWwgV291dGVyczogQ2FuIHlvdSBzZWUgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiBQVFIgcmVjb3JkcyBhbmQKICAgIEpvaG4gTDogVGhpcyBpcyBsZXNzIGhvcnJpYmxl IHRoYW4gcHJldmlvdXMgdmVyc2lvbgogICAgICAgIFRoZXJlIGFyZSBvdGhlciB0aGluZ3Mg bGlrZSB0aGlzIHRoYXQgbm8gb25lIGFza2VkIHRvIHN0YW5kYXJkaXplCiAgICAgICAgV2h5 IGRvbid0IHlvdSBqdXN0IHdyaXRlIHRoaXMgZm9yIHlvdXJzZWx2ZXM/CiAgICAgICAgSWYg eW91IGRvIHRoaXMsIHlvdSBoYXZlIHRvIGRvIG9ubGluZSBzaWduaW5nLCBkb24ndCBhc2sg cGVvcGxlCiAgICBPbmRyZWogUzogQWdyZWVzIHdpdGggSm9obgogICAgICAgIE1heWJlIGFk ZCBhIG5ldyBETlNLRVkgdHlwZSB0aGF0IGlzIGZvciBvbmxpbmUvb2ZmbGluZSBrZXkKICAg IEFuZHJldzogVGhlIHJlYXNvbiBub3QgdG8gImp1c3QgZG8gdGhpcyB3aXRoIGFsbCB5b3Vy IGZyaWVuZHMiIGlzIHRvIG1ha2UgbW9yZSBjb21wZXRpdGlvbiBhbmQgaGF2ZSBhIGJldHRl ciBlY29zeXN0ZW0KICAgICAgICBEYXZpZDogTXkgZW1wbG95ZXIgY2FuIGRvIHRoaXMgYWxy ZWFkeSwgYnV0IG11bHRpLXZlbmRvciB3b3VsZCBiZSBiZXR0ZXIKCgpkcmFmdC10YWxlLWRu c29wLXNlcnZlLXN0YWxlOiBEYXZpZCBMYXdyZW5jZQogICAgUmFsZiBXZWJlcjogSHVnZSBk ZXZpYXRpb24gd2FzIHdoYXQgdGhlIHByb3RvY29sIHdhcyBzdXBwb3NlZCB0byBiZSBkb2lu ZwogICAgICAgIFdyaXRlIG1vcmUgdXAgb24gdGhlIHJlcXVpcmVtZW50cwogICAgICAgIEZh ciB0b28gZGV0YWlsZWQgZm9yIGRlcGxveW1lbnQKICAgICAgICBNYXliZSBub3QgYmUgc3Rh bmRhcmRzIHRyYWNrLCBzaG91bGQgYmUgZXhwZXJpbWVudGFsCiAgICAgICAgVGhpcyBpcyBq dXN0IG9uZSBhcHByb2FjaAogICAgICAgIFdhcnJlbjogSWYgb3RoZXIgaW1wbGVtZW50YXRp b25zIHdhbnQgdG8gZGVzY3JpYmUgaG93IHRvIGRvIHRoaXMsIHRoYXQncyBncmVhdAogICAg ICAgIFJhbGY6IExldCBpbXBsZW1lbnRvcnMgZG8gaXQgZGlmZmVyZW50IHdheXMKICAgICAg ICBEYXZpZDogTWF5YmUgbGF5IG91dCBhdCBsZWFzdCBvbmUgd2F5CiAgICBCZW5ubzogU2lt aWxhciBxdWVzdGlvbnMgYWJvdXQgSVBSCiAgICAgICAgT3BlbkROUyBoYXMgc29tZQogICAg ICAgIFdhcnJlbjogTm90IGNsZWFyIGlmIGl0IGFwcGxpZXMKICAgIE9uZHJlaiBTOiBBZ3Jl ZXMgd2l0aCBSYWxmCiAgICAgICAgRG9lc24ndCB0aGluayBoYXJkIHRpbWVycyBhcmUgY29y cmVjdAogICAgICAgICAgICBTaG91bGQgYmUgZGVyaXZlZCBmcm9tIG9yaWdpbmFsIFRUTAog ICAgICAgICAgICBTaG91bGQgbm90IHN0cmV0Y2ggYSAzMC1zZWNvbmQgVFRMIHRvIGEgd2Vl awogICAgR2lvdmFuaSBNb3VyYTogVGhpcyBzZWVtcyB1c2VmdWwgYWZ0ZXIgc29tZSBjaGFu Z2VzCgpkcmFmdC1tdWtzLWRuc29wLWRucy1vcHBvcnR1bmlzdGljLXJlZnJlc2g6IFN0ZXBo ZW4gTW9ycmlzCiAgICBTdXphbm5lOiBXZSBuZWVkIHJldmlld2VycwogICAgTGFycy1Kb2hh biBMaW1hbjogVGhpcyBpcyBvbmx5IHJlbGV2YW50IHdoZW4geW91J3JlIHRhbGtpbmcgdG8g YXV0aG9yaXRhdGl2ZQogICAgT25kcmVqIFM6IE9ubHkgbWFyZ2luYWxseSB1c2VmdWwKICAg IFJveSBBcmVuZHM6IExvdmVzIHRoZSBpZGVhCiAgICBNYXR0OiBTZWVtcyBsaWtlIGl0IG1p Z2h0IGJlIHVzZWZ1bAogICAgICAgIFdvcnJpZWQgYWJvdXQgZXh0ZW5kaW5nIFRUTCBvbiBO UyByZWNvcmRzIG9yIFJSU0lHCiAgICBXYXJyZW46IFRoaXMgaXMgcmVhbGx5IGNvb2wKICAg ICAgICBOb3Qgc3VyZSBpZiBpdCBhbGwgdGhhdCB1c2VmdWwgYmVjYXVzZSB5b3UgaGF2ZSB0 byBsb29rIGludG8gdGhlIHpvbmUKICAgIEFsZXg6IEZpbmRzIHRoaXMgaW50ZXJlc3RpbmcK ICAgICAgICBDb3VsZCB5b3Ugc2ltdWxhdGUgdGhpcwogICAgICAgIE1heWJlIGhhdmUgYW4g RUROUyB0aGF0IHJldHVybnMgdGhlIHRpbWVzdGFtcAogICAgU2hhbmU6IENhbiBsb29rIGF0 IGF1dGhvcml0YXRpdmUgc2VydmVyIGxvZyBhbmQgZXN0aW1hdGUgdGhlIHZhbHVlIHRoaXMg d291bGQgaGF2ZSBoYWQKICAgICAgICBJZiB5b3UgaGF2ZSBhY2Nlc3MgdG8gbGFyZ2UgYXV0 aG9yaXRhdGl2ZSBsb2dzLCB0YWxrIHRvIG1lIHNvIHdlIGNhbiBkbyBtb3JlIG1lYXN1cmVt ZW50cwogICAgSmltIFI6IE1heWJlIHVzZSBhIHRpbWVzdGFtcAogICAgUmFsZjogVGhlcmUg YXJlIHNlcnZlcnMgdGhhdCBoYXZlIG5vIGlkZWEgb2Ygc2VyaWFsIG9yIGxhc3QgdXBkYXRl CiAgICAgICAgU3RlcGhlbjogVGhpcyBpcyBjb21wbGV0ZWx5IG9wdGlvbmFsCg== --------------AFA5BD6B4A5BE27C98F5D2FA-- From nobody Wed Jul 19 02:07:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6961317AD for ; Wed, 19 Jul 2017 02:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wJhrDnjtlpjw for ; Wed, 19 Jul 2017 02:07:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C095912ECC0 for ; Wed, 19 Jul 2017 02:07:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6J8ol1c028029; Wed, 19 Jul 2017 10:50:47 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707190850.v6J8ol1c028029@givry.fdupont.fr> From: Francis Dupont To: Mukund Sivaraman cc: dnsop@ietf.org In-reply-to: Your message of Tue, 18 Jul 2017 17:27:39 +0530. <20170718115739.GA32524@jurassic> Date: Wed, 19 Jul 2017 10:50:47 +0200 Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:07:23 -0000 In your previous mail you wrote: > NSEC needs no keys, only their RRSIGs would which wouldn't exist in > unsigned zones. In this case the unsigned NSEC would also not be part of > the zone (it would have to be synthesized and maintained outside the > zone). => but it is created by an authoritative server, isn't it? And as it is synthesized I can't see a good reason to use NSEC3 instead. > Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix > entire zones, when it was discussed, Mark Andrews suggested that > requiring DNS COOKIE to further reduce the chance of cache poisoning > (more than source port randomization and random message ID) could be a > reasonable idea to think about. => it adds a nonce so another (short) bunch of unpredictable bits. As NSEC is not signed it is more than vulnerable to on-the-path attacks. I am afraid it is first a massive zone destruction weapon and after perhaps an optimization... > > It seems easier to remember that DNSSEC offers proofs for denial of > > existence. => still applies... Regards Francis.Dupont@fdupont.fr PS: really if this is deployed I can see more "interesting" ways for misuses than real benefits. Of course it can be a mean to make zone managers to rush on DNSSEC... From nobody Wed Jul 19 02:37:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6D131C6F for ; Wed, 19 Jul 2017 02:37:23 -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_PASS=-0.001, URIBL_BLOCKED=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 sKoXolwKMnOz for ; Wed, 19 Jul 2017 02:37:22 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 D138F131C68 for ; Wed, 19 Jul 2017 02:37:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42477) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXlPx-000bHa-fi (Exim 4.89) (return-path ); Wed, 19 Jul 2017 10:37:17 +0100 Date: Wed, 19 Jul 2017 10:37:16 +0100 From: Tony Finch To: Paul Wouters cc: George Michaelson , dnsop WG In-Reply-To: Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:37:24 -0000 Paul Wouters wrote: > > I would feel much better if there would be some real use csases to > justify adding special code to DNS that will instantly become obsolete. Yes. For IPv4 I can't see what advantage BULK has over $GENERATE or similar back-end provisioning scripts. For IPv6, if we have any reverse DNS at all for end-user devices it'll probably be just a wildcard pointing to a placeholder record identifying the VLAN. BULK seems like far too much cleverness applied to far too small a problem. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Hebrides, Bailey: Southeast, becoming cyclonic, 5 to 7, perhaps gale 8 later. Moderate or rough, occasionally very rough later. Rain or showers. Good, occasionally poor. From nobody Wed Jul 19 02:40:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9C131C4F for ; Wed, 19 Jul 2017 02:40:12 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 L968HlVHlZDz for ; Wed, 19 Jul 2017 02:40:10 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABAF12EAF7 for ; Wed, 19 Jul 2017 02:40:10 -0700 (PDT) Received: from dhcp-8e9b.meeting.ietf.org (dhcp-8e9b.meeting.ietf.org [31.133.142.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 74E242421527; Wed, 19 Jul 2017 09:40:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: Date: Wed, 19 Jul 2017 10:40:08 +0100 Cc: dnsop WG Content-Transfer-Encoding: 7bit Message-Id: <57877158-938B-4BA4-911F-AE1ECF73EAEB@rfc1035.com> References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> To: Tony Finch X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:40:12 -0000 > On 19 Jul 2017, at 10:37, Tony Finch wrote: > > BULK seems like far too much cleverness applied to far too small a problem. +1. I'm not convinced there is a problem here that needs fixing. From nobody Wed Jul 19 02:49:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD42131950 for ; Wed, 19 Jul 2017 02:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 iCpipUHz2fNi for ; Wed, 19 Jul 2017 02:49:39 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 8A87E126C0F for ; Wed, 19 Jul 2017 02:49:39 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:1dfc:dfb0:d149:8bac] (unknown [IPv6:2001:67c:370:128:1dfc:dfb0:d149:8bac]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 13FDDBD9D; Wed, 19 Jul 2017 11:49:37 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1500457777; bh=YbExPMY5zjNGCNxdTLwe3+/LwBqGpurkrLTU2vuV9Qg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=IP61uDPEx5GGXxoHMTxlIXvGOJk0Gip4yyt7Fy0ZRwxNpuGSy8ycX5SrITpEw+sK/ zoIpWFrW7NKX7fYQ5NgtKYD6HhcNTn0dNz28NnA5Ff7LrtAebRokC17sxvVyKb3z+o B7k+e2BG9vx0HpUPVkNOVP+3C6TRysF02XuRQOG0= To: Tony Finch Cc: dnsop@ietf.org References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> From: Willem Toorop Message-ID: <357beca7-84e5-81b9-5d2e-88a31684625a@nlnetlabs.nl> Date: Wed, 19 Jul 2017 11:49:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:49:41 -0000 Op 18-07-17 om 18:09 schreef Tony Finch: > The other kind of DNS server that might be able to do something useful > with ANAME is a recursive server, so it could co-operate nicely with > authoritative servers that are playing clever tricks. But the rDNS will > have to be careful about not breaking downstream validators. > > Say (for example) my zone has: > > dotat.at. ANAME www.chiark.greenend.org.uk. > dotat.at. RRSIG ANAME > dotat.at. A 212.13.197.229 > dotat.at. RRSIG A > dotat.at. AAAA 2001:ba8:1e3:: > dotat.at. RRSIG AAAA > > A client queries its resolver for dotat.at A, but chiark has renumbered, > so the client gets a response from the ANAME-aware resolver like below. A > validating ANAME-aware client can see it should use the additional address > 212.13.197.231 in preference to the address in the answer. > > ; ANSWER > dotat.at. A 212.13.197.229 > dotat.at. RRSIG A > > ; ADDITIONAL > dotat.at. AAAA 2001:ba8:1e3:: > dotat.at. RRSIG AAAA > dotat.at. ANAME www.chiark.greenend.org.uk. > dotat.at. RRSIG ANAME > www.chiark.greenend.org.uk. A 212.13.197.231 > www.chiark.greenend.org.uk. RRSIG A > www.chiark.greenend.org.uk. AAAA 2001:ba8:1e3:: > www.chiark.greenend.org.uk. RRSIG AAAA > > Note that neither the resolver nor the client needs any algorithm updates > to avoid being confused by this additional information; they just need a > code update so that they are able to make good use of it. > > If the resolver knows the client is DNSSEC-oblivious then it can do the > substitution itself and return a simple answer like this: > > dotat.at. A 212.13.197.231 > > Validating but ANAME-oblivious resolvers won't get to enjoy clever > latency minimization tricks. Yes! This should be included in the aname draft. Thanks, -- Willem > > Tony. > From nobody Wed Jul 19 03:16:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC35131C78 for ; Wed, 19 Jul 2017 03:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jnGGd6d8wKM9 for ; Wed, 19 Jul 2017 03:15:59 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 26AF1131C63 for ; Wed, 19 Jul 2017 03:15:58 -0700 (PDT) Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6JAFuSB055676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 05:15:56 -0500 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAFpEb028452; Wed, 19 Jul 2017 04:15:51 -0600 Received: from lxdnp31k.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAFpax028449 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 19 Jul 2017 04:15:51 -0600 Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAFpVb045485; Wed, 19 Jul 2017 04:15:51 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAFoZe045482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jul 2017 04:15:51 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Wed, 19 Jul 2017 05:15:50 -0500 From: "Woodworth, John R" To: "'Paul Wouters'" , George Michaelson CC: dnsop WG , "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJbDfuAgAAPdwD//8824A== Date: Wed, 19 Jul 2017 10:15:50 +0000 Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:16:01 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Paul Wouters > > I kind of disagree. > Hi Paul, Thanks for the feedback! > > We are adding something to DNS that's not just a new RRTYPE. It > requires code changes and has a deployment and long tail. If the > only result is that anti-spammers are no longer checking reverse > PTR records, we end up with a feature in DNS that has no use, and > the anti-spammers using another method to determine "inferior" > IP addresses. DNS will be the only party left with some legacy > complication. > I don't believe the need for this has anything to do with anti- spammers. We've had several requests for this feature (as I have to believe have other ISP's). > > I would feel much better if there would be some real use csases > to justify adding special code to DNS that will instantly become > obsolete. > Just think of all the scripts out there today for IPv4 alone which expand and work around the limitations of $GENERATE (or equivalent), why not standardize this in an AXFR-able manner? Thanks, John > > Paul > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Jul 19 03:34:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C285131C9B for ; Wed, 19 Jul 2017 03:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xSF9diV6Aknt for ; Wed, 19 Jul 2017 03:34:29 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 CF1F4131C96 for ; Wed, 19 Jul 2017 03:34:28 -0700 (PDT) Received: from lxdnp04n.corp.intranet (emailout.qintra.com [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6JAYP5I026683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 05:34:26 -0500 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAYKvL032269; Wed, 19 Jul 2017 04:34:20 -0600 Received: from lxdnp31k.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAYKZh032266 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 19 Jul 2017 04:34:20 -0600 Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAYKP1004084; Wed, 19 Jul 2017 04:34:20 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6JAYKBX004078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jul 2017 04:34:20 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Wed, 19 Jul 2017 05:34:20 -0500 From: "Woodworth, John R" To: "'Tony Finch'" , Paul Wouters CC: dnsop WG , George Michaelson , "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJbDfuAgAAPdwCAABuOAP//u9kw Date: Wed, 19 Jul 2017 10:34:19 +0000 Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:34:31 -0000 > Paul Wouters wrote: > > > > I would feel much better if there would be some real use > > csases to justify adding special code to DNS that will > > instantly become obsolete. > > Yes. > Hi Tony, Thanks for the feedback! > > For IPv4 I can't see what advantage BULK has over $GENERATE > or similar back-end provisioning scripts. > Really? > > For IPv6, if we have any reverse DNS at all for end-user devices > it'll probably be just a wildcard pointing to a placeholder > record identifying the VLAN. > > BULK seems like far too much cleverness applied to far too > small a problem. > In the IPv6 world, the smallest significant network is 18 and some odd quintillion (18,000,000,000,000,000,000) addresses. Think of this as your property (e.g. your yard). Each IP address in itself is small but without the sum of each, what do you have? Suddenly, each blade of grass has value. This is how a customer feels when they are given (sold) address space. Thanks, John > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - > I xn--zr8h punycode Hebrides, Bailey: Southeast, becoming > cyclonic, 5 to 7, perhaps gale 8 later. > Moderate or rough, occasionally very rough later. Rain or > showers. Good, occasionally poor. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Jul 19 03:49:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061E131C99 for ; Wed, 19 Jul 2017 03:49:23 -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_PASS=-0.001, URIBL_BLOCKED=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 jCG5-24VVbEs for ; Wed, 19 Jul 2017 03:49:21 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 6D305131C7C for ; Wed, 19 Jul 2017 03:49:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:48588) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXmXb-000gb7-fY (Exim 4.89) (return-path ); Wed, 19 Jul 2017 11:49:15 +0100 Date: Wed, 19 Jul 2017 11:49:15 +0100 From: Tony Finch To: "Woodworth, John R" cc: Paul Wouters , dnsop WG , George Michaelson In-Reply-To: Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:49:23 -0000 Woodworth, John R wrote: > > For IPv4 I can't see what advantage BULK has over $GENERATE > > or similar back-end provisioning scripts. > > Really? If you're proposing a forklift upgrade of the DNS then I think you need to make the advantages clear, rather than expecting me to guess. > In the IPv6 world, the smallest significant network is 18 > and some odd quintillion (18,000,000,000,000,000,000) > addresses. > > Think of this as your property (e.g. your yard). Each IP address > in itself is small but without the sum of each, what do you have? > > Suddenly, each blade of grass has value. > > This is how a customer feels when they are given (sold) address space. I hate mowing the grass. Can you provide a technical reason for per-address IPv6 reverse DNS? Where I work, we bulk populate reverse v4 DHCP pools just so we know that they are pools. We aren't going to bother doing that with v6 because everything is a pool, except for a relatively small number of statically configured switches and servers and suchlike. The other use for reverse DNS is to get a quick idea of which institution has been allocated an address, at a finer granularity than whois can, and without having to dig through our more detailed databases. A wildcard PTR can do this job for v6 just fine. You can even put an APL record at the PTR target to get the forward and reverse to match. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode South Fitzroy: Northwesterly 4 or 5. Moderate or rough. Showers. Good. From nobody Wed Jul 19 04:04:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE61D131CA3 for ; Wed, 19 Jul 2017 04:04:01 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 JUURuWFuIRxk for ; Wed, 19 Jul 2017 04:04:01 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB728129468 for ; Wed, 19 Jul 2017 04:04:00 -0700 (PDT) Received: from dhcp-9ecf.meeting.ietf.org (dhcp-9ecf.meeting.ietf.org [31.133.158.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id E78A42421527; Wed, 19 Jul 2017 11:03:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: Date: Wed, 19 Jul 2017 12:03:58 +0100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> To: "Woodworth, John R" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:04:02 -0000 > On 19 Jul 2017, at 11:34, Woodworth, John R = wrote: >=20 > Think of this as your property (e.g. your yard). Each IP address > in itself is small but without the sum of each, what do you have? >=20 > Suddenly, each blade of grass has value. What value has each IPv6 address? Or a name like = host-2001-67c-1232-144-21f-5bff-fec3-ab9d.example.com? Please enlighten = me. If you have a need to generate PTRs on the fly for IPv6 addresses in = your network, fine. However that doesn't seem to be a compelling reason = to modify the DNS protocol and change every DNS server on the planet. The cost/benefit optics of this draft are unclear. From nobody Wed Jul 19 04:12:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A60131CA0 for ; Wed, 19 Jul 2017 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ts3HIC2ylpix for ; Wed, 19 Jul 2017 04:12:01 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id E428112969E for ; Wed, 19 Jul 2017 04:12:00 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 504C8E6065; Wed, 19 Jul 2017 13:11:59 +0200 (CEST) Date: Wed, 19 Jul 2017 13:11:59 +0200 (CEST) Message-Id: <20170719.131159.74748443.sthaug@nethelp.no> To: dot@dotat.at Cc: John.Woodworth@CenturyLink.com, dnsop@ietf.org, paul@nohats.ca, ggm@algebras.org From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:12:03 -0000 > Can you provide a technical reason for per-address IPv6 reverse DNS? > > Where I work, we bulk populate reverse v4 DHCP pools just so we know that > they are pools. We aren't going to bother doing that with v6 because > everything is a pool, except for a relatively small number of statically > configured switches and servers and suchlike. Much the same here. The only IPv6 addresses getting reverse DNS will be statically configured addresses. Steinar Haug, AS2116 From nobody Wed Jul 19 05:28:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9FE131B13 for ; Wed, 19 Jul 2017 05:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, 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=gmail.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 ZQouNPqaHwqF for ; Wed, 19 Jul 2017 05:28:39 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 B4E2A131451 for ; Wed, 19 Jul 2017 05:28:38 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id o19so1221166vkd.5 for ; Wed, 19 Jul 2017 05:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZJy/Hc2yVNoMFymP9qgdfig8yn+LVYgSqHsV0laKKaY=; b=SRjfnqYwnftq49s4j80Q/R5xikQfIRw/UrtTk67pNojkia6OmkK0hulDRtGeK+3R0/ yqjjqFp/2dQEh3BAyP5TWjaozCqwtEWSikzgEiTLk9aG9bX9I1fWbKZzmfSnzTFjM5b/ 86aqxtYzQzd1fXyDT/JSi2Rv/xMfpHYqzOXEbcGqJ5DB3iLbliDmrPtUzupCZvOb1jvF 105IMkcuQQgeOZW+cZmFKLyONC4wIpo1vWAftK0d0ZER4JXWNFNeedKXq8PTDAjG3CfZ A816P8qO/F/W0Z9EVNr0jghBQ3gaGMxeQvxqSEI2rC04YTHzcCF6GYfXwbu/B2cuA6h1 lKVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZJy/Hc2yVNoMFymP9qgdfig8yn+LVYgSqHsV0laKKaY=; b=qF3AdpaG9fscUVHISKrzvNkkEc+2wCeBfcc8XwE/2cOxU9Iu2iQAeWlqDAzZCK10ES M06iDWXPQGjJRr1Pw1+FqqaRVtvXiOBwoCMtH5/bQ32JimjimTXUXRLbspMlPmWF8IWt RTf9e7vabiSzqB+HG8hayoy5mq/2ciNXpTkggxwhG7ThXTMVQ/vLH3LWWaEKBz7CLGNG eXUEMejfShq6/JArgm6VOs0PchYc+SJywQhB+dVMtmJkZO90t1fjkYBVSaxZB7XDprfa 2hUKLFGuPAzqYo+L4nKXclJhz23OtiRYPYFIPIy5K2XNqf/2Y5+4RA+yZETFm4+AJzJR XnBQ== X-Gm-Message-State: AIVw110YZEJs4Ws6pQH07fRmN3U5ohWB6B/mg3xI1URey6S+Kouct5cD AQT+IuGN3F/vwqTZ7ZtCH7OL+h3cdQ== X-Received: by 10.31.128.141 with SMTP id b135mr1358232vkd.22.1500467317892; Wed, 19 Jul 2017 05:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.78 with HTTP; Wed, 19 Jul 2017 05:28:37 -0700 (PDT) In-Reply-To: <20170719084942.GA18413@laperouse.bortzmeyer.org> References: <20170719084942.GA18413@laperouse.bortzmeyer.org> From: Shumon Huque Date: Wed, 19 Jul 2017 14:28:37 +0200 Message-ID: To: Stephane Bortzmeyer Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1149267a7aeced0554aac50d" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:28:41 -0000 --001a1149267a7aeced0554aac50d Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 10:49 AM, Stephane Bortzmeyer wrote: > On Tue, Jul 04, 2017 at 11:42:56AM -0400, > Shumon Huque wrote > a message of 108 lines which said: > > > We've posted a new draft on algorithm negotiation which we're hoping to > > discuss at IETF99 > > For the discussion on thursday: > > > In contrast, many other security protocols, like TLS, IKE, SSH and > > others, support an algorithm or cipher suite negotiation mechanism > > TLS and SSH are end-to-end. Not the DNS, and it makes things more > complicated (see section 6). > Yes, that's certainly true! > > because fragments are often blocked by network security devices. > > by STUPID AND BROKEN network security devices. Otherwise, you do not > put the blame where it belongs. > I was being polite :-) I don't disagree at all. But as practical matter, it is still an operational problem that needs to be dealt with. I would love to eradicate this problem Internet wide (which I think is Mark Andrew's preferred solution), but I doubt it will happen any time soon. > As can be readily seen from the RSA to ECDSA transition, very few > > zones have transitioned from RSA to ECDSA, > > True, but not for the reasons of the response size. Both for my > employer's zones and for my own personal zones, the big issue is the > lack of support in tools like HSMs, the difficulty of algorithm > rollover, and the fact that tools like OpenDNSSEC don't make it > easy. So, we have apparently a disagreement on the basic diagnostic. > It is a problem for some sites. I agree that there are other problems that dissuade people from algorithm rollovers. But this just means that we need to collectively work on making this easier, whatever the reasons. This proposal can address some aspects of this. > the resolver has selectively cached signatures of a subset of > > algorithms supported by the zon > > How does it know? I mean, in the response from the authoritative > server, nothing indicates if the signatures are a subset or > not. Suppose I send the list ECDSA;RSA, and I receive only ECDSA > signatures. How the resolver/cache would now if it was a complete > list? > The response contains the EDNS0 option if the responder executed this protocol. In which case, the cache would tag this response as a subset. > > but prefers algorithms known to be supported for the name, > > Again, where does this knowledge come from? > When the resolver queries the DNSKEY RRset for the zone, it knows which algorithms are supported for the zone. We're working on some additional tweaks to the protocol, which I'll discuss on Thursday. Shumon --001a1149267a7aeced0554aac50d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 19, 2017 at 10:49 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr&g= t; wrote:
On Tue, Jul 04, 2017 at = 11:42:56AM -0400,
=C2=A0Shumon Huque <shuque@gmail.com= > wrote
=C2=A0a message of 108 lines which said:

> We've posted a new draft on algorithm negotiation which we're = hoping to
> discuss at IETF99

For the discussion on thursday:

> In contrast, many other security protocols, like TLS, IKE, SSH and
> others, support an algorithm or cipher suite negotiation mechanism

TLS and SSH are end-to-end. Not the DNS, and it makes things more
complicated (see section 6).

Yes, that&= #39;s certainly true!
=C2=A0
> because fragments are often blocked by network security devices.

by STUPID AND BROKEN network security devices. Otherwise, you do not
put the blame where it belongs.

I was b= eing polite :-)

I don't disagree at all. But a= s practical matter, it is still an operational problem that needs to be dea= lt with. I would love to eradicate this problem Internet wide (which I thin= k is Mark Andrew's preferred solution), but I doubt it will happen any = time soon.

> As can be readily seen from the RSA to ECDSA transition, very few
> zones have transitioned from RSA to ECDSA,

True, but not for the reasons of the response size. Both for my
employer's zones and for my own personal zones, the big issue is the lack of support in tools like HSMs, the difficulty of algorithm
rollover, and the fact that tools like OpenDNSSEC don't make it
easy. So, we have apparently a disagreement on the basic diagnostic.

It is a problem for some sites. I agree that = there are other problems that dissuade people from algorithm rollovers. But= this just means that we need to collectively work on making this easier, w= hatever the reasons. This proposal can address some aspects of this.
<= div>
> the resolver has selectively cached signatures of a subset of
> algorithms supported by the zon

How does it know? I mean, in the response from the authoritative
server, nothing indicates if the signatures are a subset or
not. Suppose I send the list ECDSA;RSA, and I receive only ECDSA
signatures. How the resolver/cache would now if it was a complete
list?

The response contains the EDNS0 o= ption if the responder executed this protocol. In which case, the cache wou= ld tag this response as a subset.
=C2=A0
> but prefers algorithms known to be supported for the name,

Again, where does this knowledge come from?

=
When the resolver queries the DNSKEY RRset for the zone, it knows whic= h algorithms are supported for the zone.

We're= working on some additional tweaks to the protocol, which I'll discuss = on Thursday.

Shumon

--001a1149267a7aeced0554aac50d-- From nobody Wed Jul 19 05:49:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210BE131CEE for ; Wed, 19 Jul 2017 05:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 nVDe0uoeH0UT for ; Wed, 19 Jul 2017 05:49:08 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0129.outbound.protection.outlook.com [23.103.201.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4C41288B8 for ; Wed, 19 Jul 2017 05:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OGaDMOcmzvFJMVpjSJsaJzXn/UQ3I/KmYK7B5JBZjUg=; b=axr8mHNN3tbRztVuLx1erDHZ9g36RNBy6q48U6dSYlU7xKTJg2+IKRjwgYfuPKWFyY622Iv27oTx7VNsTpItnf2g49TE1tny647/2ZOwzFu2gKyErRH8aZXSdvmbi7g7WRHf7LZqYwhlxeX3GelUt4QUaQG57FVp/50l4aC69wM= Received: from SN1PR09MB0797.namprd09.prod.outlook.com (10.162.101.143) by SN1PR09MB0798.namprd09.prod.outlook.com (10.162.101.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 12:49:07 +0000 Received: from SN1PR09MB0797.namprd09.prod.outlook.com ([10.162.101.143]) by SN1PR09MB0797.namprd09.prod.outlook.com ([10.162.101.143]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 12:49:07 +0000 From: "Rose, Scott (Fed)" To: "dnsop@ietf.org" Thread-Topic: comments on draft-mglt-dnsop-dnssec-validator-requirements-05 Thread-Index: AQHTAIk9FpNu0UgNwkSwkWyYAuxdTA== Date: Wed, 19 Jul 2017 12:49:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.218.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR09MB0798; 7:Rlvz/sLCljHFVg5K5eNZtmMJZMbOtBHw8kV47lVBpEFGZ0fQXAHa4Q7nUbWKXRDwjBRSyE7OSqSp8i7Rhfzgm+1o13ZkjsAbyp3qRN7I5DWJDzVyfmpzslWFwNcGbl3Q4vrPL1CMlPIohaD2cmB5jLfxOHdy/t9zQ29dTrk2NkV9MMdPzgz+mWRisKGC9wKjkuQbqWB0iUzVmlvCOIpLSMUR96HRAqh1uJRdq3D7AB+HvN9qITRRRmmztzJzKj9ErPg2IHbYsFOx2pF1EtzxuL01Wk1tx9bLXfgDA/cl1rZVRk5+f8cgMON/guUb7aY9CYE+x/PKVTifYtUtgAbsE45Va/Vg1lvw7OvDWlkOt80/7MIcEh0eqScpa996XtG4TfXeNZeUW8VOTEMiyjyGiCxD1CNhfdAU7kbNA6fXaJ8iLd4nf3K4OVKM9e7EYzXqKJenNR0UdNarTBiEGsxCS4ZPiWOOZJ++MWTCYWUyQ/sZCP++UvUoodrXW70gFqmzsG06qK+uWTK1sZXhTa+T9VeSojr5/VeTpMLlWpi67Om0PPrJdwKN+Mxz0piF/lWXBGc0Ky+4Lh2zY7luKK/iMCT8OScEikQBu9Jkyijx/q4V6Dg34BMRweu+Mwyr3Jy+8hyh/UodLLqg0Gre5zWpp6e/3GxvXZvoYvS+qTCYfW9lZyIWjxmDPe90zByqgGeHXDX+FpLzrsW7RQeIoMgXplLf9jFkuXTxjvsMsxOH1jZlDaCu4Eb3Hq2xaIKuqYB58OEsFcfpRLO8OT5xjUMcgqkSD9unLAiF3be+hbmXG0c= x-ms-office365-filtering-correlation-id: 3f96be63-1c47-4580-ff44-08d4cea48b48 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR09MB0798; x-ms-traffictypediagnostic: SN1PR09MB0798: x-exchange-antispam-report-test: UriScan:(133145235818549)(209352067349851)(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR09MB0798; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR09MB0798; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39860400002)(39840400002)(39400400002)(39410400002)(38730400002)(6506006)(8676002)(110136004)(54356999)(14454004)(77096006)(2906002)(189998001)(33656002)(53936002)(6606003)(5640700003)(6916009)(86362001)(54896002)(99286003)(50986999)(9686003)(55016002)(3280700002)(478600001)(6436002)(2351001)(19627405001)(3660700001)(230783001)(74316002)(2501003)(6116002)(2900100001)(66066001)(102836003)(8936002)(7736002)(3846002)(1730700003)(81166006)(5660300001)(25786009)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0798; H:SN1PR09MB0797.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR09MB07972DFA5FDC8C2582057850F0A60SN1PR09MB0797namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 12:49:07.2232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0798 Archived-At: Subject: [DNSOP] comments on draft-mglt-dnsop-dnssec-validator-requirements-05 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:49:11 -0000 --_000_SN1PR09MB07972DFA5FDC8C2582057850F0A60SN1PR09MB0797namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think this draft is a good idea and should be adopted, but needs some imp= rovements first. 1. In Section 4: "unsecure" should be "insecure". 2. REQ2: What should happen when there are multiple trust anchors, but only= one failed to validate? E.g. a validator has both the root and .exampleTLD= in its trust store, but missed the root rollover. The .exampleTLD key stil= l validates, but the root doesn't. Should all validation stop? Or set a war= ning, but continue to validating (succeeding only for .exampleTLD)? 3. REQ18: I don't think I understand this. Wouldn't the best way to see whi= ch algorithm(s) are in use for a given zone would be just to send a query? = Authoritative zones really may not "know" any algorithm besides SHA-1, as i= t is likely not doing online signing, but serving whatever a signing utilit= y chose. 4. Should there be a mention as to which algorithms a validator should supp= ort? It may not require a direct reference to whichever RFC is current, but= simply listing the IANA maintained registry and say "implement all the MUS= Ts and probably the SHOULDs too". Something like the following: Algorithm Usage in Validators DNSSEC signatures can be generated by different digital signatures algorith= ms. The current list of algorithms defined for use with DNSSEC is published= in an IANA maintained registry [insert IANA link here]. Validators have to= be able to understand and validate different algorithms that may be in com= mon use with DNSSEC. The DNSSEC digital signature registry table is regular= ly updated with guidance as to which algorithms are considered MANDATORY an= d/or RECOMMENDED. In order to be effective, a validator MUST understand all= digital signature algorithms marked as MANDATORY and SHOULD understand all= digital signature algorithms marked as RECOMMENDED. REQXX: Validators MUST implement all MANDATORY digital signature algorithms= and SHOULD implement all RECOMMENDED digital signature algorithms. Note: This wording isn't the best, and needs some work. I also don't know i= f the SHOULD in the REQ should be changed to a MAY, but I would prefer SHOU= LD. Scott --_000_SN1PR09MB07972DFA5FDC8C2582057850F0A60SN1PR09MB0797namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think this draft is a good idea and shoul= d be adopted, but needs some improvements first.


1. In Section 4: "unsecure" shoul= d be "insecure".


2. REQ2: What should happen when there are = multiple trust anchors, but only one failed to validate? E.g. a validator h= as both the root and .exampleTLD in its trust store, but missed the root ro= llover. The .exampleTLD key still validates, but the root doesn't. Should all validation stop? Or set a warn= ing, but continue to validating (succeeding only for .exampleTLD)?


3. REQ18: I don't think I understand this. = Wouldn't the best way to see which algorithm(s) are in use for a given zone= would be just to send a query? Authoritative zones really may not "kn= ow" any algorithm besides SHA-1, as it is likely not doing online signing, but serving whatever a signing utility= chose.


4. Should there be a mention as to which al= gorithms a validator should support? It may not require a direct reference = to whichever RFC is current, but simply listing the IANA maintained registr= y and say "implement all the MUSTs and probably the SHOULDs too". Something like the following:


Algorithm Usage in Validators


DNSSEC signatures can be generated by diffe= rent digital signatures algorithms. The current list of algorithms defined = for use with DNSSEC is published in an IANA maintained registry [insert IAN= A link here]. Validators have to be able to understand and validate different algorithms that may be in common= use with DNSSEC. The DNSSEC digital signature registry table is regularly = updated with guidance as to which algorithms are considered MANDATORY and/o= r RECOMMENDED. In order to be effective, a validator MUST understand all digital signature algorithms marked as MAN= DATORY and SHOULD understand all digital signature algorithms marked as REC= OMMENDED.


REQXX: Validators MUST implement all MANDAT= ORY digital signature algorithms and SHOULD implement all RECOMMENDED digit= al signature algorithms.


Note: This wording isn't the best, and need= s some work. I also don't know if the SHOULD in the REQ should be changed t= o a MAY, but I would prefer SHOULD.


Scott

--_000_SN1PR09MB07972DFA5FDC8C2582057850F0A60SN1PR09MB0797namp_-- From nobody Wed Jul 19 06:45:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F45131D35 for ; Wed, 19 Jul 2017 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 00QheyJYZIoI for ; Wed, 19 Jul 2017 06:45:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 22017131D2E for ; Wed, 19 Jul 2017 06:45:17 -0700 (PDT) Received: from [31.133.133.190] (dhcp-85be.meeting.ietf.org [31.133.133.190]) by mail.nic.cz (Postfix) with ESMTPSA id 5E0AD6096F; Wed, 19 Jul 2017 15:45:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500471915; bh=MXqlrnUQq8xXVR9uJlcBESiZec/+BF/g6BDTu4FcAec=; h=To:From:Date; b=L5Weysr+ChwTROBV7nn8ION+/AgnuoVtBAqgsaw24fKO9/cF3/reJFRSO4Sv0LW6c CRU/LC79htDJtDBNnn3sf9EmyWDSeMYvPSljlwk+pev87+cId+1kpazeKaLNDDL7f+ DkLBRWTo52dt6KFjoU3i2XSet29vVUi2zTP6wjFw= To: Mark Andrews Cc: dnsop@ietf.org References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com> <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz> <20170719031536.05E1B7EA7FA6@rock.dv.isc.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Wed, 19 Jul 2017 15:45:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170719031536.05E1B7EA7FA6@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:45:33 -0000 On 19.7.2017 05:15, Mark Andrews wrote: > In message <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz>, =?UTF-8?B?UGV0ciDFoHBhxI1law==?= writes: >> On 11.7.2017 13:23, Ted Lemon wrote: >>> On Jul 11, 2017, at 3:17 AM, Petr paek >> > wrote: >>>> I feel that implications from switch to non-RR format are >> underestimated >>>> and following e-mail attempts to explain why I believe it is a bad >> idea. >>>> Please accept my apology for such long e-mail. >>> >>> Petr, with all due respect, I did not see a counter-proposal here, and >>> your comments seem to reflect a misunderstanding of what >>> session-signaling is. >>> >>> In fact, the opposite of what you said is true: if this were done as a >>> normal query with EDNS0-like encapsulation, _then_ we would see >>> problems, because session signaling messages would look more like DNS >>> queries, and less like control messages. This is not a desirable >> quality. >>> >>> It's true that, for example, the DNS packet compression format would >>> have to deal with this specially, but that would also be true if this >>> were done EDNS0-style. It's true that packet dumpers would have to >>> deal with this specially, but that's also true if it's done EDNS0-style. >>> Etc. >> >> Let me clarify that I'm not insisting specifically on EDNS0. From my >> perspective anything which does not deviate from current wire format is >> okay. >> >> >>> It may be that there is a good point in your argument somewhere, but at >>> the moment, I don't see one. E.g., in your python example, yes, if >>> this were an RR, not being able to plop it into your RR-handling switch >>> would suck. But it's not an RR, doesn't have the semantics of an RR, >>> and if you plop it into your RR-handling switch, you're probably getting >>> the semantics wrong. >> >> This might be key to the the misunderstanding: >> >> I'm not talking about semantics at all. What I object to is the proposed >> wire format, not the semantics. The fact that bytes are stored in format >> compatible with RR (RFC 1035 section 4.1.3) is not related to its >> semantics. >> >>> So if you want to make this case, I think you need to be more specific >>> about why this is a problem: when I think about how to implement this >>> (which I have done, because I'm using it for dnssd), what you are >>> advocating seems harder, not easier, than what is currently being >> proposed. >> I'm trying to explain that deviance from RR format (RFC 1035 section >> 4.1.3) will force parties in the DNS ecosystem to implement support for >> the new wire format even though they are not interested in session >> signaling at all. > > Hogwash. Servers which are unaware of the opcode will return NOTIMP > or FORMERR depending on how forward thinking the developer was. > > If you have a packet dumper YOU ALREADY HAVE TO ACCOUNT FOR THIS. > There are ZERO guarentees that a packet addresses to/from port 53 > is a DNS packet. If your packet dumper can't handle these then > it is already broken. > > If you are just proxying DNS messages this should be transparent. If > the proxy is parsing the message then it returns NOTIMP or FORMERR. > >> For a lot of cases it would be sufficient if SS data could be treated as >> one of many "unknown RR types" (RFC 3597). For example tools for >> statistics would work, the capture formats would not need special >> extensions for SS, etc. >> >> We can discuss this in depth during dnsop session today. WG decided to go forward with TLV format. I still think it is a mistake but I'm going to respect WG decicion and thus I'm giving up. Further discussion on this topic is pointless. -- Petr Špaček @ CZ.NIC From nobody Wed Jul 19 06:47:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C958B131D31 for ; Wed, 19 Jul 2017 06:47:14 -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, URIBL_BLOCKED=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 iYfW3AqP3UrZ for ; Wed, 19 Jul 2017 06:47:13 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 E67FB131D22 for ; Wed, 19 Jul 2017 06:47:12 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7571731C83; Wed, 19 Jul 2017 15:47:09 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id A9316EC0B1C; Wed, 19 Jul 2017 15:44:04 +0200 (CEST) Date: Wed, 19 Jul 2017 15:44:04 +0200 From: Stephane Bortzmeyer To: Tony Finch Cc: Willem Toorop , dnsop@ietf.org Message-ID: <20170719134404.GA18669@laperouse.bortzmeyer.org> References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:47:15 -0000 On Tue, Jul 18, 2017 at 05:09:00PM +0100, Tony Finch wrote a message of 80 lines which said: > A client queries its resolver for dotat.at A, but chiark has > renumbered, so the client gets a response from the ANAME-aware > resolver like below. A validating ANAME-aware client can see it > should use the additional address 212.13.197.231 in preference to > the address in the answer. Cute trick. I love it. But it modifies the rules for response credibility (the most credible response is in the additionnal section, not in the answer section). Should we update RFC 2181, section 5.4.1? I tend to think that the A record, in that example, should be treated exactly like glue, by a ANAME-aware client. From nobody Wed Jul 19 07:41:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB71131CFA for ; Wed, 19 Jul 2017 07:41:31 -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_PASS=-0.001, URIBL_BLOCKED=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 3T1hiTLF66Kr for ; Wed, 19 Jul 2017 07:41:29 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 AF63E126CB6 for ; Wed, 19 Jul 2017 07:41:29 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39480) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXqAJ-000ltB-fZ (Exim 4.89) (return-path ); Wed, 19 Jul 2017 15:41:27 +0100 Date: Wed, 19 Jul 2017 15:41:27 +0100 From: Tony Finch To: Stephane Bortzmeyer cc: Willem Toorop , dnsop@ietf.org In-Reply-To: <20170719134404.GA18669@laperouse.bortzmeyer.org> Message-ID: References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> <20170719134404.GA18669@laperouse.bortzmeyer.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:41:32 -0000 Stephane Bortzmeyer wrote: > > Cute trick. I love it. :-) > But it modifies the rules for response credibility (the most credible > response is in the additionnal section, not in the answer section). > Should we update RFC 2181, section 5.4.1?> I tend to think that the A > record, in that example, should be treated exactly like glue, by a > ANAME-aware client. Interesting point. My understanding is that, in principle, DNSSEC makes it possible to trust parts of answers that are (in current implementations) distrusted. For example, out-of-zone data about CNAME or MX targets. There's a big opportunity here to reduce latency by doing a bit more work to eagerly validate and cache additional data. (An aside: glue appears in multiple places in the RFC 2181 5.4.1 ranking, depending on whether the server found it in an primary/secondary zone or got it in a referral.) Regarding my ANAME suggestion, the key paragraphs are shortly after the trustworkthiness ranking: Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. The first word is the key word: "Unauthenticated" - the next paragraph says: When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated shall be considered more trustworthy than unauthenticated data of the same type. Note that throughout this document, "authoritative" means a reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY records to determine the authenticity of data, the AA bit is almost irrelevant. However DNSSEC aware servers must still correctly set the AA bit in responses to enable correct operation with servers that are not security aware (almost all currently). With this context, I believe RFC 2181 says that if you have validated the additional data from an answer like the one in my example (https://mailarchive.ietf.org/arch/msg/dnsop/Zh7viwmrR7QcJSFQvqMsb7YSRU8) you are allowed to return it as a direct answer to queries, and you don't have to keep it in the additional section sin bin. It's probably also sensible to retain its low trustworthiness ranking, so that it can be replaced in the cache by a more trustworthy answer, to reduce the risk of replay attacks that use old data that's still within its RRSIG validity period. On the other hand, it might be usefully simpler to make ANAME-specific recommendations about how to handle the additional data. Dunno :-) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode East Sole, Lundy, Fastnet: Cyclonic 4 or 5, becoming northwesterly 5 to 7. Moderate or rough. Showers, thundery at first, fog patches at first. Moderate or very poor, becoming good. From nobody Wed Jul 19 08:01:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455C1131D39 for ; Wed, 19 Jul 2017 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Fjxd16il2Knj for ; Wed, 19 Jul 2017 08:01:18 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD5D131C18 for ; Wed, 19 Jul 2017 08:01:18 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 19 Jul 2017 08:01:16 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 19 Jul 2017 08:01:15 -0700 From: Edward Lewis To: "Rose, Scott (Fed)" , "dnsop@ietf.org" Thread-Topic: [Ext] [DNSOP] comments on draft-mglt-dnsop-dnssec-validator-requirements-05 Thread-Index: AQHTAJ/eQLW1DE5jLkuTbY4vbjiirg== Date: Wed, 19 Jul 2017 15:01:15 +0000 Message-ID: <65A8A166-E4DD-46D8-9CB9-00D2025171D7@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3583306875_766213541" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] comments on draft-mglt-dnsop-dnssec-validator-requirements-05 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:01:21 -0000 --B_3583306875_766213541 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 7/19/17, 08:49, "DNSOP on behalf of Rose, Scott (Fed)" wrote: >I think this draft is a good idea and should be adopted, but needs some improvements first. > Thanks for the review, the current version has items needing wider discussion. I'll pick some items to respond to now: >2. REQ2: What should happen when there are multiple trust anchors, but only one failed to validate? E.g. a validator has both the root and .exampleTLD in its trust store, but missed the root rollover. The .exampleTLD key still validates, but the root doesn't. Should all validation stop? Or set a warning, but continue to validating (succeeding only for .exampleTLD)? One of my long-standing opinions has been that it is hard to build a secure chain, so if one exists, accept it in face of alternative broken chains. If a validator is too "tight" then it would be trivial to do a denial-of-service by throwing out DNSKEYs, RRSIGs, etc., that will not lead to validation. As far as trust anchors, the level of trust (healthiness in some sense) is individual. One anchor candidate might be "false" (unauthorized) while another anchor candidate might be "true" (authorized). Trust is in the eye-of-the-operator, if the operator establishes trust in a candidate it is best to run with it, again, even if there are untrusted candidates. (Because, if too "tight" it would be trivial to do a denial of service.) >3. REQ18: I don't think I understand this. Wouldn't the best way to see which algorithm(s) are in use for a given zone would be just to send a query Authoritative zones really may not "know" any algorithm besides SHA-1, as it is likely not doing online signing, but serving whatever a signing utility chose. I'd refrain from "know" and use "use." The signer (not the zone) may or may not have a library for a particular DNSSEC security algorithm's needed cryptographic algorithm and/or hash. That's entirely opaque to the other side of the DNS protocol (as DNSSEC assumed an air gap in the most strictly secure use case). What is in use for a zone is established two ways. One is from the DS RRset. The other is via published secure entry points bootstrapped to the satisfaction of the validator operator's "trust" satisfaction. I.e., I too think that REQ18 needs further review. It would make more sense if there were on-the-fly signing capabilities (which is not something assumed by DNSSEC, although it's not a ludicrous idea, it would be operationally useful). >4. Should there be a mention as to which algorithms a validator should support? It may not require a direct reference to whichever RFC is current, but simply listing the IANA maintained registry and say "implement all the MUSTs and probably the SHOULDs too". Something like the following: For turn-key implementations, I don't think so. For general-purpose implementations, the producer of the software would make a choice based on their objectives. Easing the choice for the tool developer would be good, but I question mandating compliance with features. (I'd leave that to the "purchasing vehicle", which begs a whole'nuther discussion. There would be a need to educate the consumer, for one.) >Algorithm Usage in Validators > >DNSSEC signatures can be generated by different digital signatures algorithms. The current list of algorithms defined for use with DNSSEC is published in an IANA maintained registry [insert IANA link here]. Validators have to be able to understand and validate different algorithms that may be in common use with DNSSEC. The DNSSEC digital signature registry table is regularly updated with guidance as to which algorithms are considered MANDATORY and/or RECOMMENDED. In order to be effective, a validator MUST understand all digital signature algorithms marked as MANDATORY and SHOULD understand all digital signature algorithms marked as RECOMMENDED. > >REQXX: Validators MUST implement all MANDATORY digital signature algorithms and SHOULD implement all RECOMMENDED digital signature algorithms. > >Note: This wording isn't the best, and needs some work. I also don't know if the SHOULD in the REQ should be changed to a MAY, but I would prefer SHOULD. Thanks for the suggested text, for the most part I think it is on target. But to hark back to my comment before it, I'd change (for example): "Validators have to be able to understand and validate different algorithms that may be in common use with DNSSEC." to: "General purpose validators, in order to be widely adopted and accepted, ought to implement as many of the commonly used DNSSEC security algorithms, with "commonly" interpreted, at least on one way, to include the DNSSEC security algorithms in the IANA registry noted." ...again, wording is loose. My driving concern is that there may be some folks that have a turn-key situation in mind; the IETF famously says it is not the "protocol police." --B_3583306875_766213541 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUcF20ov0M7Y5RCn++ vVBKeMnQ0K4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NzE5MTUwMTE1WjANBgkqhkiG9w0BAQEFAASCAQCqR1yR/sjmmSiyoCrHgmIRDONfIF5Jhfm0 i2xYMpr7t9OyiQYmN4UqvQQDEJuIBHl6TfUZ3H1aoz8ULJobpVhyq6xLf+K/dUZ+yGSP8S3j QBmL5vJ2UG1eKFIRdLuBA3vUcrq2dei3PHzw9ZwdqXElxkpw2PaCvwUmi7QrpTciE1jevCXj WvvrcALubblCzT0pbQxCI8EhGSyNNos2X/gemrTFVzvNldZI3DgEt3VWEWap/9KdRv/NkTH9 8CWvF1MrbenKG3c/1YUIArzqXFltNlK+Q4sfPql2q4I2n2BcMzE0JgJSq18l9nrEchyTP3YS TXGy8j5qf3pNneau02L5 --B_3583306875_766213541-- From nobody Wed Jul 19 10:39:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9640012EC37 for ; Wed, 19 Jul 2017 10:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 U7w2HnpJgOEn for ; Wed, 19 Jul 2017 10:39:23 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C9C12EBF4 for ; Wed, 19 Jul 2017 10:39:23 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:ddec:eba0:a2ac:63c3] (unknown [IPv6:2001:559:8000:c9:ddec:eba0:a2ac:63c3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id ED3BC61FF3; Wed, 19 Jul 2017 17:39:22 +0000 (UTC) Message-ID: <596F994A.9050202@redbarn.org> Date: Wed, 19 Jul 2017 10:39:22 -0700 From: Paul Vixie User-Agent: Postbox 5.0.15 (Windows/20170609) MIME-Version: 1.0 To: sthaug@nethelp.no CC: dnsop@ietf.org References: <20170719.131159.74748443.sthaug@nethelp.no> In-Reply-To: <20170719.131159.74748443.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 17:39:25 -0000 sthaug@nethelp.no wrote: >> Can you provide a technical reason for per-address IPv6 reverse DNS? >> >> Where I work, we bulk populate reverse v4 DHCP pools just so we know that >> they are pools. We aren't going to bother doing that with v6 because >> everything is a pool, except for a relatively small number of statically >> configured switches and servers and suchlike. > > Much the same here. The only IPv6 addresses getting reverse DNS will > be statically configured addresses. ty, ty, ty! see also this, from 2011: http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/ -- P Vixie From nobody Wed Jul 19 14:58:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295791317D4 for ; Wed, 19 Jul 2017 14:58:14 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 iRzCVtQ4yPsR for ; Wed, 19 Jul 2017 14:58:12 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22CC12F29A for ; Wed, 19 Jul 2017 14:58:12 -0700 (PDT) Received: (qmail 14488 invoked from network); 19 Jul 2017 21:58:11 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jul 2017 21:58:11 -0000 Date: 19 Jul 2017 21:57:49 -0000 Message-ID: <20170719215749.2241.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: paul@nohats.ca In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 21:58:14 -0000 In article you write: >We are adding something to DNS that's not just a new RRTYPE. It requires >code changes and has a deployment and long tail. ... I realize that my biggest problem with this draft is not that I don't think that it's useful -- we have lots of RFCs that turned out to be useless but harmless. It's that it breaks the DNS by being egregiously not backward compatible. I would strongly prefer if we defer consideration of this draft until we figure out how to do DNS versioning, some way to say that this record type (and consequently, the zone returned to this AXFR or IXFR) requires special processing, and if you don't know how to do the processing, don't guess. This would update or perhaps even replace RFC 3597. We did this in a horrible ad-hoc way with DNSSEC, and even with DNSSEC there's the fallback that the unsigned answers you get from a server that doesn't understand RRSIG et al. are for many purposes adequate. But with BULK, if a secondary doesn't understand it, the answers will just be wrong. This might be something like an EDNS item which includes the need-to-understand rrtypes, but I'd prefer to do it in a way that will make the AXFR or IXFR result invalid to an old server that doesn't understand it. R's, John PS: h/t to Andrew Sullivan who replied to my suggestion that people do BULK in a stunt server by noting that we're here to make things interoperate. From nobody Wed Jul 19 15:01:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079A4131BC2 for ; Wed, 19 Jul 2017 15:01:56 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ooOAtu7lrPpM for ; Wed, 19 Jul 2017 15:01:54 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DDC131BC1 for ; Wed, 19 Jul 2017 15:01:54 -0700 (PDT) Received: (qmail 14835 invoked from network); 19 Jul 2017 22:01:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jul 2017 22:01:53 -0000 Date: 19 Jul 2017 22:01:31 -0000 Message-ID: <20170719220131.2283.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <4B2B2D27-7E24-41BC-93B7-D33FAF783BD6@vpnc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 22:01:56 -0000 In article <4B2B2D27-7E24-41BC-93B7-D33FAF783BD6@vpnc.org> you write: >If the WG still gets to freely edit the document while adhering to >"describes an existing and widely deployed method", this seems like a >good way forwards. Text can change, bits can't. OK with me. R's, John From nobody Wed Jul 19 16:14:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C09131B05 for ; Wed, 19 Jul 2017 16:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PwKAkG45veKr for ; Wed, 19 Jul 2017 16:14:13 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 098641317A4 for ; Wed, 19 Jul 2017 16:14:13 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id m7so11650987qtm.4 for ; Wed, 19 Jul 2017 16:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=x3tk8UfpyC2SymGpYdGuhwtw28MFuiMsRBC4hrX3ecc=; b=QVjIAp6dF1Ro9NvJawfidra8dx8gD4DnARICkkeeP0u+H1+WZSlyNtRUBPDxR6XTq+ 77OYeROUJRkt7jcjpNClmCmn8EwIeV/xSOUOq/YbmxtF151oaAG/3spWDUS5g3kxovEn 0/sBo/flP1wsWDPcAIMya1OtQpxsNLGq+V5BrOZ1Nvxt8AV8EXLwxhXEdhOOQGl0gXxO zHpBTlh9MC3ZLaOk7ysB5rC8IImU1sX3UAp9oknZgVelKPGJezQigV/zLH1vZ1xC/SLk rh+ou32AwedhkGUu9LdRaTCudpb2Y2Oz02r9hqudx52b0KwEzhhe8wYBS32rtbsKG47R JeAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=x3tk8UfpyC2SymGpYdGuhwtw28MFuiMsRBC4hrX3ecc=; b=IeCt9GFbF8oHVAz0HZpK7qJ4bUB39oTmdQVpP1XjErw5LmqylMq1GTRYD2sB5M2tgh zsETCQpBvZarWyHFSZbmhhTHl9Yx/aCO7R4uMc3Rues9a8Y0zJ3vPlSGxQXE6HkObOtH vb5ZDsCwVbIJfsto/zosCNoGp98T2juoFBbQibdSF4LjjiszwEFfco05rLpYC83vwJhi kPSuATcaOk3cxW4loh2eKoUwkL/WnZmp5HUJRtzNR2qxFk2ysT/P/F5ywtR2L8jEfDx2 EgRXQb5jVabZTuh9KvDoCVw3p58O20e47X5NWOve2CsMq/3UPo3J8UwKmOhFQ8Zm/1YH WHMA== X-Gm-Message-State: AIVw110AXDBIrmTkQEnBoAPXjLs4L8qAtRWx3uWDdg4ximWbIGucvZjc x+NmyOFt0SSRBXY1ciXJI3fxwLkqrw== X-Received: by 10.200.51.150 with SMTP id c22mr2263184qtb.339.1500506052096; Wed, 19 Jul 2017 16:14:12 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Wed, 19 Jul 2017 16:14:11 -0700 (PDT) In-Reply-To: <20170718094654.GA31988@jurassic> References: <20170718094654.GA31988@jurassic> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 19 Jul 2017 16:14:11 -0700 X-Google-Sender-Auth: cRtP7g693UdBSK9JNcGrlYuwVSQ Message-ID: To: Mukund Sivaraman Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 23:14:14 -0000 At Tue, 18 Jul 2017 18:20:56 +0530, Mukund Sivaraman wrote: > Dealing with water torture and some other attacks have had several > band-aid approaches that don't always work well in practice. The most > promising (and what feels correct) is > draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned > zones. Do you mean it's the most promising measure for authoritative servers? If so, and if nsec-aggressiveuse is more widely deployed in resolvers, and if the authoritative operators feel the pain so keenly, I'd rather imagine they are willing to pay the cost of deploying DNSSEC. If you mean it's the most promising measure for recursive servers, I simply don't buy the argument. (I made that comment while the wg discussed nsec-aggressiveuse and it toned down quite a lot in that sense as a result of it, so I believe it's based on a wg rough consensus). So, either way, I don't see a strong case for the trick of using nsec-aggressiveuse on an unsigned zone with DNS cookies. -- JINMEI, Tatuya From nobody Wed Jul 19 17:44:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79771129BA4 for ; Wed, 19 Jul 2017 17:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 gBV_aVGQahQ1 for ; Wed, 19 Jul 2017 17:44:20 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 240D5129A9C for ; Wed, 19 Jul 2017 17:44:20 -0700 (PDT) Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6K0iGW3053674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 18:44:16 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K0iABa004313; Wed, 19 Jul 2017 19:44:10 -0500 Received: from lxomp07u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K0iARa004307 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 19 Jul 2017 19:44:10 -0500 Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K0iA5A049352; Wed, 19 Jul 2017 19:44:10 -0500 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K0iAQl049342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jul 2017 19:44:10 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Wed, 19 Jul 2017 19:44:10 -0500 From: "Woodworth, John R" To: "'Tony Finch'" CC: dnsop WG , Paul Wouters , "George Michaelson" , "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJbDfuAgAAPdwCAABuOAP//u9kwgABYRICAAItVEA== Date: Thu, 20 Jul 2017 00:44:09 +0000 Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 00:44:22 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Tony Finch > > Can you provide a technical reason for per-address IPv6 reverse DNS? > Hi Tony, The main reason I can think of is compatibility. This (BULK-like functionality) is actually happening today. In fact several vendors have been offering this very feature in various incompatible ways simply because of the demand for it. Why not offer it in a way everyone can benefit? We continue to receive requests for this feature and it just made sense to offer it in a way that zones could be AXFR'd back and forth regardless of vendor and interoperate in a compatible manner. > > Where I work, we bulk populate reverse v4 DHCP pools just so we know > that they are pools. We aren't going to bother doing that with v6 > because everything is a pool, except for a relatively small number > of statically configured switches and servers and suchlike. > When we came up with the concept, it was to solve a v4 problem and in a way naively believed the basic concept of a minor paradigm shift from an already existing feature ($GENERATE) would be happily accepted by the community. We have literally millions of $GENERATE-based synthesized records on the IPv4 side of the house. We see a variety of uses, sure a majority are pools and rfc2317 delegations but they are all still there eating memory whether used or not. Thanks, John > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punyco= de > South Fitzroy: Northwesterly 4 or 5. Moderate or rough. Showers. Good. > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Jul 19 18:17:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D49127868 for ; Wed, 19 Jul 2017 18:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 3uHVuFfTL3vz for ; Wed, 19 Jul 2017 18:17:42 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 B4DA41272E1 for ; Wed, 19 Jul 2017 18:17:42 -0700 (PDT) Received: from lxdnp04n.corp.intranet (emailout.qintra.com [151.119.92.83]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6K1HfD8026774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 19:17:42 -0600 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K1HaDO035974; Wed, 19 Jul 2017 19:17:36 -0600 Received: from lxdnp32k.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K1Haqd035971 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 19 Jul 2017 19:17:36 -0600 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K1HavY003477; Wed, 19 Jul 2017 19:17:36 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K1Habr003472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jul 2017 19:17:36 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Wed, 19 Jul 2017 20:17:36 -0500 From: "Woodworth, John R" To: "'Jim Reid'" CC: dnsop WG , "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJbDfuAgAAPdwCAABuOAP//u9kwgABcYQCAAJGCYA== Date: Thu, 20 Jul 2017 01:17:34 +0000 Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 01:17:43 -0000 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > > What value has each IPv6 address? Or a name like > host-2001-67c-1232-144-21f-5bff-fec3-ab9d.example.com? Please > enlighten me. > Hi Jim, I guess beauty (or value) is in the eye of the beholder :) Although in practice the name would likely be shorter and potentially include other customer attributes, say acmewabbit-21f-5bff-fec3-ab9d.example.com 1. This shows the owner is example.com, customer acmewabbit 2. Reverse lookups are helpful for tools (e.g. traceroute) and logs. 3. Fulfills customer demand (not sure all their use cases but this topic shows up often enough to be important to them.) > > If you have a need to generate PTRs on the fly for IPv6 addresses > in your network, fine. However that doesn't seem to be a > compelling reason to modify the DNS protocol and change every > DNS server on the planet. > Forget for a moment about IPv6. This draft makes $GENERATE more memory efficient, scales bigger, stays intact through AXFR's and yes -it makes some nameservers (authoritative) work a bit more as a trade-off. The fact that IPv6 is a drastically bigger namespace and would benefit more is simply a bonus, this is just a next-gen $GENERATE. Thanks, John > > The cost/benefit optics of this draft are unclear. > > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Jul 19 19:12:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E852C12F274 for ; Wed, 19 Jul 2017 19:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 94YrWCf51rde for ; Wed, 19 Jul 2017 19:12:46 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 7C9EB126C2F for ; Wed, 19 Jul 2017 19:12:46 -0700 (PDT) Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6K2Cixs058695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 21:12:44 -0500 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2Cdo1045704; Wed, 19 Jul 2017 21:12:39 -0500 Received: from lxomp06u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2Cdbc045699 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 19 Jul 2017 21:12:39 -0500 Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2CdYr015698; Wed, 19 Jul 2017 21:12:39 -0500 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2CcRP015695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jul 2017 21:12:39 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Wed, 19 Jul 2017 21:12:38 -0500 From: "Woodworth, John R" To: "'John Levine'" , "dnsop@ietf.org" CC: "paul@nohats.ca" , "Woodworth, John R" Thread-Topic: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJb7Y7A Date: Thu, 20 Jul 2017 02:12:38 +0000 Message-ID: References: <20170719215749.2241.qmail@ary.lan> In-Reply-To: <20170719215749.2241.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 02:12:48 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of John Levine > > I realize that my biggest problem with this draft is not that > I don't think that it's useful -- we have lots of RFCs that > turned out to be useless but harmless. It's that it breaks the > DNS by being egregiously not backward compatible. > Hi John, As always, we welcome your comments. Agreed, BULK is not 100% backward compatible. Unfortunately, we are not coming into a greenfield situation and are forced work within the confines of where we are. Sometimes an idea like this is better discussed over a cold beer or N-A beverage and my next opportunity, I hope to sit with you and others on this list. For now, I think we've narrowed the draft opposition to two camps: Camp#1) Don't force me to use IPv6 reverse, I simply will never and Camp#2) Don't break DNS, even for a second I feel I hear and understand the concerns of both camps but believe the problems may be being over stated. If you choose to not use BULK for IPv6, fine. Perhaps you may see the benefit of $GENERATE-like synthesis that can be easily AXFR'd? > > I would strongly prefer if we defer consideration of this draft > until we figure out how to do DNS versioning, some way to say > that this record type (and consequently, the zone returned to > this AXFR or IXFR) requires special processing, and if you don't > know how to do the processing, don't guess. This would update or > perhaps even replace RFC 3597. > ... > > But with BULK, if a secondary doesn't understand it, the answers > will just be wrong. > If you choose a secondary, that is unaware of BULK, you will get NXDOMAIN's when they are hit. If BULK makes it into the top-5 DNS nameserver implementations, it's only a matter of time before the next security concern will get the secondary back in sync and in the meantime, maybe you can choose a compatible one. Early adopters will see hiccups, not sure this can be avoided, but how would delaying BULK until versioning is in place be able to prevent it? Wouldn't a secondary just have stale data or some other data inconsistency based on version incompatibility? Thanks again, John > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Thu Jul 20 00:57:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9C12ECCB for ; Thu, 20 Jul 2017 00:57:24 -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] 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 BPoCJuvWLwLD for ; Thu, 20 Jul 2017 00:57:21 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 8D25B126557 for ; Thu, 20 Jul 2017 00:57:21 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id AE9EC31C6A; Thu, 20 Jul 2017 09:57:18 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id 5ADA8EC0B75; Thu, 20 Jul 2017 09:56:46 +0200 (CEST) Date: Thu, 20 Jul 2017 09:56:46 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20170720075646.GB970@laperouse.bortzmeyer.org> References: <149916854131.16079.9203202983727964007.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149916854131.16079.9203202983727964007.idtracker@ietfa.amsl.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:57:24 -0000 On Tue, Jul 04, 2017 at 04:42:21AM -0700, IETF Secretariat wrote a message of 11 lines which said: > The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state > Candidate for WG Adoption Did anyone was brave enough to make a detailed comparison between this draft and other proposals like draft-yao-dnsop-accompanying-questions? (I was thinking myself of writing a draft on a ultra-simple proposal, allowing QDCOUNT to be > 1 but forcing all QNAMEs to be identical, but I never got time.) From nobody Thu Jul 20 00:57:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F235D126557 for ; Thu, 20 Jul 2017 00:57:24 -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] 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 U-HtN7XwjLOy for ; Thu, 20 Jul 2017 00:57:24 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 8D56E129A96 for ; Thu, 20 Jul 2017 00:57:21 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A3B7C31CE6; Thu, 20 Jul 2017 09:57:18 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id B0E75EC0B75; Thu, 20 Jul 2017 09:51:45 +0200 (CEST) Date: Thu, 20 Jul 2017 09:51:45 +0200 From: Stephane Bortzmeyer To: Shumon Huque Cc: Stephane Bortzmeyer , "dnsop@ietf.org WG" Message-ID: <20170720075145.GA970@laperouse.bortzmeyer.org> References: <20170719084942.GA18413@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:57:25 -0000 On Wed, Jul 19, 2017 at 02:28:37PM +0200, Shumon Huque wrote a message of 153 lines which said: > > Suppose I send the list ECDSA;RSA, and I receive only ECDSA > > signatures. How the resolver/cache would now if it was a complete > > list? > > The response contains the EDNS0 option if the responder executed > this protocol. In which case, the cache would tag this response as a > subset. Sorry, I still do not understand. The EDNS0 option does not indicate if the set is a subset or not. Or do you assume that, if the response indicates that the responder executes this protocol, an answer is always a subset (even if it's not)? > When the resolver queries the DNSKEY RRset for the zone, it knows > which algorithms are supported for the zone. You can have keys which are not used for signing (such as in the root today). From nobody Thu Jul 20 01:08:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CE7129AA0 for ; Thu, 20 Jul 2017 01:08:31 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OQMJK5mY9iK9 for ; Thu, 20 Jul 2017 01:08:29 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 F1FC8126557 for ; Thu, 20 Jul 2017 01:08:28 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 80so17396077uas.0 for ; Thu, 20 Jul 2017 01:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W7reEN2gjS9hErcUfGNQMDb4R+8lUqTuBtg7kKfmGTU=; b=g5t2leybvMY4TOqCwqbRPDC4TMA2wuE1n025LD00XR+xL5fkWU7F/FgbfzIDRdgps1 m07kskYfM+0CkRbESdSREVCrJgnNYnnLCnKxt+/XxWj5S/PXHDi4dDj223z64d3OxTLe I2E1DdqcCTqXJGNxwPxdM48x0eeIp05vJsc6ObXA3VaK+kB8scPgUr/1NZ/acF7z/g3N kOk9GWY+gvCXaYa57Lng7F0ZBYeLcm2zqiPf9aO+BmIglGKCWmfzMTZbVyGbSvTEphsl 9gwf0IGRQoK7KpCE9hrMx8mRvfnsGysYu1T1tTwNCgZD+o3TMGvY51LfbFc4zbcom2vB qaAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W7reEN2gjS9hErcUfGNQMDb4R+8lUqTuBtg7kKfmGTU=; b=ANP0VOwCSPeEG+bpDMP+PE0LNzFzCv+0/cT/oCxmCgeijACVZHCPRUiAQx7jRlM0Qb LmkKMpKmCjLmihfRzDA26RIeahDoa74BHioNajEc+MEloZaH/+jjlT3aVW7euafeOKvu LSElmgQQ6dGDBOTckNmzuDKjdW573vTsfnJYJL1eE0rSLCZhA2jZUOqq4lW0mN1BoLJm aeUKNtRb61OeLrNYQCtXk/GzuK3JsXTwrLsqgrkG6xKTehTTCFpDq/q6os4J8mY0vgxW fyas22WLYX1tNB7yEjipNH4m+sDfVPde7fqskUmg3cn3D4IWXSS5ZuOb0q+EXsZUhgbO WsCg== X-Gm-Message-State: AIVw110a5ptUbrdRyDKr96dREW/DVcp1tb/ZUsrszQyevG7yaU/F8mD4 52g1ZNuXTnM/mBu3fPjYvDRhjm4SuA2gFNc= X-Received: by 10.31.110.9 with SMTP id j9mr1531746vkc.171.1500538108157; Thu, 20 Jul 2017 01:08:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.78 with HTTP; Thu, 20 Jul 2017 01:08:27 -0700 (PDT) In-Reply-To: <20170720075145.GA970@laperouse.bortzmeyer.org> References: <20170719084942.GA18413@laperouse.bortzmeyer.org> <20170720075145.GA970@laperouse.bortzmeyer.org> From: Shumon Huque Date: Thu, 20 Jul 2017 10:08:27 +0200 Message-ID: To: Stephane Bortzmeyer Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c14a21ee8a3c00554bb40cb" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:08:31 -0000 --94eb2c14a21ee8a3c00554bb40cb Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 9:51 AM, Stephane Bortzmeyer wrote: > On Wed, Jul 19, 2017 at 02:28:37PM +0200, > Shumon Huque wrote > a message of 153 lines which said: > > > > Suppose I send the list ECDSA;RSA, and I receive only ECDSA > > > signatures. How the resolver/cache would now if it was a complete > > > list? > > > > The response contains the EDNS0 option if the responder executed > > this protocol. In which case, the cache would tag this response as a > > subset. > > Sorry, I still do not understand. The EDNS0 option does not indicate > if the set is a subset or not. Or do you assume that, if the response > indicates that the responder executes this protocol, an answer is > always a subset (even if it's not)? > The EDNS0 option, if received from the server, indicates that both (1) the server understands this protocol and (2) the server executed this protocol, i.e. that response includes a subset (specifically 1) of the deployed signature algorithms. I think the latest draft says this, but if not, I'll fix: https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-01 Also, if the server uses only one algorithm, but understands this protocol, then it probably shouldn't include this option, because there is nothing to do. > > When the resolver queries the DNSKEY RRset for the zone, it knows > > which algorithms are supported for the zone. > > You can have keys which are not used for signing (such as in the root > today). > Certainly, but only for the same algorithm. If there are multiple algorithms in use at an authoritative server, then there needs to be signatures associated with each algorithm. RFC 4035, Section 2.2 There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). -- Shumon Huque --94eb2c14a21ee8a3c00554bb40cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 9:51 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>= ; wrote:
On Wed= , Jul 19, 2017 at 02:28:37PM +0200,
=C2=A0Shumon Huque <shuque@gmail.com= > wrote
=C2=A0a message of 153 lines which said:

> > Suppose I send the list ECDSA;RSA, and I receive only ECDSA
> > signatures. How the resolver/cache would now if it was a complete=
> > list?
>
> The response contains the EDNS0 option if the responder executed
> this protocol. In which case, the cache would tag this response as a > subset.

Sorry, I still do not understand. The EDNS0 option does not indicate=
if the set is a subset or not. Or do you assume that, if the response
indicates that the responder executes this protocol, an answer is
always a subset (even if it's not)?

The EDNS0 option, if received from the server, indicates that both (1) the= server understands this protocol and (2) the server executed this protocol= , i.e. that response includes a subset (specifically 1) of the deployed sig= nature algorithms. I think the latest draft says this, but if not, I'll= fix:


Also, if the serv= er uses only one algorithm, but understands this protocol, then it probably= shouldn't include this option, because there is nothing to do.
=C2=A0
> When the resolver queries the DNSKEY RRset for the zone, it knows
> which algorithms are supported for the zone.

You can have keys which are not used for signing (such as in the roo= t
today).

Certainly, but only for the sam= e algorithm. If there are multiple algorithms in use at an authoritative se= rver, then there needs to be signatures associated with each algorithm.=C2= =A0

RFC 4035, Section 2.2

=C2=A0 =C2=A0There MUST be an RRSIG for each RRset using at least one DNSK= EY of
=C2=A0 =C2=A0each algorithm in the zone apex DNSKEY RRset.= =C2=A0 The apex DNSKEY RRset
=C2=A0 =C2=A0itself MUST be signed b= y each algorithm appearing in the DS RRset
=C2=A0 =C2=A0located a= t the delegating parent (if any).=C2=A0

--=C2=A0
Shumon Huque

--94eb2c14a21ee8a3c00554bb40cb-- From nobody Thu Jul 20 01:15:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4CA129AA0 for ; Thu, 20 Jul 2017 01:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 gQQRgwETm-Ib for ; Thu, 20 Jul 2017 01:15:44 -0700 (PDT) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 E7F26131483 for ; Thu, 20 Jul 2017 01:15:40 -0700 (PDT) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id v6K8FddU011460; Thu, 20 Jul 2017 17:15:39 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 7E882180064; Thu, 20 Jul 2017 17:15:38 +0900 (JST) Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id 69B50180062; Thu, 20 Jul 2017 17:15:38 +0900 (JST) Date: Thu, 20 Jul 2017 17:15:38 +0900 (JST) Message-Id: <20170720.171538.154265534035010446.fujiwara@jprs.co.jp> To: bortzmeyer@nic.fr Cc: dnsop@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <20170720075646.GB970@laperouse.bortzmeyer.org> References: <149916854131.16079.9203202983727964007.idtracker@ietfa.amsl.com> <20170720075646.GB970@laperouse.bortzmeyer.org> X-Mailer: Mew version 6.5 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.1.0.1062-23206.005 X-TM-AS-Result: No--3.340-5.0-31-10 X-imss-scan-details: No--3.340-5.0-31-10 X-TMASE-MatchedRID: vMI3egdXDQ1CXIGdsOwlUu5i6weAmSDKYawhvkuLgj6qvcIF1TcLYIAH BPmVHmpk2LitwsYAPc90Uwa6HM4n4P7tJ8S0pvwQZEi29PZzfK2hi9MC6OBOwuKv1l14gOR8zUV ZW0U/R7YyXmUu+NKW667fwSl3mRn+kuWIhM1lxJR2CNuIzaHi4TVPM/rRSR0dh8BhJvgqWBkNgl Bs2cTdnfVv3bMep8IukZOl7WKIImq0P2qkGU0Xys/8zK5WVP8LS0iSG6xyIZc+WVT1m0MMz1gXe pbcl7r7XtxqtgHfHdtHA7qb/QiH4wvvLr1z5psGgG7+Gl8X5Apg6SgcwqmguWz7Oj/VrWqVuZsg 2f88JrTgv+C6bBj4rcJgxsyaDMdiUARAPI1OA8tkfd/zPGWwsvvpR1kNBhYY7Y82MSiAt9ngc4b Wh8i7un7cGd19dSFd Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:15:46 -0000 > From: Stephane Bortzmeyer >> The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state >> Candidate for WG Adoption > > Did anyone was brave enough to make a detailed comparison between this > draft and other proposals like draft-yao-dnsop-accompanying-questions? > > (I was thinking myself of writing a draft on a ultra-simple proposal, > allowing QDCOUNT to be > 1 but forcing all QNAMEs to be identical, but > I never got time.) I prefered QDCOUNT>1 idea, but it mixes results of all queries. We want to know each RCODE and want to separate each answer. # Or, multiple DNS data in one UDP packet is possible. # DNSSEC may soluve the multiple RCODE problem. draft-yao-dnsop-accompanying-questions keeps each RCODE information in EDNS0 data. draft-bellis-dnsext-multi-qtypes does not have the problem because the qname is only one. draft-wkumari-dnsop-multiple-responses does not have the problem because the main query is one. We would like to compare all idea before proceeding. -- Kazunori Fujiwara, JPRS From nobody Thu Jul 20 01:17:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5164127337 for ; Thu, 20 Jul 2017 01:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 KbsGX48JEBAi for ; Thu, 20 Jul 2017 01:17:29 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6BF126557 for ; Thu, 20 Jul 2017 01:17:29 -0700 (PDT) Received: from [46.227.151.81] (port=51358 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:587) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dY6eF-0001Ti-DN (Exim 4.72) for dnsop@ietf.org (return-path ); Thu, 20 Jul 2017 09:17:27 +0100 To: dnsop@ietf.org References: <149916854131.16079.9203202983727964007.idtracker@ietfa.amsl.com> From: Ray Bellis Message-ID: Date: Thu, 20 Jul 2017 09:17:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149916854131.16079.9203202983727964007.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:17:31 -0000 On 04/07/2017 12:42, IETF Secretariat wrote: > The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state > Candidate for WG Adoption (entered by Tim Wicinski) I heard that someone implemented this during the Hackathon at the weekend. Does anyone know who that was? thanks, Ray From nobody Thu Jul 20 01:33:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BAA131A81 for ; Thu, 20 Jul 2017 01:33:54 -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 (1536-bit key) header.d=iecc.com header.b=M++pnD0H; dkim=pass (1536-bit key) header.d=taugh.com header.b=uE4HIfCD 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 yfMyQwJkP2ok for ; Thu, 20 Jul 2017 01:33:51 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688511318A0 for ; Thu, 20 Jul 2017 01:33:51 -0700 (PDT) Received: (qmail 93706 invoked from network); 20 Jul 2017 08:33:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16e08.59706aee.k1707; bh=zAatEDnG7vdPqp1yXEz9b7RaP/iUr9o1tAkesA4Q9Ww=; b=M++pnD0HiDUX18ursjHAn2MgGQvchz8VHQ4OzFsiuxPvmXUFt3bsXKtSIphj8ur31F4keLbqotJmp2b2gVa92AXpUCX86lM1CM90hApzjknT0gg+JnlQj74h6w/iE7uy1q/Yd5SJKM3rHzrSQ4vKuT/1keg4Y01lLFb79rHZSsB/E8aqng2G+HpXT7vkmZTtZrlv7kM90hR7KipmzW1YcC4EO7aPOuQV4WRzNLSkSvNqkTdYTJozBba52uwLg1qG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16e08.59706aee.k1707; bh=zAatEDnG7vdPqp1yXEz9b7RaP/iUr9o1tAkesA4Q9Ww=; b=uE4HIfCDhpuAhUavieKifuXHPDe5taKI2FXhHewu4sRITJnGkZYZBf2RnLwpD/nvP23nO0+8hGr4BgnChup8sr+WyZPUYzghrADdSajLRHndCDitiCBF9I65Po7MJpeDMTnIGBmPjdStwpTTztfu74nLsXd1YNaGd2Hvtxfh2kaQTY9PrWdrKUANvkZmeuBTV88P3GJQhw8uP3UNrwaS6FX92bvD3MPL+RunaMZ3d33Tcd0m5b3NW4DsIzyAwPHS Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jul 2017 08:33:50 -0000 Date: 20 Jul 2017 10:33:48 +0200 Message-ID: From: "John R Levine" To: "Woodworth, John R" Cc: "dnsop@ietf.org" , "paul@nohats.ca" In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:33:55 -0000 On Thu, 20 Jul 2017, Woodworth, John R wrote: > Camp#2) Don't break DNS, even for a second Well, yeah, except that there's no such thing as breaking the DNS for a second. If we look at the history of DNSSEC, we'd break the DNS for somewhere between a decade and forever. We have tried very hard for three decades to avoid breaking backward compatibility, and it's hard to believe that this is the reason to do it. > If you choose a secondary, that is unaware of BULK, you will get > NXDOMAIN's when they are hit. If BULK makes it into the top-5 > DNS nameserver implementations, it's only a matter of time before > the next security concern will get the secondary back in sync and > in the meantime, maybe you can choose a compatible one. If only it were that simple. BULK absolutely requires online DNSSEC signing, and there is no even halfway standard to distribute signing keys to secondary servers. I think it would be a good thing to figure out how to do DNSSEC key distribution, but we are a long way away from that. I think we can assume that "BULK works if you don't sign" is not a winning argument. Without versioning, BULK will be endlessly flaky. With versioning that keeps broken mirrors from serving it, it'd work a lot better. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jul 20 01:39:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFD2127735 for ; Thu, 20 Jul 2017 01:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 vAxYxIndDFpB for ; Thu, 20 Jul 2017 01:39:40 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 B883B127869 for ; Thu, 20 Jul 2017 01:39:39 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id n42so16498368qtn.0 for ; Thu, 20 Jul 2017 01:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mzXQp89c0mawNN8rxigxcw4w3j5Uf5pB/VeHmiFcrBk=; b=c+I+XZF8AIqV6vwxaGe2s10Uaez5QXru5/NutnS4spjb3szy8v1AbbLYzVRs8tYmvt +wFqU8GEAKFLtE0jvFqOuurViEcMIEj6EJQmHaNdla/N73/74Lqg3BXa+mjuMc2uyH73 RRDRwZe1K/uUFjUZRDTeLrOsriBG4nRzGQF0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mzXQp89c0mawNN8rxigxcw4w3j5Uf5pB/VeHmiFcrBk=; b=dGdcqGNMDnk1lEP86gUu5WfYZ3rAt7gMywsSMRTGk0qBRrlMFJp0zTR8L2WuyDAR/v 6J7F19MntTZwvwuqOwvd9Y1naRsV3Tq7nKlR1y60oyRyPjodPevLAOIcfgu0ZdzXE3lX 4Yyn1hvSXMJjMFaTMctFtuUSn1vN/M7u3qDTcZOCF890dwGODR/SO3rhnWrah1Q5p4QQ 05eXBJzbwuMWzaAjb0vhPmYh9Px+8J+WQPnE4TlGR/o7thZDdk53dX6j+47l27+w2z2I oKW8AIE0Ab/OWqUwwzg1geg2FfvqqjXfmvZHVLwisAL+hh2aIzandlMKLJ9LAH3hji76 FBFg== X-Gm-Message-State: AIVw113mOLQNOUhHZij/9JT8ev+eiEXmG1SfIi+mWOxlPwbJJ0mHf+X5 FEIsDKPPLafS9z6NcXqlwDg0PGEd71sK X-Received: by 10.237.60.57 with SMTP id t54mr4029260qte.281.1500539976116; Thu, 20 Jul 2017 01:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.228 with HTTP; Thu, 20 Jul 2017 01:39:35 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Thu, 20 Jul 2017 10:39:35 +0200 Message-ID: To: Shumon Huque Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c191f5c3f82e60554bbb089" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:39:42 -0000 --94eb2c191f5c3f82e60554bbb089 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque wrote: > On Mon, Jul 10, 2017 at 5:01 PM, =C3=93lafur Gu=C3=B0mundsson > wrote: > >> Shumon, >> >> In section 5 your draft says: >> >> If an Authoritative Server has no algorithms in common with the >> Preferred Algorithms list in the incoming query, it MUST send back a >> SERVFAIL response (Response Code 2). This response MUST contain the >> list of algorithms supported by the server in the EDNS0 Preferred >> Algorithms option. >> >> >> >> This is a HORRIBLE violation of the DNSSEC spirit. All validators are >> supposed to fail to open when they can not validate algorithm the signat= ure >> is generated by. >> > > As I tried to explain in my previous note to Paul Wouters - fail open is > horrible for DANE. Protocols can evolve. If DNSSEC had algorithm > negotiation from the beginning, fail open would not have been necessary. > This fail open behavior frequently takes people not in the DNSSEC club by > complete surprise. I've lost track of how many "WTF" moments I've had to > explain to other people about this behavior. This proposed behavior chang= e > is also signaled, not unilateral. But let's debate ... > > I disagree, if a zone operator selects "less-than" common algorithm they do that at their own risk, if the risk is not acceptable then it should dual sign.... > Section 6 >> This is hopeless algorithm, that goes against the justification of the >> document. >> basically it may force validating resolvers to fetch the answers multipl= e >> times for each TTL; once without DNSSEC, then for first algorithm, then = for >> all algorithms =3D=3D> right now validating resolvers only fetch once wi= th >> DNSSEC enabled. >> > > There has to be some initial fallback behavior with costs. This is not > uncommon in new protocols. Think about longer term benefits. > After thinking about this a few times, I still see no future benefits. > > >> This is a HORRIBLE violation of the DNSSEC spirit. All validators are >> supposed to fail to open when they can not validate algorithm the signat= ure >> is generated by. >> > > See previous discussion. > > >> >> overall this draft main idea: DNS publishers should sign with more >> algorithms, =3D=3D=3D> this means more keys in DNSKEY set i.e. larger DN= SKEY set >> =3D=3D> better for DDoS >> > > DNSSEC already has a DDoS reputation - this isn't going to make things > that much worse. Also DNSSEC has already been way surpassed in this area = by > NTP/SNMP etc. What we should be working on is deployment of proper protoc= ol > level mitigations, like Cookies, etc. > > I'm not sold on Cookies solving real problems. The way to get away from that reputation is online signing of negative answers and retirement of all RSA signatures (no I'm not promoting NSEC5), Online signing with NSEC works just fine. Olafur --94eb2c191f5c3f82e60554bbb089 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque <shuque@gmail.com>= ; wrote:
On Mon, Jul 10, 2017 at= 5:01 PM, =C3=93lafur Gu=C3=B0mundsson <olafur@cloudflare.com><= /span> wrote:
Shumo= n,=C2=A0

In section 5 your draft says:=C2=A0
   If an Authoritative Server has no algorithms in common wi=
th the
   Preferred Algorithms list in the incoming query, it MUST send back a
   SERVFAIL response (Response Code 2).  This response MUST contain the
   list of algorithms supported by the server in the EDNS0 Preferred
   Algorithms option.


This is a H= ORRIBLE violation of the DNSSEC spirit. All validators are supposed to fail= to open when they can not validate algorithm the signature is generated by= .=C2=A0

As I= tried to explain in my previous note to Paul Wouters - fail open is horrib= le for DANE. Protocols can evolve. If DNSSEC had algorithm negotiation from= the beginning, fail open would not have been necessary. This fail open beh= avior frequently takes people not in the DNSSEC club by complete surprise. = I've lost track of how many "WTF" moments I've had to exp= lain to other people about this behavior. This proposed behavior change is = also signaled, not unilateral. But let's debate ...

I disagree= , if a zone operator selects "less-than" common algorithm they do= that at their own risk,=C2=A0
if the risk is not acceptable then= it should dual sign....=C2=A0
=C2=A0
=
Section 6=C2=A0
This is hopeless algorithm, that goes agains= t the justification of the document.=C2=A0
basically it may force= validating resolvers to fetch the answers multiple times for each TTL; onc= e without DNSSEC, then for first algorithm, then for all algorithms =3D=3D&= gt; right now validating resolvers only fetch once with DNSSEC enabled.=C2= =A0

There has to b= e some initial fallback behavior with costs. This is not uncommon in new pr= otocols. Think about longer term benefits.

After thinking about this a few times, =C2=A0I stil= l see no future benefits.
=C2=A0=
This is a H= ORRIBLE violation of the DNSSEC spirit. All validators are supposed to fail= to open when they can not validate algorithm the signature is generated by= .=C2=A0

See previo= us discussion.
=C2=A0
<= div dir=3D"ltr">

overall this draft main idea: DNS = publishers should sign with more algorithms, =3D=3D=3D> this means more = keys in DNSKEY set i.e. larger DNSKEY set =3D=3D> better for DDoS=C2=A0<= /div>

DNSSEC already has= a DDoS reputation - this isn't going to make things that much worse. A= lso DNSSEC has already been way surpassed in this area by NTP/SNMP etc. Wha= t we should be working on is deployment of proper protocol level mitigation= s, like Cookies, etc.
=C2=A0

I'm not sold on Cookies solving real problems= .=C2=A0
The way to get away from that reputation =C2=A0is online = signing of negative answers and retirement of all RSA signatures (no I'= m not promoting NSEC5), Online signing with NSEC works just fine.=C2=A0

Olafur
--94eb2c191f5c3f82e60554bbb089-- From nobody Thu Jul 20 01:46:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E537D131AD7 for ; Thu, 20 Jul 2017 01:45:47 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CPNLafwseyGa for ; Thu, 20 Jul 2017 01:45:46 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 2FD54129B40 for ; Thu, 20 Jul 2017 01:45:46 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id u4so18093877uaa.1 for ; Thu, 20 Jul 2017 01:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pq/mIewPdCRZqumbzMw0aY9/+BZA1QVPDdFL55yPRFc=; b=Y/plgF3ojbIzrNZChVVfY3YVn9HnxW56c3K0XJov2m13uonh6VX+T9dwCASInm6DzX KVnQKPKQfcF7jHG4eE7UqhkJ0W9mJRsJXXr2PAPmqXGAo82yRbHbvLT1AbcLmLh3sqRj xNGBNWqZ7Y/ahqr70vpY7tRTJz/cMbH9A9QBs+HJdafLQZKh+csA7uaJEY4OBg+PSmee cF3NteoYKECoyssLngc1R/ccG8GXrkjT2eAuLzLgJjL1cg4BN+uR/0sNBcYlui6fdUCc o0yB0ayNGs9GjgIzFEZddXmyw1c8UaHordAIXdRsG4zPLI0krvuJ8Irnb8Ig3A/wgsXV f12w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pq/mIewPdCRZqumbzMw0aY9/+BZA1QVPDdFL55yPRFc=; b=tRPMQKyysrcMMz/6yNOJn6Md/v8zqihA5MyNHQToyJBypiyHLX55od7pOFpBKmJzXQ iS00h0qElhpKKRv40R1D9Vw0TrTpRVtQ8dgON7oQlVudqo+5j/eUXDSHKMolPNIBcqLT JGxuYNXjY94F3VMPeeG/UDNgYCljsUaSDMhuOilIOljjQd9DIbDnGcnIuBSmXYW0qHfd IYWBbdliDDmPUUO1evCz3+qqDEQUoBaUgf+extqTHgQ0sigDeIiUXSB8HACCZd1QNVlx esK91+WgRlE8MNS0id/bPrUt297dTeKjw/9iGjymzooV9P3cdXpi+MGw1SqYVZXJU99w Dg2Q== X-Gm-Message-State: AIVw111zpqTIBqbGQQ1LulKm+bqywhNgdaxYy/8uYslSj9HyAtW07NML 3akrV+b38CRPnZY8BuCn7MmuECE/auYD X-Received: by 10.31.110.9 with SMTP id j9mr1578331vkc.171.1500540345387; Thu, 20 Jul 2017 01:45:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.78 with HTTP; Thu, 20 Jul 2017 01:45:44 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Thu, 20 Jul 2017 10:45:44 +0200 Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c14a21e4213470554bbc6dc" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:45:48 -0000 --94eb2c14a21e4213470554bbc6dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 10:39 AM, =C3=93lafur Gu=C3=B0mundsson wrote: > > > I disagree, if a zone operator selects "less-than" common algorithm they > do that at their own risk, > if the risk is not acceptable then it should dual sign.... > Yes. The point I was trying to make is that DANE sites (and probably others if they care about security) cannot afford to fail open. So they have to dual sign if they can stomach the costs, or delay deploying new algorithms for a long time. This draft is intended to (eventually) make the dual signing case easier to deal with operationally. --=20 Shumon Huque --94eb2c14a21e4213470554bbc6dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 10:39 AM, =C3=93lafur Gu=C3=B0mundsson <olafur@clo= udflare.com> wrote:

I disagree, if a zone operator selects "l= ess-than" common algorithm they do that at their own risk,=C2=A0
=
if the risk is not acceptable then it should dual sign....=C2=A0
=

Yes. The point I was try= ing to make is that DANE sites (and probably others if they care about secu= rity) cannot afford to fail open. So they have to dual sign if they can sto= mach the costs, or delay deploying new algorithms for a long time. This dra= ft is intended to (eventually) make the dual signing case easier to deal wi= th operationally.

--=C2=A0
Shumon Huque<= /div>

--94eb2c14a21e4213470554bbc6dc-- From nobody Thu Jul 20 02:07:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08EB127735 for ; Thu, 20 Jul 2017 02:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 4Wjulp3g8d1y for ; Thu, 20 Jul 2017 02:07:30 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 537EA126B72 for ; Thu, 20 Jul 2017 02:07:30 -0700 (PDT) Received: from jurassic (unknown [115.118.170.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id CCAD656A0134; Thu, 20 Jul 2017 09:07:27 +0000 (GMT) Date: Thu, 20 Jul 2017 14:37:23 +0530 From: Mukund Sivaraman To: =?utf-8?B?56We5piO6YGU5ZOJ?= Cc: dnsop Message-ID: <20170720090723.GA454@jurassic> References: <20170718094654.GA31988@jurassic> 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.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:07:32 -0000 Hi Jinmei On Wed, Jul 19, 2017 at 04:14:11PM -0700, 神明達哉 wrote: > At Tue, 18 Jul 2017 18:20:56 +0530, > Mukund Sivaraman wrote: > > > Dealing with water torture and some other attacks have had several > > band-aid approaches that don't always work well in practice. The most > > promising (and what feels correct) is > > draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned > > zones. > > Do you mean it's the most promising measure for authoritative servers? > If so, and if nsec-aggressiveuse is more widely deployed in resolvers, > and if the authoritative operators feel the pain so keenly, I'd rather > imagine they are willing to pay the cost of deploying DNSSEC. > > If you mean it's the most promising measure for recursive servers, I > simply don't buy the argument. (I made that comment while the wg > discussed nsec-aggressiveuse and it toned down quite a lot in that > sense as a result of it, so I believe it's based on a wg rough > consensus). I had meant only one of the benefits that nsec-aggressiveuse brings: * Avoid creating unnecessary fetches from the resolver by being able to answer more queries from cache (... ignoring the wildcard case.) It would help an auth service indirectly (if resolvers don't send it as many queries) but it has to handle the queries it gets. There are different approaches that are being used for handling water torture style attacks (bloom filtering with previously seen queries, fetches-per- controls, BLOOM RR type, etc.) but compared to those methods, NSEC aggressive use is a "correct" absolute method to stop fetches to non-existent names and data that works with minimal implementation changes only. A lot of popular zones are still unsigned. There are different reasons for it. Without advocating against DNSSEC, I want to point out that the all-or-nothing behavior of validation needs absolute correctness end-to-end in all pieces that some zone owners think about when considering whether to sign their zones. There are still implementation bugs. E.g., recently for several weeks/months, .ORG had a problem where it would not allow a DS record to be marked as removed. This meant that a child zone that wanted to go from signed to unsigned state could not do so (my own zones were affected). A zone signer implementation bug (e.g., untimely RRSIG generation causing no new RRSIGs to be added before existing RRSIGs expire) has the capability to take down all internet services at a domain. This still happens today, believe it or not. A zone owner has no control over schemes like using negative trust anchors at each resolver. There is the potential of significant economic loss to a business due to downtime that owners think about. Such frailty in the DNSSEC state of implementation has to improve before advocating DNSSEC as a solution to all problems. The fact that NSEC is a DNSSEC feature, and that it solves handling negative answer queries is a side-effect, but considering things individually, solving water torture style attacks doesn't need the rest of DNSSEC. It needs NSEC. (Please don't think that I'm advocating against DNSSEC. These are problems I come across practically as a programmer for a DNS implementation.) We have several popular unsigned zones today. It is the resolver side that has to answer for random non-existent subdomains under these zones. When talking about taking away the RRSIG of NSEC, it causes people to feel uncomfortable, but unsigned zones are unsigned after all. Whatever modification can be done by an attacker with an unsigned NSEC can be done right now too for individual queries. There should be more thought about benefit vs. risk of using such a scheme. Mukund From nobody Thu Jul 20 02:08:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02F5131566 for ; Thu, 20 Jul 2017 02:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 jnRgQoDV7cMp for ; Thu, 20 Jul 2017 02:08:37 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 A74BE12ECF0 for ; Thu, 20 Jul 2017 02:08:37 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id o8so16461061qtc.5 for ; Thu, 20 Jul 2017 02:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uB+4LHfBLzmps+Fh8q7FmwufKJGkw+xJLghPRLr83ig=; b=wDP6sRKJgS7MD1vps5C+U6uY/ggfXDzVPN1eMLv4yrd0/K8Ds+6n7JErUfAleIxc+s 15LIC3Ib/4oirA0IBmS1lrNQHb2Y7qObG/nOxvMf6dEzD2dM0DdmxawB7VC7m5g5AcjD NKsua1DN1b8N5JO3h0QSCUjE4e5SDAqqRLefc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uB+4LHfBLzmps+Fh8q7FmwufKJGkw+xJLghPRLr83ig=; b=QDedaBiLrItHp/qqHFeZ8pYRIHSdqMMK1jKYk7WUiR9qI5WNKKbs8Fd9O3eFnp4J2T oiLJOwDsb0ZZKkBWaJRI+X4+r4SKC4bCFGgKcOijAELRh2pOkHIAiosVZ7uZIcmXziji Frgbfszi/DgszdOxMFvlpplOEvTtpUzcbUnIh6LylrsAUMI9CuO2xlOVsVtaKSBFlqKf 8O6ySbC4rF5UgIl/OjgV5vOLF6IW5pgU83eaDDedUZQRO/8f45XnO/LqkLdksjfFhg0s I5cG6HY09hAexU332ucJwfgDo6UYV2PUFTRib6fFq1t07/OPtiv5ZmDYxdcOaL1KoNbz Z+Fw== X-Gm-Message-State: AIVw113ZhfeARv8DdAN+M2I9CLqBncA+F+I1+FoiMKOX/5LgIZJ4V+5y haoBMs9113UbPUbryis6cG7ZJZeu1mlf X-Received: by 10.237.36.6 with SMTP id r6mr4068377qtc.159.1500541715728; Thu, 20 Jul 2017 02:08:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.228 with HTTP; Thu, 20 Jul 2017 02:08:35 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Thu, 20 Jul 2017 11:08:35 +0200 Message-ID: To: Shumon Huque Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113bbf52efe6290554bc17c0" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:08:39 -0000 --001a113bbf52efe6290554bc17c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 10:45 AM, Shumon Huque wrote: > On Thu, Jul 20, 2017 at 10:39 AM, =C3=93lafur Gu=C3=B0mundsson < > olafur@cloudflare.com> wrote: >> >> >> I disagree, if a zone operator selects "less-than" common algorithm they >> do that at their own risk, >> if the risk is not acceptable then it should dual sign.... >> > > Yes. The point I was trying to make is that DANE sites (and probably > others if they care about security) cannot afford to fail open. So they > have to dual sign if they can stomach the costs, or delay deploying new > algorithms for a long time. This draft is intended to (eventually) make t= he > dual signing case easier to deal with operationally. > The point I'm making is that the proposed medicine is worse than the ailment. Olafur --001a113bbf52efe6290554bc17c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 20, 2017 at 10:45 AM, Shumon Huque <shuque@gmail.com>= ; wrote:
On Thu, Jul = 20, 2017 at 10:39 AM, =C3=93lafur Gu=C3=B0mundsson <olafur@cloudflare.= com> wrote:

I disagree, if a zone operator selects "less-than" comm= on algorithm they do that at their own risk,=C2=A0
if the risk is= not acceptable then it should dual sign....=C2=A0
<= /blockquote>

Yes. The point I was trying to make = is that DANE sites (and probably others if they care about security) cannot= afford to fail open. So they have to dual sign if they can stomach the cos= ts, or delay deploying new algorithms for a long time. This draft is intend= ed to (eventually) make the dual signing case easier to deal with operation= ally.


The point I'm making is tha= t the proposed medicine is worse than the ailment.=C2=A0

Olafur

--001a113bbf52efe6290554bc17c0-- From nobody Thu Jul 20 02:37:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6113157A for ; Thu, 20 Jul 2017 02:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Rmr3WzUor2Tx for ; Thu, 20 Jul 2017 02:37:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 1CDEB12ECC3 for ; Thu, 20 Jul 2017 02:37:55 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id A90FD3493C3 for ; Thu, 20 Jul 2017 09:37:51 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 962F3160044 for ; Thu, 20 Jul 2017 09:37:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6C018160045 for ; Thu, 20 Jul 2017 09:37:51 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HFLxGYuCqEmM for ; Thu, 20 Jul 2017 09:37:51 +0000 (UTC) Received: from rays-mbp.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id D7C9C160044 for ; Thu, 20 Jul 2017 09:37:50 +0000 (UTC) To: dnsop From: Ray Bellis Message-ID: <1a1e0d88-3ac6-b6a7-0f64-1f023077fcb1@isc.org> Date: Thu, 20 Jul 2017 10:37:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] REMINDER: Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:37:56 -0000 The CFP submission deadline is fast approaching. If you'd like to present at this meeting please get your submissions in soon! thanks, Ray --8<--8<-- The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on September 29th and 30th 2017, the Friday and Saturday preceding NANOG 71. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we can accommodate those talks during the Members Only session on the morning of September 29th. A timeslot will also be available for lightning talks (5-10 minutes) on Saturday September 30th, for which submissions will be accepted during Friday 29th. Workshop Milestones: 26 May 2017, Call for Presentations posted and open for submissions 28 July 2017, Deadline for submission 11 August 2017, Draft Programme published 01 September 2017, Final Program published 15 September 2017, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/27/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Ray Bellis, for the OARC Programme Committee OARC depends on sponorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) From nobody Thu Jul 20 02:48:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7348213170E for ; Thu, 20 Jul 2017 02:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 mrdDsVeAgJkA for ; Thu, 20 Jul 2017 02:48:56 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 F1C7613157A for ; Thu, 20 Jul 2017 02:48:53 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:386d:ca0b:2cef:6352] (unknown [IPv6:2001:67c:370:128:386d:ca0b:2cef:6352]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id EC0F3B06E for ; Thu, 20 Jul 2017 11:48:51 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1500544132; bh=CVw+hhO3lzDS+VW7wHtsaLsa8s4QfMK0SHJAde+wrTs=; h=Subject:To:References:From:Date:In-Reply-To; b=wBc9RVZ7/CFJjUtXkWSfs2WkYA7YertjjHvXQ8bTKjmwoaY2SRWIU3rhmuKgKyBgt /xoSDSB1vJRBzEex0pdntTiabIUUrcuXlSU0lBkgCZh5Mk/p/xtofdAeGJ0ggzIRsU QZTd2krxhIWs4lsfACixG53Jlud0rY5nGTicyFRg= To: dnsop@ietf.org References: From: Willem Toorop Message-ID: <257a0f7a-a78d-d665-512f-ff2a71dfaede@nlnetlabs.nl> Date: Thu, 20 Jul 2017 11:48:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:48:58 -0000 Op 20-07-17 om 10:45 schreef Shumon Huque: > On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson > > wrote: > > > I disagree, if a zone operator selects "less-than" common algorithm > they do that at their own risk, > if the risk is not acceptable then it should dual sign.... > > > Yes. The point I was trying to make is that DANE sites (and probably > others if they care about security) cannot afford to fail open. So they > have to dual sign if they can stomach the costs, or delay deploying new > algorithms for a long time. This draft is intended to (eventually) make > the dual signing case easier to deal with operationally. So, Providers of DANE backed services are stuck on the well-known algorithms, and do not have insight on algorithm support by clients verifying these services with DANE. This draft in combination with double signing, provides the means to deal with this (and in a secure manner too). I think this is an important motivation of this work and that this should be reflected in the Introduction section of the draft. -- Willem > > -- > Shumon Huque > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Thu Jul 20 03:11:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE489131BFC for ; Thu, 20 Jul 2017 03:11:36 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 r2zc4zWliK6J for ; Thu, 20 Jul 2017 03:11:35 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 1E23E12F290 for ; Thu, 20 Jul 2017 03:11:35 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id w45so19310633uac.5 for ; Thu, 20 Jul 2017 03:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XjmIik4H534eoLLpIA6SJ0oddvsK3LuXj0IbeHzThnA=; b=dytKQJ3LCZfTF5WWM85HoJW+xVMejf3Q/T2zosc/INBphJGeVfunSQTDlbJKGThbQB fyA1bO1iXFUwo41/KNT7rzrcUN7U6XjlegLmTtEiAt0fppTyhPWJylCoHM75yv/pyocB E8GKY7fVKqA2Jboa4HrcxVy8pOBL7+nTvLKrj4rCAsf4gBpnqXCQdIDQd82T+iFKyMNU 7fzcnDZw+QGomHMQOodCIEsMrMzDmbEfXJVEYJ5X+MmQzyTXVqcnJhP6dNVO5vW+vqgG UsguHRGPKhT6b7I242GOyujIXZdAQftQZRfgTPRbbSpb6gPx2nNS2hmSq5dSKbkjv4Of KCUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XjmIik4H534eoLLpIA6SJ0oddvsK3LuXj0IbeHzThnA=; b=HGa80MD3hlY7EZNXzKM8qUJQV31wcvIg4EsxKDsyr6py9LGJnADK0mPkM+TfRuDFWT Pn5vXIcS9soE7q0QnvkDoI90tJ3fzZ4ZkNalLyhDeTkn6j0+AdzAh+rkBdCNM8a3VhMm 5a00lsfhqXsu9zSOUqMAMPvx5As+2JdXRinBi8yNNTcGb4T9Jwa92+W9fvNrqghL8xwz Bd07kowEGFrQmMm+LzfbKfDE30J6qNFWHcghgDpgtjiJCJJuBM5ki1tmz5JNaHfDbRGX yV60KOHnOafOs+HGIYUvszK1CNBWeT5lZPCGu5voIbbGLpsscFjZT37KiXNSVrsqlwsc Li4w== X-Gm-Message-State: AIVw111FMWfg3x5PbsK+Qm75eB7le84FfLz34J5D3PBUL6BYKV1D/ntB twe+IXlDuHmwwVO4RdaczYspXAEdb9AK X-Received: by 10.176.2.116 with SMTP id 107mr1836861uas.203.1500545494323; Thu, 20 Jul 2017 03:11:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.78 with HTTP; Thu, 20 Jul 2017 03:11:33 -0700 (PDT) In-Reply-To: <257a0f7a-a78d-d665-512f-ff2a71dfaede@nlnetlabs.nl> References: <257a0f7a-a78d-d665-512f-ff2a71dfaede@nlnetlabs.nl> From: Shumon Huque Date: Thu, 20 Jul 2017 12:11:33 +0200 Message-ID: To: Willem Toorop Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113e45d42897b00554bcf9aa" Archived-At: Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:11:37 -0000 --001a113e45d42897b00554bcf9aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 11:48 AM, Willem Toorop wrote= : > Op 20-07-17 om 10:45 schreef Shumon Huque: > > On Thu, Jul 20, 2017 at 10:39 AM, =C3=93lafur Gu=C3=B0mundsson > > > wrote: > > > > > > I disagree, if a zone operator selects "less-than" common algorithm > > they do that at their own risk, > > if the risk is not acceptable then it should dual sign.... > > > > > > Yes. The point I was trying to make is that DANE sites (and probably > > others if they care about security) cannot afford to fail open. So they > > have to dual sign if they can stomach the costs, or delay deploying new > > algorithms for a long time. This draft is intended to (eventually) make > > the dual signing case easier to deal with operationally. > > So, > > Providers of DANE backed services are stuck on the well-known > algorithms, and do not have insight on algorithm support by clients > verifying these services with DANE. > > This draft in combination with double signing, provides the means to > deal with this (and in a secure manner too). > > I think this is an important motivation of this work and that this > should be reflected in the Introduction section of the draft. > > -- Willem > Thank you Willem, and your point is noted. We will work on improving the introduction to address this. --=20 Shumon Huque --001a113e45d42897b00554bcf9aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 11:48 AM, Willem Toorop <willem@nlnetlabs.nl&g= t; wrote:
Op 20-07-17 om 10:45 sch= reef Shumon Huque:
> On Thu, Jul 20, 2017 at 10:39 AM, =C3=93lafur Gu=C3= =B0mundsson
> <o= lafur@cloudflare.com <mailto:olafur@cloudflare.com>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0I disagree, if a zone operator selects "less-t= han" common algorithm
>=C2=A0 =C2=A0 =C2=A0they do that at their own risk,
>=C2=A0 =C2=A0 =C2=A0if the risk is not acceptable then it should dual s= ign....
>
>
> Yes. The point I was trying to make is that DANE sites (and probably > others if they care about security) cannot afford to fail open. So the= y
> have to dual sign if they can stomach the costs, or delay deploying ne= w
> algorithms for a long time. This draft is intended to (eventually) mak= e
> the dual signing case easier to deal with operationally.

So,

Providers of DANE backed services are stuck on the well-known
algorithms, and do not have insight on algorithm support by clients
verifying these services with DANE.

This draft in combination with double signing, provides the means to
deal with this (and in a secure manner too).

I think this is an important motivation of this work and that this
should be reflected in the Introduction section of the draft.

-- Willem

Thank you Wille= m, and your point is noted. We will work on improving the introduction to a= ddress this.

--=C2=A0
Shumon Huque
=

--001a113e45d42897b00554bcf9aa-- From nobody Thu Jul 20 04:11:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3F129AD1 for ; Thu, 20 Jul 2017 04:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=gmail.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 VGmhK8uV3TqF for ; Thu, 20 Jul 2017 04:11:07 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 34DE512EAF0 for ; Thu, 20 Jul 2017 04:11:07 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id m86so3621502lfi.4 for ; Thu, 20 Jul 2017 04:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Fwnenff2EgOCLxYOAl5NNo2WeKSd1c+uDom3cQlfPdw=; b=sheVY/wmWeKwWR9TfjOt4kUhGHHq6FI32bV1yHZ/wedufeSoZuZ7mjJvmWbSWTG375 x0HaLFVdVJW0+FyxmbGovD1D5pKUYQG3V2RvAvxUFDbsgbeA9VWhWtV//EHpkTiLserB b3C4zXHyGKC23gO6k4O9JSC1bEPuVkdFaCQo82ibKTaZcsrZwwxQikjB5zgUsVkbHb5O VP+xiN/Pq412JNiegPhgmhRlaFCVlB9d/Tm77J/tRy4T86Hw0I8J5X6aaPpU1uFnLvwZ 64B7Y0ausSLJcTIUjRDr1NU5eTkjGzi/Hh+FAHf7NZLncEVKf0L0tqhQZ3LT0BCQdP0U mtJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Fwnenff2EgOCLxYOAl5NNo2WeKSd1c+uDom3cQlfPdw=; b=pMRPaFqH0I9Uc5XaCQcizprSgIaFPT/ruPgjsRF/C9gULDKaUJhwAd+jOBamB376FN F8h4GIDcbQ7Oyp1zGDEuA+bOifXGOTICwku2KEeONi3FQ8p6MVZZnVPoxvGKDnE2P8dY yhHYb9kHyzrzPcnC3gRyO9HrH4ThqLEm1Xf4aIgghms+2giUaZ204ig01hTS2ZrhVTxe WfdBVjUk/2lU9KJSImI8jm+PcATraKkyHN35IrBI52utsPGno9JOiK1r3zI9OowZwjfS JXZA6/fBTBChGxoIacamXpyT8gRBFTFZnz6xO6zQcdLw1qaFUbyUlNeRZBySIHerUGF8 RUjQ== X-Gm-Message-State: AIVw113XTJTYYPoFPkhYsXLkIoQDVjS03dqiStHi54pfAtixzTwZ4+Os W4P4x8mMtUAUy2bBfLvneviB96xEsw== X-Received: by 10.25.56.27 with SMTP id f27mr1324786lfa.167.1500549065513; Thu, 20 Jul 2017 04:11:05 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.5.20 with HTTP; Thu, 20 Jul 2017 04:11:04 -0700 (PDT) In-Reply-To: <65A8A166-E4DD-46D8-9CB9-00D2025171D7@icann.org> References: <65A8A166-E4DD-46D8-9CB9-00D2025171D7@icann.org> From: Daniel Migault Date: Thu, 20 Jul 2017 13:11:04 +0200 X-Google-Sender-Auth: DX9hxI6FWQawyhSRq-wT2mhKgGQ Message-ID: To: Edward Lewis Cc: "Rose, Scott (Fed)" , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="f403045ea33e04a1250554bdcedd" Archived-At: Subject: Re: [DNSOP] [Ext] comments on draft-mglt-dnsop-dnssec-validator-requirements-05 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:11:10 -0000 --f403045ea33e04a1250554bdcedd Content-Type: text/plain; charset="UTF-8" Hi, Thank you for the feed backs Scott. We will address them in the next version. The motivation for crypto deprecation is clearly to follow the crypto recommendations stated by the IETF. However, this requirement for the validator is to actually "validate" those requirements are effective. The intent is clearly not to overcome the crypto recommendations. But you made a good point, and we will address this. Yours, Daniel On Wed, Jul 19, 2017 at 5:01 PM, Edward Lewis wrote: > > On 7/19/17, 08:49, "DNSOP on behalf of Rose, Scott (Fed)" < > dnsop-bounces@ietf.org on behalf of scott.rose@nist.gov> wrote: > > >I think this draft is a good idea and should be adopted, but needs some > improvements first. > > > > Thanks for the review, the current version has items needing wider > discussion. > > I'll pick some items to respond to now: > > >2. REQ2: What should happen when there are multiple trust anchors, but > only one failed to validate? E.g. a validator has both the root and > .exampleTLD in its trust store, but missed the root rollover. The > .exampleTLD key still validates, but the root doesn't. Should all > validation stop? Or set a warning, but continue to validating (succeeding > only for .exampleTLD)? > > One of my long-standing opinions has been that it is hard to build a > secure chain, so if one exists, accept it in face of alternative broken > chains. If a validator is too "tight" then it would be trivial to do a > denial-of-service by throwing out DNSKEYs, RRSIGs, etc., that will not lead > to validation. > > As far as trust anchors, the level of trust (healthiness in some sense) is > individual. One anchor candidate might be "false" (unauthorized) while > another anchor candidate might be "true" (authorized). Trust is in the > eye-of-the-operator, if the operator establishes trust in a candidate it is > best to run with it, again, even if there are untrusted candidates. > (Because, if too "tight" it would be trivial to do a denial of service.) > > >3. REQ18: I don't think I understand this. Wouldn't the best way to see > which algorithm(s) are in use for a given zone would be just to send a > query Authoritative zones really may not "know" any algorithm besides > SHA-1, as it is likely not doing online signing, but serving whatever a > signing utility chose. > > I'd refrain from "know" and use "use." The signer (not the zone) may or > may not have a library for a particular DNSSEC security algorithm's needed > cryptographic algorithm and/or hash. That's entirely opaque to the other > side of the DNS protocol (as DNSSEC assumed an air gap in the most strictly > secure use case). > > What is in use for a zone is established two ways. One is from the DS > RRset. The other is via published secure entry points bootstrapped to the > satisfaction of the validator operator's "trust" satisfaction. > > I.e., I too think that REQ18 needs further review. It would make more > sense if there were on-the-fly signing capabilities (which is not something > assumed by DNSSEC, although it's not a ludicrous idea, it would be > operationally useful). > > >4. Should there be a mention as to which algorithms a validator should > support? It may not require a direct reference to whichever RFC is current, > but simply listing the IANA maintained registry and say "implement all the > MUSTs and probably the SHOULDs too". Something like the following: > > For turn-key implementations, I don't think so. For general-purpose > implementations, the producer of the software would make a choice based on > their objectives. > > Easing the choice for the tool developer would be good, but I question > mandating compliance with features. (I'd leave that to the "purchasing > vehicle", which begs a whole'nuther discussion. There would be a need to > educate the consumer, for one.) > > >Algorithm Usage in Validators > > > >DNSSEC signatures can be generated by different digital signatures > algorithms. The current list of algorithms defined for use with DNSSEC is > published in an IANA maintained registry [insert IANA link here]. > Validators have to be able to understand and validate different algorithms > that may be in common use with DNSSEC. The DNSSEC digital signature > registry table is regularly updated with guidance as to which algorithms > are considered MANDATORY and/or RECOMMENDED. In order to be effective, a > validator MUST understand all digital signature algorithms marked as > MANDATORY and SHOULD understand all digital signature algorithms marked as > RECOMMENDED. > > > >REQXX: Validators MUST implement all MANDATORY digital signature > algorithms and SHOULD implement all RECOMMENDED digital signature > algorithms. > > > >Note: This wording isn't the best, and needs some work. I also don't know > if the SHOULD in the REQ should be changed to a MAY, but I would prefer > SHOULD. > > Thanks for the suggested text, for the most part I think it is on target. > But to hark back to my comment before it, I'd change (for example): > > "Validators have to be able to understand and validate different > algorithms that may be in common use with DNSSEC." > > to: > > "General purpose validators, in order to be widely adopted and accepted, > ought to implement as many of the commonly used DNSSEC security algorithms, > with "commonly" interpreted, at least on one way, to include the DNSSEC > security algorithms in the IANA registry noted." > > ...again, wording is loose. > > My driving concern is that there may be some folks that have a turn-key > situation in mind; the IETF famously says it is not the "protocol police." > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --f403045ea33e04a1250554bdcedd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for the feed ba= cks Scott. We will address them in the next version.

The motivation= for crypto deprecation is clearly to follow the crypto recommendations sta= ted by the IETF. However, this requirement for the validator is to actually= "validate" those requirements are effective. The intent is clear= ly not to overcome the crypto recommendations.=C2=A0 But you made a good po= int, and we will address this.

Yours,
Daniel=C2=A0 <= br>

On Wed, = Jul 19, 2017 at 5:01 PM, Edward Lewis <edward.lewis@icann.org>= wrote:

On 7/19/17, 08:49, "DNSOP on behalf of Rose, Scott (Fed)" <dnsop-bounces@ietf.org on behalf= of scott.rose@nist.gov> wrot= e:

>I think this draft is a good idea and should be adopted, but needs some= improvements first.
>

Thanks for the review, the current version has items needing wider d= iscussion.

I'll pick some items to respond to now:

>2. REQ2: What should happen when there are multiple trust anchors, but = only one failed to validate? E.g. a validator has both the root and .exampl= eTLD in its trust store, but missed the root rollover. The .exampleTLD key = still validates, but the root doesn't. Should all validation stop? Or s= et a warning, but continue to validating (succeeding only for .exampleTLD)?=

One of my long-standing opinions has been that it is hard to build a= secure chain, so if one exists, accept it in face of alternative broken ch= ains.=C2=A0 If a validator is too "tight" then it would be trivia= l to do a denial-of-service by throwing out DNSKEYs, RRSIGs, etc., that wil= l not lead to validation.

As far as trust anchors, the level of trust (healthiness in some sense) is = individual.=C2=A0 One anchor candidate might be "false" (unauthor= ized) while another anchor candidate might be "true" (authorized)= .=C2=A0 Trust is in the eye-of-the-operator, if the operator establishes tr= ust in a candidate it is best to run with it, again, even if there are untr= usted candidates.=C2=A0 (Because, if too "tight" it would be triv= ial to do a denial of service.)

>3. REQ18: I don't think I understand this. Wouldn't the best wa= y to see which algorithm(s) are in use for a given zone would be just to se= nd a query=C2=A0 Authoritative zones really may not "know" any al= gorithm besides SHA-1, as it is likely not doing online signing, but servin= g whatever a signing utility chose.

I'd refrain from "know" and use "use."=C2=A0 The si= gner (not the zone) may or may not have a library for a particular DNSSEC s= ecurity algorithm's needed cryptographic algorithm and/or hash.=C2=A0 T= hat's entirely opaque to the other side of the DNS protocol (as DNSSEC = assumed an air gap in the most strictly secure use case).

What is in use for a zone is established two ways.=C2=A0 One is from the DS= RRset.=C2=A0 The other is via published secure entry points bootstrapped t= o the satisfaction of the validator operator's "trust" satisf= action.

I.e., I too think that REQ18 needs further review.=C2=A0 It would make more= sense if there were on-the-fly signing capabilities (which is not somethin= g assumed by DNSSEC, although it's not a ludicrous idea, it would be op= erationally useful).

>4. Should there be a mention as to which algorithms a validator should = support? It may not require a direct reference to whichever RFC is current,= but simply listing the IANA maintained registry and say "implement al= l the MUSTs and probably the SHOULDs too". Something like the followin= g:

For turn-key implementations, I don't think so.=C2=A0 For genera= l-purpose implementations, the producer of the software would make a choice= based on their objectives.

Easing the choice for the tool developer would be good, but I question mand= ating compliance with features.=C2=A0 (I'd leave that to the "purc= hasing vehicle", which begs a whole'nuther discussion.=C2=A0 There= would be a need to educate the consumer, for one.)

>Algorithm Usage in Validators
>
>DNSSEC signatures can be generated by different digital signatures algo= rithms. The current list of algorithms defined for use with DNSSEC is publi= shed in an IANA maintained registry [insert IANA link here]. Validators hav= e to be able to understand and validate different algorithms that may be in= common use with DNSSEC. The DNSSEC digital signature registry table is reg= ularly updated with guidance as to which algorithms are considered MANDATOR= Y and/or RECOMMENDED. In order to be effective, a validator MUST understand= all digital signature algorithms marked as MANDATORY and SHOULD understand= all digital signature algorithms marked as RECOMMENDED.
>
>REQXX: Validators MUST implement all MANDATORY digital signature algori= thms and SHOULD implement all RECOMMENDED digital signature algorithms.
>
>Note: This wording isn't the best, and needs some work. I also don&= #39;t know if the SHOULD in the REQ should be changed to a MAY, but I would= prefer SHOULD.

Thanks for the suggested text, for the most part I think it is on ta= rget.=C2=A0 But to hark back to my comment before it, I'd change (for e= xample):

"Validators have to be able to understand and validate different algor= ithms that may be in common use with DNSSEC."

to:

"General purpose validators, in order to be widely adopted and accepte= d, ought to implement as many of the commonly used DNSSEC security algorith= ms, with "commonly" interpreted, at least on one way, to include = the DNSSEC security algorithms in the IANA registry noted."

...again, wording is loose.

My driving concern is that there may be some folks that have a turn-key sit= uation in mind; the IETF famously says it is not the "protocol police.= "


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--f403045ea33e04a1250554bdcedd-- From nobody Thu Jul 20 04:36:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9195E131C06 for ; Thu, 20 Jul 2017 04:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ZX6gJ7dXhWSH for ; Thu, 20 Jul 2017 04:36:46 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC00131C10 for ; Thu, 20 Jul 2017 04:36:40 -0700 (PDT) Received: from dhcp-8e9b.meeting.ietf.org (dhcp-8e9b.meeting.ietf.org [31.133.142.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id B05612421527; Thu, 20 Jul 2017 11:36:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: Date: Thu, 20 Jul 2017 12:36:38 +0100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <6901EEC2-5F25-4F28-AB5D-0F164D5077A5@rfc1035.com> References: <20170719215749.2241.qmail@ary.lan> To: "Woodworth, John R" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:36:47 -0000 > On 20 Jul 2017, at 03:12, Woodworth, John R = wrote: >=20 > For now, I think we've narrowed the draft opposition to two camps: >=20 > Camp#1) Don't force me to use IPv6 reverse, I simply will never >=20 > and >=20 > Camp#2) Don't break DNS, even for a second Well I don't recognise either of these camps. What was it you were saying about beauty being in the eye of the = beholder? :-) I'm in Camp N (for some definition of N): where's the use = case/justification for BULK and is it worth the effort? It's not clear if the WG has fully considered the impact of BULK on = signed reverse zones. Doing something to the DNS that further hinders = uptake of DNSSEC is probably a bad idea IMO. YMMV. Proposed protocol = changes which do that need to come with compelling benefits that = outweigh this drawback. From nobody Thu Jul 20 05:09:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73872126E3A for ; Thu, 20 Jul 2017 05:09:37 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DzPe8B_nJUg6 for ; Thu, 20 Jul 2017 05:09:33 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 EFA78129B43 for ; Thu, 20 Jul 2017 05:09:32 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id v105so39779048wrb.0 for ; Thu, 20 Jul 2017 05:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EBTwiVPgghjdhOqZoVcXCL8H1cWZw7A3NjK7a4Dj1eY=; b=kXAIkgkNBl3DYeBl7wt+VNQW8B/pKjxUoLAa3wlyh7k61BYcGOMnoi0lSXGiw/V2sA tnLLRs0niHvCqyMUsYgKZSOGx5GnmITwFbYle8UA7rOML1+widbqqac6MvX2FkkFP5YR 5FLSPEask89CjJyEQ22jLUQOSer8DV11PRE/0iyCf9mgYP997hU9PMr25awPEn9RrfuU wFLDf1f0m8Jfi0ziuqMkAUXHRsMfpxy2vMUTHOvmlTwFmYwBr8LbUJTFGB6ZU1jq393Y vvM+OesQV0XIzmbMj5VZoqxw3SoinxLwuuqwZdpbYbW8/SVDoZPDLkABlXnPPtTlyWib fVEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EBTwiVPgghjdhOqZoVcXCL8H1cWZw7A3NjK7a4Dj1eY=; b=N8W++I4WVaOI5SVBV9jfWyeb9YPbP698sv4L8ub8tJNcUGQFmPSKsDo8+iNGEfbeBh x21ZJ7ea4FAGqIsAQ31sN1K0gAm2KlkXNsfMYmvgzlwtls8oL+SJYpcs9MzTgDWQETz3 zlKCLj5bQ68XtUfeoocbFZrsjLjnadkvXiKhKEj8p33SVwDXBpt1GbEWnNbW2sly2JR3 5eC6ejI8BWLhxcrA7PEUkT8p48Gfdbwjd7vbV+D1X6YGMd1KS7cx690MuNhP55el3jSO znLSVwWGvnCmK3T8t2XvVWL9pjeiY350TRR3abHrjkh2+nmw0q0DIlxaQbmZzXlMbVVT H46Q== X-Gm-Message-State: AIVw110UdSOtLs7jKqFUFwlA+5L48f4sTG1OBp/EbIgm7CslT3gl6aP5 NGnmsHntMXljwa6Yo+7V6+S32KJyPg== X-Received: by 10.223.164.218 with SMTP id h26mr7308537wrb.100.1500552571506; Thu, 20 Jul 2017 05:09:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.139 with HTTP; Thu, 20 Jul 2017 05:09:31 -0700 (PDT) In-Reply-To: <6901EEC2-5F25-4F28-AB5D-0F164D5077A5@rfc1035.com> References: <20170719215749.2241.qmail@ary.lan> <6901EEC2-5F25-4F28-AB5D-0F164D5077A5@rfc1035.com> From: tjw ietf Date: Thu, 20 Jul 2017 14:09:31 +0200 Message-ID: To: Jim Reid Cc: "Woodworth, John R" , dnsop WG Content-Type: multipart/alternative; boundary="f403045f22aefdde960554be9e4f" Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:09:37 -0000 --f403045f22aefdde960554be9e4f Content-Type: text/plain; charset="UTF-8" Another Data Point: One of the Apps Area ADs stopped by to tell the chairs that 1) they like the general idea; 2) their employer has a need for this *outside of the PTR space*; and 3) would be willing to shepherd the work through. Now, they also the first to admit that the Application people do the most abuse to DNS standards (hence the need for the attrleaf document). In fact, my employer, who is quite abusive in how they deploy CNAMEs could very easily work up a very legitimate use case for using BULK for deploying some of our larger zones. Add that to the fact that my employer insists on deploying DNS between multiple vendors - whether it is DNS software or managed DNS services. So while it's great to trash IPv6 rDNS (and count me first in line to trash IPv6 anything), there are actual other reasons why this would be useful. Just keep that in mind. tim On Thu, Jul 20, 2017 at 1:36 PM, Jim Reid wrote: > > > On 20 Jul 2017, at 03:12, Woodworth, John R > wrote: > > > > For now, I think we've narrowed the draft opposition to two camps: > > > > Camp#1) Don't force me to use IPv6 reverse, I simply will never > > > > and > > > > Camp#2) Don't break DNS, even for a second > > Well I don't recognise either of these camps. > > What was it you were saying about beauty being in the eye of the beholder? > :-) > > I'm in Camp N (for some definition of N): where's the use > case/justification for BULK and is it worth the effort? > > It's not clear if the WG has fully considered the impact of BULK on signed > reverse zones. Doing something to the DNS that further hinders uptake of > DNSSEC is probably a bad idea IMO. YMMV. Proposed protocol changes which do > that need to come with compelling benefits that outweigh this drawback. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f403045f22aefdde960554be9e4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another Data Point:=C2=A0

One of the Ap= ps Area ADs stopped by to tell the chairs that 1) they like the general ide= a; 2) their employer has a need for this *outside of the PTR space*; and 3)= would be willing to shepherd the work through. =C2=A0 Now, they also the f= irst to admit that the Application people do the most abuse to DNS standard= s (hence the need for the attrleaf document).=C2=A0

In fact, my employer, who is quite abusive in how they deploy CNAMEs coul= d very easily work up a very legitimate use case for using BULK for deployi= ng some of our larger zones. =C2=A0 Add that to the fact that my employer i= nsists on deploying DNS between multiple vendors - whether it is DNS softwa= re or managed DNS services. =C2=A0=C2=A0

So while = it's great to trash IPv6 rDNS (and count me first in line to trash IPv6= anything), there are actual other reasons why this would be useful. =C2=A0= Just keep that in mind.

tim

<= /div>

On Thu, Jul = 20, 2017 at 1:36 PM, Jim Reid <jim@rfc1035.com> wrote:

> On 20 Jul 2017, at 03:12, Woodworth, John R <John.Woodworth@Century= Link.com> wrote:
>
> For now, I think we've narrowed the draft opposition to two camps:=
>
> Camp#1) Don't force me to use IPv6 reverse, I simply will never >
> and
>
> Camp#2) Don't break DNS, even for a second

Well I don't recognise either of these camps.

What was it you were saying about beauty being in the eye of the beholder? = :-)

I'm in Camp N (for some definition of N): where's the use case/just= ification for BULK and is it worth the effort?

It's not clear if the WG has fully considered the impact of BULK on sig= ned reverse zones. Doing something to the DNS that further hinders uptake o= f DNSSEC is probably a bad idea IMO. YMMV. Proposed protocol changes which = do that need to come with compelling benefits that outweigh this drawback.<= br>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--f403045f22aefdde960554be9e4f-- From nobody Thu Jul 20 05:35:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E98A129AC4 for ; Thu, 20 Jul 2017 05:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 0V_AKqpdlCLC for ; Thu, 20 Jul 2017 05:35:06 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 EFFA3131C17 for ; Thu, 20 Jul 2017 05:34:59 -0700 (PDT) Received: from [IPv6:2001:981:19be:1:50bf:8888:2e7c:bc75] (unknown [IPv6:2001:981:19be:1:50bf:8888:2e7c:bc75]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id EDF47B5F7 for ; Thu, 20 Jul 2017 14:34:57 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl To: dnsop@ietf.org References: From: Matthijs Mekking Message-ID: <7d425067-84ff-2471-d39a-0c3a20c0116c@pletterpet.nl> Date: Thu, 20 Jul 2017 14:34:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:35:13 -0000 Wes, It's been a while since I have had a look at this draft, my apologies. I don't think it is ready for WGLC because I am not convinced the math is correct. Section 6 defines the waitTime: waitTime = addHoldDownTime + (DNSKEY RRSIG Signature Validity) + MAX(MIN((DNSKEY RRSIG Signature Validity) / 2, MAX(original TTL of K_old DNSKEY RRSet) / 2, 15 days), 1 hour) + 2 * MAX(TTL of all records) Which is the same as: waitTime = addHoldDownTime + (DNSKEY RRSIG Signature Validity) + queryInterval + 2 * MAX(TTL of all records) but reads better. This should be the same as Itrp as defined in RFC 7583: Itrp >= queryInterval + AddHoldDownTime + queryInterval Basically these two differ at the following points: 1. Itrp does not include (DNSKEY RRSIG Signature Validity). It does mention that the validator should not see a validly signed DNSKEY RRset without the new key in that period. So adding (DNSKEY RRSIG Signature Validity) is a good update. 2. waitTime only adds one queryInterval, while Itrp adds two. I believe to be safe on the publishing side, two queryIntervals is needed. RFC 7583 explains: A validator will treat it as a trust anchor the next time it retrieves the RRset, a process that can take up to another queryInterval (the third term). 3. waitTime adds two MAX(TTL of all records) (margin). The draft says that it probably not needed, and I agree, and that explains why it is missing from the Itrp definition. 4. Both definitions (Itrp and waitTime) don't really take into consideration the retryTime defined in RFC 5011. Perhaps that can be used for defining the extra safety margin. 5. Itrp actually is defined with a modifiedQueryInterval which excludes the RRSIG expiration interval. Now this is recognized to be the time between inception and expiration of the RRSIG, I actually think it does not need to be removed from the equation. So Itrp could have worked with just queryInterval. Given these points I think the correct definition of waitTime is: margin = 2 * MAX(TTL) waitTime = addHoldDownTime + signatureValidity(DNSKEY) + 2 * queryInterval + margin I think slop needs to be separated and it should be documented that this is a suggested value for the slop. Furthermore, this document should also give guidance on the wait time before a revoked DNSKEY can be removed from the zone: waitRemoveTime = signatureValidity(DNSKEY) + queryInterval + margin This document should probably update RFC 7583 because it is giving a better definition of Itrp and Irev. For readability of the document I would like to suggest to move the Attack example and breakdown to the Appendix. Kind regards, Matthijs On 05-07-17 19:11, Wes Hardaker wrote: > > Folks, > > We believe that the latest draft-rfc5011-security-considerations > document is ready for WGLC, and would like the chairs to start that > process unless anyone thinks it's not ready to go forward. In > particular, we believe all outstanding issues with it have been > resolved. > > Objections? > From nobody Thu Jul 20 06:35:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC789131C27 for ; Thu, 20 Jul 2017 06:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 YD-nVYQ_Q2Vc for ; Thu, 20 Jul 2017 06:34:58 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 D80E21288B8 for ; Thu, 20 Jul 2017 06:34:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39343) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dYBbM-000Ats-eV (Exim 4.89) (return-path ); Thu, 20 Jul 2017 14:34:48 +0100 Date: Thu, 20 Jul 2017 14:34:48 +0100 From: Tony Finch To: John R Levine cc: "Woodworth, John R" , "dnsop@ietf.org" , "paul@nohats.ca" In-Reply-To: Message-ID: References: <20170719215749.2241.qmail@ary.lan> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:35:00 -0000 John R Levine wrote: > > BULK absolutely requires online DNSSEC signing, This basically means that BULK is a master-only feature, which implies that there's no need for BULK to work across zone transfers, which implies the need to standardize it for interop is almost nonexistent. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet, Irish Sea: South or southwest becoming cyclonic, 5 to 7, perhaps gale 8 later. Moderate or rough, becoming rough or very rough later in Fastnet and west Lundy. Rain or thundery showers. Good, occasionally poor. From nobody Thu Jul 20 07:22:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE97E131828 for ; Thu, 20 Jul 2017 07:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Dm4Du/Bg; dkim=pass (1024-bit key) header.d=yitter.info header.b=lKUq9R7n 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 VaIgE0sgI3j3 for ; Thu, 20 Jul 2017 07:21:57 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700EE13146C for ; Thu, 20 Jul 2017 07:21:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id BCA83BD997 for ; Thu, 20 Jul 2017 14:21:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500560486; bh=EWKjXEecPj9qAmJiMAJHJ3Y4lE923UM6XIzuYlyE2w8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Dm4Du/Bg5u9TRoX1Pse49qmLTNlhi6zgHT5C5YezjDQIVoQsIQAA9842MQpq1A8fq OdjRw48qHObluPsD4SFgN07CksMsqBWTC+zxJCBw7p285dBR1A5hnzrHr1vX7yT4FS jIoHq3p5n53YEabaorhJCsm0WDAb0MXJzCeaqQW4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGzNqFshlNUB for ; Thu, 20 Jul 2017 14:21:25 +0000 (UTC) Date: Thu, 20 Jul 2017 10:21:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500560485; bh=EWKjXEecPj9qAmJiMAJHJ3Y4lE923UM6XIzuYlyE2w8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=lKUq9R7n4GGsasrt38NeQe7PVcRvsZf6iQzkKUU6XE+0c2teKQY5anUd8s6PnSBAr IYy49QbgDPUwp1FgQH3uGvB7pOJoWHo4g/lSywHyg4j5rleibE1p+zdZ7M5kq9gBjl Rr5xT6TkdSALP0gacQkZf7+5XTiManljMUwftz6E= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170720142122.ncrkwi27ghdwj2sq@mx4.yitter.info> References: <20170719215749.2241.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:21:59 -0000 On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote: > This basically means that BULK is a master-only feature, which implies > that there's no need for BULK to work across zone transfers, which implies > the need to standardize it for interop is almost nonexistent. I don't think that follows. The DNS market is, like the mail market did some while ago, undergoing a period of consolidation in which a fairly small number of people have a very large number of dependent customers. Unfortuantely, whereas mail is asynchronous, DNS is effectively synchronous: if the provder has a bad day and you can't get an answer the site is down. This means that customers want to have multiple different vendors as their master, and they want the secondaries of those sources to offer as much as possible the same features, even when various DNS Tricks are in use; and they want the downstreams to be using standard protocols. The more we can make interoperate to support that, the better off those users are. It is possible this is not a case that will work for that (see John L's note), but I think the argument that master-only features don't need to surive zone transfers is mistaken. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jul 20 07:31:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F174A131B05 for ; Thu, 20 Jul 2017 07:31:50 -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 (1536-bit key) header.d=iecc.com header.b=BnZU+Bsk; dkim=pass (1536-bit key) header.d=taugh.com header.b=WOZVioGH 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 camd7Pa2EYTQ for ; Thu, 20 Jul 2017 07:31:49 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357D2131BA0 for ; Thu, 20 Jul 2017 07:31:49 -0700 (PDT) Received: (qmail 30933 invoked from network); 20 Jul 2017 14:31:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=78d3.5970bed4.k1707; bh=o+Dz/7sU5FT5uxFy3pJmnKUlbC46ViVDTSaiRx2bmJo=; b=BnZU+BskSTGD+TY/xbB7tlL1CCDejSBQ5Prjvmo8+D7CKJO+v6GQwfXQNJLP/vqkzv6JjSFEabRlfIW9myDW5kJY70tknOyVTXy92cREPA2GVQ6MJthbKgQTYb3ju8aosk9brK9cM+RAEgyWzQ7Skn83ntzaPXLWeCdgLXxv6hvKN7Spp3GCg9eBmOhlJuP+STiYm0uQF5CzTpTLu8mlEEI0jjZtJjEf/Y+Dspw6S5+oZL36U38sRPEwn56RSxo9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=78d3.5970bed4.k1707; bh=o+Dz/7sU5FT5uxFy3pJmnKUlbC46ViVDTSaiRx2bmJo=; b=WOZVioGHDCH09zzxN4Z0JDL3zGrGen0/6IA46QxDbWoIi/7L05ZVFzPk8kYANkyMpkc/N3fxXtiQBL9+YvKauivjOrp1nLljs9vp5u0o7/3d7QuhBf11I3XzMMAg/8aS+AnUtLZIRU0UDQ92m7LZlqzUo8aOO2ACwufMSSPPJkus6bYzLPrggUtWz0YIx38pOvsI9n9xXJea4gMwHBX3E9Ylmcy6q6qBR7YmYbUCuLunZaxqBmpWCfkdoa79DVZv Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jul 2017 14:31:47 -0000 Date: 20 Jul 2017 16:31:45 +0200 Message-ID: From: "John R Levine" To: "Tony Finch" Cc: "dnsop@ietf.org" In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:31:51 -0000 On Thu, 20 Jul 2017, Tony Finch wrote: > John R Levine wrote: >> >> BULK absolutely requires online DNSSEC signing, > > This basically means that BULK is a master-only feature, which implies > that there's no need for BULK to work across zone transfers, which > implies the need to standardize it for interop is almost nonexistent. I can't speak for the draft's authors, but in previous correspondence I've gotten the impression that they believe that slaves that serve BULK can stay in sync via AXFR and IXFR. Perhaps they can clarify how this is supposed to work. I could sort of imagine a DNAME like scheme where the server returns the signed BULK and the generated record and the RRSIGs and NSECs to show that the name for which it was generated doesn't exist, so the cache that receives it can unscramble the mess, but wow, would that ever be a poster child for why this needs DNS versioning. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jul 20 08:02:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DBC131A56 for ; Thu, 20 Jul 2017 08:02:20 -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] 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 6AJ3gz--2UBc for ; Thu, 20 Jul 2017 08:02:07 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 A190E12EC46 for ; Thu, 20 Jul 2017 08:02:07 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id C791E31CE6; Thu, 20 Jul 2017 17:02:04 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id DEDC9EC0B75; Thu, 20 Jul 2017 17:00:31 +0200 (CEST) Date: Thu, 20 Jul 2017 17:00:31 +0200 From: Stephane Bortzmeyer To: Mukund Sivaraman Cc: Paul Hoffman , dnsop@ietf.org Message-ID: <20170720150031.GA22702@laperouse.bortzmeyer.org> References: <20170718094654.GA31988@jurassic> <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> <20170718125056.GA7982@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170718125056.GA7982@jurassic> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:02:21 -0000 On Tue, Jul 18, 2017 at 06:20:56PM +0530, Mukund Sivaraman wrote a message of 27 lines which said: > It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned > zones. That's quite funny. During the development of RFC 8020 (draft-ietf-dnsop-nxdomain-cut), which addresses the same concern as draft-ietf-dnsop-nsec-aggressiveuse, many people said that the feature was dangerous, and we should mandate the use of DNSSEC. In the end, it is not mandatory (see sections 2, 3rd para, and section 7 of RFC 8020). draft-ietf-dnsop-nsec-aggressiveuse is more aggressive (because it can now synthetizes answers) so it seems to me the same reasons should apply? From nobody Thu Jul 20 08:08:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6671252BA for ; Thu, 20 Jul 2017 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=b2y4rxAt; dkim=pass (1024-bit key) header.d=yitter.info header.b=LNuOzU/o 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 48aYa8kVoh5f for ; Thu, 20 Jul 2017 08:08:20 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A72A131CDF for ; Thu, 20 Jul 2017 08:08:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 6A14DBD996 for ; Thu, 20 Jul 2017 15:08:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500563294; bh=EJ32RjvUkci9cG/YLE8mfQX1/mDVZWl9pOFAqjrGfik=; h=Date:From:To:Subject:References:In-Reply-To:From; b=b2y4rxAts3d6UeegFba4UUjC3zTudlag2OMP1oBC1lkPavzg0qH3bHqZzUbylxyZU Fs3ksz3Fjk8rxXS3bo8bEX1C8VKN4+6L+W9zVAEdMHXDoe+ihpLKawI0TiFlMDtZYI S+Ld3DMn2IQJ2IQqlsVUig2bfj1RsoIhn9WyzyMk= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmA3BtKyYpUj for ; Thu, 20 Jul 2017 15:08:13 +0000 (UTC) Date: Thu, 20 Jul 2017 11:08:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500563292; bh=EJ32RjvUkci9cG/YLE8mfQX1/mDVZWl9pOFAqjrGfik=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LNuOzU/oNDXbAgrWfhjqLCBwPQdet1Ul+CO8FPr0rB1DrLuHS89hnR0QcJ2/PSnub LSzrtV4c9Qglm57LzuczX1dAdMdKaoD5/v507KYKpbJ9cA11GS/88OcxYRZ1anJYZ9 yq1VQ+8azziMiItFhA+Fc39R3ZLZODYskfZATGis= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:08:22 -0000 Dear colleagues, On Mon, Jul 10, 2017 at 06:16:53PM -0400, Shumon Huque wrote: > negotiation from the beginning, fail open would not have been necessary. > This fail open behavior frequently takes people not in the DNSSEC club by > complete surprise. I've lost track of how many "WTF" moments I've had to > explain to other people about this behavior. DNSSEC is mostly like that. I think it is because most people used to security extensions are used to them in end to end protocols, and used to failing when the arrangement is not end-to-end. For instance, people also express astonishment that DNSKEYs don't expire. Everyone always has to be reminded that signatures expire, and if you want to expire keys you take them out of the zone. This is not to say, "Stupid users," but instead to say that at least _part_ of the reason DNSSEC violates a lot of expectations is because DNS does. People continue to believe, for example, that there's always one authoritative server, one recursive, and one stub. We all know that's _also_ a bad model, but it's mostly good enough except when it isn't. So, I think one can sympathise completely with the "WTF" moments, but still think the response is, "Yep, this thing violates all your assumptions. Sorry." Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jul 20 08:19:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D271317CC for ; Thu, 20 Jul 2017 08:19:13 -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] 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 gFDGuQE6hpQg for ; Thu, 20 Jul 2017 08:19:12 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 6B9C4131532 for ; Thu, 20 Jul 2017 08:19:12 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EF07731CE6; Thu, 20 Jul 2017 17:19:10 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id 09293EC0B75; Thu, 20 Jul 2017 17:15:34 +0200 (CEST) Date: Thu, 20 Jul 2017 17:15:34 +0200 From: Stephane Bortzmeyer To: Jim Reid Cc: "Woodworth, John R" , dnsop WG Message-ID: <20170720151534.GC22702@laperouse.bortzmeyer.org> References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:19:13 -0000 On Wed, Jul 19, 2017 at 12:03:58PM +0100, Jim Reid wrote a message of 18 lines which said: > However that doesn't seem to be a compelling reason to modify the > DNS protocol and change every DNS server on the planet. No. Only the authoritative servers, and not even all of them (this BULK feature can be made optional.) From nobody Thu Jul 20 08:19:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834A51252BA for ; Thu, 20 Jul 2017 08:19:15 -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] 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 8953Nc-9H4NK for ; Thu, 20 Jul 2017 08:19:13 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 7932E131746 for ; Thu, 20 Jul 2017 08:19:12 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0EAB331CFB; Thu, 20 Jul 2017 17:19:11 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id 77AF8EC0B75; Thu, 20 Jul 2017 17:13:25 +0200 (CEST) Date: Thu, 20 Jul 2017 17:13:25 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20170720151325.GB22702@laperouse.bortzmeyer.org> References: <150040947342.11401.6673996996138598307.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: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:19:15 -0000 On Tue, Jul 18, 2017 at 01:24:33PM -0700, IETF Secretariat wrote a message of 11 lines which said: > The DNSOP WG has placed draft-woodworth-bulk-rr in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ I've read it and, while I'm not convinced it can be implemented properly (I would like to see running code), I think there is a clear demand for that and that the solution is reasonable. I therefore support its adoption. (Of course, as always, it does not mean I will support the result at the end.) I'm still hesitant with the NPN feature. I would like the draft to be modified to make clearer that it is non-mandatory to support BULK. For instance, setcion 3's "When an authoritative nameserver receives a query for which it does not have a matching name or a covering wildcard, it MUST then look for BULK RRs" should be replaced by "When a *BULK-aware* authoritative nameserver receives a query for which it does not have a matching name or a covering wildcard, …" Section 3.2.3 "longer values MUST be truncated to the width" Left-truncated or right-truncated? From nobody Thu Jul 20 08:28:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA98E131473 for ; Thu, 20 Jul 2017 08:27:59 -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] 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 TxXb3e2fc-tl for ; Thu, 20 Jul 2017 08:27:58 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 9A6C2126C0F for ; Thu, 20 Jul 2017 08:27:58 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 2034731CE6; Thu, 20 Jul 2017 17:27:57 +0200 (CEST) Received: by godin (Postfix, from userid 1000) id B289AEC0B75; Thu, 20 Jul 2017 17:25:59 +0200 (CEST) Date: Thu, 20 Jul 2017 17:25:59 +0200 From: Stephane Bortzmeyer To: John Levine Cc: dnsop@ietf.org, paul@nohats.ca Message-ID: <20170720152559.GD22702@laperouse.bortzmeyer.org> References: <20170719215749.2241.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170719215749.2241.qmail@ary.lan> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:28:00 -0000 On Wed, Jul 19, 2017 at 09:57:49PM -0000, John Levine wrote a message of 38 lines which said: > We did this in a horrible ad-hoc way with DNSSEC, and even with > DNSSEC there's the fallback that the unsigned answers you get from a > server that doesn't understand RRSIG et al. are for many purposes > adequate. I do not understand. If you sign on the master and forget to check the slaves (for instance if they are BIND with dnssec-enable no), the results are catastrophic for validating resolvers. You HAVE TO know and check your secondaries. It is the same with BULK as it is with DNSSEC. And DNSSEC is not the only case where we introduced RRtypes where you have to check your slaves to be sure they support it. There was also DNAME. That's why I don't share the fears about BULK: you cannot easily deploy a new feature that will require a change in the resolvers, because you don't know all the resolvers, and cannot change them even if you know they are too old. But your secondaries are only a small set of carefully chosen servers, and you have your say. From nobody Thu Jul 20 08:54:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4B1131D06 for ; Thu, 20 Jul 2017 08:54:00 -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 (1536-bit key) header.d=iecc.com header.b=DZl3VhId; dkim=pass (1536-bit key) header.d=taugh.com header.b=LfZkyc4n 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 GVm0jotpaKTE for ; Thu, 20 Jul 2017 08:53:58 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CD0131C73 for ; Thu, 20 Jul 2017 08:53:48 -0700 (PDT) Received: (qmail 39654 invoked from network); 20 Jul 2017 15:53:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9ae4.5970d20b.k1707; bh=SvCRiIdgD5Wwrf36aiIODqcl2l7VNPx0uhAuF8qm0w8=; b=DZl3VhIdG91aIxXMAeXy4C8fB2yExkhwBcxt+kDs+dt9fVPFHdEPyCST5CIAl4q/XQV7Wlxd5Rvq9xWRsrkM0Sq4vXIUsaIifDYq3vA7hleJ1S0rFUspUgu37Xrm8tq5ATDg+CkgauLEmNqf+vDPTb/61TcLBS69ACyCWFE9q2CbTYtODXhOcyMW/Byvw3O2GrJpvMGhg9QFjIqn2iuZ61PYE7g3tUWb4mjnf1qTmVlFM1uLdGAoobCRw5BTj4tv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9ae4.5970d20b.k1707; bh=SvCRiIdgD5Wwrf36aiIODqcl2l7VNPx0uhAuF8qm0w8=; b=LfZkyc4nhwzVHOvQZ/r52C7pjCj1Ce9lx1mrZNw87U20dxSh2pb0pkJa+2RAz1DmdTy2Uu4IRKoUIdHptpSdViuQepRLNBXwEp5QT/Arz47ReZ5XF0njYK/GCIBC3jr+B7i7EdBbC/gvTTxHHdSVoXT0tD0KFAOGcl02rrBQDPelPOrAh1kwx835hIxubRr1AzpP+cod9tngVYqL0dX1oL5jSWjIJxDtBKTLpBeirnjWPLLsXGsH8jpC56Zed0mb Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jul 2017 15:53:47 -0000 Date: 20 Jul 2017 17:53:46 +0200 Message-ID: From: "John R Levine" To: "Stephane Bortzmeyer" Cc: dnsop@ietf.org, paul@nohats.ca In-Reply-To: <20170720152559.GD22702@laperouse.bortzmeyer.org> References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:54:00 -0000 > That's why I don't share the fears about BULK: you cannot easily > deploy a new feature that will require a change in the resolvers, > because you don't know all the resolvers, and cannot change them even > if you know they are too old. But your secondaries are only a small > set of carefully chosen servers, and you have your say. I hear otherwise from people who run big DNS farms. It's common to use multiple secondary providers, and it's hard to tell who's running what server software. I also note that it took about a decade before people felt comfortable using DNAMEs. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jul 20 09:41:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AB4131C4E for ; Thu, 20 Jul 2017 09:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 Yuhp3G6sCQGZ for ; Thu, 20 Jul 2017 09:41:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 1DE1C131714 for ; Thu, 20 Jul 2017 09:41:35 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 0D33A60732 for ; Thu, 20 Jul 2017 18:41:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500568894; bh=dDMW5iKsnYDfG2X9JhloRnCgA4YSuVjFcivOrwLY5oQ=; h=Date:From:To; b=uMmg+inSlkpqkpj7LqQX/nYTzvKQWw0hEm0mkypYnPeIT6qZ5xEBLvxN0WvHRdFJY SzwgxiERwCBosePO9RHmWF5Le1lnAvHq0IDcyyHMT2Ma3xHqk0fT1esfWmrzawn5Mj Pjw/7iIviH90zlBTdF/ckqVIq2wX3dVUBgQdAcWs= Date: Thu, 20 Jul 2017 18:41:33 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: dnsop Message-ID: <1686897744.6421.1500568893614.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.9_GA_1794 (ZimbraWebClient - GC59 (Linux)/8.7.9_GA_1794) Thread-Index: drTJLRO/4nkR2JIAujzyHoaQf8cQWQ== Thread-Topic: UDP fragmentation vs multiple-responses and multi-qtypes X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:41:38 -0000 multi-qtypes Security Considerations says: > The method documented here does not change any of the security > properties of the DNS protocol itself. I don't think this statement is true. Why? a) DNS DDoS threats are real and there was a shift towards minimizing answers. This goes in the reverse direction. But you address this in both security considerations. multiple-responses Security Considerations says: >=20 > Additional records will make DNS responses even larger than they are > currently, leading to larger records that can be used in DNS > reflection attacks. One could mitigate this by only serving > responses to EXTRA requests over TCP or when using Cookies [RFC5395], > although there is no easy way to signal this to a client other than > through the use of the truncate bit. multi-qtypes Security Considerations says: > It should however be noted that this method does increase the > potential amplification factor when the DNS protocol is used as a > vector for a denial of service attack. b) UDP fragmentations - it strongly increases the risk of UDP fragmentation which is strongly discouraged (SHOULD NOT) in BCP 145. also multiple-responses Security Considerations says: > A malicious authoritative server could include a large number of > extra records (and associated DNSSEC information) and attempt to DoS > the recursive by making it do lots of DNSSEC validation. However, > this is not considered a realistic threat; CPU for validation is > cheap compared to bandwidth. This can be mitigated by allowing the > recursive resolver to ignore Additional records whenever it considers > itself under attack or its CPU resources are otherwise over- > committed. It should be noted, that ECC validation is more CPU intensive than RSA, as as such I find "CPU for validation is cheap compared to bandwidth" quite bold claim that should come with some data. Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- From nobody Thu Jul 20 09:45:30 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E467129B15 for ; Thu, 20 Jul 2017 09:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 8ZmAQR9nObLS for ; Thu, 20 Jul 2017 09:45:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 AEF45131CE2 for ; Thu, 20 Jul 2017 09:45:26 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 6B15360FE4 for ; Thu, 20 Jul 2017 18:45:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500569125; bh=g5PwOGExk1T1piHNF9UlmQj0lfF+zzgoqpC6t8A2CDU=; h=Date:From:To; b=PWqfO6aNJ7hFNb3uPOduX6eLORCGLk5Wa7vkdoyP+XNQkz1eTPjXShHBNz4LP5YnL dc5RBWochmHUQUFGvcg48SvwqsFPD9dQnk3Snn0PPkwekfetyh88DJJfPI6uecvcfc lYCazA9Y4Ms11WkgBQD1SZYJ0fvoWmtk5F80p17U= Date: Thu, 20 Jul 2017 18:45:25 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: dnsop Message-ID: <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> In-Reply-To: <148944868965.20421.13262969145873649331@ietfa.amsl.com> References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.9_GA_1794 (ZimbraWebClient - GC59 (Linux)/8.7.9_GA_1794) Thread-Topic: I-D Action: draft-ietf-dnsop-session-signal-02.txt Thread-Index: 7lbTkAoESeblbP4/5AsbJtwcIHDhKQ== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:45:28 -0000 Hey, there's one thing I don't really understand from this draft. Is this useful for DNS at all, or is this targeted at DNS-SD only? I think this needs some explaining and perhaps a clear cut is needed. Although it's not mentioned anywhere in the document, the draft makes much more sense to me, if it would clearly state, this should be only used in DNS-SD sessions. Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: "dnsop" > Sent: Tuesday, 14 March, 2017 00:44:49 > Subject: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Domain Name System Operations of the IET= F. >=20 > Title : DNS Session Signaling > Authors : Ray Bellis > Stuart Cheshire > John Dickinson > Sara Dickinson > Allison Mankin > Tom Pusateri >=09Filename : draft-ietf-dnsop-session-signal-02.txt >=09Pages : 25 >=09Date : 2017-03-13 >=20 > Abstract: > The EDNS(0) Extension Mechanism for DNS is explicitly defined to only > have "per-message" semantics. This document defines a new Session > Signaling Opcode used to communicate persistent "per-session" > operations, expressed using type-length-value (TLV) syntax, and > defines an initial set of TLVs used to manage session timeouts and > termination. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-session-signal-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Jul 20 09:51:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C91131A76 for ; Thu, 20 Jul 2017 09:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=NvzAYpDY; dkim=pass (1024-bit key) header.d=yitter.info header.b=X7EANCkC 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 dnphsNFqQZjo for ; Thu, 20 Jul 2017 09:51:18 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6069131714 for ; Thu, 20 Jul 2017 09:51:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id F21D0BD996 for ; Thu, 20 Jul 2017 16:50:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500569447; bh=8iY4DaymIuGK0n0BCN5ATONVeTMbRtYdFUBY+MfO2Qc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NvzAYpDY+OPkZeoWECS4gkzyKAZOBTJ5iPXfLZ3ldweT9vUSuUeiTcPqfXe1ZFe0P FHwbTGIjSx8LfWpGNLSjBToaG4rmw3C6yB1pb1cDPYhP6CsUrxlhKMst24wdDwMWNF ZkqBoXvMAu/Mt8ySV3kUQKQxC/CPqpjOYvV3AAhs= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijeXt_VcxQWw for ; Thu, 20 Jul 2017 16:50:46 +0000 (UTC) Date: Thu, 20 Jul 2017 12:50:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500569446; bh=8iY4DaymIuGK0n0BCN5ATONVeTMbRtYdFUBY+MfO2Qc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=X7EANCkC34za+aEMiVyYbZs+p1AvivB7cW8PO6yfrApPku+WUmoodKPbCeQpEEDvd PeY7bjhTToMEvjz14zAtAVTSCSVmnMaTxVlUtOwcpPHwBCMxba8XLWq4jBAv0K1d+B Oxdex04nx08LLvznhlBjPeZE73Viss4zbWN4tY1E= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:51:20 -0000 On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ondřej Surý wrote: > Is this useful for DNS at all, or is this targeted at DNS-SD only? I can think of at least one way it would be useful. Large authoritatives often have a clear population of query sources that ask a lot -- the "top talkers". It would be excellent if those clients stood up TCP connections and kept them in place because then (1) the server could treat their TCP connections as long-lived and (2) the server could treat new UDP packets from those IPs as suspect. The current TCP handling makes this mostly suck, and the session-signalling approach makes it suck less. But it's certainly another step along the way to DNSbis by accident. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jul 20 09:53:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F265131461 for ; Thu, 20 Jul 2017 09:53:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yW5ESwsIgU22 for ; Thu, 20 Jul 2017 09:53:26 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 6185A129B15 for ; Thu, 20 Jul 2017 09:53:26 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id s4so17146925pgr.5 for ; Thu, 20 Jul 2017 09:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+orfRfHxcSRGKlemGTgXv8/1gZR6Esr1FjbuzV8MVVU=; b=0YhuZanz2UFEolxxrHkM0BmWM5Qn15QI9doy21PIxk/gPf+f4BADuGYeGKiVEP+5VZ RKE2hKxWIKIMVqKODuAvXhwYNPxb3+5TrSC4EgYyy3h1MOQw4Qu+EYjFl+xoahvwwO/r B24PhLLHhFywU+qP9UluCA1N660kJXhSymzMpWvKukJuCxVMBp6ANvuBraV7wJAc1QRq 3lzL+8uxOptpy3bWmzlAsw7bPyka4P1+w0pmoDKw99GvB/Y3L7d/xxdDxPrXmFyba1eY izSnPp+8LfjB/d2quNZViUNfuQZq5OPPFBx+7hd5MNhNausehHGD4vM6spbqPGi8VaEt s6yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+orfRfHxcSRGKlemGTgXv8/1gZR6Esr1FjbuzV8MVVU=; b=fhSRF2i+ZrE4iSq3dci7KyRZ231Zwur/+AbAxRbmjND04Q64p/1XO07EOPez9yfp2U 2lA+ZKA2YZQ0sRuOEhZQckQJGQVgW7aNRIgLfMLZfPqCrx0VwaCmqBTyUa9O+PrYrIZA 2bTTsCHp8X/wPF5IiS4Vg7kWtcEaugP1+bZGQbReRZMpRIMWHVftct7sAt9eYezVFgJz GaWHeY82r7Zv2veVb0T9wa0TddYgo0Rpn3zg1zyTn8LPCoy/voiXB6+zOeRJCprLgJ5l hopvc0T/1qEvaswi0fBCny14vFs8/LGc+FxsIjOqGQpadX8EyfIwKtUKTvup5in1vYfd N/kQ== X-Gm-Message-State: AIVw1137/aGrgxwOdF8DjlS+CggYPDMDlQr1nJczWl+w8VjPVBBR+JY9 LaLvm3ic0oeotDRAsDwAqNnNOdNTGiNU X-Received: by 10.99.43.5 with SMTP id r5mr4495429pgr.135.1500569605848; Thu, 20 Jul 2017 09:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 09:52:45 -0700 (PDT) In-Reply-To: <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> From: Ted Lemon Date: Thu, 20 Jul 2017 18:52:45 +0200 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: dnsop Content-Type: multipart/alternative; boundary="001a1146e2e051561f0554c296b3" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:53:28 -0000 --001a1146e2e051561f0554c296b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For TCP connections, being able to signal session liveness policy is useful for DNS, not just DNSSD. It seems likely that DNS Push is useful for things other than DNSSD. I think this is generally useful, not just for DNSSD. Rather than thinking of this as a DNSSD-specific enhancement, think of this as an enhancement to section 4.2.2 of RFC1035. On Thu, Jul 20, 2017 at 6:45 PM, Ond=C5=99ej Sur=C3=BD = wrote: > Hey, > > there's one thing I don't really understand from this draft. > > Is this useful for DNS at all, or is this targeted at DNS-SD only? > > I think this needs some explaining and perhaps a clear cut is needed. > Although it's not mentioned anywhere in the document, the draft makes > much more sense to me, if it would clearly state, this should be only > used in DNS-SD sessions. > --001a1146e2e051561f0554c296b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For TCP connections, being able to signal session liveness= policy is useful for DNS, not just DNSSD. =C2=A0 It seems likely that DNS = Push is useful for things other than DNSSD. =C2=A0 I think this is generall= y useful, not just for DNSSD. =C2=A0 Rather than thinking of this as a DNSS= D-specific enhancement, think of this as an enhancement to section 4.2.2 of= RFC1035.

On Thu, = Jul 20, 2017 at 6:45 PM, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz>= ; wrote:
Hey,

there's one thing I don't really understand from this draft.

Is this useful for DNS at all, or is this targeted at DNS-SD only?

I think this needs some explaining and perhaps a clear cut is needed.
Although it's not mentioned anywhere in the document, the draft makes much more sense to me, if it would clearly state, this should be only
used in DNS-SD sessions.
--001a1146e2e051561f0554c296b3-- From nobody Thu Jul 20 09:59:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6C5131945 for ; Thu, 20 Jul 2017 09:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 QoqPYdVnXcKa for ; Thu, 20 Jul 2017 09:59:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 1DA65127B60 for ; Thu, 20 Jul 2017 09:59:44 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 6A52E61111; Thu, 20 Jul 2017 18:59:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500569982; bh=anr4HMBuVhGQsvQeqy5lIG4fIvg+awM4pGIr9gRW/r4=; h=Date:From:To; b=ZFZAfsghsr0bVdeLfcc/UM15jMXKwQXku40uIY3yj7RPC3Tj3ll+CE15DJK2zhE0+ puT7CwSVzhcSJ4/gcO04jnUoBkWtXpIzB2PA96EeARs8VXNK+oVazUjk9pu4OeBarh aVZrbGrY1BFwUpxAGVWLyHesRFCc1hqYMehww23Q= Date: Thu, 20 Jul 2017 18:59:42 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Andrew Sullivan Cc: dnsop Message-ID: <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> In-Reply-To: <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.9_GA_1794 (ZimbraWebClient - GC59 (Linux)/8.7.9_GA_1794) Thread-Topic: I-D Action: draft-ietf-dnsop-session-signal-02.txt Thread-Index: JeFeLvEP3kkyAPQuue8CSNKiMKeGGg== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:59:46 -0000 > But it's certainly another step along the way to DNSbis by accident. Would it be useful to make it not "by accident"? That's why I have a love-hate relationship with TLV inside DNS messages. I have a couple questions: a) make DNS over TCP/TLS sessions without TLV suck less? b) make this draft DNS-SD only, so it can fast forward... c) use the changed paradigm to work on DNSbis without the accident part? Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Andrew Sullivan" > To: "dnsop" > Sent: Thursday, 20 July, 2017 18:50:44 > Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt > On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ond=C5=99ej Sur=C3=BD wrote: >> Is this useful for DNS at all, or is this targeted at DNS-SD only? >=20 > I can think of at least one way it would be useful. Large > authoritatives often have a clear population of query sources that ask > a lot -- the "top talkers". It would be excellent if those clients > stood up TCP connections and kept them in place because then (1) the > server could treat their TCP connections as long-lived and (2) the > server could treat new UDP packets from those IPs as suspect. The > current TCP handling makes this mostly suck, and the > session-signalling approach makes it suck less. >=20 > But it's certainly another step along the way to DNSbis by accident. >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Jul 20 10:00:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6C131D12 for ; Thu, 20 Jul 2017 10:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 QTk9vFQki0Vt for ; Thu, 20 Jul 2017 10:00:44 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 BF492131D0A for ; Thu, 20 Jul 2017 10:00:24 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id w45so27776064uac.5 for ; Thu, 20 Jul 2017 10:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=cc8c2TlXwc/cH2hLY11PxqSgSPrHtzEA+6sfdq1p+rI=; b=whQihSnJJsivBimvWDB/zkltBhMu+SA+QaAQIT0XbdifQlnhhCUuPDYUDzQbM/v6zG kjYfrJdlqvQ3B0ULEjFNCosvag2qfgFJkFTK6K8rsNWt1E9Z5tRbkXFDQssZEabVKxIO XPmVUF/jy/1yNgJjmwNNJEj3pjzefG5W/jXn1GoC0GzR6Pm0FrdO45uNqSa31E3BFC+7 DLTjT5KnR8sRKZrcPURjq9O9rAS4CDLn8QimI9nORMoKcmMnysdGHdWiA801VeUfFIpR ++rg0mgeaVZPjdv0VKjoTJmnepfYoqfPNk4bKrhHD+n4pCMGzU6s8MbhCYfUTA6tGCz6 m7ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cc8c2TlXwc/cH2hLY11PxqSgSPrHtzEA+6sfdq1p+rI=; b=APcpBzryFRN9AlvpEx+2rQIAS1G+fk5rWrIgDU+Y3ToKRAlLyCt0HZgH6vQzf6tE3U 1Vpb9iLHhEBkOJQSbLOsGseN8vM4XdHT457eASqIbUHNszchLJs600ZkO//xPecKfvWt 2kko2AmUOogbqLPW+EGKmXnvFXQMDSl3ND13n+W5QTZEbQOB58q8izr2tGgZ/APX3XiZ QZUmTsZq0xLVD0oIJWIP1HWj3g9FFeRGmN6/GN9/IAVYpNezxWCa98OqQ05LMWRd0VnQ 3d42bLD2NslSSticPqFCDBH5GSufKM6EOa4rWDsph039s7hc9W3Fyyu2C/nl+HcFcSV/ InVw== X-Gm-Message-State: AIVw112Qts0alcu8wvP+5Vb67tZx1pZTuPhp924QM+y/O4V6XLLBQ2ao /F55T/cnaGsU4IE6weInBtn/X1KhJ9p2Wjw= X-Received: by 10.31.7.211 with SMTP id 202mr2271488vkh.212.1500570023733; Thu, 20 Jul 2017 10:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Thu, 20 Jul 2017 10:00:23 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:f81e:2ea1:f1aa:ee5d] From: George Michaelson Date: Thu, 20 Jul 2017 19:00:23 +0200 Message-ID: To: dnsop WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:00:50 -0000 I probably will not carry the WG with me on this, but I find myself thinking the PII aspect of client-ID makes it a wider-internet question and we might have views as a WG, and promote questions as a WG, but I think the "final call" on this is something which needs more than WG approval. Its a big question. I'd actually welcome adoption on many levels, but that isn't to pre-empt that it goes to WGLC. I think we need to formalize the issues and take them out of the WG for review and discussion. documenting current practice is ok btw, but .. PII. -G From nobody Thu Jul 20 10:09:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E63F131B2B for ; Thu, 20 Jul 2017 10:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=PIM3QndZ; dkim=pass (1024-bit key) header.d=yitter.info header.b=QXKHpuze 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 F4vk-j-2Q2T7 for ; Thu, 20 Jul 2017 10:09:11 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE93131AA9 for ; Thu, 20 Jul 2017 10:09:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id DCEA6BD996 for ; Thu, 20 Jul 2017 17:09:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500570550; bh=LQ8o4fofBeg+zmDU4AMJxWrTcPm8CJwUSJztKTRZKXI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=PIM3QndZA3Aaw2QdKwymADfr3won/phU/vlkydSeu6KyGk/z8RO2qVivy8AXBPt7q 4+g6NngaFFCMk20D5oafeiSjypK+ZOEGVlxSH+tuRTLJPUWTyp3HZdauMGHvMsEZad t0a1HRWmI+3dQKEw1QkYEfGixOqHH7KHbYkM8mFA= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvRcNLVUhsaT for ; Thu, 20 Jul 2017 17:09:09 +0000 (UTC) Date: Thu, 20 Jul 2017 13:09:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500570549; bh=LQ8o4fofBeg+zmDU4AMJxWrTcPm8CJwUSJztKTRZKXI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QXKHpuzeDOyF/T7DxmCxZ1qruZ5T7VGTOhkKzc2AOT6cP6pkEwHL2jd4RGk4n4GO5 R21AqWRwiEqwjjewSr3WSD8W6v3tXPIXGplcNkscDoLxQYRlAPStvpkTwxaVCWwPzj n9AFVbPmAclWkIikyeOJUZWpsHSKp7Mko3RvzayQ= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:09:13 -0000 On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: > > But it's certainly another step along the way to DNSbis by accident. > > Would it be useful to make it not "by accident"? Yes. That was basically the point I was trying to make at the beginning of today's session, about overall analysis. > b) make this draft DNS-SD only, so it can fast forward... > I'm not keen on this. > c) use the changed paradigm to work on DNSbis without the accident part? I'm starting to wonder whether a bof is needed. Maybe the IAB's workshop will produce some fruit? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jul 20 10:54:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F46E1270AC for ; Thu, 20 Jul 2017 10:54:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NZUeaTKyB771 for ; Thu, 20 Jul 2017 10:54:44 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 8DF5E1252BA for ; Thu, 20 Jul 2017 10:54:44 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v190so17863346pgv.2 for ; Thu, 20 Jul 2017 10:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6IvA5exAcZ7aLHuQBc5UhTwSh7Y+SVq3DdRpwCXu2KE=; b=gRIw1L5M10U7npTlJbskRHh1OL7sv+Ca0zAbEhswdCnnkOsRfg8ObsREKqYNU3iGC1 svH3nln1xXMe5XeWYF8yqvLh5oB41skd0jsk30ANuwj0Jgl5cmp2M/nF5wiinfQNMsP9 cqWvUjoCyg6oaOfydRwkupXLvGr2wgTUsqWupZBcAZiRvDrWOChVjlqldVD0cRp5uM81 ZEG3UDHdvfm5pRMbDePJ2ewElzyb+zIxCTmp2rYIVE8rt0eJEZHN2nV+ZUh0n7zCZV+S sKAKbBmqi2/aJL7Bjql4/UmlXdLCy/cl4hQAqIAuws+f/5ita5ExxZOVWsVK2lO3SY1y at/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6IvA5exAcZ7aLHuQBc5UhTwSh7Y+SVq3DdRpwCXu2KE=; b=nzJFSBu42jnJRbv/nIuT6fF24YbzaaxeQHbT7GxdYUN6sDvZGBOfj0xMfYZ+QiVWk0 eqNYiAmyle/VLs5WHS2E7oBFMmGXePFJAF+0XbcsKFDpqcQ5AE1Hr46dYTKzaDIjzkKl tifw2GwKbTl7Uw6gs1X3y86Yx/nFnPmmXtMtJZDII6p0btmzo3ztffx9U9jky5nQPt+w m+oD0ppeRQvsePspHiXdKefHEWToFgBp9svd3VviaJDn65CzfCgt63d7d5/Ubw+iu19Y E9XvRK+Gzj6lnXOSfOYbmyK43h4uyVBTFjZ9eQ4fsM9MWtdZxHGa1alfgphv/Tw82DQ9 LVxg== X-Gm-Message-State: AIVw111rluCXYOES2egnREedUMHM1x3KT7ZUP5t07Kb9myuj1Ofor0h/ +m2dq/+Cs6v+hlpqaR7QRRdnD7K6mcYz X-Received: by 10.84.215.210 with SMTP id g18mr5075019plj.210.1500573284101; Thu, 20 Jul 2017 10:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 10:54:03 -0700 (PDT) In-Reply-To: References: From: Ted Lemon Date: Thu, 20 Jul 2017 19:54:03 +0200 Message-ID: To: George Michaelson Cc: dnsop WG Content-Type: multipart/alternative; boundary="94eb2c19f1428f31720554c37171" Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:54:46 -0000 --94eb2c19f1428f31720554c37171 Content-Type: text/plain; charset="UTF-8" It would be nice if there were an RFC to point to that used a method that didn't include PII. For the use cases of which I am ware, there is no need to identify individual devices: only policies. What's lacking is a way to do this in the home router, so the PII winds up getting exported to the cloud not because that's necessary to accomplish the filtering but because it's the only available place where the translation from PII->policy can be done in practice. Unfortunately, solving _that_ problem is definitely out of scope for DNSOP. On Thu, Jul 20, 2017 at 7:00 PM, George Michaelson wrote: > I probably will not carry the WG with me on this, but I find myself > thinking the PII aspect of client-ID makes it a wider-internet > question and we might have views as a WG, and promote questions as a > WG, but I think the "final call" on this is something which needs more > than WG approval. > > Its a big question. I'd actually welcome adoption on many levels, but > that isn't to pre-empt that it goes to WGLC. I think we need to > formalize the issues and take them out of the WG for review and > discussion. > > documenting current practice is ok btw, but .. PII. > > -G > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c19f1428f31720554c37171 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It would be nice if there were an RFC to point to that use= d a method that didn't include PII. =C2=A0 For the use cases of which I= am ware, there is no need to identify individual devices: only policies. = =C2=A0 What's lacking is a way to do this in the home router, so the PI= I winds up getting exported to the cloud not because that's necessary t= o accomplish the filtering but because it's the only available place wh= ere the translation from PII->policy can be done in practice. =C2=A0 Unf= ortunately, solving _that_ problem is definitely out of scope for DNSOP.

On Thu, Jul 20= , 2017 at 7:00 PM, George Michaelson <ggm@algebras.org> wrote= :
I probably will not carry the WG with m= e on this, but I find myself
thinking the PII aspect of client-ID makes it a wider-internet
question and we might have views as a WG, and promote questions as a
WG, but I think the "final call" on this is something which needs= more
than WG approval.

Its a big question. I'd actually welcome adoption on many levels, but that isn't to pre-empt that it goes to WGLC. I think we need to
formalize the issues and take them out of the WG for review and
discussion.

documenting current practice is ok btw, but .. PII.

-G

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c19f1428f31720554c37171-- From nobody Fri Jul 21 01:02:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B63131748 for ; Fri, 21 Jul 2017 01:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 vozKtly6yHdM for ; Fri, 21 Jul 2017 01:02:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 DB52312EB2B for ; Fri, 21 Jul 2017 01:02:54 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a] (unknown [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a]) by mail.nic.cz (Postfix) with ESMTPSA id AE5DF61FF3 for ; Fri, 21 Jul 2017 10:02:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500624172; bh=6Wz8Ln9BJhySoJO2loJqdY9OO5lZT/TxOfiYoaJcLGA=; h=To:From:Date; b=MuIyBM0gwCDH95skPagCLCaMLw+yyvNYe/NJCFR03joQuuTC8RPio6e9bprpc8NGx jHPDZTqc3faNr7VE1bc4OZXUvXl/ON8h3+p5Wl3qR+5JXKrgEGcho7Cdvo7eQn0pcf GDn64dMyVTWdRkGdRHd1p9GV8QZ7OfLIovZ6CDR8= To: dnsop@ietf.org References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Fri, 21 Jul 2017 10:02:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:02:56 -0000 On 20.7.2017 19:09, Andrew Sullivan wrote: > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: >>> But it's certainly another step along the way to DNSbis by accident. >> >> Would it be useful to make it not "by accident"? > > Yes. That was basically the point I was trying to make at the > beginning of today's session, about overall analysis. > > > b) make this draft DNS-SD only, so it can fast forward... >> > > I'm not keen on this. > > >> c) use the changed paradigm to work on DNSbis without the accident part? Yes please! My main opposition comes from fact that current session signaling draft "accidentaly" defines new protocol which is using the old DNS-RFC1035 as "transport". I would welcome DNSbis effort with clear cut. Here please note that clear cut does not mean that RR format and data, for example, has to be incompatible! It is still possible to share big chunks of specifications (like RR definitions, namespace, etc.) but define a DNSbis protocol which is clearly distinguishable from the old DNS. Petr Špaček @ CZ.NIC > I'm starting to wonder whether a bof is needed. Maybe the IAB's > workshop will produce some fruit? From nobody Fri Jul 21 01:23:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262D4131935 for ; Fri, 21 Jul 2017 01:23:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 pdl617flU9Q9 for ; Fri, 21 Jul 2017 01:23:11 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 0FBB1131CE6 for ; Fri, 21 Jul 2017 01:23:11 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id s70so21644211pfs.0 for ; Fri, 21 Jul 2017 01:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u+/KcM41D17Yi0aquYueT4ZaxdXgGl9UOKloL/OgVZU=; b=AD39bfWB91JodICllAAdY+qnwpssV5kjYmsFOWKKbZaVqCoDtlu0P0J8Fzmslkg2na O+tq3qKvxEt8CxAlkA/A40z8LlRA15/Ju6EvoSD1lcOyIZ/LC7sIn2cb2aePTTddc0x3 2i7OF9Qo/MQD1O11K5vTbPkKO1ZCrKHMS5s6KbKdxSRndNL6a0S510BN/AjgydXEejXr DYKgbYq07l9MimIL3+JRXrX8iFrrpaALWuTyHZIg6hIA4eX7alA+uOiCRzysgif1WQ1v hwSXmeIwNeH8Sr2qsBenT3a9PwJ4vw3EN14nzm8HvtfqsLFCMgfW81Zz4hEzIDMz4k2D O24A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u+/KcM41D17Yi0aquYueT4ZaxdXgGl9UOKloL/OgVZU=; b=rZxostpQ5+6J+4HX1gzUX0YN43LCpuwgBEjGz+39QrweZCmJgAv8/fCGfYchhXGeVh cgH49ABAlDznfI/mpnPAzAj6LkNAoYQREEqRnEGS465BQ5VaN7k8dJEoZJDLrvgZ1jsC /KJ3HrKIcx4iVclsU4FQ4CibS9/UDnMLb96D+Wc2HsjWaW1ZzszQR5+ZDdVgD3UMGdqV 8nUtN9b6i4jiAKwnerQEwsj37fSuN3vk3Ryrtq0Id3alZNGeMi242/c8N2uBU4Kwgz6k lvIHGK6OOO7bzaZMgeo9idiSK2SOo5gOM6QZVp3cAMQb5FxBH8BAWLnzuO9ovSWruhTN QuaA== X-Gm-Message-State: AIVw1138CZHe6k2wPc4WaqWvFwTiXw69BK+muVk19f4NbwpEE7/92lLO Frj6YtmzkI3QNp5OKPMENpN6uLnsMRbp X-Received: by 10.98.7.87 with SMTP id b84mr6876099pfd.216.1500625390493; Fri, 21 Jul 2017 01:23:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.130 with HTTP; Fri, 21 Jul 2017 01:22:30 -0700 (PDT) In-Reply-To: References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> From: Ted Lemon Date: Fri, 21 Jul 2017 10:22:30 +0200 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop WG Content-Type: multipart/alternative; boundary="001a1143ccc45781140554cf9314" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:23:14 -0000 --001a1143ccc45781140554cf9314 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am hearing from a number of people that this is "a new protocol" and hence requires careful thought and perhaps a new working group, along with the associated delay. I do not _entirely_ disagree with this position, although it would be really inconvenient from my perspective. However, I would like to point out that the objection "it is a new protocol" is not a technical objection. Also, the same objection can actually much more justly be raised against several other proposals that were brought before the working group. For example, the multiple RRtypes proposal, the multiple responses proposal, and the extended error codes proposal. All of these define new protocol, in ways that are in, like session signaling, backward-compatible with the existing protocol. The other proposals are actually much more significant changes than session signaling is, in terms of what they actually do, as opposed to what their wire format is. And as for a new DNS wire format, which I also think would be a good idea, this is pretty clearly *not *what session signaling is. How would you do a DNS query with session signaling? In what way would it be an improvement over the existing query format? It's possible that a new wire format can be built on top of session signaling, but session signaling doesn't build a new wire format, and if we choose to do session signaling, that doesn't preclude doing a different wire format for queries later. Session signaling is just a control plane for DNS. It's useful. I would like to see it done sooner rather than later. If we are not going to do it sooner rather than later, I would like the reason to be something more than vague unease about walking backwards into a new wire format. On Fri, Jul 21, 2017 at 10:02 AM, Petr =C5=A0pa=C4=8Dek wrote: > On 20.7.2017 19:09, Andrew Sullivan wrote: > > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ond=C5=99ej Sur=C3=BD wrote: > >>> But it's certainly another step along the way to DNSbis by accident. > >> > >> Would it be useful to make it not "by accident"? > > > > Yes. That was basically the point I was trying to make at the > > beginning of today's session, about overall analysis. > > > > > b) make this draft DNS-SD only, so it can fast forward... > >> > > > > I'm not keen on this. > > > > > >> c) use the changed paradigm to work on DNSbis without the accident par= t? > > Yes please! > > My main opposition comes from fact that current session signaling draft > "accidentaly" defines new protocol which is using the old DNS-RFC1035 as > "transport". > > I would welcome DNSbis effort with clear cut. Here please note that > clear cut does not mean that RR format and data, for example, has to be > incompatible! > > It is still possible to share big chunks of specifications (like RR > definitions, namespace, etc.) but define a DNSbis protocol which is > clearly distinguishable from the old DNS. > > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > > I'm starting to wonder whether a bof is needed. Maybe the IAB's > > workshop will produce some fruit? > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a1143ccc45781140554cf9314 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am hearing from a number of people that this is "a = new protocol" and hence requires careful thought and perhaps a new wor= king group, along with the associated delay. =C2=A0 I do not _entirely_ dis= agree with this position, although it would be really inconvenient from my = perspective.

However, I would like to point out that the= objection "it is a new protocol" is not a technical objection.= =C2=A0 Also, the same objection can actually much more justly be raised aga= inst several other proposals that were brought before the working group. = =C2=A0 For example, the multiple RRtypes proposal, the multiple responses p= roposal, and the extended error codes proposal.

Al= l of these define new protocol, in ways that are in, like session signaling= , backward-compatible with the existing protocol. =C2=A0 The other proposal= s are actually much more significant changes than session signaling is, in = terms of what they actually do, as opposed to what their wire format is.

And as for a new DNS wire format, which I also think= would be a good idea, this is pretty clearly not what session signa= ling is. =C2=A0 How would you do a DNS query with session signaling? =C2=A0= In what way would it be an improvement over the existing query format? =C2= =A0 It's possible that a new wire format can be built on top of session= signaling, but session signaling doesn't build a new wire format, and = if we choose to do session signaling, that doesn't preclude doing a dif= ferent wire format for queries later.

Session sign= aling is just a control plane for DNS. =C2=A0 It's useful. =C2=A0 I wou= ld like to see it done sooner rather than later. =C2=A0 If we are not going= to do it sooner rather than later, I would like the reason to be something= more than vague unease about walking backwards into a new wire format.

On Fri, J= ul 21, 2017 at 10:02 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz>= ; wrote:
On 20.7.= 2017 19:09, Andrew Sullivan wrote:
> On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ond=C5=99ej Sur=C3=BD wrote:=
>>> But it's certainly another step along the way to DNSbis by= accident.
>>
>> Would it be useful to make it not "by accident"?
>
> Yes.=C2=A0 That was basically the point I was trying to make at the > beginning of today's session, about overall analysis.
>
>=C2=A0 > b) make this draft DNS-SD only, so it can fast forward... >>
>
> I'm not keen on this.
>
>
>> c) use the changed paradigm to work on DNSbis without the accident= part?

Yes please!

My main opposition comes from fact that current session signaling draft
"accidentaly" defines new protocol which is using the old DNS-RFC= 1035 as
"transport".

I would welcome DNSbis effort with clear cut. Here please note that
clear cut does not mean that RR format and data, for example, has to be
incompatible!

It is still possible to share big chunks of specifications (like RR
definitions, namespace, etc.) but define a DNSbis protocol which is
clearly distinguishable from the old DNS.

Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC

> I'm starting to wonder whether a bof is needed.=C2=A0 Maybe the IA= B's
> workshop will produce some fruit?

____________________________= ___________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a1143ccc45781140554cf9314-- From nobody Fri Jul 21 01:24:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E34131748 for ; Fri, 21 Jul 2017 01:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 8SucaakXvdZs for ; Fri, 21 Jul 2017 01:24:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 A612412EC51 for ; Fri, 21 Jul 2017 01:24:38 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a] (unknown [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a]) by mail.nic.cz (Postfix) with ESMTPSA id 39CED62250 for ; Fri, 21 Jul 2017 10:24:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500625477; bh=CuKQ79bIdPLyqFGH7J7D40kk+fzH9xrrjrn0wij9oa4=; h=To:From:Date; b=f+y3rbNd9ZTSpXHa3VbCijMUebyige1nlnclk1jnRLHfO5EJky8F2hdswALCp9suH w1I0kPe4cXRqaqjuaMzTuLiySZjWIzhJ8EFZ+8Xhad5Q6WyqUcHszi8qqj/UOZDha9 AHfZYG6VmagaeDB6aI7wHvKGG3dBeokPbdw5NrQg= To: dnsop@ietf.org References: <201707190850.v6J8ol1c028029@givry.fdupont.fr> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Fri, 21 Jul 2017 10:24:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <201707190850.v6J8ol1c028029@givry.fdupont.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:24:40 -0000 On 19.7.2017 10:50, Francis Dupont wrote: > In your previous mail you wrote: > >> NSEC needs no keys, only their RRSIGs would which wouldn't exist in >> unsigned zones. In this case the unsigned NSEC would also not be part of >> the zone (it would have to be synthesized and maintained outside the >> zone). > > => but it is created by an authoritative server, isn't it? > And as it is synthesized I can't see a good reason to use NSEC3 instead. > >> Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix >> entire zones, when it was discussed, Mark Andrews suggested that >> requiring DNS COOKIE to further reduce the chance of cache poisoning >> (more than source port randomization and random message ID) could be a >> reasonable idea to think about. > > => it adds a nonce so another (short) bunch of unpredictable bits. > As NSEC is not signed it is more than vulnerable to on-the-path attacks. > I am afraid it is first a massive zone destruction weapon and after > perhaps an optimization... Oh yes, very good point Francis. Let me repeat that I'm against this proposal. Petr Špaček @ CZ.NIC > >> > It seems easier to remember that DNSSEC offers proofs for denial of >> > existence. > > => still applies... > > Regards > > Francis.Dupont@fdupont.fr > > PS: really if this is deployed I can see more "interesting" ways for misuses > than real benefits. Of course it can be a mean to make zone managers From nobody Fri Jul 21 01:30:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18CA129AA0 for ; Fri, 21 Jul 2017 01:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 TzY1Uj98QboX for ; Fri, 21 Jul 2017 01:30:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 A80A812778D for ; Fri, 21 Jul 2017 01:30:15 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a] (unknown [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a]) by mail.nic.cz (Postfix) with ESMTPSA id 0AB60622A1 for ; Fri, 21 Jul 2017 10:30:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500625814; bh=hfSw/QP4K3p16S7t1H1JDVRRcUl7+mxhGp5bt8cpNMQ=; h=To:From:Date; b=mGxVJuZHGOD2gQnMrVdv9t+t6zAXnZ4a/YjYGEBJv4XX+E5P7LO2Ik4rtlVxmhhpL ihXThyLtQqqpfPhA7JBpByXzobPqGExtloPKADVyBs6THP6OjgbgWVxnemUEmcq1sw m2lMUxoTyJCpaUTPqc3ZgjipVF5Y1ywlKSNt4Tms= To: dnsop@ietf.org References: <20170718094654.GA31988@jurassic> <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> <20170718125056.GA7982@jurassic> <20170720150031.GA22702@laperouse.bortzmeyer.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <138b3c18-70ae-c2ca-1f63-e68e256e6e48@nic.cz> Date: Fri, 21 Jul 2017 10:30:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170720150031.GA22702@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:30:17 -0000 On 20.7.2017 17:00, Stephane Bortzmeyer wrote: > On Tue, Jul 18, 2017 at 06:20:56PM +0530, > Mukund Sivaraman wrote > a message of 27 lines which said: > >> It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned >> zones. > > That's quite funny. During the development of RFC 8020 > (draft-ietf-dnsop-nxdomain-cut), which addresses the same concern as > draft-ietf-dnsop-nsec-aggressiveuse, many people said that the feature > was dangerous, and we should mandate the use of DNSSEC. In the end, it > is not mandatory (see sections 2, 3rd para, and section 7 of RFC > 8020). It is worth noting that implementation in Unbound enables this only for DNSSEC-signed zones to avoid problems with broken CDNs. In other words, DNSSEC is used as indicator "we can do DNS properly". That sounds reasonable to me. Petr Špaček @ CZ.NIC > draft-ietf-dnsop-nsec-aggressiveuse is more aggressive (because it can > now synthetizes answers) so it seems to me the same reasons should > apply? From nobody Fri Jul 21 02:13:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAFB126557 for ; Fri, 21 Jul 2017 02:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8EOdawd28YOh for ; Fri, 21 Jul 2017 02:13:46 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 AB37A129A96 for ; Fri, 21 Jul 2017 02:13:45 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id w191so3421945wmw.1 for ; Fri, 21 Jul 2017 02:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WISX1sl8pQNMTpQBrn5qEH48LVPu0yDDTi/HcKmTKZ8=; b=DMkfL6fat0guv2VDTQeJThXf+GZslpdaRxcWugXk4PfxC3kdAbbKXyaFvX3N9tzkVD fbIPo0KCPcJIMtDePMBrSrk9KF4kAntbmQtsOi+xrPno+TWDmvqVaGdQp1v1smBOdG83 Rk9hxxRFZUm1Y04xWHl65GWMEz4NYHnZy/SDif6SOonYE8LgmIMevF06WV4pII0/2/0I aueAE3Hz9Cg7CjHbohXIzWKMthySkpDslz73gN3amger84CS9YvWV9aNm8fogaGFFS+L nGFgdAAP2gMyWwfr6j+PjojFtihRqDvwjoGNuPhuuV5/eS2ZUgMVwbwfah4a15M3D1IY POLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WISX1sl8pQNMTpQBrn5qEH48LVPu0yDDTi/HcKmTKZ8=; b=iyfnGoBR9dtOHFqhmtlAYay6dKO6dz04SYiIa9YnUeZxX1lnJTDt9OOF8iV3saxCYI NgnV6VS6U0dIBDjgCQtoKuk+ChWwd+aX7X3hWWpXd7IMxWD8DQ20cjpBH2VtJDfd8v16 pL0NjwxJsRPUi7pprJAYL+XoZgT2e+AYhtKkT3AFF05gxu6I7y9mL2brQlLYERbxrzub Eu1t8VfODxDDU3Z0O9s30U3LAbYqJfnCKRcYzqyEKz9NxdUKyXLksseL0ZphQl1Q/WmW jcu7SoyNxKvjAZn4F4Va4BFGBHBQ/e3sMQSOtXSKSSvp4lcFljby9MKALT6CrIp1UCtW 9AOw== X-Gm-Message-State: AIVw113MksUeQhGcbq6L3lnLkc79fg89edzcwWwuymCDmSsmAas9xS6a WCGEmg5LX5XXzp8Zz5A= X-Received: by 10.28.111.218 with SMTP id c87mr4028408wmi.36.1500628424078; Fri, 21 Jul 2017 02:13:44 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:1cb6:5324:3799:1231? ([2001:67c:370:128:1cb6:5324:3799:1231]) by smtp.gmail.com with ESMTPSA id 92sm6820842wro.68.2017.07.21.02.13.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 21 Jul 2017 02:13:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: Date: Fri, 21 Jul 2017 05:13:41 -0400 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <46EC1114-9C85-4D95-AD4C-3A155CADA2C9@gmail.com> References: To: George Michaelson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:13:48 -0000 George, > On Jul 20, 2017, at 1:00 PM, George Michaelson = wrote: >=20 > I probably will not carry the WG with me on this, but I find myself > thinking the PII aspect of client-ID makes it a wider-internet > question and we might have views as a WG, and promote questions as a > WG, but I think the "final call" on this is something which needs more > than WG approval. A couple of points of precision on this: first, I=E2=80=99m not sure = =E2=80=9CPII=E2=80=9D is rigorously defined in our context, so we might = need to be more specific on that (although I agree with the intuitive = sense you seem to have about it). Second, technically the WG doesn=E2=80=99t approve publication of a = document anyway; a decision by the WG to advance a particular document = along the process is neither necessary nor sufficient to get it = published; there are several additional steps to publication approval. With those things said, however: >=20 > Its a big question. I'd actually welcome adoption on many levels, but > that isn't to pre-empt that it goes to WGLC. I think we need to > formalize the issues and take them out of the WG for review and > discussion. >=20 > documenting current practice is ok btw, but .. PII. >=20 Agreed there are some aspects here that need cross-area review, and = making sure that happens is part of the chairs=E2=80=99 followup from = discussion of the draft to date. Suzanne From nobody Fri Jul 21 02:23:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E640127869 for ; Fri, 21 Jul 2017 02:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 pdFxcpfGTlSi for ; Fri, 21 Jul 2017 02:23:06 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 16484126557 for ; Fri, 21 Jul 2017 02:23:06 -0700 (PDT) Received: from jurassic (unknown [115.117.171.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 0547956A02DB; Fri, 21 Jul 2017 09:23:03 +0000 (GMT) Date: Fri, 21 Jul 2017 14:53:01 +0530 From: Mukund Sivaraman To: Petr =?utf-8?B?xaBwYcSNZWs=?= Cc: dnsop@ietf.org Message-ID: <20170721092301.GA3781@jurassic> References: <201707190850.v6J8ol1c028029@givry.fdupont.fr> 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.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:23:07 -0000 On Fri, Jul 21, 2017 at 10:24:35AM +0200, Petr Špaček wrote: > On 19.7.2017 10:50, Francis Dupont wrote: > > In your previous mail you wrote: > > > >> NSEC needs no keys, only their RRSIGs would which wouldn't exist in > >> unsigned zones. In this case the unsigned NSEC would also not be part of > >> the zone (it would have to be synthesized and maintained outside the > >> zone). > > > > => but it is created by an authoritative server, isn't it? > > And as it is synthesized I can't see a good reason to use NSEC3 instead. > > > >> Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix > >> entire zones, when it was discussed, Mark Andrews suggested that > >> requiring DNS COOKIE to further reduce the chance of cache poisoning > >> (more than source port randomization and random message ID) could be a > >> reasonable idea to think about. > > > > => it adds a nonce so another (short) bunch of unpredictable bits. > > As NSEC is not signed it is more than vulnerable to on-the-path attacks. > > I am afraid it is first a massive zone destruction weapon and after > > perhaps an optimization... > > Oh yes, very good point Francis. Let me repeat that I'm against this > proposal. The zone is unsigned. An on-path attacker can do pretty much whatever he pleases anyway including poisoning cache and denying service. The addition of the cookie was to prevent the risk of an off-path attack becoming a massive zone destruction weapon. Mukund From nobody Fri Jul 21 04:36:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95A113157A for ; Fri, 21 Jul 2017 04:36:38 -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_PASS=-0.001, URIBL_BLOCKED=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 bEBoVPUfRkPB for ; Fri, 21 Jul 2017 04:36:37 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 D263A12ECB7 for ; Fri, 21 Jul 2017 04:36:36 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35204) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dYWEU-000ez5-dI (Exim 4.89) (return-path ); Fri, 21 Jul 2017 12:36:34 +0100 Date: Fri, 21 Jul 2017 12:36:33 +0100 From: Tony Finch To: Andrew Sullivan cc: dnsop@ietf.org In-Reply-To: <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> Message-ID: References: <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:36:38 -0000 Andrew Sullivan wrote: > > For instance, people also express astonishment that DNSKEYs don't > expire. Everyone always has to be reminded that signatures expire, and > if you want to expire keys you take them out of the zone. I agree with your message. It might be useful to explain this DNSKEY oddity by comparison with x.509 certificates. In particular, it's the cert that expires, not the key, and when you renew a cert you can re-use the same key. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or rough. Rain or showers. Good, occasionally poor. From nobody Fri Jul 21 04:47:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2C21317B1 for ; Fri, 21 Jul 2017 04:47:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 8xhW6kv4F7_l for ; Fri, 21 Jul 2017 04:47:40 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 07A5913157A for ; Fri, 21 Jul 2017 04:47:39 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id d29so34050948uai.2 for ; Fri, 21 Jul 2017 04:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LPvtPZ9/25aXg58UteOzSG1nBn1/4aj8dC2sRGNmZ8E=; b=SfhBUZRO4XOtUH3UFNutxOa3UKc6gD2aepafUgNHc5mg9Dc7CXN9DKC74NNDRvdAZU +1iEw1dBpMu6giuomIWJwZf6Muct9plf0FdmixnvfQQg0h/kClBtCdFnCgdnWfEJ+FDi 0Dj7fwRZOaa15d1uiBcesdUsOkDNZN2yQguaCoo1fJKNFncxAmiRer01vtNhwxMNBuRN WmnZwqxlxpGAatQhXj79R3WUIUkIuXJyp444ACofOL3/GbJpsi9cTGqgjxnFIJdcFoFq cZNQfW+p3Lvv7ZEC4+NyiJN6Cq7WWC8VD6x/iDw2dVwD8FBj7GURYTj245MSsdWaU7A5 ghUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LPvtPZ9/25aXg58UteOzSG1nBn1/4aj8dC2sRGNmZ8E=; b=HbSPM9R+iekRGMDZOCQljpcn7Rp0CZf6i34zY7Q5FiyI58SvRMfb+ucJ+zT5+hz+dJ zbA3nvZSbV6JZsbUzMQ+dtHo0A158oDEIUPWEVC73y3QemJMY1yP1MXRjclq8YMO+8zt 42txDHdlcXA6UDGjj3MdujFahkyjaOfYoh8iO8Zm2JYbfnXmkq/2Xrn1Kv7SVYobO8CT cIbdreLiqLklDQ8Nrzw07/XGUlhmnFXHO02qBtE4fIHARzdSJnncNw/k2DEhWWML7EFf seaScABAS7E1IOispv0nVC2Y1c7IMLn3wz6GqhW2O4WArsIf0mchoOVwUF+d9UJEQefc M+KA== X-Gm-Message-State: AIVw1119kEpENPT3o3wNqOMippUGNXN1A9cGimTsCvN5vCOSsqKW3QIA Eu0C/U6S7qKlPF0bzrqPm5B+mg/5qIDmy90= X-Received: by 10.31.234.3 with SMTP id i3mr4011332vkh.115.1500637658920; Fri, 21 Jul 2017 04:47:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.72 with HTTP; Fri, 21 Jul 2017 04:46:58 -0700 (PDT) In-Reply-To: References: <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> From: Warren Kumari Date: Fri, 21 Jul 2017 13:46:58 +0200 Message-ID: To: Tony Finch Cc: Andrew Sullivan , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:47:42 -0000 On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: > Andrew Sullivan wrote: >> >> For instance, people also express astonishment that DNSKEYs don't >> expire. Everyone always has to be reminded that signatures expire, and >> if you want to expire keys you take them out of the zone. > > I agree with your message. > > It might be useful to explain this DNSKEY oddity by comparison with x.509 > certificates. In particular, it's the cert that expires, not the key, and > when you renew a cert you can re-use the same key. Yeah, you *can* reuse the same key, but (I suspect) most don't -- from what I've seen, then general process is: 1: Erk! My cert is about to / has just expired!!! 2: Search for and follow some online recipe related to "make ssl certificate" 3: ???? 4: Go back to sleep. I think that (but would be happy to be proven wrong) that most certificate renewals[0] involve a change of keys too. W [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode > Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 > veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or > rough. Rain or showers. Good, occasionally poor. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Jul 21 05:58:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0064B1300BB for ; Fri, 21 Jul 2017 05:58:27 -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_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=algebras-org.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 tD7Jlt9M72fF for ; Fri, 21 Jul 2017 05:58:24 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 8CCFD12F24E for ; Fri, 21 Jul 2017 05:58:24 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id k43so8116634uaf.3 for ; Fri, 21 Jul 2017 05:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YDCh6OaxKktwCpcKbKOqZ4pzhivpCNrJqHt0NB7j1/I=; b=e1pwHYasmThKtwpO6VvqERBCi4/jIAgZpIkg24xBTmlkB0Wbo05SjhfNArByK4uNI1 omfVVtmb1buYgSSTqllWbIY50lLGvawB28EgXv7hJAKl2aRENMdijKBbQeBfF7PmkORx 1vVK5vxNc/pyXT7XCClkr3yC13FCkaN1Ovzu5jK6RbQTTEhlPMViS01iHCmKBUEMO2ex fT0rjtKIOeuWM36dyDe1s0AM7gC0fbfQS6W9klU73iH4Pwv0NiqQU5FfmdHlnANzHMby vmM8PZL5srYfhX77h1gtgu9btqmjQV2VG4vc3mxZnTLKa8tMV4kTF2inFtSkqYcy826C 5a9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YDCh6OaxKktwCpcKbKOqZ4pzhivpCNrJqHt0NB7j1/I=; b=aKcub3w1mCFcosNrKWR0OWuo5mOo+iPyqyx/0ZVtN7mk49pFDx4xGdjiE0wegeKjfu FYPQy38+igp1iEfNkYk9NJkFm2arUfKUyqhPYXKbyR2NA53IQch1qjVA8q89I4zFLwwr s3dGSq3+BOWfhVxt5IcqIhQmUMhNdq8NzqrdJuIim5K6WCBh8ZDwTRdVOg68WgFJx9wU rAUdQkpelkPVmJlL6AObeB80eJVpyMFfd3BbiwKTWcVtBXXUFp7/RcQAYZx8sYixx2RW fjas1qCyW0K1KTbpvIzSj7CQA5kG15NGOnZ0txHuQLLCEI3ZGFZfCphu9H4d1EZBzfTy FH4Q== X-Gm-Message-State: AIVw111jK/iiBvTCXfKv8mEw0PTizZHhdT28Bbohm59RTni0nq4Z+k9S O17D5dQhqzkcYhTJZfHHctgDYaLRyMoj3Pk= X-Received: by 10.176.23.3 with SMTP id j3mr4938905uaf.128.1500641903600; Fri, 21 Jul 2017 05:58:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Fri, 21 Jul 2017 05:58:23 -0700 (PDT) X-Originating-IP: [212.71.191.138] In-Reply-To: References: <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> From: George Michaelson Date: Fri, 21 Jul 2017 14:58:23 +0200 Message-ID: To: Warren Kumari Cc: Tony Finch , dnsop , Andrew Sullivan Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 12:58:27 -0000 A fine bit of epistemology lies in the question: is it the same certificate, if you re-issue it with the same keys? No, because it has a different serial. but the crypto doesn't care, its the validation which cares which is a product of the crypto. so validation cares but cryptographic functions themselves, not such. The nice thing about bare key cryptography, is that fish don't need bicycles. Dates are dates and validity intervals are a thing, but you can re-bake as many times as you like if there is nothing embedded in the structure like a serial. Oh wait.. we sign the SOA don't we... I (for one) hang onto the .req file. Maybe thats naughty, but I do, so in my case Warren routine is that the keypair is being reused, because.. well.. because I like to. Software I consume I suspect (like you) doesn't, and re-mints shiny new keys now with added keynomium, but when I do it by hand? yes I reuse the .req file. But I am probably being led into bad places as a result. I am sure wiser heads will say. On Fri, Jul 21, 2017 at 1:46 PM, Warren Kumari wrote: > On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: >> Andrew Sullivan wrote: >>> >>> For instance, people also express astonishment that DNSKEYs don't >>> expire. Everyone always has to be reminded that signatures expire, and >>> if you want to expire keys you take them out of the zone. >> >> I agree with your message. >> >> It might be useful to explain this DNSKEY oddity by comparison with x.509 >> certificates. In particular, it's the cert that expires, not the key, and >> when you renew a cert you can re-use the same key. > > > Yeah, you *can* reuse the same key, but (I suspect) most don't -- from > what I've seen, then general process is: > 1: Erk! My cert is about to / has just expired!!! > 2: Search for and follow some online recipe related to "make ssl certificate" > 3: ???? > 4: Go back to sleep. > > I think that (but would be happy to be proven wrong) that most > certificate renewals[0] involve a change of keys too. > > W > [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc. > >> >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode >> Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 >> veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or >> rough. Rain or showers. Good, occasionally poor. >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Jul 21 06:24:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E593E12F24E for ; Fri, 21 Jul 2017 06:24:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 X-R-TckxLdmk for ; Fri, 21 Jul 2017 06:24:07 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 B1D46131CB4 for ; Fri, 21 Jul 2017 06:24:07 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 80so45330218uas.0 for ; Fri, 21 Jul 2017 06:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=82MWGgDiuNfQLUMKTxJ7srZy4AQMMBgbZrxW5hbX8Qo=; b=ond1395SkqPgVygve2mTtfhO9ZEDUdIlFZ1HBLj13bkdmvKQgApXRAxVJwg5S52USi PE4NrrH0kx6/OoHwQuYD+MHeG21HRq0wOJwbEuMOBmeM+yGxUdDEfj3vOj1LR8V3mOt6 ufcqcw0PS2DVQ1wW5Y6INxk/TnsiIGUMyWJM+4i0epy+p/+heqyMbqX5H5ZogSzrdtRz fVMNWbl+OkC4UqHXRNoft79DO/r/xvf2s6xLl3eEGqJU7ZLrMiKX1ASA8S+u7muCPUdW DQBMn6r3bHLf5p0+1MYsk8RjLSoMm5a8YxPOmzXlXJtXtSdOMV0HwusuFnxeXblTRl9u ng1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=82MWGgDiuNfQLUMKTxJ7srZy4AQMMBgbZrxW5hbX8Qo=; b=B5ydZ1+XReEXsXTTmqSG3mZ2OteC2Fm9f0air6aa7hA0gTsliJNMs1cVsW4M4HenVg d/k55jphDzWi0+qgmt6U+HW8b601omFo5deqlJc7ttVdRCToJF4noTWT7eQiWPGNKwrY OomxCMzMAsk9wJs5hZgq09+H++L1zj5O/yC3dosb/2b/CgFjxacRXZwJXPmZUj7GCQ3N +YGyCoCMhOShWBNjMnDdQUm7eKmryaH3mGVD9Uz7CFeUsKvz3+ldyp1UWO0h94k0+NgX 9BEAG9NLPO6i3rRt43KsZOVkZZL5krUwAqb1P57lBdfcXWZfnzQ9QBGU4ppQmrgaVyuR NNDA== X-Gm-Message-State: AIVw111NXc7/ZBEPJ/fhC7CKue80E3Fn+s/AI4NMnOE0w7EbZJfDLkum H6Xpk34V1UX60QQOOqK/nYVe0y3DVSUS X-Received: by 10.31.171.136 with SMTP id u130mr3341819vke.156.1500643446645; Fri, 21 Jul 2017 06:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.72 with HTTP; Fri, 21 Jul 2017 06:23:26 -0700 (PDT) In-Reply-To: References: <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> From: Warren Kumari Date: Fri, 21 Jul 2017 15:23:26 +0200 Message-ID: To: George Michaelson Cc: Tony Finch , dnsop , Andrew Sullivan Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:24:10 -0000 I've also heard the "changing the keys is good hygiene" argument -- if someone has wandered off with your private keys (like an old administrator) you have limited how long they can reuse them.... but, a: there is room for argument and b: we have gotten way down into the weeds here... W On Fri, Jul 21, 2017 at 2:58 PM, George Michaelson wrote: > A fine bit of epistemology lies in the question: is it the same > certificate, if you re-issue it with the same keys? No, because it has > a different serial. but the crypto doesn't care, its the validation > which cares which is a product of the crypto. so validation cares but > cryptographic functions themselves, not such. > > The nice thing about bare key cryptography, is that fish don't need > bicycles. Dates are dates and validity intervals are a thing, but you > can re-bake as many times as you like if there is nothing embedded in > the structure like a serial. Oh wait.. we sign the SOA don't we... > > I (for one) hang onto the .req file. Maybe thats naughty, but I do, so > in my case Warren routine is that the keypair is being reused, > because.. well.. because I like to. Software I consume I suspect (like > you) doesn't, and re-mints shiny new keys now with added keynomium, > but when I do it by hand? yes I reuse the .req file. > > But I am probably being led into bad places as a result. I am sure > wiser heads will say. > > On Fri, Jul 21, 2017 at 1:46 PM, Warren Kumari wrote: >> On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: >>> Andrew Sullivan wrote: >>>> >>>> For instance, people also express astonishment that DNSKEYs don't >>>> expire. Everyone always has to be reminded that signatures expire, and >>>> if you want to expire keys you take them out of the zone. >>> >>> I agree with your message. >>> >>> It might be useful to explain this DNSKEY oddity by comparison with x.509 >>> certificates. In particular, it's the cert that expires, not the key, and >>> when you renew a cert you can re-use the same key. >> >> >> Yeah, you *can* reuse the same key, but (I suspect) most don't -- from >> what I've seen, then general process is: >> 1: Erk! My cert is about to / has just expired!!! >> 2: Search for and follow some online recipe related to "make ssl certificate" >> 3: ???? >> 4: Go back to sleep. >> >> I think that (but would be happy to be proven wrong) that most >> certificate renewals[0] involve a change of keys too. >> >> W >> [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc. >> >>> >>> Tony. >>> -- >>> f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode >>> Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 >>> veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or >>> rough. Rain or showers. Good, occasionally poor. >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Jul 21 12:19:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42090131A50 for ; Fri, 21 Jul 2017 12:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-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 nJS4oFc7bL3s for ; Fri, 21 Jul 2017 12:19:18 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 8F8C2131A55 for ; Fri, 21 Jul 2017 12:19:16 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id k43so15873632uaf.3 for ; Fri, 21 Jul 2017 12:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jRgRHnpuB6Ce1W7+hra5bw65ulBPJ80rHyFYyH6/2ZE=; b=wv3JQkBHjEuZfMMuX6XkJLLq36S7xHfsSgKn9t/KSXsuCiGpt6FCsy6pAJnZYz3D6t NwCkJn0AgQ8qoYQOXBmgF5GidDwleiGWcQOqo/f3HEIynjR2fiXQ2qX8mh5cT5mX46VJ 80PnulOmIpgBcy2JrzdzM5ag3yJg+5/H3q7M2idVzSfVlPp0Z/8ePigYkvZP3/aLt3km Kuxg5FawS0HusKU/o2vaQUay1Xdau1MmQ1ko8TlVDsTNOCxIrw/IfzXW0iUeMXEiz5Xl eWK3JBlN22IZprsXeOQ3IIEqiOen9JWHAsa9oYCHGrIs5rLLrRIbXNtDYZgWtkTxfZ41 Egwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jRgRHnpuB6Ce1W7+hra5bw65ulBPJ80rHyFYyH6/2ZE=; b=rJRYSD9b22OFZAzINlZrAL83I1dkHmGXNt0ZCGmrD2ugPPg2P5UF8RAPiwLMuJBUbB V5XUBjwIUkm/DGi2+a3Yljw+UE+sF4Id8qoZtv/CRlMnEbPALM1pab03d1UkwDQwb0U0 yiSKTYR89OYyx6WOGPgYVQFXGt1pRdEr2jewBBvL51PPW2+KU7l8f8UZOy2QQgy99d+R g37pAp2SSbtsmlxa39yrlCr72XlLuI9kzLnqoApHhhYyZsCm1G7ppMMFiRcyv3cpibCD m0FlXeIbMxh+PVVhoHJM+CQmBrsEKtSKZrE9vxqngKsRWthLmon6tWm+Ij6GPA1dN0ZJ KARg== X-Gm-Message-State: AIVw111Rlcwb22fKUqlsQcb4Ve8Gu2jRiN5HozgAjFi5hBvtiXE9pTju DJ4029S3IjpiXynUSP/pwV0Ro/3/ga8e X-Received: by 10.176.81.34 with SMTP id e31mr5250394uaa.73.1500664755284; Fri, 21 Jul 2017 12:19:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.14 with HTTP; Fri, 21 Jul 2017 12:19:14 -0700 (PDT) In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> From: Matthew Pounsett Date: Fri, 21 Jul 2017 21:19:14 +0200 Message-ID: To: John R Levine Cc: Stephane Bortzmeyer , dnsop , Paul Wouters Content-Type: multipart/alternative; boundary="94eb2c1912c6aad5820554d8bd8f" Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 19:19:20 -0000 --94eb2c1912c6aad5820554d8bd8f Content-Type: text/plain; charset="UTF-8" On 20 July 2017 at 17:53, John R Levine wrote: > That's why I don't share the fears about BULK: you cannot easily >> deploy a new feature that will require a change in the resolvers, >> because you don't know all the resolvers, and cannot change them even >> if you know they are too old. But your secondaries are only a small >> set of carefully chosen servers, and you have your say. >> > > I hear otherwise from people who run big DNS farms. It's common to use > multiple secondary providers, and it's hard to tell who's running what > server software. I also note that it took about a decade before people > felt comfortable using DNAMEs. > Dear $VENDOR. I'm a customer who is considering deploying the BULK RR type into my zone, and I would like to know whether your systems support it. Thank you, $CUSTOMER. That said.. there is still an issue with key distribution for online signing which is required to make this work. I see the utility in BULK, but I'm persuaded that there needs to be more work before it's deployable in an environment where *XFR is required. --94eb2c1912c6aad5820554d8bd8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 20 July 2017 at 17:53, John R Levine <johnl@taugh.com> wrote:
That's why I don't share the fears about BULK: you cannot easily deploy a new feature that will require a change in the resolvers,
because you don't know all the resolvers, and cannot change them even if you know they are too old. But your secondaries are only a small
set of carefully chosen servers, and you have your say.

 I hear otherwise from people who run big DNS farms.=C2=A0 It's common t= o use multiple secondary providers, and it's hard to tell who's run= ning what server software.=C2=A0 I also note that it took about a decade be= fore people felt comfortable using DNAMEs.

Dear $VENDOR. =C2=A0

I'm a customer who is considering deploying the BULK RR type in= to my zone, and I would like to know whether your systems support it.
=

Thank you,
$CUSTOMER.


That said.. there is still an issue with key distribution = for online signing which is required to make this work. =C2=A0 I see the ut= ility in BULK, but I'm persuaded that there needs to be more work befor= e it's deployable in an environment where *XFR is required.=C2=A0
=

--94eb2c1912c6aad5820554d8bd8f-- From nobody Fri Jul 21 16:47:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15764129AFF for ; Fri, 21 Jul 2017 16:47:30 -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, URIBL_BLOCKED=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 vaZonfrQd-YZ for ; Fri, 21 Jul 2017 16:47:28 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B31D126B7F for ; Fri, 21 Jul 2017 16:47:28 -0700 (PDT) Received: from [192.168.0.16] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 577651BD15; Sat, 22 Jul 2017 01:47:26 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Sat, 22 Jul 2017 01:47:21 +0200 Message-ID: In-Reply-To: <20170720150031.GA22702@laperouse.bortzmeyer.org> References: <20170718094654.GA31988@jurassic> <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> <20170718125056.GA7982@jurassic> <20170720150031.GA22702@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 23:47:30 -0000 On 20 Jul 2017, at 17:00, Stephane Bortzmeyer wrote: > draft-ietf-dnsop-nsec-aggressiveuse is more aggressive (because it can > now synthetizes answers) so it seems to me the same reasons should > apply? That it is more aggressive, -and- that it relies on a feature of DNSSEC, suggests that we SHOULD be stricter here, and the only interpretation of ‘stricter’ I can imagine is requiring DNSSEC. However, I have advocated (offline) in the past for allowing unsigned NSEC to be used to deter PRSD attacks, allowing the resolver to reduce queries to the targeted auth by >90% - a win for both sides. It is a tricky balance. If somebody is under attack, that surely is the worst time for them to upload a DS, while enabling DNSSEC on their end (which would come with RRSIGs that validators then ignore) as a mitigation strategy that actually works, would be wonderful to have. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Jul 21 16:52:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FFE127599 for ; Fri, 21 Jul 2017 16:52:39 -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, URIBL_BLOCKED=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 0VfsLa9yWlom for ; Fri, 21 Jul 2017 16:52:38 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DAE120721 for ; Fri, 21 Jul 2017 16:52:37 -0700 (PDT) Received: from [192.168.0.16] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 9CB051BD15; Sat, 22 Jul 2017 01:52:36 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Sat, 22 Jul 2017 01:52:34 +0200 Message-ID: <253354DC-7B95-4474-8288-A50C33288968@powerdns.com> In-Reply-To: References: <20170720150809.qv6nbwsite7icu45@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 23:52:39 -0000 Hello George, On 21 Jul 2017, at 14:58, George Michaelson wrote: > I (for one) hang onto the .req file. Maybe thats naughty, but I do, so > in my case Warren routine is that the keypair is being reused, > because.. well.. because I like to. Software I consume I suspect (like > you) doesn't, and re-mints shiny new keys now with added keynomium, > but when I do it by hand? yes I reuse the .req file. As a data point, several Let’s Encrypt clients will reuse keys. Those that do not by default can often be configured to do so. The benefits of reusing the key should be obvious to anyone that also uses TLSA. If you think about it, a TLSA record is also a certificate, but your signer auto-renews it for you. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Jul 21 16:56:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35824129AFF for ; Fri, 21 Jul 2017 16:56:01 -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, URIBL_BLOCKED=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 aN5OZ9PftaHg for ; Fri, 21 Jul 2017 16:55:59 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8200129482 for ; Fri, 21 Jul 2017 16:55:59 -0700 (PDT) Received: from [192.168.0.16] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 770A71BD15; Sat, 22 Jul 2017 01:55:58 +0200 (CEST) From: "Peter van Dijk" To: "dnsop WG" Date: Sat, 22 Jul 2017 01:55:58 +0200 Message-ID: <1700A63D-A6D6-47B7-B098-ECFA481BD7A2@powerdns.com> In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> <6901EEC2-5F25-4F28-AB5D-0F164D5077A5@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 23:56:01 -0000 Tim, On 20 Jul 2017, at 14:09, tjw ietf wrote: > Another Data Point: > > One of the Apps Area ADs stopped by to tell the chairs that 1) they > like > the general idea; 2) their employer has a need for this *outside of > the PTR > space*; and 3) would be willing to shepherd the work through. Now, > they > also the first to admit that the Application people do the most abuse > to > DNS standards (hence the need for the attrleaf document). > > In fact, my employer, who is quite abusive in how they deploy CNAMEs > could > very easily work up a very legitimate use case for using BULK for > deploying > some of our larger zones. Add that to the fact that my employer > insists > on deploying DNS between multiple vendors - whether it is DNS software > or > managed DNS services. It would be very helpful if the mentioned AD, or your employer, could elaborate on these use cases. As it stands we (PowerDNS) do not see the point of BULK (even though we are capable of online signing and thus have it easier than some of the other name servers), but we could certainly be convinced otherwise. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Jul 21 16:59:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0241243F3 for ; Fri, 21 Jul 2017 16:59:03 -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, URIBL_BLOCKED=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 LHXLMnjq9bnU for ; Fri, 21 Jul 2017 16:59:01 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166B3126B7E for ; Fri, 21 Jul 2017 16:59:01 -0700 (PDT) Received: from [192.168.0.16] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id C24B61BD15; Sat, 22 Jul 2017 01:58:59 +0200 (CEST) From: "Peter van Dijk" To: "dnsop WG" Date: Sat, 22 Jul 2017 01:58:59 +0200 Message-ID: <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> In-Reply-To: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 23:59:04 -0000 Hello John, On 20 Jul 2017, at 3:17, Woodworth, John R wrote: > Although in practice the name would likely be shorter and potentially > include other customer attributes, > say acmewabbit-21f-5bff-fec3-ab9d.example.com > > 1. This shows the owner is example.com, customer acmewabbit > 2. Reverse lookups are helpful for tools (e.g. traceroute) > and logs. 1 and 2 could be covered with a wildcard PTR, as I think Tony Finch pointed out. > Forget for a moment about IPv6. This draft makes $GENERATE more > memory efficient, scales bigger, stays intact through AXFR's > and yes -it makes some nameservers (authoritative) work a bit more > as a trade-off. One could make $GENERATE more efficient without actually implementing the BULK RR, by taking your pattern matching logic and implementing it inside the name server. Of course, this makes generating the NSEC/NSEC3 chain much harder than it is with today’s $GENERATE implementations that actually generate all the names. A very interesting puzzle would be implementing BULK support, based on the pattern matching in the draft, -without- doing NSEC(3) white/black lies - i.e. generating the widest possible NSEC instead of the narrowest one. For NSEC3 I suspect this is not feasible. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Jul 21 21:06:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93DE12ECC0 for ; Fri, 21 Jul 2017 21:06:48 -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 (1536-bit key) header.d=iecc.com header.b=UntBDXtE; dkim=pass (1536-bit key) header.d=taugh.com header.b=faeF7K6k 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 R4cHzzd_iLWm for ; Fri, 21 Jul 2017 21:06:47 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD34D129ACD for ; Fri, 21 Jul 2017 21:06:46 -0700 (PDT) Received: (qmail 57810 invoked from network); 22 Jul 2017 04:06:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e1d0.5972cf55.k1707; bh=/Ztx7bAjMU3DDxL5+vQjN2T7tl3QCr4pObx+58J5t9k=; b=UntBDXtEigdpQV1D2TdSz6eo/ou6iIxYX1K50OnLrMG3rk/kwoFtt7mUL6MjKGa/iulnuVGXY0GMbuezNv2KJNKq96YbHK6p3dqlXH5LXF2OBjd8JLOtwd/pKphwvDQxcInVD9kJTONzrBJlxmkDidBtm9vu7k1g8C462MF7YR7jF/DljSYYep02piIugZBrtSAg3ytVvfpzLPpwCyUKjUmrgb+zGTsg5KWAOGdQOvRygPajufOOkdex5F8vu5Bj DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e1d0.5972cf55.k1707; bh=/Ztx7bAjMU3DDxL5+vQjN2T7tl3QCr4pObx+58J5t9k=; b=faeF7K6keHRI4ACkW/Yjs357MT9TGLJyM/4iCodJKX57VnVB+H18JK5YSYl5uMsJY+A7GdDkK/U3MbpR/SYj/ieKH+DOgFeZepk3+gnr1yicKnUBvYO+9OnrNWCu+BoX+btwaKPH8FHaqVETQw9R/els4MQ8LYPvmszZrMbyEjTuZBu8O53r9jjJMsz6XkswpPCoY9Hyp2AXR2msoMwBpR3PM5EmPZDJfKQsX5pK0buwFJ2Y5dt8QlRe3iDZr/I0 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 22 Jul 2017 04:06:44 -0000 Date: 22 Jul 2017 06:06:44 +0200 Message-ID: From: "John R Levine" To: "Matthew Pounsett" Cc: "dnsop" In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 04:06:48 -0000 On Fri, 21 Jul 2017, Matthew Pounsett wrote: > Dear $VENDOR. > > I'm a customer who is considering deploying the BULK RR type into my zone, > and I would like to know whether your systems support it. > > Thank you, > $CUSTOMER. Dear $CUSTOMER, Thank you for your question. Here at $VENDOR we take pride in our six-sigma state of the art customer focused service. We use industry standard Apache and BIND software on most of our systems, and nginx and NSD on the rest. Thank you for the opportunity to be of service, Sincerely, "Bob", $VENDOR associate customer specialist I think you overestimate how much a typical non-specialist DNS provider knows about their software. If you don't believe me, write to a few and ask whether they need DS or DNSKEY to make a secure delegation. > That said.. there is still an issue with key distribution for online > signing which is required to make this work. I see the utility in BULK, > but I'm persuaded that there needs to be more work before it's deployable > in an environment where *XFR is required. No kidding. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jul 21 21:49:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1E1129ACD for ; Fri, 21 Jul 2017 21:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 5Kl8405eTWm7 for ; Fri, 21 Jul 2017 21:49:35 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 830681274D2 for ; Fri, 21 Jul 2017 21:49:35 -0700 (PDT) Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6M4nYnj009704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Jul 2017 23:49:34 -0500 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M4nSr8063887; Fri, 21 Jul 2017 23:49:29 -0500 Received: from lxdnp32k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M4nSMO063884 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Fri, 21 Jul 2017 23:49:28 -0500 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M4nSTh036057; Fri, 21 Jul 2017 22:49:28 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M4nSxS036054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jul 2017 22:49:28 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Fri, 21 Jul 2017 23:49:28 -0500 From: "Woodworth, John R" To: "'John R Levine'" CC: "dnsop@ietf.org" , "paul@nohats.ca" , "Woodworth, John R" Thread-Topic: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJb7Y7AgADKXwCAAobawA== Date: Sat, 22 Jul 2017 04:49:27 +0000 Message-ID: References: <20170719215749.2241.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 04:49:37 -0000 > -----Original Message----- > From: John R Levine [mailto:johnl@taugh.com] > Hi John, Thanks again for your feedback. > > On Thu, 20 Jul 2017, Woodworth, John R wrote: > > Camp#2) Don't break DNS, even for a second > > Well, yeah, except that there's no such thing as breaking the > DNS for a second. If we look at the history of DNSSEC, we'd > break the DNS for somewhere between a decade and forever. > We have tried very hard for three decades to avoid breaking > backward compatibility, and it's hard to believe that this is > the reason to do it. > This is a very noble endeavor indeed, I both applaud and respect it. Having said that, just what level of significance would it take for us to bend in this respect? What type of feature, etc.? > > ...BULK absolutely requires online DNSSEC signing, > Unfortunately, I respectfully reject this as a statement of fact. There's even a provision (NPN) in the draft which offers a reasonable method designed specifically for offline signatures. While the NPN documentation is imperfect, we've still seen a lot of interest it, and with the help of the WG, we feel it could prove very useful. Thanks, John > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, > Trumansburg NY Please consider the environment before reading > this e-mail. https://jl.ly -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Fri Jul 21 22:07:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A8B12741D for ; Fri, 21 Jul 2017 22:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 laJTsJd-luaq for ; Fri, 21 Jul 2017 22:07:01 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 9B954126C2F for ; Fri, 21 Jul 2017 22:07:01 -0700 (PDT) Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6M56wBc042466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Jul 2017 23:06:58 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M56r7I037641; Sat, 22 Jul 2017 00:06:53 -0500 Received: from lxomp06u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M56r3b037638 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 00:06:53 -0500 Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M56qku019663; Sat, 22 Jul 2017 00:06:53 -0500 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M56qi3019660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 00:06:52 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 00:06:52 -0500 From: "Woodworth, John R" To: "'Tony Finch'" , John R Levine CC: "dnsop@ietf.org" , "paul@nohats.ca" , "Woodworth, John R" Thread-Topic: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJb7Y7AgADKXwCAAFQZAIACPvOQ Date: Sat, 22 Jul 2017 05:06:51 +0000 Message-ID: References: <20170719215749.2241.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 05:07:03 -0000 > From: Tony Finch [mailto:dot@dotat.at] > Hi Tony, Thanks for the feedback. > > John R Levine wrote: > > > > BULK absolutely requires online DNSSEC signing, > > This basically means that BULK is a master-only feature, which > implies that there's no need for BULK to work across zone > transfers, which implies the need to standardize it for > interop is almost nonexistent. > Although BULK does actually offer an offline DNSSEC signing solution, no such solution is required for unsigned zones which today is where all the implementations I am aware of live anyway. Thanks, John > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I > xn--zr8h punycode Lundy, Fastnet, Irish Sea: South or southwest > becoming cyclonic, 5 to 7, perhaps gale 8 later. Moderate or > rough, becoming rough or very rough later in Fastnet and west > Lundy. Rain or thundery showers. Good, occasionally poor. -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Fri Jul 21 22:13:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DFE129ACD for ; Fri, 21 Jul 2017 22:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 5GTWrCHD3wTu for ; Fri, 21 Jul 2017 22:13:23 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 CB7121294A2 for ; Fri, 21 Jul 2017 22:13:23 -0700 (PDT) Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6M5DG0b047729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Jul 2017 23:13:16 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M5DBJg050859; Sat, 22 Jul 2017 00:13:11 -0500 Received: from lxomp07u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M5DBhT050856 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 00:13:11 -0500 Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M5DBWD049216; Sat, 22 Jul 2017 00:13:11 -0500 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6M5DAZd049211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 00:13:10 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 00:13:10 -0500 From: "Woodworth, John R" To: "'Andrew Sullivan'" , "dnsop@ietf.org" CC: "Woodworth, John R" Thread-Topic: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJb7Y7AgADKXwCAAFQZAIAADQMAgAI2gIA= Date: Sat, 22 Jul 2017 05:13:10 +0000 Message-ID: References: <20170719215749.2241.qmail@ary.lan> <20170720142122.ncrkwi27ghdwj2sq@mx4.yitter.info> In-Reply-To: <20170720142122.ncrkwi27ghdwj2sq@mx4.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 05:13:25 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Andrew Sullivan > > On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote: > > This basically means that BULK is a master-only feature, which implies > > that there's no need for BULK to work across zone transfers, which > > implies the need to standardize it for interop is almost nonexistent. > > I don't think that follows. > > The DNS market is, like the mail market did some while ago, > undergoing a period of consolidation in which a fairly small number > of people have a very large number of dependent customers. > Unfortuantely, whereas mail is asynchronous, DNS is effectively > synchronous: if the provder has a bad day and you can't get an > answer the site is down. > This means that customers want to have multiple different vendors > as their master, and they want the secondaries of those sources to > offer as much as possible the same features, even when various DNS > Tricks are in use; and they want the downstreams to be using > standard protocols. The more we can make interoperate to support > that, the better off those users are. > Hi Andrew, Thanks for the feedback and support! Thanks, John > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Fri Jul 21 23:33:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF925126DEE for ; Fri, 21 Jul 2017 23:33:35 -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 (1536-bit key) header.d=iecc.com header.b=X5HZdT8W; dkim=pass (1536-bit key) header.d=taugh.com header.b=Ce71v+ci 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 ggBtV1DJOHRg for ; Fri, 21 Jul 2017 23:33:34 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E902126C22 for ; Fri, 21 Jul 2017 23:33:34 -0700 (PDT) Received: (qmail 69445 invoked from network); 22 Jul 2017 06:33:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10f43.5972f1bc.k1707; bh=lFeO28oQFaZ+RpnOJ+rMnwLdCnrYzeem70jCJSIqnc0=; b=X5HZdT8WZfuWcYBfDtzAM8qc1lGlyXT4rh2pxPMX+npo0NoiVVtpBfsO1ydzK8dIB84gkq18DZcl2UZtFZI9G4WQxLCpKkwxOA2s1NbRdMpkT6dQ72+Ouquad/uFuVlCJYOEsZ7p4n9q/PwdMIFDh6ib8CZXdSCLhucbof2k9tlig9LYmluvbBGHVLzsXr2Si/cbhirfrxzyPwI07gkFBCP268CdRmKOaxjdMHuPbBMwZ4HTxY87gtCxiE76radQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10f43.5972f1bc.k1707; bh=lFeO28oQFaZ+RpnOJ+rMnwLdCnrYzeem70jCJSIqnc0=; b=Ce71v+ciZwq6BZJZYUgJhVc6oOge7H72L7GTcZyvZT0wHrxtibX8FaB9qQE8zGlBBMbwQf/5gNbzxsVXF+AExnSygWahTy699ixsEWLP+eTPXdwk85OLLVSfqO0TFNLqWPBhDWFf6kL7yPbs8RoZUjzM721/Lq8w3lkkMKMykcldXcIoxLynwftuxxC5L/XURw6WIQS7Q8XqIusocWYD9tTaxAkgJcv1e3uN8bFrhTU5N2oDihATCHyZNVn1zjZL Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 22 Jul 2017 06:33:32 -0000 Date: 22 Jul 2017 08:33:30 +0200 Message-ID: From: "John R Levine" To: "Woodworth, John R" Cc: "dnsop@ietf.org" In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 06:33:36 -0000 > Having said that, just what level of significance would it take > for us to bend in this respect? What type of feature, etc.? For DNSSEC the issue was the fundamental integrity of the DNS. I think it's fair to say that this isn't that. >> ...BULK absolutely requires online DNSSEC signing, > Unfortunately, I respectfully reject this as a statement of fact. > There's even a provision (NPN) ... ... which only works if you upgrade every validating resolver. If you get to do that, you might as well just send the signed BULK record, the NSEC and RRSIG that show there's nothing at the name, and let the resolver figure it out. Given how slowly people update their client DNS libraries, NPN would be a recipe for decades of DNS flakiness, as some resolvers accept the generated records and some don't. As I said a few messages ago, this really needs to wait until we figure out how to signal DNS versioning, and if we don't want to wait for every resolver in the world to be updated, how to distribute signing keys along with AXFR/IXFR to allow online signing to work portably. I'm not opposed to BULK because I don't think it's useful -- there are plenty of RRs that are useless but harmless. But I really don't want to break the DNS, particularly for something that is at most arguably useful. R's, John PS: I hope it's self evident why "it doesn't matter because hardly anyone uses DNSSEC" is not a persuasive argument. From nobody Sat Jul 22 06:19:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D31129AD1 for ; Sat, 22 Jul 2017 06:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 qUrU0exnUSjo for ; Sat, 22 Jul 2017 06:19:36 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 936DE127058 for ; Sat, 22 Jul 2017 06:19:36 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id t2so37814447qkc.1 for ; Sat, 22 Jul 2017 06:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XPsAUAjd+ZmE3+vZ5sDB2XhapYfbKeVj2zPP3e8HdDk=; b=D2lgNgAngpvhcZjWYBBzPNmaH5R7vqHMakFcq4lxyiZ3jhYnY6juCo798juREmnEvM fmYON3LcnBkiBTm5BFlFOtfCJNqz9GNyCuZwcnfhgKL9QpeJzkujgKs6B7KwTmvyU/j9 SKlmyM5Bh8xVTqUczkocQ2PClbjSi6cTJjyCxCvqeOajYrp3npJ/KdW3qPxxa3hHAM+u k6hsNYEu5MaBBFUCRJMV7R3ZplQC9NtSCiMxZXyx0SQF9x9wCWXoyRhmuj7gXhKgUimQ 2V5IIr9J2eGI3ysBPAICFMffiPWxDXTb3YufwL2tFSZPL2oukdvHdxmzhotRjK24bfbp geUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XPsAUAjd+ZmE3+vZ5sDB2XhapYfbKeVj2zPP3e8HdDk=; b=bCFDtU66tPMs6k8c3I4gJPI/Ls0ijO9kJB+jwhHVR4HzrLMJFc8puN45oKWR74AzAQ JHiOg6PWFvlp4n0gyQ5fTDqKsiyjJXCpwVcYIZbDI4G/OHJXMhefn8KG4pdHN7afZGJ0 FDv8WzBVbll5uFBR/E1RBYmqY740C8h04+3g0O6rVHAlw7/EVcJ23BMaC4NQ3unsT0dD +2FodXFbdhc0mmr/8xSnFyQnV6ZgII1oqoKp2lVX9RBide2VUDjyaCjxzxgZYhFYPZfq ax6L0TsSEJsBzzR4Jg4kTgl8WIK9TG0VzK1NTRuL4n63uHAFr1825EFiJRnSMa9Nimyl 13FA== X-Gm-Message-State: AIVw111xuDk1sEg+5s6lHguGYq31c3gYafK2xdoftaHvdUFXvdnKT80o 4irMtMZ/44pwOXOyq05R6kOr8qIU9q8M X-Received: by 10.55.217.215 with SMTP id q84mr1528034qkl.186.1500729575680; Sat, 22 Jul 2017 06:19:35 -0700 (PDT) MIME-Version: 1.0 References: <1686897744.6421.1500568893614.JavaMail.zimbra@nic.cz> In-Reply-To: <1686897744.6421.1500568893614.JavaMail.zimbra@nic.cz> From: Lanlan Pan Date: Sat, 22 Jul 2017 13:19:25 +0000 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: dnsop Content-Type: multipart/alternative; boundary="001a1147a3004330090554e7d5e7" Archived-At: Subject: Re: [DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 13:19:39 -0000 --001a1147a3004330090554e7d5e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Avoid UDP fragmentations (big response packet) on protocol level could reduce DDoS defense cost. Similar to the DNS ANY qtype deprecation. Ond=C5=99ej Sur=C3=BD =E4=BA=8E2017=E5=B9=B47=E6=9C=882= 1=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8A=E5=8D=8812:41=E5=86=99=E9=81=93=EF= =BC=9A > multi-qtypes Security Considerations says: > > The method documented here does not change any of the security > > properties of the DNS protocol itself. > > I don't think this statement is true. Why? > > a) DNS DDoS threats are real and there was a shift towards minimizing > answers. This goes in the reverse direction. But you address this > in both security considerations. > > multiple-responses Security Considerations says: > > > > Additional records will make DNS responses even larger than they are > > currently, leading to larger records that can be used in DNS > > reflection attacks. One could mitigate this by only serving > > responses to EXTRA requests over TCP or when using Cookies [RFC5395]= , > > although there is no easy way to signal this to a client other than > > through the use of the truncate bit. > > multi-qtypes Security Considerations says: > > It should however be noted that this method does increase the > > potential amplification factor when the DNS protocol is used as a > > vector for a denial of service attack. > > > b) UDP fragmentations - it strongly increases the risk of UDP fragmentati= on > which is strongly discouraged (SHOULD NOT) in BCP 145. > > also multiple-responses Security Considerations says: > > > A malicious authoritative server could include a large number of > > extra records (and associated DNSSEC information) and attempt to DoS > > the recursive by making it do lots of DNSSEC validation. However, > > this is not considered a realistic threat; CPU for validation is > > cheap compared to bandwidth. This can be mitigated by allowing the > > recursive resolver to ignore Additional records whenever it consider= s > > itself under attack or its CPU resources are otherwise over- > > committed. > > It should be noted, that ECC validation is more CPU intensive than RSA, a= s > as such I find "CPU for validation is cheap compared to bandwidth" quite > bold claim that should come with some data. > > Cheers, > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a1147a3004330090554e7d5e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Avoid UDP fragmentations (big response packet) o= n protocol level could reduce DDoS defense cost.

Similar to the DNS = ANY qtype deprecation.

O= nd=C5=99ej Sur=C3=BD <ondrej.sury@= nic.cz>=E4=BA=8E2017=E5=B9=B47=E6=9C=8821=E6=97=A5=E5=91=A8=E4=BA=94= =E4=B8=8A=E5=8D=8812:41=E5=86=99=E9=81=93=EF=BC=9A
multi-qtypes Security Considerations says:
>=C2=A0 =C2=A0 The method documented here does not change any of the sec= urity
>=C2=A0 =C2=A0 properties of the DNS protocol itself.

I don't think this statement is true.=C2=A0 Why?

a) DNS DDoS threats are real and there was a shift towards minimizing
=C2=A0 =C2=A0answers.=C2=A0 This goes in the reverse direction.=C2=A0 But y= ou address this
=C2=A0 =C2=A0in both security considerations.

multiple-responses Security Considerations says:
>
>=C2=A0 =C2=A0 Additional records will make DNS responses even larger th= an they are
>=C2=A0 =C2=A0 currently, leading to larger records that can be used in = DNS
>=C2=A0 =C2=A0 reflection attacks.=C2=A0 One could mitigate this by only= serving
>=C2=A0 =C2=A0 responses to EXTRA requests over TCP or when using Cookie= s [RFC5395],
>=C2=A0 =C2=A0 although there is no easy way to signal this to a client = other than
>=C2=A0 =C2=A0 through the use of the truncate bit.

multi-qtypes Security Considerations says:
>=C2=A0 =C2=A0 It should however be noted that this method does increase= the
>=C2=A0 =C2=A0 potential amplification factor when the DNS protocol is u= sed as a
>=C2=A0 =C2=A0 vector for a denial of service attack.


b) UDP fragmentations - it strongly increases the risk of UDP fragmentation=
=C2=A0 =C2=A0which is strongly discouraged (SHOULD NOT) in BCP 145.

also multiple-responses Security Considerations says:

>=C2=A0 =C2=A0 A malicious authoritative server could include a large nu= mber of
>=C2=A0 =C2=A0 extra records (and associated DNSSEC information) and att= empt to DoS
>=C2=A0 =C2=A0 the recursive by making it do lots of DNSSEC validation.= =C2=A0 However,
>=C2=A0 =C2=A0 this is not considered a realistic threat; CPU for valida= tion is
>=C2=A0 =C2=A0 cheap compared to bandwidth.=C2=A0 This can be mitigated = by allowing the
>=C2=A0 =C2=A0 recursive resolver to ignore Additional records whenever = it considers
>=C2=A0 =C2=A0 itself under attack or its CPU resources are otherwise ov= er-
>=C2=A0 =C2=A0 committed.

It should be noted, that ECC validation is more CPU intensive than RSA, as<= br> as such I find "CPU for validation is cheap compared to bandwidth"= ; quite
bold claim that should come with some data.

Cheers,
--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Technical Fellow
=C2=A0--------------------------------------------
=C2=A0CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e C= Z.NIC
=C2=A0Milesovska 5, 130 00 Praha 3, Czech Republic
=C2=A0mailto:ondrej= .sury@nic.cz=C2=A0 =C2=A0 https://nic.cz/
=C2=A0--------------------------------------------

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--001a1147a3004330090554e7d5e7-- From nobody Sat Jul 22 08:54:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D78131E0C for ; Sat, 22 Jul 2017 08:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VUedKKXjWvjP for ; Sat, 22 Jul 2017 08:54:01 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E21131E09 for ; Sat, 22 Jul 2017 08:54:01 -0700 (PDT) Received: (qmail 35426 invoked from network); 22 Jul 2017 15:54:00 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jul 2017 15:54:00 -0000 Date: 22 Jul 2017 15:53:38 -0000 Message-ID: <20170722155338.9829.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [DNSOP] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 15:54:03 -0000 Speaking of nsec-aggressiveuse, while staring out the window of the train this morning it occurred to me that BULK breaks NXDOMAIN synthesis, too, both the NSEC kind and the RFC 8020 kind. The RFC 8020 problem is familiar, since rbldnsd, a stunt DNS server that does sort of the same thing BULK does, taking CIDR ranges and turning them on the fly into DNSBL entries, gets NXDOMAIN wrong,a too. It's been on my list of things to fix for ages. (It doesn't even try to do DNSSEC.) The RFC 8020 fix is tedious but I think straightforward -- identify every interior node in the zone that might have a BULK match below it and return NODATA rather than NXDOMAIN. Since the set of interior nodes can be gargantuan this means that you have to do a tail match as well as an exact match on BULK patterns on every query. The aggressive NSEC problem is much uglier. If the server does online signing, it can return RFC 4470 white lies for names within a span which might have BULK matches. It's a QoI issue whether a server does that for every NXDOMAIN in a zone that contains a BULK record, or tries to figure out which spans could contain a match and which don't. For offline signed zones, we're back to putting hacks in the recursive resolvers. Today's hack is a new flag (perhaps an EDNS0 one) that says pretend this was a white lie, i.e., don't use this result to synthsize NXDOMAINs. While all this is nominally possible, I remain unconvinced that BULK is worth all of this violence to the DNS. By the way, is this the first time this issue has come up with BULK? I don't see anything about it in the draft, and I don't recall it being discussed before. If we're still finding new incompatibilities between BULK and the DNS, how confident are we that there aren't more we haven't found yet? R's, John From nobody Sat Jul 22 11:06:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60A0131C15 for ; Sat, 22 Jul 2017 11:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 d4kUDjnxRDiP for ; Sat, 22 Jul 2017 11:06:03 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47DE131714 for ; Sat, 22 Jul 2017 11:06:03 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 4F39C2421527; Sat, 22 Jul 2017 18:06:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: Date: Sat, 22 Jul 2017 19:05:58 +0100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> To: "Woodworth, John R" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 18:06:05 -0000 > On 20 Jul 2017, at 02:17, Woodworth, John R = wrote: >=20 > this is just a next-gen $GENERATE Indeed. We all get that. However $GENERATE is a BIND-ism, like views. = It=E2=80=99s not part of the DNS protocol. I=E2=80=99m not yet convinced = $GENERATE (albeit with a BULK makeover) needs to be. The use case for BULK still hasn=E2=80=99t been made IMO. From nobody Sat Jul 22 11:59:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D697B1318A8 for ; Sat, 22 Jul 2017 11:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Jee71svRrVRv for ; Sat, 22 Jul 2017 11:59:37 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D497212700F for ; Sat, 22 Jul 2017 11:59:36 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 0A6CC2421527; Sat, 22 Jul 2017 18:59:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <20170720152559.GD22702@laperouse.bortzmeyer.org> Date: Sat, 22 Jul 2017 19:59:32 +0100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 18:59:38 -0000 > On 20 Jul 2017, at 16:25, Stephane Bortzmeyer = wrote: >=20 > And DNSSEC is not the only case where we introduced RRtypes where you > have to check your slaves to be sure they support it. There was also > DNAME. >=20 > That's why I don't share the fears about BULK BULK would be an RRtype which *by design* prevents another part of the = DNS from working. That=E2=80=99s just wrong. Behaviour like that might = be acceptable for a non-trivial protocol change like a new header bit or = EDNS option (say). But a new RRtype? Really? BTW, if there are cases where an ISP=E2=80=99s customers care about = reverse DNS for their IPv6 addresses, what=E2=80=99s stopping those = customer devices using dynamic update to provision their names or have = the DHCP server do that for them? Why can=E2=80=99t the ISP's = provisioning systems and tools spit out PTR records for the IP addresses = which need this secret sauce? It=E2=80=99s still not clear to me what problem is actually being fixed = by BULK and why no other provisioning mechanism is applicable. If the WG is to adopt this draft, I think there first has to be a clear = problem statement backed by use cases. [Prettier log files doesn=E2=80=99t= do it for me. YMMV.] That way, the WG will be able to decide how well = the final version of the document addresses these requirement if/when it = gets to WGLC. Apologies for introducing a meaningful and relevant Subject: header. From nobody Sat Jul 22 14:23:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBBC12711E for ; Sat, 22 Jul 2017 14:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 DVA8ID449TzG for ; Sat, 22 Jul 2017 14:23:33 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 C30F312009C for ; Sat, 22 Jul 2017 14:23:33 -0700 (PDT) Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MLNUEC061228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 15:23:30 -0600 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNP5m033903; Sat, 22 Jul 2017 15:23:25 -0600 Received: from lxomp07u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNP6L033886 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 15:23:25 -0600 Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNPND053957; Sat, 22 Jul 2017 16:23:25 -0500 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNPJS053954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 16:23:25 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 16:23:25 -0500 From: "Woodworth, John R" To: "'John R Levine'" , Tony Finch CC: "dnsop@ietf.org" , "Woodworth, John R" Thread-Topic: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJb7Y7AgADKXwCAAFQZAIAAD+qAgANDleA= Date: Sat, 22 Jul 2017 21:23:24 +0000 Message-ID: References: <20170719215749.2241.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 21:23:35 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of John R Levine > > On Thu, 20 Jul 2017, Tony Finch wrote: > > John R Levine wrote: > >> > >> BULK absolutely requires online DNSSEC signing, > > > > This basically means that BULK is a master-only feature, which implies > > that there's no need for BULK to work across zone transfers, which > > implies the need to standardize it for interop is almost nonexistent. > > I can't speak for the draft's authors, but in previous correspondence > I've gotten the impression that they believe that slaves that serve > BULK can stay in sync via AXFR and IXFR. Perhaps they can clarify > how this is supposed to work. > Hi John, Thanks again for your feedback. First, let me state *I LOVE DNSSEC* but this was definitely not always the case. In fact it took nearly a decade for me to go from: "Why are they solving for a nuclear meltdown of SSl/TLS/PKI?" to: "Why isn't this everywhere already?!" Wherever I was on this path, DNSSEC's eventual ubiquitousness was always assumed. However, even now while my group is actively promoting DNSSEC adoption, from where I sit, I see roughly 1/10 of 1% authoritative zones with DNSSEC enabled and believe me, most of those 0.1% were by mandate and not choice. I write this not as discouragement, reason to dismiss or to point out failure, as this is *my* community and *my* responsibility to see it succeed and thrive. Rather, this is to point out opportunity where it can be seen. Dean (co-author) and I believe the success of DNSSEC is vital to the future of the Internet and hope to play active roles in its future. However, as stated its low adoption rate offers an opportunity to make changes before critical mass makes it much more complicated. I see no reason to delay technology like NSEC5 and BULK out of fear it will slow the adoption of DNSSEC but rather see this as an opportunity to move forward in parallel and meet this new landscape we are all building. As this progress is made, I would like to propose a phased-in approach for BULK which can be added to the draft a la IPv6. Phase-1) BULK only assumed to work on *own* authoritative nameservers with insecure zones Phase-2) BULK only assumed to work with *some* external backup nameservers with insecure zones Phase-3) BULK only assumed to work with *most* external backup nameservers with insecure zones Phase-4) BULK only assumed to work on with *some* validating nameservers Phase-5) BULK works on all authoritative nameservers and validating nameservers Thanks, John > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > https://jl.ly -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Sat Jul 22 14:31:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6D6129A9F for ; Sat, 22 Jul 2017 14:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 K3lcGj5DVfwc for ; Sat, 22 Jul 2017 14:30:58 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 749F512009C for ; Sat, 22 Jul 2017 14:30:58 -0700 (PDT) Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MLUvxg043307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 16:30:57 -0500 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLUpPG011278; Sat, 22 Jul 2017 15:30:51 -0600 Received: from lxomp06u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLUpef011271 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 15:30:51 -0600 Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLUpvJ004482; Sat, 22 Jul 2017 16:30:51 -0500 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLUp4D004479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 16:30:51 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 16:30:51 -0500 From: "Woodworth, John R" To: "'Stephane Bortzmeyer'" , "dnsop@ietf.org" CC: "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJdKUGAgAM4cJA= Date: Sat, 22 Jul 2017 21:30:50 +0000 Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> <20170720151325.GB22702@laperouse.bortzmeyer.org> In-Reply-To: <20170720151325.GB22702@laperouse.bortzmeyer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 21:30:59 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBETlNPUCBbbWFpbHRvOmRuc29w LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGFuZSBCb3J0em1leWVyDQo+DQoN CkhpIFN0w6lwaGFuZSwNCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIGNvbW1lbnRzIGFuZCBlbmNv dXJhZ2VtZW50Lg0KDQo+DQo+ID4gVGhlIEROU09QIFdHIGhhcyBwbGFjZWQgZHJhZnQtd29vZHdv cnRoLWJ1bGstcnIgaW4gc3RhdGUgQ2FuZGlkYXRlIGZvcg0KPiA+IFdHIEFkb3B0aW9uIChlbnRl cmVkIGJ5IFRpbSBXaWNpbnNraSkNCj4gPg0KPiA+IFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUg YXQNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13b29kd29ydGgt YnVsay1yci8NCj4NCj4gSSd2ZSByZWFkIGl0IGFuZCwgd2hpbGUgSSdtIG5vdCBjb252aW5jZWQg aXQgY2FuIGJlIGltcGxlbWVudGVkDQo+IHByb3Blcmx5IChJIHdvdWxkIGxpa2UgdG8gc2VlIHJ1 bm5pbmcgY29kZSksDQo+DQoNCldlIGFyZSB3b3JraW5nIG9uIHRoaXMgYXQgdGhlIG1vbWVudC4N Cg0KPg0KPiBJIHRoaW5rIHRoZXJlIGlzIGEgY2xlYXIgZGVtYW5kIGZvciB0aGF0IGFuZCB0aGF0 IHRoZSBzb2x1dGlvbg0KPiBpcyByZWFzb25hYmxlLiBJIHRoZXJlZm9yZSBzdXBwb3J0IGl0cyBh ZG9wdGlvbi4gKE9mIGNvdXJzZSwNCj4gYXMgYWx3YXlzLCBpdCBkb2VzIG5vdCBtZWFuIEkgd2ls bCBzdXBwb3J0IHRoZSByZXN1bHQgYXQgdGhlIGVuZC4pDQo+DQoNClRoYW5rcy4NCg0KPg0KPiBJ J20gc3RpbGwgaGVzaXRhbnQgd2l0aCB0aGUgTlBOIGZlYXR1cmUuDQo+DQoNClVuZGVyc3Rvb2Qu DQoNCj4NCj4gSSB3b3VsZCBsaWtlIHRoZSBkcmFmdCB0byBiZSBtb2RpZmllZCB0byBtYWtlIGNs ZWFyZXIgdGhhdCBpdA0KPiBpcyBub24tbWFuZGF0b3J5IHRvIHN1cHBvcnQgQlVMSy4gRm9yIGlu c3RhbmNlLCBzZXRjaW9uIDMncw0KPiAiV2hlbiBhbiBhdXRob3JpdGF0aXZlIG5hbWVzZXJ2ZXIg cmVjZWl2ZXMgYSBxdWVyeSBmb3Igd2hpY2gNCj4gaXQgZG9lcyBub3QgaGF2ZSBhIG1hdGNoaW5n IG5hbWUgb3IgYSBjb3ZlcmluZyB3aWxkY2FyZCwgaXQNCj4gTVVTVCB0aGVuIGxvb2sgZm9yIEJV TEsgUlJzIg0KPiBzaG91bGQgYmUgcmVwbGFjZWQgYnkgIldoZW4gYSAqQlVMSy1hd2FyZSogYXV0 aG9yaXRhdGl2ZQ0KPiBuYW1lc2VydmVyIHJlY2VpdmVzIGEgcXVlcnkgZm9yIHdoaWNoIGl0IGRv ZXMgbm90IGhhdmUgYQ0KPiBtYXRjaGluZyBuYW1lIG9yIGEgY292ZXJpbmcgd2lsZGNhcmQsIOKA piINCj4NCj4gU2VjdGlvbiAzLjIuMyAibG9uZ2VyIHZhbHVlcyBNVVNUIGJlIHRydW5jYXRlZCB0 byB0aGUgd2lkdGgiDQo+IExlZnQtdHJ1bmNhdGVkIG9yIHJpZ2h0LXRydW5jYXRlZD8NCj4NCg0K SSB3b3VsZCBsaWtlIHRvIGhhdmUgYSBkaXNjdXNzaW9uIHdpdGggeW91IHNvbWV0aW1lIGFib3V0 IHRoaXMuDQoNCg0KVGhhbmtzLA0KSm9obg0KDQotLSBUSEVTRSBBUkUgVEhFIERST0lEUyBUTyBX SE9NIEkgUkVGRVI6DQpUaGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHByb3BlcnR5IG9mIENlbnR1 cnlMaW5rIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkg cHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNl bmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgY29tbXVu aWNhdGlvbiBhbmQgYW55IGF0dGFjaG1lbnRzLg0K From nobody Sat Jul 22 14:40:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F63131B39 for ; Sat, 22 Jul 2017 14:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 xoOCrWx49eoP for ; Sat, 22 Jul 2017 14:40:16 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 3CD86131B5E for ; Sat, 22 Jul 2017 14:40:16 -0700 (PDT) Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MLeE4L011965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 15:40:15 -0600 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLe9nc033460; Sat, 22 Jul 2017 15:40:09 -0600 Received: from lxdnp32k.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLe9HM033453 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 15:40:09 -0600 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLe9CY063354; Sat, 22 Jul 2017 15:40:09 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLe9rx063347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 15:40:09 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 16:40:09 -0500 From: "Woodworth, John R" To: "'Matthew Pounsett'" , John R Levine CC: dnsop , Paul Wouters , "Woodworth, John R" Thread-Topic: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJdKxeAgAAHwwCAAcu9AIABY6Bw Date: Sat, 22 Jul 2017 21:40:08 +0000 Message-ID: References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: multipart/alternative; boundary="_000_A05B583C828C614EBAD1DA920D92866BD0824617PODCWMBXEX501ct_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 21:40:18 -0000 --_000_A05B583C828C614EBAD1DA920D92866BD0824617PODCWMBXEX501ct_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBETlNPUCBbbWFpbHRvOmRuc29wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNYXR0aGV3IFBvdW5zZXR0DQo+DQo+ID4gT24gMjAgSnVseSAyMDE3IGF0IDE3OjUzLCBKb2hu IFIgTGV2aW5lIDxqb2hubEB0YXVnaC5jb20+IHdyb3RlOg0KPiA+IFRoYXQncyB3aHkgSSBkb24n dCBzaGFyZSB0aGUgZmVhcnMgYWJvdXQgQlVMSzogeW91IGNhbm5vdCBlYXNpbHkNCj4gPiBkZXBs b3kgYSBuZXcgZmVhdHVyZSB0aGF0IHdpbGwgcmVxdWlyZSBhIGNoYW5nZSBpbiB0aGUgcmVzb2x2 ZXJzLA0KPiA+IGJlY2F1c2UgeW91IGRvbid0IGtub3cgYWxsIHRoZSByZXNvbHZlcnMsIGFuZCBj YW5ub3QgY2hhbmdlIHRoZW0gZXZlbg0KPiA+IGlmIHlvdSBrbm93IHRoZXkgYXJlIHRvbyBvbGQu IEJ1dCB5b3VyIHNlY29uZGFyaWVzIGFyZSBvbmx5IGEgc21hbGwNCj4gPiBzZXQgb2YgY2FyZWZ1 bGx5IGNob3NlbiBzZXJ2ZXJzLCBhbmQgeW91IGhhdmUgeW91ciBzYXkuDQo+DQo+IEkgaGVhciBv dGhlcndpc2UgZnJvbSBwZW9wbGUgd2hvIHJ1biBiaWcgRE5TIGZhcm1zLiAgSXQncyBjb21tb24g dG8NCj4gdXNlIG11bHRpcGxlIHNlY29uZGFyeSBwcm92aWRlcnMsIGFuZCBpdCdzIGhhcmQgdG8g dGVsbCB3aG8ncyBydW5uaW5nDQo+IHdoYXQgc2VydmVyIHNvZnR3YXJlLiAgSSBhbHNvIG5vdGUg dGhhdCBpdCB0b29rIGFib3V0IGEgZGVjYWRlIGJlZm9yZQ0KPiBwZW9wbGUgZmVsdCBjb21mb3J0 YWJsZSB1c2luZyBETkFNRXMuDQo+DQoNCkhpIE1hdHRoZXcsDQoNClRoYW5rcyBmb3IgeW91ciBj b21tZW50cy4NCg0KSSBoZWFyIGFuZCB1bmRlcnN0YW5kIHlvdXIgY29uY2VybnMuICBXZSBoYXZl IHNpbWlsYXIgY29uY2VybnMgYnV0DQoqSSogZmVlbCB3ZSBjb3VsZCBvZmZlciBhIHBoYXNlZC1p biBhcHByb2FjaCB0byBzZXQgZXZlcnlvbmUncw0KZXhwZWN0YXRpb25zIGFwcHJvcHJpYXRlbHku ICBJZiBvbmUgY2hvb3NlcyB0byBzdGVwIGFoZWFkIG9mIHRoZSBwaGFzZQ0KYXQgbGVhc3QgdGhl eSdkIGhhdmUgYW4gaWRlYSB3aGF0IHRyb3VibGVzIGF3YWl0IHRoZW0uDQoNCj4NCj4gRGVhciAk VkVORE9SLg0KPg0KPiBJJ20gYSBjdXN0b21lciB3aG8gaXMgY29uc2lkZXJpbmcgZGVwbG95aW5n IHRoZSBCVUxLIFJSIHR5cGUgaW50byBteQ0KPiB6b25lLCBhbmQgSSB3b3VsZCBsaWtlIHRvIGtu b3cgd2hldGhlciB5b3VyIHN5c3RlbXMgc3VwcG9ydCBpdC4NCj4NCj4gVGhhbmsgeW91LA0KPiAk Q1VTVE9NRVIuDQo+DQo+DQo+IFRoYXQgc2FpZC4uIHRoZXJlIGlzIHN0aWxsIGFuIGlzc3VlIHdp dGgga2V5IGRpc3RyaWJ1dGlvbiBmb3Igb25saW5lDQo+IHNpZ25pbmcgd2hpY2ggaXMgcmVxdWly ZWQgdG8gbWFrZSB0aGlzIHdvcmsuICAgSSBzZWUgdGhlIHV0aWxpdHkgaW4NCj4gQlVMSywgYnV0 IEknbSBwZXJzdWFkZWQgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBtb3JlIHdvcmsgYmVmb3JlIGl0 J3MNCj4gZGVwbG95YWJsZSBpbiBhbiBlbnZpcm9ubWVudCB3aGVyZSAqWEZSIGlzIHJlcXVpcmVk Lg0KPg0KDQpPbmxpbmUgc2lnbmluZyBpbiB0aGlzIGVudmlyb25tZW50IHdpbGwgbm90IGJlIHBv c3NpYmxlIHVudGlsIHRoaXMNCmlzIHNvbHZlZCBidXQgSSBiZWxpZXZlIHRoZSBwaGFzZWQgaW4g YXBwcm9hY2ggd291bGQgZ2l2ZSB1cyB0aGUgdGltZQ0KdG8gc29sdmUgZm9yIGl0IHdpdGhvdXQg ZGVsYXlpbmcgaW5zZWN1cmUgZGVwbG95bWVudCAocGhhc2UxKS4NCg0KDQpUaGFua3MsDQpKb2hu DQo+DQotLSBUSEVTRSBBUkUgVEhFIERST0lEUyBUTyBXSE9NIEkgUkVGRVI6DQpUaGlzIGNvbW11 bmljYXRpb24gaXMgdGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBv ZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5k IGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55IGF0dGFjaG1l bnRzLg0K --_000_A05B583C828C614EBAD1DA920D92866BD0824617PODCWMBXEX501ct_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmltDQoJe21zby1zdHlsZS1uYW1lOmlt O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IEZyb206IEROU09QIFttYWlsdG86 ZG5zb3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hdHRoZXcgUG91bnNldHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZndDsgJmd0OyBPbiAyMCBKdWx5IDIwMTcgYXQgMTc6NTMsIEpvaG4gUiBMZXZpbmUg Jmx0O2pvaG5sQHRhdWdoLmNvbSZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZndDsgJmd0OyBUaGF0J3Mgd2h5IEkgZG9uJ3Qgc2hhcmUgdGhlIGZlYXJzIGFib3V0IEJV TEs6IHlvdSBjYW5ub3QgZWFzaWx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsg Jmd0OyBkZXBsb3kgYSBuZXcgZmVhdHVyZSB0aGF0IHdpbGwgcmVxdWlyZSBhIGNoYW5nZSBpbiB0 aGUgcmVzb2x2ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7ICZndDsgYmVj YXVzZSB5b3UgZG9uJ3Qga25vdyBhbGwgdGhlIHJlc29sdmVycywgYW5kIGNhbm5vdCBjaGFuZ2Ug dGhlbSBldmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgJmd0OyBpZiB5b3Ug a25vdyB0aGV5IGFyZSB0b28gb2xkLiBCdXQgeW91ciBzZWNvbmRhcmllcyBhcmUgb25seSBhIHNt YWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgJmd0OyBzZXQgb2YgY2FyZWZ1 bGx5IGNob3NlbiBzZXJ2ZXJzLCBhbmQgeW91IGhhdmUgeW91ciBzYXkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7 IEkgaGVhciBvdGhlcndpc2UgZnJvbSBwZW9wbGUgd2hvIHJ1biBiaWcgRE5TIGZhcm1zLiZuYnNw OyBJdCdzIGNvbW1vbiB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IHVzZSBt dWx0aXBsZSBzZWNvbmRhcnkgcHJvdmlkZXJzLCBhbmQgaXQncyBoYXJkIHRvIHRlbGwgd2hvJ3Mg cnVubmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IHdoYXQgc2VydmVyIHNv ZnR3YXJlLiZuYnNwOyBJIGFsc28gbm90ZSB0aGF0IGl0IHRvb2sgYWJvdXQgYSBkZWNhZGUgYmVm b3JlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgcGVvcGxlIGZlbHQgY29tZm9y dGFibGUgdXNpbmcgRE5BTUVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkhpIE1hdHRoZXcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIGhlYXIgYW5kIHVuZGVyc3RhbmQgeW91ciBjb25jZXJucy4mbmJzcDsgV2Ug aGF2ZSBzaW1pbGFyIGNvbmNlcm5zIGJ1dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4q SSogZmVlbCB3ZSBjb3VsZCBvZmZlciBhIHBoYXNlZC1pbiBhcHByb2FjaCB0byBzZXQgZXZlcnlv bmUnczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5leHBlY3RhdGlvbnMgYXBwcm9wcmlh dGVseS4mbmJzcDsgSWYgb25lIGNob29zZXMgdG8gc3RlcCBhaGVhZCBvZiB0aGUgcGhhc2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXQgbGVhc3QgdGhleSdkIGhhdmUgYW4gaWRlYSB3 aGF0IHRyb3VibGVzIGF3YWl0IHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgRGVhciAkVkVORE9SLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m Z3Q7IEknbSBhIGN1c3RvbWVyIHdobyBpcyBjb25zaWRlcmluZyBkZXBsb3lpbmcgdGhlIEJVTEsg UlIgdHlwZSBpbnRvIG15PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgem9uZSwg YW5kIEkgd291bGQgbGlrZSB0byBrbm93IHdoZXRoZXIgeW91ciBzeXN0ZW1zIHN1cHBvcnQgaXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mZ3Q7IFRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jmd0OyAkQ1VTVE9NRVIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jmd0OyBUaGF0IHNhaWQuLiB0aGVyZSBpcyBzdGlsbCBhbiBpc3N1ZSB3aXRoIGtleSBk aXN0cmlidXRpb24gZm9yIG9ubGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7 IHNpZ25pbmcgd2hpY2ggaXMgcmVxdWlyZWQgdG8gbWFrZSB0aGlzIHdvcmsuJm5ic3A7Jm5ic3A7 IEkgc2VlIHRoZSB1dGlsaXR5IGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsg QlVMSywgYnV0IEknbSBwZXJzdWFkZWQgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBtb3JlIHdvcmsg YmVmb3JlIGl0J3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyBkZXBsb3lhYmxl IGluIGFuIGVudmlyb25tZW50IHdoZXJlICpYRlIgaXMgcmVxdWlyZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9ubGluZSBzaWduaW5nIGluIHRo aXMgZW52aXJvbm1lbnQgd2lsbCBub3QgYmUgcG9zc2libGUgdW50aWwgdGhpczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5pcyBzb2x2ZWQgYnV0IEkgYmVsaWV2ZSB0aGUgcGhhc2VkIGlu IGFwcHJvYWNoIHdvdWxkIGdpdmUgdXMgdGhlIHRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+dG8gc29sdmUgZm9yIGl0IHdpdGhvdXQgZGVsYXlpbmcgaW5zZWN1cmUgZGVwbG95bWVu dCAocGhhc2UxKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkpvaG48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0t IFRIRVNFIEFSRSBUSEUgRFJPSURTIFRPIFdIT00gSSBSRUZFUjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8Y2VudGVyPlRoaXMgY29tbXVuaWNhdGlvbiBp cyB0aGUgcHJvcGVydHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNlIG9mIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGlt bWVkaWF0ZWx5DQogbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95 IGFsbCBjb3BpZXMgb2YgdGhlIGNvbW11bmljYXRpb24gYW5kIGFueSBhdHRhY2htZW50cy48L2Nl bnRlcj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A05B583C828C614EBAD1DA920D92866BD0824617PODCWMBXEX501ct_-- From nobody Sat Jul 22 15:20:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7BD12EC1D for ; Sat, 22 Jul 2017 15:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 sxzrvDIsUwNY for ; Sat, 22 Jul 2017 15:20:17 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 2D2DE129B6A for ; Sat, 22 Jul 2017 15:20:17 -0700 (PDT) Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MMKG3J005385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 17:20:16 -0500 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKBn1052079; Sat, 22 Jul 2017 17:20:11 -0500 Received: from lxdnp31k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKAM9052075 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 17:20:10 -0500 Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKAoQ057868; Sat, 22 Jul 2017 16:20:10 -0600 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKAia057865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 16:20:10 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 17:20:10 -0500 From: "Woodworth, John R" To: "'Peter van Dijk'" , dnsop WG CC: "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJbDfuAgAAPdwCAABuOAP//u9kwgABcYQCAAJGCYIADa7GAgAEYHOA= Date: Sat, 22 Jul 2017 22:20:09 +0000 Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> In-Reply-To: <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 22:20:18 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBETlNPUCBbbWFpbHRvOmRuc29w LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlciB2YW4gRGlqaw0KPg0KPiBIZWxs byBKb2huLA0KPg0KPiAxIGFuZCAyIGNvdWxkIGJlIGNvdmVyZWQgd2l0aCBhIHdpbGRjYXJkIFBU UiwgYXMgSSB0aGluayBUb255IEZpbmNoIHBvaW50ZWQgb3V0Lg0KPg0KDQpIaSBQZXRlciwNCg0K VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpXaWxkY2FyZHMgYXJlIGEgZ29vZCBzdGFydCwg b3IgYXQgbGVhc3QgdGhleSBhcHBlYXIgc28gb24gdGhlIHN1cmZhY2UuDQoNClVuZm9ydHVuYXRl bHksIHRoZSB2YWd1ZW5lc3Mgb2YgdGhlaXIgZGVmaW5pdGlvbiBhbmQgdmFyaW91cw0KaW1wbGVt ZW50YXRpb25zIG9mIHdpbGRjYXJkcyB3b3VsZCBtYWtlIHRoaXMgYSBwb29yIGNob2ljZS4NCg0K Tm90IHRvIG1lbnRpb24sIHdpbGRjYXJkcyB3aWxsIHNldmVyZWx5IGZyYWdtZW50IHRoZSBuYW1l c3BhY2Ugb25jZQ0KcmVhbCBQVFJzIGFyZSBpbnRyb2R1Y2VkIGNyZWF0aW5nIGEgcmF0aGVyIGZp bmUgbWVzcy4NCg0KVGhpcyB3b3VsZCBhbHNvIGFkZCBhbm90aGVyIGxldmVsIG9mIGNvbXBsaWNh dGlvbiBhbmQgcmVzdHJpY3QgdGhlDQpsYXllcmluZyBjYXBhYmlsaXRpZXMgd2UgYXJlIGF0dGVt cHRpbmcgdG8gaW50cm9kdWNlIGFuZCB3b3VsZA0KaW5ldml0YWJseSBwcm92ZSBmYXIgbW9yZSBw cm9ibGVtYXRpYyBhbmQgcmVzb3VyY2UgaW50ZW5zaXZlIHRoYW4NCnlvdSBtaWdodCBleHBlY3Qs IHNpbXBseSB0byBjb21wZW5zYXRlIGZvciBhbGwgdGhlIGZyYWdtZW50YXRpb24uDQoNCj4NCj4g PiBGb3JnZXQgZm9yIGEgbW9tZW50IGFib3V0IElQdjYuICBUaGlzIGRyYWZ0IG1ha2VzICRHRU5F UkFURSBtb3JlDQo+ID4gbWVtb3J5IGVmZmljaWVudCwgc2NhbGVzIGJpZ2dlciwgc3RheXMgaW50 YWN0IHRocm91Z2ggQVhGUidzIGFuZCB5ZXMNCj4gPiAtaXQgbWFrZXMgc29tZSBuYW1lc2VydmVy cyAoYXV0aG9yaXRhdGl2ZSkgd29yayBhIGJpdCBtb3JlIGFzIGENCj4gPiB0cmFkZS1vZmYuDQo+ DQo+IE9uZSBjb3VsZCBtYWtlICRHRU5FUkFURSBtb3JlIGVmZmljaWVudCB3aXRob3V0IGFjdHVh bGx5IGltcGxlbWVudGluZw0KPiB0aGUgQlVMSyBSUiwgYnkgdGFraW5nIHlvdXIgcGF0dGVybiBt YXRjaGluZyBsb2dpYyBhbmQgaW1wbGVtZW50aW5nIGl0DQo+IGluc2lkZSB0aGUgbmFtZSBzZXJ2 ZXIuIE9mIGNvdXJzZSwgdGhpcyBtYWtlcyBnZW5lcmF0aW5nIHRoZSBOU0VDL05TRUMzDQo+IGNo YWluIG11Y2ggaGFyZGVyIHRoYW4gaXQgaXMgd2l0aCB0b2RheeKAmXMgJEdFTkVSQVRFIGltcGxl bWVudGF0aW9ucw0KPiB0aGF0IGFjdHVhbGx5IGdlbmVyYXRlIGFsbCB0aGUgbmFtZXMuDQo+DQoN ClRoaXMgd291bGQgc3RpbGwgYmUgYSB2ZW5kb3ItaGFjayAoYmluZCkgYW5kIG5vdCBhIHN0YW5k YXJkLiAgV2UgYXJlDQpsb29raW5nIGZvciBhIHZlbmRvciBhZ25vc3RpYyBzb2x1dGlvbiBhbmQg ZmVlbCBhIHN0YW5kYXJkcyBib2R5IGlzDQp1bHRpbWF0ZWx5IHJpZ2h0IGNob2ljZS4gIEFkZGl0 aW9uYWxseSwgdGhpcyBkb2VzIG5vdCBhZGRyZXNzIHRoZQ0KYWJpbGl0eSB0byBBWEZSIHRoZSAn aW50ZW50JyAoJEdFTkVSQVRFKS4NCg0KPg0KPiBBIHZlcnkgaW50ZXJlc3RpbmcgcHV6emxlIHdv dWxkIGJlIGltcGxlbWVudGluZyBCVUxLIHN1cHBvcnQsIGJhc2VkDQo+IG9uIHRoZSBwYXR0ZXJu IG1hdGNoaW5nIGluIHRoZSBkcmFmdCwgLXdpdGhvdXQtIGRvaW5nIE5TRUMoMykNCj4gd2hpdGUv YmxhY2sgbGllcyAtIGkuZS4gZ2VuZXJhdGluZyB0aGUgd2lkZXN0IHBvc3NpYmxlIE5TRUMgaW5z dGVhZA0KPiBvZiB0aGUgbmFycm93ZXN0IG9uZS4gRm9yIE5TRUMzIEkgc3VzcGVjdCB0aGlzIGlz IG5vdCBmZWFzaWJsZS4NCj4NCg0KVW5mb3J0dW5hdGVseSwgdGhlcmUgYXJlIGxvdHMgb2Ygd2F5 cyBETlMgaXMgYWJ1c2VkIHRvIHByb3ZpZGUgYW4NCnVuZHVlIHByZWp1ZGljZSBhZ2FpbnN0IGh1 Z2Ugc3dhdGhzIG9mIG1pbGQtbWFubmVyZWQsIGxlZ2l0aW1hdGUgSVBzLg0KDQpXaGlsZSBvdXIg c29sdXRpb24gKE5QTikgb2ZmZXJzIHRoZSBzYW1lIG9wcG9ydHVuaXR5IGZvciBhYnVzZSwgaXQN CmRvZXNuJ3QgcHJlZW1wdGl2ZWx5IGRlZmVhdCBvdGhlciBvcHRpb25zLCBzdWNoIGFzIG9ubGlu ZSBzaWduaW5nDQp3aGVyZSBCVUxLIGdlbmVyYXRlZCByZWNvcmRzIGFyZSAqZXhhY3RseSogbGlr ZSBhbnkgb3RoZXIgcmVjb3JkLg0KDQoNClRoYW5rcywNCkpvaG4NCg0KPg0KPiBLaW5kIHJlZ2Fy ZHMsDQo+IC0tDQo+IFBldGVyIHZhbiBEaWprDQo+IFBvd2VyRE5TLkNPTSBCViAtIGh0dHBzOi8v d3d3LnBvd2VyZG5zLmNvbS8NCi0tIFRIRVNFIEFSRSBUSEUgRFJPSURTIFRPIFdIT00gSSBSRUZF UjoNClRoaXMgY29tbXVuaWNhdGlvbiBpcyB0aGUgcHJvcGVydHkgb2YgQ2VudHVyeUxpbmsgYW5k IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1 dGhvcml6ZWQgdXNlIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNh dGlvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJl cGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFu ZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Sat Jul 22 15:32:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616AA129B25 for ; Sat, 22 Jul 2017 15:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 xV_0haZPSums for ; Sat, 22 Jul 2017 15:32:49 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 E6FCB12708C for ; Sat, 22 Jul 2017 15:32:48 -0700 (PDT) Received: from lxdnp04n.corp.intranet (emailout.qintra.com [151.119.92.83]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MMWmdu059450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 16:32:48 -0600 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMWhM1034505; Sat, 22 Jul 2017 16:32:43 -0600 Received: from lxomp06u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMWgQI034499 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 16:32:43 -0600 Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMWgJV028186; Sat, 22 Jul 2017 17:32:42 -0500 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMWgQn028183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 17:32:42 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 17:32:42 -0500 From: "Woodworth, John R" To: "'John Levine'" , "dnsop@ietf.org" CC: "Woodworth, John R" Thread-Topic: [DNSOP] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse Thread-Index: AQHTAwLoCOM6XgX3E0ixAnIofn87GqJgbY6w Date: Sat, 22 Jul 2017 22:32:42 +0000 Message-ID: References: <20170722155338.9829.qmail@ary.lan> In-Reply-To: <20170722155338.9829.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 22:32:50 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of John Levine > > Speaking of nsec-aggressiveuse, while staring out the window of > the train this morning it occurred to me that BULK breaks > NXDOMAIN synthesis, too, both the NSEC kind and the RFC 8020 kind. > Hi John, Thanks again for your comments. I'm confused, wouldn't a simple NS record solve this? Thanks, John > > > R's, > John -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Sat Jul 22 15:37:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01014129B25 for ; Sat, 22 Jul 2017 15:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 ZmgzXKhMhlcJ for ; Sat, 22 Jul 2017 15:37:58 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 42150124BE8 for ; Sat, 22 Jul 2017 15:37:58 -0700 (PDT) Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MMbvwi038750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 17:37:57 -0500 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMbqwr026645; Sat, 22 Jul 2017 17:37:52 -0500 Received: from lxomp07u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMbqJ8026640 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 17:37:52 -0500 Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMbqGn032987; Sat, 22 Jul 2017 17:37:52 -0500 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMbpoK032984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 17:37:52 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 17:37:51 -0500 From: "Woodworth, John R" To: "'Jim Reid'" CC: dnsop WG , "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJbDfuAgAAPdwCAABuOAP//u9kwgABcYQCAAJGCYIAEm2QA///20RA= Date: Sat, 22 Jul 2017 22:37:51 +0000 Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 22:37:59 -0000 PiBGcm9tOiBKaW0gUmVpZCBbbWFpbHRvOmppbUByZmMxMDM1LmNvbV0NCj4NCj4gPiBPbiAyMCBK dWwgMjAxNywgYXQgMDI6MTcsIFdvb2R3b3J0aCwgSm9obiBSIDxKb2huLldvb2R3b3J0aEBDZW50 dXJ5TGluay5jb20+IHdyb3RlOg0KPiA+DQo+ID4gdGhpcyBpcyBqdXN0IGEgbmV4dC1nZW4gJEdF TkVSQVRFDQo+DQo+IEluZGVlZC4gV2UgYWxsIGdldCB0aGF0LiBIb3dldmVyICRHRU5FUkFURSBp cyBhIEJJTkQtaXNtLCBsaWtlDQo+IHZpZXdzLiBJdOKAmXMgbm90IHBhcnQgb2YgdGhlIEROUyBw cm90b2NvbC4gSeKAmW0gbm90IHlldA0KPiBjb252aW5jZWQgJEdFTkVSQVRFIChhbGJlaXQgd2l0 aCBhIEJVTEsgbWFrZW92ZXIpIG5lZWRzIHRvIGJlLg0KPg0KPiBUaGUgdXNlIGNhc2UgZm9yIEJV TEsgc3RpbGwgaGFzbuKAmXQgYmVlbiBtYWRlIElNTy4NCj4NCg0KSGkgSmltLA0KDQpUaGFua3Mg YWdhaW4gZm9yIHlvdXIgY29tbWVudHMuDQoNCldvdywgdG91Z2ggY3Jvd2QuLi4gIGdsYWQgSSB3 YXNuJ3QgaW4gdGhlIFdHIHRvIHNlZSBhbGwgdGhlDQoiSnVzdCB1c2UgW0RlbF0ga2V5ISIgY29t bWVudHMgd2hlbiBTUEYgZmxvYXRlZCBpbi4gIDt7Pg0KDQoNClRoYW5rcywNCkpvaG4NCi0tIFRI RVNFIEFSRSBUSEUgRFJPSURTIFRPIFdIT00gSSBSRUZFUjoNClRoaXMgY29tbXVuaWNhdGlvbiBp cyB0aGUgcHJvcGVydHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNlIG9mIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGlt bWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBhbmQgZGVzdHJveSBh bGwgY29waWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Sat Jul 22 15:58:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DFE129ADA for ; Sat, 22 Jul 2017 15:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 xspBHANKR6gt for ; Sat, 22 Jul 2017 15:58:19 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 72015126C7A for ; Sat, 22 Jul 2017 15:58:19 -0700 (PDT) Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MMwIQt010658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 17:58:18 -0500 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMwD3v006247; Sat, 22 Jul 2017 17:58:13 -0500 Received: from lxomp06u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMwDvd006243 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 17:58:13 -0500 Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMwCCw063006; Sat, 22 Jul 2017 17:58:12 -0500 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMwCnp063003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 17:58:12 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 17:58:12 -0500 From: "Woodworth, John R" To: "'Jim Reid'" , Stephane Bortzmeyer CC: dnsop WG , "Woodworth, John R" Thread-Topic: [DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr Thread-Index: AQHTAxyykhI9QM+je06sHbLWvDEmLaJgcI4g Date: Sat, 22 Jul 2017 22:58:11 +0000 Message-ID: References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 22:58:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBETlNPUCBbbWFpbHRvOmRuc29w LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gUmVpZA0KPg0KPiBCVFcsIGlmIHRo ZXJlIGFyZSBjYXNlcyB3aGVyZSBhbiBJU1DigJlzIGN1c3RvbWVycyBjYXJlIGFib3V0DQo+IHJl dmVyc2UgRE5TIGZvciB0aGVpciBJUHY2IGFkZHJlc3Nlcywgd2hhdOKAmXMgc3RvcHBpbmcgdGhv c2UNCj4gY3VzdG9tZXIgZGV2aWNlcyB1c2luZyBkeW5hbWljIHVwZGF0ZSB0byBwcm92aXNpb24g dGhlaXIgbmFtZXMNCj4gb3IgaGF2ZSB0aGUgREhDUCBzZXJ2ZXIgZG8gdGhhdCBmb3IgdGhlbT8g V2h5IGNhbuKAmXQgdGhlIElTUCdzDQo+IHByb3Zpc2lvbmluZyBzeXN0ZW1zIGFuZCB0b29scyBz cGl0IG91dCBQVFIgcmVjb3JkcyBmb3IgdGhlIElQDQo+IGFkZHJlc3NlcyB3aGljaCBuZWVkIHRo aXMgc2VjcmV0IHNhdWNlPw0KPg0KDQpIaSBKaW0sDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50 cy4NCg0KSG93IGV4YWN0bHkgZG9lcyBhIGhpZGUtdGhlLWJvZHkgc2NoZW1lIHNvbHZlIHRoZSBp c3N1ZT8gIERvIHdlDQpyZWFsbHkgd2FudCBhIC82NCB0byBiZSBkeW5hbWljYWxseSB1cGRhdGVk IGJlY2F1c2Ugd2Ugc2hpZnQgdGhlDQpwcm9ibGVtIGJhY2sgdG8gdGhlbT8NCg0KV2UndmUgYWN0 dWFsbHkgaGFkIHJlcXVlc3RzIG5hcnJvd2VkIHRvIGEgc2ltcGxlIC85NiB0byBoZWxwIHdpdGgN CnRoZWlyIHByb2JsZW0sIGFzIGlmIHNocmlua2luZyB0aGVpciByZXF1ZXN0IHRvIHNpbXBseSB0 aGUgZXF1aXZhbGVudA0Kb2YgdGhlIElQdjQgSW50ZXJuZXQgd291bGQgaGVscCA6KSAuDQoNCk90 aGVyIHByb3ZpZGVycyBhcmUgbW9yZSB0aGFuIHdpbGxpbmcgdG8gYmVzdG93IGEgc29sdXRpb24g dG8NCm91ciBjdXN0b21lcnMgdG9kYXksICphY3R1YWxseSogcG9sbHV0aW5nIEROUyB3aXRoIGFs bCB0aGUgZG9vbXNkYXkNCmZlYXJzIHlvdSdyZSB0b3V0aW5nIGJlY29taW5nIGZ1bGZpbGxlZC4N Cg0KV2h5IHdvdWxkbid0IHdlIHdhbnQgdG8gdGFrZSB0aGUgb3Bwb3J0dW5pdHkgdG8gdGFrZSB0 aGlzIG9uIGFzIGENCmNvbW11bml0eSBhbmQgZ3VpZGUgaXQgdGhlIHdheSB3ZSB3YW50LCB3aXRo aW4gdGhlIGJvdW5kYXJpZXMgd2Ugc2V0LA0KYW5kIHdpdGggdGhlIHN0YW5kYXJkcyBzdXBwb3J0 IChETlNTRUMsIGV0Yy4pIHdlIHdhbnQgdG8gcHJvbW90ZT8NCg0KDQpUaGFua3MsDQpKb2huDQoN Cj4NCi0tIFRIRVNFIEFSRSBUSEUgRFJPSURTIFRPIFdIT00gSSBSRUZFUjoNClRoaXMgY29tbXVu aWNhdGlvbiBpcyB0aGUgcHJvcGVydHkgb2YgQ2VudHVyeUxpbmsgYW5kIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBVbmF1dGhvcml6ZWQgdXNlIG9m IHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBhbmQg ZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkgYXR0YWNobWVu dHMuDQo= From nobody Sat Jul 22 17:29:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DF129B61 for ; Sat, 22 Jul 2017 17:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ReJpJcKpvIp2 for ; Sat, 22 Jul 2017 17:28:56 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 559DC129468 for ; Sat, 22 Jul 2017 17:28:56 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v6N0RcmI047051 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Sun, 23 Jul 2017 00:27:39 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v6N0Rc7E047050 for dnsop@ietf.org; Sun, 23 Jul 2017 00:27:38 GMT Date: Sun, 23 Jul 2017 00:27:38 GMT From: Vernon Schryver Message-Id: <201707230027.v6N0Rc7E047050@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 00:28:58 -0000 > From: "Woodworth, John R" > > One could make $GENERATE more efficient without actually implementing > > the BULK RR, by taking your pattern matching logic and implementing it > ... > This would still be a vendor-hack (bind) and not a standard. The examples I've noticed in this thread look similar to RPZ patterns, although perhaps I've missed examples that do not fit the RPZ mold. RPZ is not exactly a standard and certainly not without controversy, but it is documented and available for more than BIND. https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/ RPZ is officially only for recursive resolvers, but that is because superficially it makes little sense for an authority to rewrite its own response. However, RPZ works on authorities (masters) in at least BIND. Could RPZ be a partial solution to the problem that the BULK RR would solve? I agree that a statement of the problems solved by the BULK RR would be good. Vernon Schryver vjs@rhyolite.com From nobody Sat Jul 22 23:21:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CDA129B2A for ; Sat, 22 Jul 2017 23:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=QCCcHMnG; dkim=pass (1536-bit key) header.d=taugh.com header.b=OZNK1HUb 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 bPMz1Bx0-hqm for ; Sat, 22 Jul 2017 23:21:55 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AAE126C2F for ; Sat, 22 Jul 2017 23:21:54 -0700 (PDT) Received: (qmail 96820 invoked from network); 23 Jul 2017 06:21:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17a32.59744081.k1707; bh=AIltPWpB24NM9mq+w6xoWuMo7N5V0Is9GRAUHDbyXBg=; b=QCCcHMnGGT0VzC+F0aaJdpsdTe02rmQ2dw3JBKw0C1ClL/06B2qCtj4utdrDaTce4hGa62A5pm7E/257m7FG2gtBPQlTfayhfNttmHv2boiaFhiWGbMofpe7Ox9KNI+hocRLUj490R94sLKb7Amp/OGUQQrq4zr9UpIRVTiVtv1WN7e2jemZXFBzDJ+Lz1REBVma6ABZTjDrcjSNRR8Es/+SrRHaLqTb6Qu3zp+NuUgDvSK9TJmjNtRRJ9DZsMB+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17a32.59744081.k1707; bh=AIltPWpB24NM9mq+w6xoWuMo7N5V0Is9GRAUHDbyXBg=; b=OZNK1HUb9sjtUlcSt9Ao5DNlYjT+sxCGUvCdqeMB82+ISLjW+siswggUVD+0zKCEQygaFXG+hUlQpX/vkns8hMpxjCJ/q6GH56LE6qqtXgEz89FdMDI56S41h4Pyt/N5ewiZ4Nd2mzBaUAH0mu0V2OPwWtKOqaZheFtBEuHgGV49gy+psbGnogmwE4BEYGZYerwVP1rUwBgN1CmgYVCeitRissK2aaRDj383m48tB+ZLKYgJ+HY0/xC2YSRZGYyx Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 23 Jul 2017 06:21:53 -0000 Date: 23 Jul 2017 08:21:53 +0200 Message-ID: From: "John R Levine" To: "Woodworth, John R" Cc: "dnsop@ietf.org" In-Reply-To: References: <20170722155338.9829.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 06:21:57 -0000 >> Speaking of nsec-aggressiveuse, while staring out the window of >> the train this morning it occurred to me that BULK breaks >> NXDOMAIN synthesis, too, both the NSEC kind and the RFC 8020 kind. > I'm confused, wouldn't a simple NS record solve this? No, this is all within the zone where BULK is synthesizing records. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jul 24 01:30:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1D5131C3B for ; Mon, 24 Jul 2017 01:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 w17BpfvITvpJ for ; Mon, 24 Jul 2017 01:30:04 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77AC131C32 for ; Mon, 24 Jul 2017 01:30:04 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 565712421527; Mon, 24 Jul 2017 08:30:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: Date: Mon, 24 Jul 2017 09:29:59 +0100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <6924C811-8541-4A06-8717-89FAB4BF5598@rfc1035.com> References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> To: "Woodworth, John R" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 08:30:06 -0000 > On 22 Jul 2017, at 23:58, Woodworth, John R = wrote: >=20 > How exactly does a hide-the-body scheme solve the issue? I don=E2=80=99t understand the question and have no information/contaxt = that would allow me to give a meaningful answer. What do you mean by =E2=80=9Chide-the-body=E2=80=9D? And what is =E2=80=9C= the issue=E2=80=9D? AFAICT you have still to define a use case or problem statement. Until = this gets done, nobody can be really sure what problem is supposedly = fixed by BULK. From nobody Mon Jul 24 05:55:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E768131A7C for ; Mon, 24 Jul 2017 05:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 vvBM2vpr2Usd for ; Mon, 24 Jul 2017 05:55:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 703BB127869 for ; Mon, 24 Jul 2017 05:55:21 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id A503E61E92; Mon, 24 Jul 2017 14:55:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500900919; bh=82stzSnkUszm1Ewk6LEhOXs7Q/jSVGBvLcosnHDO900=; h=Date:From:To; b=jwNOISeRSTuE42ZumEW0D6bJ+0JJ8s6Eqvj+b72syZAR/oCeuW3qgJnq185Pp/iA3 RAWl+la6oDzGsZ874FVapNbjhfGR3MRJxOQoZRBsBYhIEVXU5BWsWGPiyudg2MrcsX stSJIx7tfzU4UJHXGmfnVtOGo+krwwiPR45OTXQ0= Date: Mon, 24 Jul 2017 14:55:19 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: John R Levine Cc: "Woodworth, John R" , dnsop Message-ID: <1600298321.7649.1500900919500.JavaMail.zimbra@nic.cz> In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.9_GA_1794 (ZimbraWebClient - GC59 (Linux)/8.7.9_GA_1794) Thread-Topic: DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: /pi3F5DkzfJJ+6Zzux+d95zOHMthNg== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 12:55:25 -0000 ----- Original Message ----- > From: "John R Levine" > To: "Woodworth, John R" > Cc: "dnsop" > Sent: Saturday, 22 July, 2017 08:33:30 > Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-wo= odworth-bulk-rr in state "Candidate for WG > Adoption" >>> ...BULK absolutely requires online DNSSEC signing, >> Unfortunately, I respectfully reject this as a statement of fact. >> There's even a provision (NPN) ... >=20 > ... which only works if you upgrade every validating resolver. If you > get to do that, you might as well just send the signed BULK record, the > NSEC and RRSIG that show there's nothing at the name, and let the resolve= r > figure it out. Given how slowly people update their client DNS libraries= , > NPN would be a recipe for decades of DNS flakiness, as some resolvers > accept the generated records and some don't. +1 Personally, I think NPN should be just dropped as John L. is correct in his= assessment here. I still think BULK is too complicated[*], but I understand the value of interoperability between DNS server vendors. * - compare to our synthrecord plugin: https://www.knot-dns.cz/docs/2.5/html/modules.html#synthrecord-automatic-fo= rward-reverse-records Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- From nobody Mon Jul 24 06:02:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFCC131CE6 for ; Mon, 24 Jul 2017 06:02:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-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 wxkb0WCG4-dK for ; Mon, 24 Jul 2017 06:02:07 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 5836F1276AF for ; Mon, 24 Jul 2017 06:02:06 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 80so77634098uas.0 for ; Mon, 24 Jul 2017 06:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gp1wxmd9fLKf38vBPh5qgLLIi5x96PMTzKuWd/MFm7w=; b=Dm/iu4Huvl6bhQPJZKMNnR6WAzFxbvEKNUNHRimm7tWVW6AdxYiUmSQ8O6XGcFJRR+ ReAwa/N9VBYGb4c7/KlsQbV0k7q2KjV6Cohw1Y3lsZre9GHdM8zbDhG+n9cbmOkRV1Lu VzbeFh2oTSgmjW5rhsxCVR3aCz4DcUAeMZtdph19yXgPX3dhZ/gCyuzm5jb0pppBl5ey zHhPTEb39TBqq47USlM/LITtdDEXlLgEkkwqhV2sKwFRmW4c9Xh/LbwBK0HSXFTtXwOc 0spRiFJ7wsa78hT1bj1BDePx/14rclQilkcbR3rwtSvtWSwztmYXE/HvZhTMDZ2MuI2R GHSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gp1wxmd9fLKf38vBPh5qgLLIi5x96PMTzKuWd/MFm7w=; b=MCK52ZL/VT3IEPcBZh8IVMSnCRhiXeqN/kpDa/zq5Dq/ULsmw3L8pQP/0Z6D1Voc/0 4EXLRRSVUu8kiZoA50FYCMyouQATsCbDy8PVzwosWlP6G+57JnA6xP5ottIldsIARakm OzUsvd9UMHgKSdkHMaBZx3x3HD7gI1aJRxFPw36cAYriEdUt+QOqTMBLZNg1VoFLXju/ nhpi2hVEsZsSlLyZ+m+OV9KvhnpkRq2zImllMEm/WvPmLrdUpgFap8aOJ43dp8mJH9Ho K55TvWKaHfppWu+djKTelfrcOAo7U7+AVxT3Os00kIKiwj9OYYFCyqFcdgltHvb0w92w F26A== X-Gm-Message-State: AIVw110L8o8atHfZhdU51uclkgF6LLs19kYhtUcIChNsCoJqTYqXH6iH HRytyqD7o5RuysqA7uIJjDvMo6klLAwS X-Received: by 10.159.49.7 with SMTP id m7mr10327995uab.194.1500901325934; Mon, 24 Jul 2017 06:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.14 with HTTP; Mon, 24 Jul 2017 06:02:05 -0700 (PDT) In-Reply-To: References: <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org> From: Matthew Pounsett Date: Mon, 24 Jul 2017 09:02:05 -0400 Message-ID: To: "Woodworth, John R" Cc: John R Levine , dnsop , Paul Wouters Content-Type: multipart/alternative; boundary="f403045e36cc602a6e05550fd2c1" Archived-At: Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 13:02:09 -0000 --f403045e36cc602a6e05550fd2c1 Content-Type: text/plain; charset="UTF-8" On 22 July 2017 at 17:40, Woodworth, John R wrote: > > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Matthew > Pounsett > > > > > > > On 20 July 2017 at 17:53, John R Levine wrote: > > > > That's why I don't share the fears about BULK: you cannot easily > > > > deploy a new feature that will require a change in the resolvers, > > > > because you don't know all the resolvers, and cannot change them even > > > > if you know they are too old. But your secondaries are only a small > > > > set of carefully chosen servers, and you have your say. > > > > > > I hear otherwise from people who run big DNS farms. It's common to > > > use multiple secondary providers, and it's hard to tell who's running > > > what server software. I also note that it took about a decade before > > > people felt comfortable using DNAMEs. > > > > > > > Hi Matthew, > > > > Thanks for your comments. > > > > I hear and understand your concerns. We have similar concerns but > > *I* feel we could offer a phased-in approach to set everyone's > > expectations appropriately. If one chooses to step ahead of the phase > > at least they'd have an idea what troubles await them. > Something's wrong with your email client. Your quoted text above was not me. > > > > > > > Dear $VENDOR. > > > > > > I'm a customer who is considering deploying the BULK RR type into my > > > zone, and I would like to know whether your systems support it. > > > > > > Thank you, > > > $CUSTOMER. > > > > > > > > > That said.. there is still an issue with key distribution for online > > > signing which is required to make this work. I see the utility in > > > BULK, but I'm persuaded that there needs to be more work before it's > > > deployable in an environment where *XFR is required. > > > > > > > Online signing in this environment will not be possible until this > > is solved but I believe the phased in approach would give us the time > > to solve for it without delaying insecure deployment (phase1). > > > What's your mechanism for enforcing (or even signalling) this phased approach in the DNS? --f403045e36cc602a6e05550fd2c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 22 July 2017 at 17:40, Woodworth, John R <John.Woodwor= th@centurylink.com> wrote:

> From: DNSOP [mailto:= dnsop-bounces@i= etf.org] On Behalf Of Matthew Pounsett

>

> > On 20 July 2017= at 17:53, John R Levine <johnl@taugh.com> wrote:

> > That's why = I don't share the fears about BULK: you cannot easily

> > deploy a new fe= ature that will require a change in the resolvers,

> > because you don= 't know all the resolvers, and cannot change them even

> > if you know the= y are too old. But your secondaries are only a small

> > set of carefull= y chosen servers, and you have your say.

>

> I hear otherwise fro= m people who run big DNS farms.=C2=A0 It's common to

> use multiple seconda= ry providers, and it's hard to tell who's running

> what server software= .=C2=A0 I also note that it took about a decade before=

> people felt comforta= ble using DNAMEs.

>

=C2=A0

Hi Matthew,=

=C2=A0

Thanks for your comments.=

=C2=A0

I hear and understand you= r concerns.=C2=A0 We have similar concerns but

*I* feel we could offer a= phased-in approach to set everyone's

expectations appropriatel= y.=C2=A0 If one chooses to step ahead of the phase

at least they'd have = an idea what troubles await them.


Something's wrong with your email client.=C2= =A0 Your quoted text above was not me.
=C2=A0

=

=C2=A0

>=C2=A0<= /span>

> Dear $VENDOR.=C2=A0

>

> I'm a customer w= ho is considering deploying the BULK RR type into my

> zone, and I would li= ke to know whether your systems support it.

>

> Thank you,=

> $CUSTOMER.=

>

>

> That said.. there is= still an issue with key distribution for online

> signing which is req= uired to make this work.=C2=A0=C2=A0 I see the utility in

> BULK, but I'm pe= rsuaded that there needs to be more work before it's

> deployable in an env= ironment where *XFR is required.

>=C2=A0<= /span>

=C2=A0

Online signing in = this environment will not be possible until this

is solved but I believe t= he phased in approach would give us the time

to solve for it without d= elaying insecure deployment (phase1).


What's your mechanism for enforcing (or even signall= ing) this phased approach in the DNS?

--f403045e36cc602a6e05550fd2c1-- From nobody Mon Jul 24 06:44:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE04D131D0F for ; Mon, 24 Jul 2017 06:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 q1Hy2QSz0ISg for ; Mon, 24 Jul 2017 06:44:01 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 3A37612ECB4 for ; Mon, 24 Jul 2017 06:44:01 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:49608) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dZdeQ-000BkG-fi (Exim 4.89) (return-path ); Mon, 24 Jul 2017 14:43:58 +0100 Date: Mon, 24 Jul 2017 14:43:58 +0100 From: Tony Finch To: Peter van Dijk cc: dnsop WG In-Reply-To: <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 13:44:03 -0000 Peter van Dijk wrote: > > One could make $GENERATE more efficient without actually implementing > the BULK RR, by taking your pattern matching logic and implementing it > inside the name server. Andrew Sullivan was right to say that there is an advantage to having BULK as an RR compared to the $GENERATE master file directive, because an RR makes it easier to interoperate across multiple providers in a multi-master DNS setup. I guess a BULK that is just a standardized version of $GENERATE (with multi-master-only online signing when there's an unfeasible number of generated records) isn't a completely terrible idea, though it's a lot less complicated than the current draft. I'd still like to see lots more specific examples of how it could be used other than for v6 reverse DNS. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fisher, German Bight: Northeast backing north 3 or 4, occasionally 5. Slight. Showers. Good occasionally poor. From nobody Mon Jul 24 06:51:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA58E131D14 for ; Mon, 24 Jul 2017 06:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 nzgAAzV1BN5E for ; Mon, 24 Jul 2017 06:51:42 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 87CC6131771 for ; Mon, 24 Jul 2017 06:51:42 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50237) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dZdls-000J6b-eN (Exim 4.89) (return-path ); Mon, 24 Jul 2017 14:51:40 +0100 Date: Mon, 24 Jul 2017 14:51:40 +0100 From: Tony Finch To: "Woodworth, John R" cc: 'Peter van Dijk' , dnsop WG In-Reply-To: Message-ID: References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 13:51:44 -0000 Woodworth, John R wrote: > > Wildcards are a good start, or at least they appear so on the surface. > > Unfortunately, the vagueness of their definition and various > implementations of wildcards would make this a poor choice. Do you mean there are problems with RFC 4592? If so, what are they? Can you give us details, please? > Not to mention, wildcards will severely fragment the namespace once > real PTRs are introduced creating a rather fine mess. In what way? What do you mean by "fragmented"? A reverse lookup would get a generic wildcard PTR for unregistered addresses and a specific PTR for registered hosts. If you choose the PTR names sensibly then I don't think the namespace would be fragmented. The main disadvantage (same as BULK) is that it would screw up mail server anti-spam heuristics. > This would also add another level of complication and restrict the > layering capabilities we are attempting to introduce and would > inevitably prove far more problematic and resource intensive than > you might expect, simply to compensate for all the fragmentation. Can you unpack this in more detail please? What are these layering capabilities you refer to? Why do you think wildcards are more resource intensive than BULK? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Dover: Northwest 4 or 5, occasionally 6 at first. Slight. Rain. Moderate or good. From nobody Mon Jul 24 10:08:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CEA131D21 for ; Mon, 24 Jul 2017 10:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 qly89MHef3rN for ; Mon, 24 Jul 2017 10:08:42 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D8712EBF7 for ; Mon, 24 Jul 2017 10:08:42 -0700 (PDT) Received: from [10.8.200.238] (unknown [136.179.21.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 7CDE661FF3 for ; Mon, 24 Jul 2017 17:08:41 +0000 (UTC) Message-ID: <59762997.1040708@redbarn.org> Date: Mon, 24 Jul 2017 10:08:39 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: dnsop WG References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 17:08:50 -0000 Tony Finch wrote: > Peter van Dijk wrote: >> One could make $GENERATE more efficient without actually implementing >> the BULK RR, by taking your pattern matching logic and implementing it >> inside the name server. > > Andrew Sullivan was right to say that there is an advantage to having BULK > as an RR compared to the $GENERATE master file directive, because an RR > makes it easier to interoperate across multiple providers in a > multi-master DNS setup. i think there's only an advantage if zone slaves, and not just multi-masters, can generate responses from the BULK record. -- P Vixie From nobody Mon Jul 24 10:38:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D70712ECF0 for ; Mon, 24 Jul 2017 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 bLse--oIdW_w for ; Mon, 24 Jul 2017 10:38:34 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0538129B2A for ; Mon, 24 Jul 2017 10:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=yWQxPwG0T2kv+Xce8CSgBeWtt+xmqIjlgE7AZiiv1/8=; b=C+apBWcJWFWWLw5yMPgo491CvwjHp9AYBVolEbd2YRgpy5yTds5wbmVPKm76xhL16/Qg/9TMuSrxM9zCi68DeqmPqtjC1KRPLbzXYy7Bs6FP6bje+e/owS0VN5gzQMy07abH+OKivVnqUW4xoTADYQomMGTBlXwB1Q9STqwPcFA=; Received: ; Mon, 24 Jul 2017 10:38:33 -0700 To: dnsop@ietf.org From: Jacob Hoffman-Andrews Message-ID: <83f87b5d-1b39-bad8-5ab4-5ebb5991f57b@eff.org> Date: Mon, 24 Jul 2017 10:38:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: [DNSOP] Extended errors draft X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 17:38:36 -0000 I asked on the Unbound mailing list if there were any ways to differentiate between DNSSEC-related SERVFAILs and other types of SERVFAILs, and was referred to the extended error draft: https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02. I can't speak to the implementation detail, but I can confirm that this would be a very useful thing for ACME servers (and probably CAs in general). In particular, ACME defines a number of error types, one of which is "dnssec" (DNSSEC validation failed). Right now Boulder, Let's Encrypt's ACME server, never returns that because it's hard to distinguish error types. We get a lot of support requests from people who get SERVFAILs and don't know why. If we could provide a more detailed error message to start with, the people attempting to issue certificates and getting errors would be able to help themselves more easily. I'm also somewhat in support of the extended textual error message concept. ACME provides textual error messages in addition to error types, and it's been very useful and informative. From nobody Mon Jul 24 12:38:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CC13178D; Mon, 24 Jul 2017 12:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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=gmail.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 E0lc7ULZBXYe; Mon, 24 Jul 2017 12:38:19 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 F25B1131667; Mon, 24 Jul 2017 12:38:18 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id t201so27951137wmt.1; Mon, 24 Jul 2017 12:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=CRmwt2t3MVjRiQhJLmNk6O9rPg21jp7fH0D0LlHBmgE=; b=pGlq6f+H7BMKHIP5ZtknWzJ9jj+PDCvBC0LIzuop+ptgqXghKugse0gAkajUcmD/a1 B8yKnOf+OS1STI7YqiOkSpLPYDSJxjfKv1H+puHcmZqh8mJTTKYI+k26+BJxqdB3Fi54 jtLSHjOd1smunOOYjMBfwaFVdo0hPz60LDLqnO9+wZ1nGNaObPoj9HsvBrq0Cw/Jbk17 xxaZc9vvlBTQheYFHAUBfLtTNy0pJ9eIxIMXuVC3zMzciDKB6xGcJ85VMi7WubJInASN sZvGkSauP+81e286TqknsFU3Fo65Anysaln2SwCgEOmSLyPGaPVKYn/Xk450EwroYTCr osmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=CRmwt2t3MVjRiQhJLmNk6O9rPg21jp7fH0D0LlHBmgE=; b=fpC1SHoOU1ATuCPwrnt87/l8+U3tYQ5Vg9D8e9Fp+KcGItHeMdlcFrcOKM+JrLwta7 ljk7AuNyQa1oHmfMEzkFCTLaM2TfDM/aIJ39e0CRtW03y0vNbbzgrw02Ich240YOreLL mNUBFRyPJrWg90QEIy1c7JCibwUXRPNuluf0+zblCgXByQGaRv9pKtTzbj7ozlZHN40C zdZcWPNbT4lzeXZQtg/819qK/37XsgPaMCkat/RHjHkHQFjXCTQTObGv3rrt9HdCMJBv HE/lESrmhtJZIGuPby4uV51IZqup83tRlor4Q0nctnSGhvfiqrD7xcDsEU9BXQJetHle ldLQ== X-Gm-Message-State: AIVw110HNM1zDThptAIo2b93bw0N7Auy3y9bJPkVeT8mo+sXvHQGVFIS 5hBEqcqSD5SFUlQBwQ/iInIi6+GKL3sE X-Received: by 10.28.207.12 with SMTP id f12mr5300800wmg.92.1500925097121; Mon, 24 Jul 2017 12:38:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.139 with HTTP; Mon, 24 Jul 2017 12:38:16 -0700 (PDT) From: tjw ietf Date: Mon, 24 Jul 2017 15:38:16 -0400 Message-ID: To: "dnsop-chairs@ietf.org" Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c0d462a3fa3e80555155b9a" Archived-At: Subject: [DNSOP] Minutes from Thursday Meeting X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 19:38:22 -0000 --94eb2c0d462a3fa3e80555155b9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again to Mr, Hoffman from keeping copious notes. They are uploaded here: Minutes IETF99: dnsop and I included them below for the time-constrained. Please send any corrections to the chairs. thanks again tim ------------ dnsop-ietf99-minutes-2.txt DNSOP WG Thursday 20 July 2017Tim Wicinski , Suzanne Woolf < suzworldwide@gmail.com> Minutes taken by Paul Hoffman Text from the slides is not reproduced here DPRIVE on IETF network: Warren Kumari Pretty picture of the IETF use Open errata on RFC 8078, needs feedback draft-bellis-dnsext-multi-qtypes and draft-wkumari-dnsop-multiple-responses: Wes Hardaker If the client knows it has multiple questions: draft-bellis-dnsext-multi-qtypes If the server has a better idea of what you want than you do: draft-wkumari-dnsop-multiple-responses Happy eyeballs applies to both drafts Paul Hoffman: Likes both Shane Kerr: Likes multi-qtypes, both are OK Ralph Weber: Questions on multi-qtypes There is no need for either David Lawrence: Likes multiple-responses Ondrej Surey: Missing description of smart attackers Olafur Gundmunsson: If we open the question, there will be other ideas coming Has an experiment that will result in a draft Andrew Sullivan: Disagrees that these are optimizations Change the architectural assumptions of the DNS We need a focused discussion on that Paul Wouters: Likes both Simplify the ANAME with special processing Kazunori Fujiwara: Wants to compare all of proposals Ray Bellis: Objects to Olafur's comment Wants to hear more from Andrew Mukund S: Prefers smart clients to smart servers Jim Reid: Would like objective data to indicate whether it is worth the effort Warren promised data Matt Pounsett: Likes both drafts Maybe can do both changes in a single draft Wes: They depend on who has the knowledge draft-bellis-dnsop-xpf: Peter van Dijk Substantial changes since previous version Ondrej S: Why not EDNS0? If there is a TSIG over the query, that will break Sara Dickenson: Client subnet is informational Violates basic principals Directly injects metadata into questions Needs more privacy concerns Say we're going to violate privacy Maybe consider encryption between trusted parties Daniel Kahn Gilmore: Agreed with Sara Warren Kumari: Wouldn't have done client subnet if they had thought about privacy draft-wkumari-dnsop-extended-error: David Lawrence Paul W: The signaling bits are not protected by crypto Olafur: People have wanted this forever; should do it Jim: Great ideas Maybe lightweight codepoint allocation Be careful of codes that will cause further action of recursive servers David: Talking to IANA how expert review happens Petr =C5=A0pa=C4=8Dek: Needs implementation in clients or it is use= less Andres Schultz: Need vendor values Ralf: Can be used for many things draft-tale-dnsop-edns0-clientid: David Lawrence This is obviously PII Everything that Sara said about XPF applies here Customer will do this regardless of whether or not this is adopted Paul W: Doesn't like people coming to the WG and saying "we'll do it anyway" We should stop accepting these Sara: Likes documenting what we are do Do as informational Likes the way the draft is organized Need to be careful about where we draw the line of documentng things we don't like Peter VD: People are squatting on points; please do it Ralph: This needs to be done Stephane: Has too many privacy issues, doesn't want it adopted Won't review Privacy should be in control of the user, not the administrator David: Wants to see people make more conscious decisions in the life Daniel: Appreciates desire to document privacy violations Doesn't like the flexibility of the suboptions Where do we draw the line on which info do we not transmit on the DNS? Paul W: No one knows the difference of Informational RFCs David: There are actually DNS full standards We should be better about pushing to full standards draft-edmonds-dnsop-capabilities: Robert Edmonds draft-huque-dnssec-alg-nego: Shumon Huque Francis Dupont: Not clear which is stronger: use "preferred" Shumon: Either have client preference, or zone operator specifies Ondrej S: If we all move to EC crypto, is this a problem? Shumon: Still might have reasons to transition to new algs Ondrej: Maybe the size isn't a problem Stephane: This ID could fit in draft-edmonds-dnsop-capabilities Think about that before going forwards on this draft Ralf: This makes DNSSEC a hell of lot more complicated Would rather work with what we have Petr: This will be a nightmare because it blows up the number of possibilities ?: Likes the idea, gives more flexibility to DNSSEC Olafur: Horrible idea Delay DNSSEC deployment We already have techniques to determine how many resolvers do what algorithms Causes delay of DANE deployment --94eb2c0d462a3fa3e80555155b9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again to Mr, Hoffman from keeping copious notes.=C2= =A0 They are uploaded here:
and I included them below for the time-constrained. =C2=A0 Ple= ase send any corrections to the chairs.

thanks aga= in

tim

------------


dnsop-ietf99-minutes-2.txt
=

DNSOP WG
Thursday 20 July 2017Tim W= icinski <tjw.ietf@gmail.com>= ;, Suzanne Woolf <suzworldwide= @gmail.com>
Minutes taken by Paul Hoffman
Text f= rom the slides is not reproduced here

DPRIVE on IE= TF network: Warren Kumari
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pretty pict= ure of the IETF use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Open errata on RF= C 8078, needs feedback

draft-bellis-dnsext-multi-q= types and draft-wkumari-dnsop-multiple-responses: Wes Hardaker
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the client knows it has multiple questions: = draft-bellis-dnsext-multi-qtypes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If t= he server has a better idea of what you want than you do: draft-wkumari-dns= op-multiple-responses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Happy eyeballs = applies to both drafts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul Hoffman: = Likes both
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Shane Kerr: Likes multi-qt= ypes, both are OK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ralph Weber: Questi= ons on multi-qtypes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 There is no need for either
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 David Lawrence: Likes multiple-responses
=C2=A0 =C2=A0 =C2=A0= =C2=A0 Ondrej Surey: Missing description of smart attackers
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Olafur Gundmunsson: If we open the question, there= will be other ideas coming
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Has an experiment that will result in a draft
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Andrew Sullivan: Disagrees that these are opt= imizations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Change the architectural assumptions of the DNS
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We need a focused discussion on = that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul Wouters: Likes both
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Simplify the ANA= ME with special processing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kazunori F= ujiwara: Wants to compare all of proposals
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Ray Bellis: Objects to Olafur's comment
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Wants to hear more from Andrew
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund S: Prefers smart clients to smar= t servers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jim Reid: Would like object= ive data to indicate whether it is worth the effort
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Warren promised data
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Matt Pounsett: Likes both drafts
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Maybe can do both chan= ges in a single draft
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Wes: They depend on who has the knowledge

draft-bellis-dnsop-xpf: Peter van Dijk
=C2=A0 =C2=A0 =C2=A0= =C2=A0 Substantial changes since previous version
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Ondrej S: Why not EDNS0?
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If there is a TSIG over the query, that wil= l break
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sara Dickenson: Client subnet= is informational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Violates basic principals
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Directly injects metadata into questions
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Needs more priv= acy concerns
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Say we're going to violate privacy
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Maybe consider encryption between truste= d parties
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Daniel Kahn Gilmore: Agreed= with Sara
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Warren Kumari: Wouldn'= t have done client subnet if they had thought about privacy

<= /div>
draft-wkumari-dnsop-extended-error: David Lawrence
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Paul W: The signaling bits are not protected by cr= ypto
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Olafur: People have wanted this = forever; should do it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jim: Great idea= s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Maybe l= ightweight codepoint allocation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Be careful of codes that will cause further action= of recursive servers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 David: Talking to IANA how expert review happens
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Petr =C5=A0pa=C4=8Dek: Needs implementation in = clients or it is useless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Andres Schul= tz: Need vendor values
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ralf: Can be u= sed for many things

draft-tale-dnsop-edns0-clienti= d: David Lawrence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is obviously P= II
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Everything that Sara said about XP= F applies here
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Customer will do this = regardless of whether or not this is adopted
=C2=A0 =C2=A0 =C2=A0= =C2=A0 Paul W: Doesn't like people coming to the WG and saying "w= e'll do it anyway"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 We should stop accepting these
=C2=A0 =C2=A0= =C2=A0 =C2=A0 Sara: Likes documenting what we are do
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Do as informational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Likes the way the = draft is organized
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Need to be careful about where we draw the line of documentng th= ings we don't like
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Peter VD: Peop= le are squatting on points; please do it
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Ralph: This needs to be done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Step= hane: Has too many privacy issues, doesn't want it adopted
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Won't review
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Privacy sho= uld be in control of the user, not the administrator
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 David: Wants to see people ma= ke more conscious decisions in the life
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Daniel: Appreciates desire to document privacy violations
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Doesn't like the f= lexibility of the suboptions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Where do we draw the line on which info do we not tran= smit on the DNS?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul W: No one knows= the difference of Informational RFCs
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 David: There are actually DNS full standards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 We should be better about pushing to full standards
=

draft-edmonds-dnsop-capabilities: Robert Edmonds
<= div>
draft-huque-dnssec-alg-nego: Shumon Huque
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Francis Dupont: Not clear which is stronger: use &= quot;preferred"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Shumon: Either have client preference, or zone operator speci= fies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ondrej S: If we all move to EC c= rypto, is this a problem?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Shumon: Still might have reasons to transition to new alg= s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ondrej:= Maybe the size isn't a problem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S= tephane: This ID could fit in draft-edmonds-dnsop-capabilities
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Think about that be= fore going forwards on this draft
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ral= f: This makes DNSSEC a hell of lot more complicated
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Would rather work with what we h= ave
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Petr: This will be a nightmare be= cause it blows up the number of possibilities
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 ?: Likes the idea, gives more flexibility to DNSSEC
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Olafur: Horrible idea
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Delay DNSSEC deployment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We already have te= chniques to determine how many resolvers do what algorithms
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Causes delay of DANE d= eployment


--94eb2c0d462a3fa3e80555155b9a-- From nobody Mon Jul 24 16:44:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB758126CB6 for ; Mon, 24 Jul 2017 16:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 h5Zksth1mdu7 for ; Mon, 24 Jul 2017 16:44:17 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BCC120724 for ; Mon, 24 Jul 2017 16:44:17 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id 480F112C1465; Mon, 24 Jul 2017 19:44:16 -0400 (EDT) Date: Mon, 24 Jul 2017 19:44:16 -0400 From: Robert Edmonds To: Ted Lemon Cc: George Michaelson , dnsop WG Message-ID: <20170724234416.pum23jfgvt4lfuf4@mycre.ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 23:44:19 -0000 RFC 7217 ("A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)") is sort of relevant. From the introduction of that document, which describes drawbacks of traditional IPv6 SLAAC addresses: o Since the resulting Interface Identifiers are constant across networks, the resulting IPv6 addresses can be leveraged to track and correlate the activity of a host across multiple networks (e.g., track and correlate the activities of a typical client connecting to the public Internet from different locations), thus negatively affecting the privacy of users. That drawback translates pretty much directly to the 48-bit MAC CLIENT-IDENTIFIER variant in draft-tale-dnsop-edns0-clientid. For the dnsmasq use case, I would guess there's a CPE router/gateway device involved, in which case the CPE device has a unique device-specific value burned in (e.g., a WAN-facing MAC address, or serial number) which could easily be hashed together with the client's MAC address to produce a stable but opaque identifier specific to the particular CPE device involved. (That is, if the client device travels to a different network gatewayed by a CPE device implementing the same scheme, the identifier generated would be different, because the CPE device has a different WAN-facing MAC address.) So, the cloud would still wind up executing the PII -> policy translation, but you take the 'P' out of 'PII', and don't need to store any extra state on the CPE device. Ted Lemon wrote: > It would be nice if there were an RFC to point to that used a method that > didn't include PII. For the use cases of which I am ware, there is no > need to identify individual devices: only policies. What's lacking is a > way to do this in the home router, so the PII winds up getting exported to > the cloud not because that's necessary to accomplish the filtering but > because it's the only available place where the translation from > PII->policy can be done in practice. Unfortunately, solving _that_ > problem is definitely out of scope for DNSOP. > > On Thu, Jul 20, 2017 at 7:00 PM, George Michaelson wrote: > > > I probably will not carry the WG with me on this, but I find myself > > thinking the PII aspect of client-ID makes it a wider-internet > > question and we might have views as a WG, and promote questions as a > > WG, but I think the "final call" on this is something which needs more > > than WG approval. > > > > Its a big question. I'd actually welcome adoption on many levels, but > > that isn't to pre-empt that it goes to WGLC. I think we need to > > formalize the issues and take them out of the WG for review and > > discussion. > > > > documenting current practice is ok btw, but .. PII. > > > > -G > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Robert Edmonds From nobody Mon Jul 24 17:59:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE70812702E for ; Mon, 24 Jul 2017 17:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, 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=gmail.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 DQ6Gx1AYZseq for ; Mon, 24 Jul 2017 17:59:07 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 F17B2124BE8 for ; Mon, 24 Jul 2017 17:59:06 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id g6so64738328qkf.5 for ; Mon, 24 Jul 2017 17:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=K7omV4cw1d/DOYN9qKBOQbVjoLa558LJliedauD3068=; b=bUmiizlCIfkKCDdAzMxvqJmta8LfBpkTwoNcydWoJGEgg/iEBWpYNqPC2HVX4ZTfUT plU0rNwWtGyaYAq90Au0CdCI+3p3tnDu06+mCZi3wtI4uUpt27g19+Bx51879MvOVjb2 Tt3xeb6/04RgbF9qBZ8t9Cf4+AhblEFRSgMvKePCx+/QQ7M5nAmiFrJ90q1KfpGlmqwF d4aDOYhe36aatPqlF3cdSwYE673mvmMwWQfddUACV4lZVzsCbDGur/1rWzS/Pm3MJaS6 9yM8XXenrhp2zVCnWtPtj/Mzky5Y1SR9e8EsXdXMF8l1pMtvGXdu2XLOqJqRqwMevAxx Z+9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=K7omV4cw1d/DOYN9qKBOQbVjoLa558LJliedauD3068=; b=ESCPaRaTb9zwemmWlOhfO1/9G1tbWIx/uty1Nk60/TEopW2v94+lYz7A7M+B6tsY9z dzj0ERs+cfZfp4UATZaWPOxB8TrTGlIrlMJW3gBaabqRZXmzF46iuWfOPyfw0CsQCkkD zibS6C+8W+Vm5WLoD3KRjHPSvYqKfBeq1ye5Q/MsW5wtT3XkL0jXS3KYmr5SOrvdgEMD 8+V0IWPr8ddNfXlPkToSol56FiL2CUWTMr9MMX1QOf6kMeTw6I87gTwPz03uCoRw1/tL KDhsj/aIBL3cFiQijxxlJewj7zTSMOKJIRTb7tdpHyaAnSbhxpW4YYqfuuleYfbcKCmJ v22g== X-Gm-Message-State: AIVw111Yxg7GU5E2q4rzTZJMGj+89vGySCAPGrtQC/hyWAAuRaWD/yda fWe4E6liAYO6e5Uvi+7RXVhxglW5cXdd X-Received: by 10.55.12.4 with SMTP id 4mr23809748qkm.151.1500944346118; Mon, 24 Jul 2017 17:59:06 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.99.115 with HTTP; Mon, 24 Jul 2017 17:59:05 -0700 (PDT) In-Reply-To: References: From: Christopher Morrow Date: Mon, 24 Jul 2017 20:59:05 -0400 X-Google-Sender-Auth: 0A3vOvFqdGKVO8393S4cn7NUXZY Message-ID: To: Ted Lemon Cc: George Michaelson , dnsop WG Content-Type: multipart/alternative; boundary="001a114c8000940193055519d6ac" Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 00:59:09 -0000 --001a114c8000940193055519d6ac Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon wrote: > It would be nice if there were an RFC to point to that used a method that > didn't include PII. For the use cases of which I am ware, there is no > need to identify individual devices: only policies. What's lacking is a > way to do this in the home router, so the PII winds up getting exported to > the cloud not because that's necessary to accomplish the filtering but > because it's the only available place where the translation from > PII->policy can be done in practice. Unfortunately, solving _that_ > problem is definitely out of scope for DNSOP. > > isn't the query path here: (largely) client -> cpe-router -> provider-cache-resolver -> auth-dns and at the cache->auth layer it's potentially the case that the provider can say: "use precision of /24" or "use precision of /17" ? So, there's really not much "pii" that can be worried over at the provider-cache-resolver (they already know who you are...) and they (provider) can decide how much granularity is "important" to release to the upstream authoritative cache. --001a114c8000940193055519d6ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon <mellon@fugue.com> wrote:
It would be = nice if there were an RFC to point to that used a method that didn't in= clude PII. =C2=A0 For the use cases of which I am ware, there is no need to= identify individual devices: only policies. =C2=A0 What's lacking is a= way to do this in the home router, so the PII winds up getting exported to= the cloud not because that's necessary to accomplish the filtering but= because it's the only available place where the translation from PII-&= gt;policy can be done in practice. =C2=A0 Unfortunately, solving _that_ pro= blem is definitely out of scope for DNSOP.

=
isn't the query path here: (largely)
=C2=A0 client =C2= =A0-> cpe-router -> provider-cache-resolver -> auth-dns
=
and at the cache->auth layer it's potentially the cas= e that the provider can say: "use precision of /24" or "use = precision of /17" ? So, there's really not much "pii" th= at can be worried over at the provider-cache-resolver (they already know wh= o you are...) and they (provider) can decide how much granularity is "= important" to release to the upstream authoritative cache.
=
--001a114c8000940193055519d6ac-- From nobody Tue Jul 25 00:23:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D4131822 for ; Tue, 25 Jul 2017 00:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 nhmRarE89oqc for ; Tue, 25 Jul 2017 00:23:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 162A413188F for ; Tue, 25 Jul 2017 00:23:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xGqTl34x1z3Nl; Tue, 25 Jul 2017 09:23:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1500967403; bh=ztFI3y0IEcRRFMcXmMn4YPv91l5DdfxYKNU8GjtbIEQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nKMqxirOUA094CXTP3d2rDOSwNb4ds+2ON3jMk1AsE+pAnOvWA0GcaCuqJ4Vwi/ND Sgq+udopEA+qe0N0GMSbtMiMt2N7c83ge2dDZ5KRIevjgW7Z84j4i1e2sykqziAp8+ kq5K5q6yDm/dSTQy8xSnVUscOZH0d0+8gGQ2j1NI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cpNSttTAncWI; Tue, 25 Jul 2017 09:23:20 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 25 Jul 2017 09:23:20 +0200 (CEST) Received: from [10.0.1.185] (unknown [85.93.125.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 89F9630AFAA; Tue, 25 Jul 2017 03:23:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 89F9630AFAA Content-Type: multipart/alternative; boundary=Apple-Mail-F8C906EF-94F0-4091-80F0-4A8D56E0A601 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 25 Jul 2017 09:23:16 +0200 Cc: Ted Lemon , dnsop WG , George Michaelson Content-Transfer-Encoding: 7bit Message-Id: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> References: To: Christopher Morrow Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 07:23:30 -0000 --Apple-Mail-F8C906EF-94F0-4091-80F0-4A8D56E0A601 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable And then there are mobile phones with wifi and LTE tracking, already massive= ly abused by AP's and companies like Apple are randomising macs. This draft is good for the ad business, not good for the enduser. Paul Sent from my iPhone > On Jul 25, 2017, at 02:59, Christopher Morrow wr= ote: >=20 >=20 >=20 >> On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon wrote: >> It would be nice if there were an RFC to point to that used a method that= didn't include PII. For the use cases of which I am ware, there is no nee= d to identify individual devices: only policies. What's lacking is a way t= o do this in the home router, so the PII winds up getting exported to the cl= oud not because that's necessary to accomplish the filtering but because it'= s the only available place where the translation from PII->policy can be don= e in practice. Unfortunately, solving _that_ problem is definitely out of s= cope for DNSOP. >>=20 > isn't the query path here: (largely) > client -> cpe-router -> provider-cache-resolver -> auth-dns >=20 > and at the cache->auth layer it's potentially the case that the provider c= an say: "use precision of /24" or "use precision of /17" ? So, there's reall= y not much "pii" that can be worried over at the provider-cache-resolver (th= ey already know who you are...) and they (provider) can decide how much gran= ularity is "important" to release to the upstream authoritative cache. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail-F8C906EF-94F0-4091-80F0-4A8D56E0A601 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
And then there are mobile phones with w= ifi and LTE tracking, already massively abused by AP's and companies like Ap= ple are randomising macs.

This draft is good for the ad business, not good f= or the enduser.

Paul

Sent from my iPhone

On Jul 25, 20= 17, at 02:59, Christopher Morrow <morrowc.lists@gmail.com> wrote:



On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon &= lt;mellon@fugue.com> wrote:
It wou= ld be nice if there were an RFC to point to that used a method that didn't i= nclude PII.   For the use cases of which I am ware, there is no need to= identify individual devices: only policies.   What's lacking is a way t= o do this in the home router, so the PII winds up getting exported to the cl= oud not because that's necessary to accomplish the filtering but because it'= s the only available place where the translation from PII->policy can be d= one in practice.   Unfortunately, solving _that_ problem is definitely o= ut of scope for DNSOP.

isn't the query p= ath here: (largely)
  client  -> cpe-router -> pro= vider-cache-resolver -> auth-dns

and at the cach= e->auth layer it's potentially the case that the provider can say: "use p= recision of /24" or "use precision of /17" ? So, there's really not much "pi= i" that can be worried over at the provider-cache-resolver (they already kno= w who you are...) and they (provider) can decide how much granularity is "im= portant" to release to the upstream authoritative cache.
= --Apple-Mail-F8C906EF-94F0-4091-80F0-4A8D56E0A601-- From nobody Tue Jul 25 00:51:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B102512F280 for ; Tue, 25 Jul 2017 00:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 e3cK20AnNfjU for ; Tue, 25 Jul 2017 00:51:06 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBC912EA95 for ; Tue, 25 Jul 2017 00:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=4YsxyVEIC9ueWQDQfVLFdCVW32YCyqLH7wT3WD9kAyY=; b=OX/b95QrE5Bw6qTn5os9GrnN4u1AHRF2z+a6gSAxd0vdBg/ilVP1YUdhkFqB1JDwSrvGJxtC0moeWqPn23AjjqbcojHeYV20YqGN6b8I0eqBX/TQCvF1BZXvCbgY7FeMaQGW/dPgi6wc5qzYJIPIY8rMn05przxkBeVRo3a6sgQ=; Received: ; Tue, 25 Jul 2017 00:51:03 -0700 To: Paul Wouters , Christopher Morrow Cc: dnsop WG , Ted Lemon , George Michaelson References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> From: Jacob Hoffman-Andrews Message-ID: <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> Date: Tue, 25 Jul 2017 00:51:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 07:51:08 -0000 I agree: The EDN0 Client ID draft seems quite bad from a privacy perspective, and I believe it should not be adopted. More broadly, enforcing content blocks with DNS is an anti-pattern. If we're assuming that the entity doing the content blocking has administrative access to DNS clients, they can simply install content blockers there. That allows much finer-grained blocked, like blocking individual pages rather than having to block all of Tumblr because of a request to block a single page. The draft even acknowledges the ineffectiveness of DNS-based content blocking: > DNS filtering products are easy circumvented and should not be > considered real security measures. With commonly available tools it > is trivial to discover the non-filtered DNS responses and use them in= > place of the filtered responses. So it seems incorrect to propagate a privacy-harming DNS extension that is ineffective at its stated goals. From nobody Tue Jul 25 01:07:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE7312F280 for ; Tue, 25 Jul 2017 01:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gf-0Zj-mmX5K for ; Tue, 25 Jul 2017 01:07:52 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C548F127978 for ; Tue, 25 Jul 2017 01:07:52 -0700 (PDT) Received: from [10.8.200.238] (unknown [136.179.21.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2DADA61FF3; Tue, 25 Jul 2017 08:07:52 +0000 (UTC) Message-ID: <5976FC55.10301@redbarn.org> Date: Tue, 25 Jul 2017 01:07:49 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Jacob Hoffman-Andrews CC: Paul Wouters , Christopher Morrow , dnsop WG , Ted Lemon , George Michaelson References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> In-Reply-To: <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 08:07:54 -0000 Jacob Hoffman-Andrews wrote: > I agree: The EDN0 Client ID draft seems quite bad from a privacy > perspective, and I believe it should not be adopted. > > More broadly, enforcing content blocks with DNS is an anti-pattern. If > we're assuming that the entity doing the content blocking has > administrative access to DNS clients, they can simply install content > blockers there. i think content blocking is a reach -- in your interpretation. this is about CDN. as in, how to decide which address record set to give a dns client, given that all you know is the recursive server address, yet you're trying to implement policy for an expected tcp session that might immediately follow. > ... The draft even acknowledges the ineffectiveness of DNS-based content > blocking: > >> DNS filtering products are easy circumvented and should not be >> considered real security measures. With commonly available tools it >> is trivial to discover the non-filtered DNS responses and use them in >> place of the filtered responses. > > So it seems incorrect to propagate a privacy-harming DNS extension that > is ineffective at its stated goals. your reasoning is flawed. there are indeed privacy problems here. the data miners and data scientists and aggregators of the world will have a much better idea which end user a dns request was generated for, in the case where all they see is above the recursive not below, and this option is used. that's a fine reason to oppose adoption. but it's got precious little to do with content filtering. as i wrote in a recent circleid article, dns-level content filtering will only work when end users believe that the recursive name server operator has aligned interests, and for that reason one shouldn't say "it's easy to bypass" but rather "end-user cooperation is required." this draft would be more adoption-worthy if it used similar language. see also: http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/ -- P Vixie From nobody Tue Jul 25 01:22:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9248F127978 for ; Tue, 25 Jul 2017 01:22:35 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 BD_2kshX1dcD for ; Tue, 25 Jul 2017 01:22:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1F6BB1200F3 for ; Tue, 25 Jul 2017 01:22:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xGrnz2PHxz3Nr for ; Tue, 25 Jul 2017 10:22:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1500970951; bh=7/+pvcqn6OkN+ivsLEyd7tqp201lOkodNHBzXcFSvRk=; h=Date:From:To:Subject:In-Reply-To:References; b=aw6/YU0++smls2ZCNnqWzuwghxbSzzBV+LGEPVZ2sPyXyEYi3E4vX9ldGeMgBzWE2 fF7mtcsnDJ/wZGUdl1K1rF1unUe9xd6mP0e8H2EFc/hxDh1BJUebxbAja/ojn1hU9n kmQ32ALD7UqAJNeASqfEgPfXG3/QGfEdWUxBgo4g= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jPd6vxl0lXQt for ; Tue, 25 Jul 2017 10:22:30 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 25 Jul 2017 10:22:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C8B9630AFA2; Tue, 25 Jul 2017 04:22:28 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C8B9630AFA2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B1FF240D3592 for ; Tue, 25 Jul 2017 04:22:28 -0400 (EDT) Date: Tue, 25 Jul 2017 04:22:28 -0400 (EDT) From: Paul Wouters To: dnsop In-Reply-To: <5976FC55.10301@redbarn.org> Message-ID: References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 08:22:35 -0000 On Tue, 25 Jul 2017, Paul Vixie wrote: > users believe that the recursive name server operator has aligned interests, > and for that reason one shouldn't say "it's easy to bypass" but rather > "end-user cooperation is required." So if 8.8.8.8 and your local ISP's nameserver do this to track you, what choice does an average enduser have? > this is about CDN. as in, how to decide which address record set to give > a dns client, given that all you know is the recursive server address, > yet you're trying to implement policy for an expected tcp session that > might immediately follow. This draft, unlike ECS, is about pinning individual users and tracking them. You saying this is needed for an optimized CDN based TCP stream is not fairly covering the use case of gathering PII. Because this option trasmits information that is meant to identify specific clients You should really have said "This draft attempts to link the DNS query to the individual TCP stream following to identify the specific user, to then apply specific filtering/censoring/protecting policies to the identified individual users (eg children, dissidents) for their own good". If you just wanted CDN optimalization, the ISP recursive server could simply use ECS. Paul From nobody Tue Jul 25 02:55:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C8A127010 for ; Tue, 25 Jul 2017 02:55:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 f7FUvKg2nrSe for ; Tue, 25 Jul 2017 02:55:16 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 96655131C35 for ; Tue, 25 Jul 2017 02:55:13 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id r14so50699545qte.4 for ; Tue, 25 Jul 2017 02:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0OgKzhEXkJ2Pit3wzKkBvvA9m07I3bJ78N0zrnshwLM=; b=atfGd2+YjbM7Oxa/dxu8WB59gAunoVMWPwdJonmGrvri9cIVctnklDZQSBHeIGgTLq frGxyceHo6gZUSlExTzn01/6KSTw5Zu9ZefdS2Cep5E9MG/RWnNzqJkfSHpGM7Sxwo0y BhhuCYOTiKr7T/5/T1S2jByDrzhSpLN9l7SW7OHT9nBT8GyGR81rI2VYnemKDLaTqZGn I370DG7x3PxMaMTkOyECYabiuIwHL9obDvR2XVK5kFaB0hWz2Tu5Z1+xdLQVpZb7Sb2e aqD7Oibj+DqRD5lHUNxoaMzul00fAWbtRIDSaKwnzil5Dk4GDgCDc1mH3Ji9ZN/OLBA2 K/sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0OgKzhEXkJ2Pit3wzKkBvvA9m07I3bJ78N0zrnshwLM=; b=T3K+SlwrCM0TojwKhLntF7ZR6D95dxJX7wMGnus88YEgd2UBtejTPVdzODCDXe3/1G QU9F7Qi11auhtKlI/hha8Z7weuu/8Fy9jtkPES1Mvt3c/ZOITy1dZsIHN4eJj+anYUxh j//hBaTsDxa46PgpkviV4aTGHJUmJ93Opue35vMuTeNh3bQT6N/XYvLq7Xm9to4MtTme 0DUkfbKDNOlgnAT8pToyBOqupnsJeTkhyrjvq3BoG8c5PyfhKSSnIuEipL3OC54Z65mU ZiAxmeqTqQx9VSXmupDXSM3S5hPR/hCAlRHySAao1s8Sj2hg9L67fMe1LCLSxIrRfL3K D+MQ== X-Gm-Message-State: AIVw110CFq2hFrNHcemZPAirzgZ4C7Nga95v3llUCYIeIMnwUdmNY17s cq525vbGhLE2DCLx X-Received: by 10.237.33.204 with SMTP id m12mr12745439qtc.249.1500976512504; Tue, 25 Jul 2017 02:55:12 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m41sm9905282qtc.78.2017.07.25.02.55.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 02:55:11 -0700 (PDT) From: Ted Lemon Message-Id: <7E291C54-9C0E-418F-A9A4-AB2FFB1700E6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5C827A3B-7CE7-4E82-A5AA-910A1702180B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Jul 2017 05:55:10 -0400 In-Reply-To: Cc: George Michaelson , dnsop WG To: Christopher Morrow References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 09:55:18 -0000 --Apple-Mail=_5C827A3B-7CE7-4E82-A5AA-910A1702180B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 24, 2017, at 8:59 PM, Christopher Morrow = wrote: > and at the cache->auth layer it's potentially the case that the = provider can say: "use precision of /24" or "use precision of /17" ? So, = there's really not much "pii" that can be worried over at the = provider-cache-resolver (they already know who you are...) and they = (provider) can decide how much granularity is "important" to release to = the upstream authoritative cache. There is no such thing as an upstream authoritative cache. The = filtering is being done at the cache. This is not client subnet: this = is client ID. So the cache, which is not authoritative, is receiving = PII about a specific client machine. Being able to filter the PII at = the CPE would indeed improve privacy in this case; the problem is that = the CPE has to have a UI or API that allows that to happen, and they = don't. The reason DNS filtering is useful is not that it is forced upon the end = user, but that it allows devices that use the default cache to get = filtering in a way that does not depend on the software installed on = them. So e.g. your IoT device can be infected by a worm but not = actually exfiltrate any private information to the attacker, because the = attacker's DNS is blocked. Being able to know that a particular device is a particular device is = actually quite useful in this context; unfortunately, there is no way to = distinguish "useful" and "personally-identifying". Even if you only = identify the IoT devices in your home, by doing so you reduce the search = space for identifying the other devices. --Apple-Mail=_5C827A3B-7CE7-4E82-A5AA-910A1702180B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 24, 2017, at 8:59 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
and at the cache->auth layer it's = potentially the case that the provider can say: "use precision of /24" = or "use precision of /17" ? So, there's really not much "pii" that can = be worried over at the provider-cache-resolver (they already know who = you are...) and they (provider) can decide how much granularity is = "important" to release to the upstream authoritative = cache.

There= is no such thing as an upstream authoritative cache.   The = filtering is being done at the cache.   This is not client subnet: = this is client ID.   So the cache, which is not authoritative, is = receiving PII about a specific client machine.   Being able to = filter the PII at the CPE would indeed improve privacy in this case; the = problem is that the CPE has to have a UI or API that allows that to = happen, and they don't.

The reason DNS filtering is useful is not that it is forced = upon the end user, but that it allows devices that use the default cache = to get filtering in a way that does not depend on the software installed = on them.   So e.g. your IoT device can be infected by a worm but = not actually exfiltrate any private information to the attacker, because = the attacker's DNS is blocked.

Being able to know that a particular = device is a particular device is actually quite useful in this context; = unfortunately, there is no way to distinguish "useful" and = "personally-identifying".   Even if you only identify the IoT = devices in your home, by doing so you reduce the search space for = identifying the other devices.

= --Apple-Mail=_5C827A3B-7CE7-4E82-A5AA-910A1702180B-- From nobody Tue Jul 25 06:53:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788D3131A7C for ; Tue, 25 Jul 2017 06:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 55ouGxLjiKsw for ; Tue, 25 Jul 2017 06:53:20 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 E81B51276AF for ; Tue, 25 Jul 2017 06:53:19 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id r14so53898558qte.4 for ; Tue, 25 Jul 2017 06:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uvQiZ57nysPR6lhLyeGvDPAtXNmq7SSidQLCB02+4d8=; b=ZKCtsDKk16uhZZl7mb1w14DyRR+ArDRY/12v0be5MDIYStI+EKITK9QZ6rbL1jYhvX gzY9irkQmkSmwQbZyTxe8uiivUpdvAfKeZd2Tp8r11Pfp8mXC78xIlw+c7uNeUu+qsZU S61tjULl8dGp6pjZLJaD5Cc8YUe1wDDxA/+1GdePLIfoNLzuszxdlvj/SwYofWuthu42 h6FduvDvGmZfnp5bkN7D1u88YdY9EtnWsEUAD55j95r3bPkGTPwVYGzrsT5hWDWOYjiY LSO3e0cjb/0HEkwuarO1VTDcVzLQpKIDFE1k2JPWgft5bAMGdORZNKujtCfLn4R1gQVz wZHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uvQiZ57nysPR6lhLyeGvDPAtXNmq7SSidQLCB02+4d8=; b=s/y6VE+QlT/whJwMwoBE+yYz/e4KbQTbYSzWLYKsTRHHISMS1YomolJ0vgm4dr1jDQ y5WwfmldsF5ObMRj0coKIzoakyDCzSGOrkWZLvsYMD7+7mdF74sfFR5I3qefdvfcXH1M mXel9jv1idhrUHcYMLionWWdH6SL7chFuKnbDOTj0NH02Sskjiy3ztb9ot1DdbZXdo0b o234xBDOvle0c6ysJoveKjDRqYpAhpdGOSCnzobaeEbS1za9f/DwTnsClVjWF56cVcgd rn5RZxcaUc0RFh6ibnSth6+ck343zwFS8HCSyaUN9yHyYQ97YWcRzTARj/RvMBi3gjQl m9sQ== X-Gm-Message-State: AIVw112dJXjjOgdB6/9+/dzwwTEHYoGpquuAbtjUYfLNwzggHu3Ph4eX HPijgb5Bwn/eW+0qEnmuEF6t1XBHpXgx X-Received: by 10.200.34.87 with SMTP id p23mr24222632qtp.279.1500990799098; Tue, 25 Jul 2017 06:53:19 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.99.115 with HTTP; Tue, 25 Jul 2017 06:53:18 -0700 (PDT) In-Reply-To: <7E291C54-9C0E-418F-A9A4-AB2FFB1700E6@fugue.com> References: <7E291C54-9C0E-418F-A9A4-AB2FFB1700E6@fugue.com> From: Christopher Morrow Date: Tue, 25 Jul 2017 09:53:18 -0400 X-Google-Sender-Auth: WQ1Z6B2Sp7emsc5uliHuHbc_rdQ Message-ID: To: Ted Lemon Cc: George Michaelson , dnsop WG Content-Type: multipart/alternative; boundary="001a11404b4c6439f5055524a729" Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 13:53:22 -0000 --001a11404b4c6439f5055524a729 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon wrote: > On Jul 24, 2017, at 8:59 PM, Christopher Morrow > wrote: > > and at the cache->auth layer it's potentially the case that the provider > can say: "use precision of /24" or "use precision of /17" ? So, there's > really not much "pii" that can be worried over at the > provider-cache-resolver (they already know who you are...) and they > (provider) can decide how much granularity is "important" to release to the > upstream authoritative cache. > > > There is no such thing as an upstream authoritative cache. The filtering > is being > apologies, 'upstream (from the cache resolver's perspective) authoritative SERVER'. > done at the cache. This is not client subnet: this is client ID. So > the cache, which is not authoritative, is receiving PII about a specific > client machine. Being able to > I agree with this, the cache resolver sees the client's IP address. > filter the PII at the CPE would indeed improve privacy in this case; the > problem is that the CPE has to have a UI or API that allows that to happen, > and they don't. > > I don't think the CPE is the answer, the cache-resolver CAN decide to send along in it's edns0 option: "1.2.128.0/17" instead of "1.2.3.0/24". Or it seems to me that this is a fine knob to add to resolver software... granted you'd need some extra config about your client subnets in use. > The reason DNS filtering is useful is not that it is forced upon the end > user, but that it allows devices that use the default cache to get > filtering in a way that does not > I don't believe the goal of the draft is to enable filtering. Certainly for a nation-state actor you could see: "Oh, now I know what subnets use the resolver over there, so I can limit useful replies, or steer requestors toward 'better/approved' content' > depend on the software installed on them. So e.g. your IoT device can be > infected by a worm but not actually exfiltrate any private information to > the attacker, because the attacker's DNS is blocked. > > you seem to be conflating a few things here... or using 'content filtering' in a different way here than before in this response. > Being able to know that a particular device is a particular device is > actually quite useful in this context; unfortunately, there is no way to > distinguish "useful" and "personally-identifying". Even if you only > identify the IoT devices in your home, by doing so you reduce the search > space for identifying the other devices. > > I don't think the draft is aiming at 'device' as much as 'region of the network'. The cache resovler COULD choose to send /32 (or /128) level data in the edns0 option, but that seems counterproductive, and a bit invasive. -chris --001a11404b4c6439f5055524a729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon <mellon@fugue.com> wrote:
On Jul 24, 2017, at 8:59 PM, Christopher Morrow <= ;morrowc.lists= @gmail.com> wrote:
and at the cache->auth layer it's potentially= the case that the provider can say: "use precision of /24" or &q= uot;use precision of /17" ? So, there's really not much "pii&= quot; that can be worried over at the provider-cache-resolver (they already= know who you are...) and they (provider) can decide how much granularity i= s "important" to release to the upstream authoritative cache.

There is no such thing as an up= stream authoritative cache. =C2=A0 The filtering is being

apologies, 'upstream (from the cache resolv= er's perspective) authoritative SERVER'.
=C2=A0
done at= the cache. =C2=A0 This is not client subnet: this is client ID. =C2=A0 So = the cache, which is not authoritative, is receiving PII about a specific cl= ient machine. =C2=A0 Being able to

=
I agree with this, the cache resolver sees the client's IP address= .
=C2=A0
filter the PII at the CPE would indeed improve privacy= in this case; the problem is that the CPE has to have a UI or API that all= ows that to happen, and they don't.


I don't think the CPE is the answer, the cache-= resolver CAN decide to send along in it's edns0 option: "1.2.128.0/17" instead of "1.2.3.0/24". Or it seems to me that this is a = fine knob to add to resolver software... granted you'd need some extra = config about your client subnets in use.
=C2=A0
The = reason DNS filtering is useful is not that it is forced upon the end user, = but that it allows devices that use the default cache to get filtering in a= way that does not

I don't= believe the goal of the draft is to enable filtering.
Certainly = for a nation-state actor you could see: "Oh, now I know what subnets u= se the resolver over there, so I can limit useful replies, or steer request= ors toward 'better/approved' content'
=C2=A0
depend= on the software installed on them. =C2=A0 So e.g. your IoT device can be i= nfected by a worm but not actually exfiltrate any private information to th= e attacker, because the attacker's DNS is blocked.

=

you seem to be conflating a few thin= gs here... or using 'content filtering' in a different way here tha= n before in this response.
=C2=A0
Being able to know= that a particular device is a particular device is actually quite useful i= n this context; unfortunately, there is no way to distinguish "useful&= quot; and "personally-identifying". =C2=A0 Even if you only ident= ify the IoT devices in your home, by doing so you reduce the search space f= or identifying the other devices.


I don't think the draft is aiming at 'device'= as much as 'region of the network'. The cache resovler COULD choos= e to send /32 (or /128) level data in the edns0 option, but that seems coun= terproductive, and a bit invasive.

-chris
--001a11404b4c6439f5055524a729-- From nobody Tue Jul 25 07:38:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2906131771 for ; Tue, 25 Jul 2017 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, 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=gmail.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 g_1TGM9vm86M for ; Tue, 25 Jul 2017 07:38:33 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 441C61270B4 for ; Tue, 25 Jul 2017 07:38:33 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d145so63303565qkc.2 for ; Tue, 25 Jul 2017 07:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=emeK4f/4DUS30gKyk4ayeiOvAmk1rZ/hjiJwKfHgQYk=; b=b32bowKRgA5EwaYSzDrKJ4tUMgGUM7lW7z9PHlVP+PDsMRR/3N0VBdNOIStAKfrl2l 9mEmOdXe3sZvJ72dB/Fn2h494zKdzxKvFR1xn+MJovsJVmQjYHvoyyNIZ5C2TKlKbGVz xpy/0me45ZgsHNzql7iuCbqfCZpKKDghq8Bj+VqO6KZ3BQ/5z8xt5A2aE5e3ntSC92/n tH3GTCU+zrppHftKusm3ydJf4pl51Dmio/7GwUoAfqtTl6Yw5tbnD6BgUgEQ4Wdv1aNc SRKyxXsqZXXgYzAEZ95ocGfKh9qFN35ta6FLHDKiGJ0b/eb0nTbMtfQV50pbX+caJjID ZDxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=emeK4f/4DUS30gKyk4ayeiOvAmk1rZ/hjiJwKfHgQYk=; b=AP3ptVi8xLR9nsCC6QpTUdFd6NG2bwQ/auUCdl7jdzzefcFOh/TsFDPMC/meBk5r9l pYVkm4vpqRBChpTwi0XDOVN9Q6egHI+IfDHNipCGx3fMd28ZNP/Tj5GFAjtaHcvJBT5p pA4Btu8Hsp++0VBlYRMVZQItKm2ADQoGBAw+N2wLeIeB0T+a1omquvMU2X9P4Hj/t18q iIQCRikGpwmF1hHhzj2h9J9SbD4L7S0RmIE+3Jkuv2HJ3W2dUm1ivLuz968SIpIgPstq 3GWYMXLoZB2iifNHGlidYxfmyvx9s+nxwY8+FoU1xqDzCIfTLttwdplhZKsuCpYdxngw w/oA== X-Gm-Message-State: AIVw1133c9qt/jPqrMwRodVNcpix8kSIVilzwqtpgbohTsx26V2+efRC hZu64SYDJa6irOl2rllHEPsewQU4jY65 X-Received: by 10.55.74.142 with SMTP id x136mr8954940qka.254.1500993512366; Tue, 25 Jul 2017 07:38:32 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.99.115 with HTTP; Tue, 25 Jul 2017 07:38:31 -0700 (PDT) In-Reply-To: References: <7E291C54-9C0E-418F-A9A4-AB2FFB1700E6@fugue.com> From: Christopher Morrow Date: Tue, 25 Jul 2017 10:38:31 -0400 X-Google-Sender-Auth: HdB_LFt2rzD8RfGcLS_gIHwT2ao Message-ID: To: Ted Lemon Cc: George Michaelson , dnsop WG Content-Type: multipart/alternative; boundary="001a114a826c1d693b05552549e2" Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 14:38:36 -0000 --001a114a826c1d693b05552549e2 Content-Type: text/plain; charset="UTF-8" darn, I keep reading 'client-id' as 'client subnet' :( back in my hole I go. On Tue, Jul 25, 2017 at 9:53 AM, Christopher Morrow wrote: > > > On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon wrote: > >> On Jul 24, 2017, at 8:59 PM, Christopher Morrow >> wrote: >> >> and at the cache->auth layer it's potentially the case that the provider >> can say: "use precision of /24" or "use precision of /17" ? So, there's >> really not much "pii" that can be worried over at the >> provider-cache-resolver (they already know who you are...) and they >> (provider) can decide how much granularity is "important" to release to the >> upstream authoritative cache. >> >> >> There is no such thing as an upstream authoritative cache. The >> filtering is being >> > > apologies, 'upstream (from the cache resolver's perspective) authoritative > SERVER'. > > >> done at the cache. This is not client subnet: this is client ID. So >> the cache, which is not authoritative, is receiving PII about a specific >> client machine. Being able to >> > > I agree with this, the cache resolver sees the client's IP address. > > >> filter the PII at the CPE would indeed improve privacy in this case; the >> problem is that the CPE has to have a UI or API that allows that to happen, >> and they don't. >> >> > I don't think the CPE is the answer, the cache-resolver CAN decide to send > along in it's edns0 option: "1.2.128.0/17" instead of "1.2.3.0/24". Or it > seems to me that this is a fine knob to add to resolver software... granted > you'd need some extra config about your client subnets in use. > > >> The reason DNS filtering is useful is not that it is forced upon the end >> user, but that it allows devices that use the default cache to get >> filtering in a way that does not >> > > I don't believe the goal of the draft is to enable filtering. > Certainly for a nation-state actor you could see: "Oh, now I know what > subnets use the resolver over there, so I can limit useful replies, or > steer requestors toward 'better/approved' content' > > >> depend on the software installed on them. So e.g. your IoT device can >> be infected by a worm but not actually exfiltrate any private information >> to the attacker, because the attacker's DNS is blocked. >> >> > you seem to be conflating a few things here... or using 'content > filtering' in a different way here than before in this response. > > >> Being able to know that a particular device is a particular device is >> actually quite useful in this context; unfortunately, there is no way to >> distinguish "useful" and "personally-identifying". Even if you only >> identify the IoT devices in your home, by doing so you reduce the search >> space for identifying the other devices. >> >> > I don't think the draft is aiming at 'device' as much as 'region of the > network'. The cache resovler COULD choose to send /32 (or /128) level data > in the edns0 option, but that seems counterproductive, and a bit invasive. > > -chris > --001a114a826c1d693b05552549e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
darn, I keep reading 'client-id' as 'client su= bnet' :( back in my hole I go.

On Tue, Jul 25, 2017 at 9:53 AM, Christopher Morrow = <morrowc.lists@gmail.com> wrote:


On Tue, Jul 25, 2017 at 5:55 AM, Ted Lem= on <mellon@fugue.com> wrote:
On Jul 24, 2017, at 8:59 PM, Ch= ristopher Morrow <morrowc.lists@gmail.com> wrote:
and at the cache->auth layer = it's potentially the case that the provider can say: "use precisio= n of /24" or "use precision of /17" ? So, there's really= not much "pii" that can be worried over at the provider-cache-re= solver (they already know who you are...) and they (provider) can decide ho= w much granularity is "important" to release to the upstream auth= oritative cache.

There is no= such thing as an upstream authoritative cache. =C2=A0 The filtering is bei= ng

apologies, 'upst= ream (from the cache resolver's perspective) authoritative SERVER'.=
=C2=A0
done at the cache. =C2=A0 This is not = client subnet: this is client ID. =C2=A0 So the cache, which is not authori= tative, is receiving PII about a specific client machine. =C2=A0 Being able= to

I agree with this, = the cache resolver sees the client's IP address.
=
=C2=A0
filter the PII at the CPE would indeed improve privacy in thi= s case; the problem is that the CPE has to have a UI or API that allows tha= t to happen, and they don't.


I don't think the CPE is the answer, the cache-= resolver CAN decide to send along in it's edns0 option: "1.2.128.0/17" instead o= f "1.2.3.0/24"= ;. Or it seems to me that this is a fine knob to add to resolver software..= . granted you'd need some extra config about your client subnets in use= .
=C2=A0
The reason DNS filtering i= s useful is not that it is forced upon the end user, but that it allows dev= ices that use the default cache to get filtering in a way that does not

I don't believe the go= al of the draft is to enable filtering.
Certainly for a nation-st= ate actor you could see: "Oh, now I know what subnets use the resolver= over there, so I can limit useful replies, or steer requestors toward '= ;better/approved' content'
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
depe= nd on the software installed on them. =C2=A0 So e.g. your IoT device can be= infected by a worm but not actually exfiltrate any private information to = the attacker, because the attacker's DNS is blocked.


you seem to be conflating a= few things here... or using 'content filtering' in a different way= here than before in this response.
=C2=A0
=
Being able to know that a particular device is a particular device = is actually quite useful in this context; unfortunately, there is no way to= distinguish "useful" and "personally-identifying". =C2= =A0 Even if you only identify the IoT devices in your home, by doing so you= reduce the search space for identifying the other devices.

<= /div>

I don't think the dr= aft is aiming at 'device' as much as 'region of the network'= ;. The cache resovler COULD choose to send /32 (or /128) level data in the = edns0 option, but that seems counterproductive, and a bit invasive.

-chris

--001a114a826c1d693b05552549e2-- From nobody Tue Jul 25 07:45:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8108E131CE7 for ; Tue, 25 Jul 2017 07:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 yJOjJL3iXRmT for ; Tue, 25 Jul 2017 07:44:58 -0700 (PDT) Received: from smtp109.iad3a.emailsrvr.com (smtp109.iad3a.emailsrvr.com [173.203.187.109]) (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 13913131CD0 for ; Tue, 25 Jul 2017 07:44:58 -0700 (PDT) Received: from smtp22.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4B53C6A29; Tue, 25 Jul 2017 10:44:53 -0400 (EDT) X-Auth-ID: bgreene@senki.org Received: by smtp22.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 5075868B3; Tue, 25 Jul 2017 10:44:51 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [10.107.174.135] ([TEMPUNAVAIL]. [36.84.70.252]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Tue, 25 Jul 2017 10:44:53 -0400 From: Barry Raveendran Greene Message-Id: <38A2F929-CEA5-460C-929F-EB715993FC25@senki.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DFAC50CA-EB57-45F9-9AFB-9EE886707E32"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Jul 2017 21:44:42 +0700 In-Reply-To: Cc: Ted Lemon , dnsop WG , George Michaelson To: Christopher Morrow References: <7E291C54-9C0E-418F-A9A4-AB2FFB1700E6@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 14:45:00 -0000 --Apple-Mail=_DFAC50CA-EB57-45F9-9AFB-9EE886707E32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 25, 2017, at 8:53 PM, Christopher Morrow = wrote: >=20 > I don't believe the goal of the draft is to enable filtering. The goal of the draft is to provide options. How those options are = deployed is between the customer and the operator as defined by their = contract. --Apple-Mail=_DFAC50CA-EB57-45F9-9AFB-9EE886707E32 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZd1lbAAoJEFVuk3AWv0XzeUYH/35uq3Io+gYbmNdeArhFGwnf gXFMrsEUQ9ZQMat6Q4mq/cFQyQLJmL7Mca4bAnWpZqlxYuaFl8h9qfCaFKa5kOtE 2wY3tmb0a5r33IRD2cn/ZSx6bdwIORR76oDtgq0sEGoRKaBOJAAEQVPKPGmFcdlx sBXNG7YtLZBPS82zYLjpac/dRudPgKJ5hPpctHLmxajtyeV7K9eWLvobXgZ8eVss rq1TANnTR9R7D4uTCJ+FQYNh1Ku9UOAQjmEkBSakSmDyY/nE/Iu4yJmf/+Y95Hw7 JdiAXyRIrP7U4Uw5JD8iVI7xOLgoJmEl/akwqWhajFugrpSNF+/Ny9mqE3KeG7M= =nKci -----END PGP SIGNATURE----- --Apple-Mail=_DFAC50CA-EB57-45F9-9AFB-9EE886707E32-- From nobody Tue Jul 25 09:01:28 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA75131DAE; Tue, 25 Jul 2017 09:01:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150099848605.26159.3205030418843126355.idtracker@ietfa.amsl.com> Date: Tue, 25 Jul 2017 09:01:26 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-extended-error in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 16:01:26 -0000 The DNSOP WG has placed draft-wkumari-dnsop-extended-error in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-wkumari-dnsop-extended-error/ From nobody Tue Jul 25 09:04:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444B4131CAD for ; Tue, 25 Jul 2017 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, 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=gmail.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 Rq5uygKyT663 for ; Tue, 25 Jul 2017 09:04:06 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 4E7BA131D15 for ; Tue, 25 Jul 2017 09:04:06 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id c184so60362453wmd.0 for ; Tue, 25 Jul 2017 09:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SKnEuzFG2N6DCYPiysqBrNOhPhUfv52ZsN9uQNUr1DE=; b=RJ+me++qwYRe7TavSjxL8olNWco0B8YrWHkLZQDVY9YiaF1RAqhDivHqkXPMzKOPJ8 zFsSyqO3NdAwU+5NfhQqhgLDNoZlmKWo3rp08jxhBL1cHRBtTXPrpM2+EZIsITw24/h6 wjXOPfqEYPMmVO91O6XXBA1NiyDabXbnZV/aiVGC254fYckxfWZF80h4wDXXIaI3RNwj S6Ftpn3qJYBZ4dSlymvxdxr2pncNEi+oIoDhO7OEsyFpEuKycoFND2VwfI2bYbWTtigR /csp/Kt3vF5ghPrTr0GdDzHJlucGcmLaddfMvpgdFAztxEDLLlcSEp27UOGE3oXEeT9b UYlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SKnEuzFG2N6DCYPiysqBrNOhPhUfv52ZsN9uQNUr1DE=; b=qm9okCHA9vI9wWS532XgeqW96S6GGr3UNDOWfeb211rK5DuBIS3ebku/tj8R1Z0t1g 96lZ9kF1GS+RU3OQnFtwDNqQwacJaUjmHcYc29VYJW7rogPxLpYD6tjwDc0QxZT7wj4B eTxadLVjmIY/osbHKG/Bbz2LvEtlRH0pJqjjHhseUv9xXTlgjVk52hceYxPaGAdUP2Hy XBB3a2+4LvKEsvaOdrvocSwkWe3ujg37SksbhMb+QYaEM8ka/cq1eyMqo36i9Bys/P+y PX1IpIr63ptqk2GyUkyY+slWZ3F9Ace0z38JyV46L3dkExQ1tcDLEyMAQ3xK/X3yT0il 0Vfw== X-Gm-Message-State: AIVw110NYipl1ae7FXip7pZ9ivY8wx1e9OZ7EKi+7d+MxESCxNYBkElw RnUgBNFl/idnKXjWB7jBghhkUlJ116PB X-Received: by 10.28.51.148 with SMTP id z142mr3050598wmz.92.1500998644712; Tue, 25 Jul 2017 09:04:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.139 with HTTP; Tue, 25 Jul 2017 09:04:04 -0700 (PDT) From: tjw ietf Date: Tue, 25 Jul 2017 12:04:04 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a1143bb8806cc050555267bfd" Archived-At: Subject: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 16:04:08 -0000 --001a1143bb8806cc050555267bfd Content-Type: text/plain; charset="UTF-8" This draft was the only one which seemed to have broad support in some form during the meeting last week. This starts a Call for Adoption for draft-wkumari-dnsop-extended-error The draft is available here: https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 8 August 2017, 23:59 Thanks, tim wicinski DNSOP co-chair --001a1143bb8806cc050555267bfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This draft was the only one which seemed to have broad sup= port in some form during the meeting last week. =C2=A0

This starts a Call for Adoption for=C2=A0draft-wkumari-dnsop-extended-error

The draft is available here:

Please review this draft to see if you think it is su= itable for adoption by DNSOP, and comments to the list, clearly stating you= r view.
Please also indicate if you are willing to contribute text, = review, etc.

This call for adoption ends: 8 August 2017, 23:59

Thanks,
<= span style=3D"font-size:14px">tim wicinski
DNSOP co-cha= ir


--001a1143bb8806cc050555267bfd-- From nobody Tue Jul 25 09:04:22 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7254131DA3; Tue, 25 Jul 2017 09:04:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150099865994.26087.15174709830936033323.idtracker@ietfa.amsl.com> Date: Tue, 25 Jul 2017 09:04:19 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-extended-error in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 16:04:20 -0000 The DNSOP WG has placed draft-wkumari-dnsop-extended-error in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document was previously in state Candidate for WG Adoption The document is available at https://datatracker.ietf.org/doc/draft-wkumari-dnsop-extended-error/ From nobody Tue Jul 25 11:29:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3DF131B3F for ; Tue, 25 Jul 2017 11:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=umich.edu 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 QbtdwtHvM-Xr for ; Tue, 25 Jul 2017 11:29:35 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 ACE33131CCA for ; Tue, 25 Jul 2017 11:29:35 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id x125so73607740ywa.0 for ; Tue, 25 Jul 2017 11:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2lFN1oedM0RO6Zf8WvegJ7wQpZbizcjlIB90GFAczSI=; b=mR84c2nr7/NeJUR2yJ29PIJlgNOQFkzH/D/0Hqm8ZUMtUJTc73Ls/XnclXJDRlcN1R URv7PmY0Azu2z4qeaHpHg+2RrdjZmtKXHKXzZwzRr1xSVqOXvOQqY2LCe2nN47kg8X0N tYCjQS9bM5ahCq9abA01ODwDfOCah7D8MZg9GugBM9On8bPa0mth1lZIwSlJDDX822B9 jITd0f/q3FoVmw1WyFg3V77GBFnWyHa2wezDbFb9dMhGI8lcovqYahZCPoW8bUHAKj/Z snrs5x3LN105+Vx0xUEST3udg8A9czS5V6mBuPxrV2Hj37NsjUbPYIUKyJhjcp4yRxLd uBbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2lFN1oedM0RO6Zf8WvegJ7wQpZbizcjlIB90GFAczSI=; b=M6JET9QYhN7sONdoRKREUbzAgT0Wnk6dX6xw/U1G2+UFCbf6Xvtjde4f98+tniVApn oxSO9L7DHcJK2bYiCTWWELajIjSYNPpWvCYH3dfJ3MUeVBOuMdk2H1HjSUPXgmgX96oh hrJXeaYLfpmB9JgVf7GwLkK+a3BO4K/v3tiJZaBQNW0dwtqXciZnfWUikp1i+X+Wy6Tj EL3MeKOlBgtzjNx0l0pdmNYKoxbs+KudqyZxEn3UN77kGvQL6GVM+XuEBa3NXoESMB1i uYnbiUP6oqvYn8c31NoZKQVwBWVzDoF1/lByCxHYJGBtoGsVxy/51E34lpSMQNZXKO9p by5Q== X-Gm-Message-State: AIVw113qRfNLbux+jpU8jyZjJtZL17T0gZZbMeDJ6YMTJFF38b+bcUjx H9Ww603WXDIDw50y6frnEv27t8S1t4Tb9nw= X-Received: by 10.13.240.4 with SMTP id z4mr17083309ywe.276.1501007374608; Tue, 25 Jul 2017 11:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.105.11 with HTTP; Tue, 25 Jul 2017 11:29:34 -0700 (PDT) In-Reply-To: References: From: Bob Harold Date: Tue, 25 Jul 2017 14:29:34 -0400 Message-ID: To: tjw ietf Cc: dnsop Content-Type: multipart/alternative; boundary="f40304360b165ea25d05552883af" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 18:29:38 -0000 --f40304360b165ea25d05552883af Content-Type: text/plain; charset="UTF-8" On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: > This draft was the only one which seemed to have broad support in some > form during the meeting last week. > > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > The draft is available here: > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 August 2017, 23:59 > > This appears to be useful. I will review and contribute. -- Bob Harold --f40304360b165ea25d05552883af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf <tjw.ietf@gmail.com> wrote:
This= draft was the only one which seemed to have broad support in some form dur= ing the meeting last week. =C2=A0

This starts a Call f= or Adoption for=C2=A0draft-wkumari-dnsop-extended-error

The draft is a= vailable here:

Please review this draft to see if you th= ink it is suitable for adoption by DNSOP, and comments to the list, clearly= stating your view.

Please also indicate if you are willing to contr= ibute text, review, etc.

This call for adoption ends: 8 August 2017,= 23:59

=

<= div class=3D"gmail_extra">This appears to be useful.=C2=A0 I will review an= d contribute.

--=C2=A0
Bob Harold

--f40304360b165ea25d05552883af-- From nobody Tue Jul 25 11:30:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CD8131EAA for ; Tue, 25 Jul 2017 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 Y5To_Rz-xEMj for ; Tue, 25 Jul 2017 11:29:57 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3E1131EA7 for ; Tue, 25 Jul 2017 11:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=G+AmBgrOZEoy9pISFVe/5tydxcacAUQ86Hsi4vfauFU=; b=TPUxf52e3v25Mga1TasDCab4hwaKoi/9XpbaOF7YA910eZplOdNUlcyWFHP2gT4Dbpu+5optcISm0QHUDn/JHyOxEU00eYu93ekXH4NNvp69fl3j9FWIG9z/hthgISql2p4aor9J0EazZOnA47anIw0QwATiI6xwSCtJs7c2UJY=; Received: ; Tue, 25 Jul 2017 11:29:52 -0700 To: Paul Vixie Cc: Paul Wouters , Christopher Morrow , dnsop WG , Ted Lemon , George Michaelson References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> From: Jacob Hoffman-Andrews Message-ID: <0bcc846c-129e-c7f8-503a-2a82eec278d5@eff.org> Date: Tue, 25 Jul 2017 11:29:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5976FC55.10301@redbarn.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 18:30:00 -0000 On 07/25/2017 01:07 AM, Paul Vixie wrote: > i think content blocking is a reach -- in your interpretation. > > this is about CDN. as in, how to decide which address record set to > give a dns client, given that all you know is the recursive server > address, yet you're trying to implement policy for an expected tcp > session that might immediately follow. Perhaps I'm reading the wrong RFC? I was basing my comments on https://tools.ietf.org/html/draft-tale-dnsop-edns0-clientid-01, which very explicitly talks about content blocking: > For example, a parental control service that restricts access to particular domains from particular devices needs to have a device-specific identifier. From nobody Tue Jul 25 12:21:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A046F131ED2 for ; Tue, 25 Jul 2017 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LMk0BiXP1S6I for ; Tue, 25 Jul 2017 12:21:23 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 44FB0131ED5 for ; Tue, 25 Jul 2017 12:21:23 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id r14so60028490qte.4 for ; Tue, 25 Jul 2017 12:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:embedded-html; bh=Eeh0BfmsE7EcCOVPer2ulk9FCT03x7HaljsY/eQT9ZI=; b=mhCvpO+U/4xFwaLkounjo5QtmFzsEH7XhWSoNh2s8p4ofCL+ssVBmOi970pp9vVvR6 nPTM6ds7FiK7MtpIsWC/P+UQlLzeFxt5URLrickhryV3pp9nNkSml1H4RRP7SGwwnlnp ohJ895box2Je61wakqoL1bP94pwfDf0xgkjGur4T6ACacVrXy5yIrRRE5wNMPcs205EB kBwyA3JcMK+CARJp6C18f6S5ufdfTNt0rlfEvTJ8/YntdOmICBgg1wEW/uGvIk/dQ9UD qSrz+TnrTvch+WROF/qlJnqYQkvp8GzN49dA2AAjlxSs0KuXjCoMHlLEPU48aI035Ig6 5HHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:embedded-html; bh=Eeh0BfmsE7EcCOVPer2ulk9FCT03x7HaljsY/eQT9ZI=; b=GO7IgIFzEq1naUSANBKu5yeKBLG/WOKiNVmncCKNw7l5mD99Esm+N4HlXB+hLC+r2m VNEl6yMPbXNMjjqH1D/rzqtUu38TtQTMzAnA8ORtM1SuSijYFQiorm22qnQF+RlO2avv k1SBkqp+aIVsq86yM1LkjDrlcTiUlsgk7S8p0kRQB/svvgHJL5YoGnui0rNHWCmKFPcU ADSjIS1hz2ahU7/c/OdvMrh2QoSB8mLWQCsI94sjoR1YlXl4sHovm/uW2FjW5DKQ6Acg ZYe/aMmAgVM6rLcKMFhHmsOrqdmyoRAiuVVmtHLQNDz00FO/RoS0YlXi7m0HkVPN6Gdu yScw== X-Gm-Message-State: AIVw111uGhX+5/qd6BDE5Fi0Gqeeq8z0U34hj/ydnQt+4bTCPrhTqC5A JXCYS4qrwevlEQ== X-Received: by 10.200.54.89 with SMTP id n25mr25561109qtb.219.1501010482328; Tue, 25 Jul 2017 12:21:22 -0700 (PDT) Received: from [200.7.87.103] ([2001:13c7:7001:7000:695e:32fc:eac4:2ba9]) by smtp.gmail.com with ESMTPSA id w24sm10845020qtc.49.2017.07.25.12.21.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 12:21:21 -0700 (PDT) From: "Carlos M. Martinez" To: "Bob Harold" Cc: "tjw ietf" , dnsop Date: Tue, 25 Jul 2017 16:21:17 -0300 Message-ID: <395CF43F-F516-4B2A-8D17-42323C5A2337@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E349D2E7-BC50-4FE5-A01E-6103FE4A6FDA_=" Embedded-HTML: [{"HTML":[1511, 2343], "plain":[195, 733], "uuid":"BDA752B0-3310-48A2-9408-3E8ECA2069E7"}] X-Mailer: MailMate (1.9.6r5383) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 19:21:26 -0000 --=_MailMate_E349D2E7-BC50-4FE5-A01E-6103FE4A6FDA_= Content-Type: text/plain; format=flowed I also support adoption. Current SERVFAIL messaging provides too little information for interested parties and makes debugging problems difficult. On 25 Jul 2017, at 15:29, Bob Harold wrote: > On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: > >> This draft was the only one which seemed to have broad support in >> some >> form during the meeting last week. >> >> This starts a Call for Adoption for >> draft-wkumari-dnsop-extended-error >> >> The draft is available here: >> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 >> >> Please review this draft to see if you think it is suitable for >> adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, >> etc. >> >> This call for adoption ends: 8 August 2017, 23:59 >> >> > This appears to be useful. I will review and contribute. > > -- > Bob Harold > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=_MailMate_E349D2E7-BC50-4FE5-A01E-6103FE4A6FDA_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I also support adoption. Current= SERVFAIL messaging provides too little information for interested partie= s and makes debugging problems difficult.

On 25 Jul 2017, at 15:29, Bob Harold wrote:

=
On Tue, Jul 25, 2017 at 12:04 = PM, tjw ietf <tjw.ietf@gmail.com> wrote:
This draft was the only one which = seemed to have broad support in some form during the meeting last week. =C2= =A0

This starts a Call for Adoption for=C2=A0draft-wkum= ari-dnsop-extended-error

The draft is available here:

Please review this draft to see if you think it i= s suitable for adoption by DNSOP, and comments to the list, clearly stati= ng your view.

Please also indicate if you are willing to contr= ibute text, review, etc.

This call for adoption ends: 8 August= 2017, 23:59


This appears to be useful.=C2=A0 I = will review and contribute.

--=C2=A0
Bob Haro= ld

________________________________= _______________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.= org/mailman/listinfo/dnsop

--=_MailMate_E349D2E7-BC50-4FE5-A01E-6103FE4A6FDA_=-- From nobody Tue Jul 25 12:26:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD2E12EBF4 for ; Tue, 25 Jul 2017 12:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 R7D8m2TJ8AzP for ; Tue, 25 Jul 2017 12:26:35 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3633B124234 for ; Tue, 25 Jul 2017 12:26:35 -0700 (PDT) Received: from [10.8.200.238] (unknown [136.179.21.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id EF8C761FF3 for ; Tue, 25 Jul 2017 19:26:34 +0000 (UTC) Message-ID: <59779B68.2000906@redbarn.org> Date: Tue, 25 Jul 2017 12:26:32 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: dnsop References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 19:26:37 -0000 Paul Wouters wrote: > On Tue, 25 Jul 2017, Paul Vixie wrote: > >> users believe that the recursive name server operator has aligned >> interests, and for that reason one shouldn't say "it's easy to bypass" >> but rather "end-user cooperation is required." > > So if 8.8.8.8 and your local ISP's nameserver do this to track you, what > choice does an average enduser have? some of run our own rdns. some use vpn's. some use opendns or similar. > Because this option trasmits information that is meant to identify > specific clients and that's a reason to oppose adoption, as far as i'm concerned. > You should really have said "This draft attempts to link the DNS query > to the individual TCP stream following to identify the specific user, > to then apply specific filtering/censoring/protecting policies to the > identified individual users (eg children, dissidents) for their own > good". that's a significant overstatement. the user is more likely to send an http cookie than to have the rdns server send a per-user ID on their behalf. moreover, parental controls are a fig leaf, almost a joke, and so is dns-level filtering. as i wrote the other day: << I fought SOPA not because I believed that content somehow "wanted to be free", but because this kind of filtering will only be effective where the end-users see it as a benefit see it, in other words, as aligned with their interests. >> http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/ when you invoke "for their own good" you're worrying about internet unilateralism that does not actually or in any effective way exist. if tale wants to create a signaling pattern that's so bypassable that noone will ever use it unless they want its impacts, let him. -- P Vixie From nobody Tue Jul 25 12:46:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7302312FEE2 for ; Tue, 25 Jul 2017 12:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=quotient-inc-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 swEqITRojmZy for ; Tue, 25 Jul 2017 12:46:51 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 4EE7812EBF9 for ; Tue, 25 Jul 2017 12:46:51 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v205so39832905itf.1 for ; Tue, 25 Jul 2017 12:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quotient-inc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QmjyC8ibpE/OkjjWw2RD8Y2jV4N2iNrYqVFYC8grZFU=; b=zxTPEBVR9HgSs0zeDb2enuUNfBQDUUMdDCzC+ICE35i+Tx4EZcij1kFVUOsp6Evnd/ 484C/+F7G3lK0c0UveE9dk7z9JzxP+MaWW0rXd0Sn8TY7Bb/HBO9A13S43EVnL4h7a+b Ie+wvaGMpNexMvT5fb5chzQ8hAdDbt8zrphGiBmXXTCyZ7L4QD/yM2eiUfTSPVP4RbE7 X2bqZLEhNrOqGZqdf0aU8CPMcarIBaa+f+JgElZziVwgMLqINLgiIzOLdKnunl4aMXa5 oJl/9Jq/pywTbrOKgJd/5fAvZKXp2Ac45TMxbnYmkC0BU2HZ9OC3kHWhneTIlpBAJUVJ c3uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QmjyC8ibpE/OkjjWw2RD8Y2jV4N2iNrYqVFYC8grZFU=; b=A+59IvJ+XZA1bcCUFBKNfERnCPtgaCkDy1epCojz5FirGgLTCqje3RbxrspEcPQ5Jf +SpeZtaHbURkrWMq9PErtk+itWEqYGv+ZKNPpdjL2OVUBMzPgBUXHsR9cG9m34FSRIAg auiVDkEvMOFc6Pr9eFhCV1pPrez6ww6OWt5UVjkKR56N/NXIuDABsD53eSak0a39Idbu NV0jz6Dg9PDb2EjksJhOJhLiVDF0xTzOsSOcTQ/GlARCpRv4E3rZbmpYMqWYpEuVq/Wi XlTM7tmAw9T2cdVYeGTC2XVNN+EE6dGbWrxalEHFeJE+Hx9UrKN/At1aCxkURNaWcFpY rxHQ== X-Gm-Message-State: AIVw1116RQrhs6pflZuewSwDzSzSrgPgb1b4ZvaV4l0ODFs8PwZG89xY C1TGqmIgGrynfMuvwx+hWU5Bn1KnyjwU X-Received: by 10.36.189.198 with SMTP id x189mr12040248ite.56.1501012010514; Tue, 25 Jul 2017 12:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.67 with HTTP; Tue, 25 Jul 2017 12:46:50 -0700 (PDT) In-Reply-To: References: From: Peter DeVries Date: Tue, 25 Jul 2017 15:46:50 -0400 Message-ID: To: tjw ietf Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c19e22cb0d28005552997b5" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 19:46:53 -0000 --94eb2c19e22cb0d28005552997b5 Content-Type: text/plain; charset="UTF-8" I have read the draft and support adoption. I plan to review and contribute. Peter On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: > This draft was the only one which seemed to have broad support in some > form during the meeting last week. > > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > The draft is available here: > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 August 2017, 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --94eb2c19e22cb0d28005552997b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have read the draft and support adoption.=C2=A0 I plan t= o review and contribute. =C2=A0

Peter

On Tue, Jul 25, 2017 at = 12:04 PM, tjw ietf <tjw.ietf@gmail.com> wrote:
This draft was the only one which se= emed to have broad support in some form during the meeting last week. =C2= =A0

This starts a Call for Adoption for=C2=A0draft-wkumari-dn= sop-extended-error

= The draft is available here:
https= ://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02<= br>

Please review this draft to see if you think it is suitable for adoptio= n by DNSOP, and comments to the list, clearly stating your view.

Pl= ease also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 8 August 2017, 23:59

Thanks,<= /div>
tim wicinski
DNSOP co-chair



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--94eb2c19e22cb0d28005552997b5-- From nobody Tue Jul 25 13:42:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0D131EF1 for ; Tue, 25 Jul 2017 13:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wuLP61N0o5zu for ; Tue, 25 Jul 2017 13:41:59 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE8B131EE7 for ; Tue, 25 Jul 2017 13:41:59 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id 6A31B12C1466; Tue, 25 Jul 2017 16:41:58 -0400 (EDT) Date: Tue, 25 Jul 2017 16:41:58 -0400 From: Robert Edmonds To: dnsop@ietf.org Message-ID: <20170725204158.isyxgyb7l5d5degr@mycre.ws> References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> <59779B68.2000906@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59779B68.2000906@redbarn.org> Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 20:42:01 -0000 Paul Vixie wrote: > Paul Wouters wrote: > > On Tue, 25 Jul 2017, Paul Vixie wrote: > > > > > users believe that the recursive name server operator has aligned > > > interests, and for that reason one shouldn't say "it's easy to bypass" > > > but rather "end-user cooperation is required." > > > > So if 8.8.8.8 and your local ISP's nameserver do this to track you, what > > choice does an average enduser have? > > some of run our own rdns. some use vpn's. some use opendns or similar. The internet now has billions of users. With the possible exception of OpenDNS who have gone to admirable lengths to populate their knowledge base with device-specific configuration instructions [0], I don't think any of the choices you've listed are available to the "average enduser", who almost by definition lacks the specialized technical knowledge needed to select an alternative DNS resolution provider. [0] https://support.opendns.com/hc/en-us/categories/204012907-OpenDNS-Device-Configuration -- Robert Edmonds From nobody Tue Jul 25 13:53:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4193B131EFF for ; Tue, 25 Jul 2017 13:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org 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 gDU19ZoSNwKk for ; Tue, 25 Jul 2017 13:53:00 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::156]) (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 74A43131EFA for ; Tue, 25 Jul 2017 13:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:Cc:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=aUUPO0CZgqvKXO5RpG8ao04jK3eI135BctJQFsjtnEQ=; b=mGScyU2Cg5mSNdcLH3L2N0JfwW X0XeiImLKPLTikvTuDiD080Se4+HZ2DSKqlC6ibdBUYGQC97Dydx7WafYh+f8uuK9q+3JYhCVHKbS cd6KXNxXiBpsQWtNrVyQB6cmsnfemuN7DbzPzkNj6Jf+F97a1OgeKu2nRnVewUQzrELYREOVVUGEP KFwu38swkWLaZaeC4fCyTxC/NG/5h1SyNW/8EK6UjkCwrGpHiGN19O2qu9bZRZeRSq3aPjtVR5CZs H9ZHr6RbpA/AVosPTy9alXEuwM3QDipKvvMsYJRh3Jx12y4bQDt4tYH9b4ODWL8VP317FejWKbhMU WnK68xkg==; Received: from [2607:f2c0:101:202:8013:ad3e:5316:1b92] (helo=node-131fee54bx1ng9lsb6.ipv6.teksavvy.com) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1da6p7-000DZc-NK; Tue, 25 Jul 2017 20:52:58 +0000 From: Joe Abley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <083C34A2-92B9-4A9F-A331-9C38E22417C7@hopcount.ca> Date: Tue, 25 Jul 2017 16:52:56 -0400 To: dnsop@ietf.org X-Mailer: Apple Mail (2.3273) X-SA-Exim-Connect-IP: 2607:f2c0:101:202:8013:ad3e:5316:1b92 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false Archived-At: Subject: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 20:53:02 -0000 Hi Richard, all, I foolishly allowed Tim to pay for lunch and therefore have been tricked = into doing actual work. There are a couple more of these inbound to the = list, one for each of the e-mails containing points that were found not = to have been addressed in -04. My goal is to identify some kind of = consensus on each this week and the propose some actual text. With reference to: = https://mailarchive.ietf.org/arch/msg/dnsop/_W6ois9hFYlAWUmka21FX91910s > - There is no mechanism for signaling section 4.1/ section 4.3 = "partial > response" behavior to clients (e.g., a new OPT record EDNS header = flag > bit > = > ). Correct. I presume you are suggesting that there should be one. I have = not heard anybody else require such a thing, and new EDNS code points = are thought by at least some to be thorny things to pass undigested = through middleboxes so I think it's a non-trivial suggestion that would = require a proposal that itself would need thorough review. That feels = out of scope for this document, but perhaps something analogous to = extended RCODEs in the sense that it's channel metadata. I think it would be uncontroversial to note explicitly that the = mechanism described in this document contains no such signalling, = however. Let me know if that seems like a pragmatic solution. > - Insisting that the HINFO OS field SHOULD be empty ("set to the = null > string") seems a little too strong; there's room in it for=E2=80=94an= d value > from=E2=80=94a short explanation (e.g., as can be observed today: > =20 > dns.cloudflare.com > . 3789 IN HINFO "Please stop asking for ANY" "See > draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS field > of the HINFO > RDATA SHOULD be short to minimize the size of the response, and MAY = be > empty or MAY include a summarized description of local policy." I am happy with that text. Unless there are violent objections from the = assembled throng, I will make that change. > - "Conventional [ANY] response" is used but not defined. I am not sure why it's ambiguous without a definition. To me that phrase = seems pretty straightforward; if your core objection is that the DNS = standards are not written down with great accuracy, yeah. The only = definition I can think of really is something like "A response to a = query that had QTYPE=3DANY which follows convention" which just seems = longer, not more clear. What did you have in mind? > - "ANY does not mean ALL" is misleading=E2=80=94RFC 1035 > < > https://tools.ietf.org/html/rfc1035#section-3.2.3> > is clear about > QTYPE=3D255 being "a request for *all* records" (emphasis mine). = That > said, the proposed *response* behavior is consistent with that RFC. All records that the server constructing the response knows about? All records that the server can fit into the response given the = constraints of the available transport? ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to = Blackadder the Second that probably pleases nobody but me. ("Kill Bob!" = "Never!") I think to that point we can implicitly acknowledge between ourselves = that less ambiguity would be nice, but that on the whole this text as-is = at worst does no harm, and at best helps illustrate the philosophy of = the approach being described. Let me know how much of that you can live with :-) Joe From nobody Tue Jul 25 13:53:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E75131F2D for ; Tue, 25 Jul 2017 13:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org 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 3EWJB7MC9CRV for ; Tue, 25 Jul 2017 13:53:15 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::156]) (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 23EBA131F10 for ; Tue, 25 Jul 2017 13:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:Cc:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CU/hF5ciVAw+XuJDzwEv6MoX1zA25NIDq2umxw2Chpw=; b=xoZdE6+cX2QyNLunn1bw/vSmpG Wy6lWZwaiCnzcRLM+srD0dmXRBbp/n8h02JFJT6Dg8aw+3uhqUK3tLf5exb995M7CgsRiHbJlIe2M 1vdIDV2CEVKyZ6Znv+oJMmyR8GXTnR8OFFfYv5jE+6basanOe0eyjSXBM1+sOyP/xYvfy3ubXW/yb +lkzBHJ9nG5ZLxRy4j4YxZ+QAzyokkwLBZQpf9ywRvAjdib64lUcTXz6yw+alXCO4mBAkl/ikOBvX MAsqXHIzahoEuHh7lEb92uWP9gFeYIA7Z0cCB8V9QCa2kDPwLGJno0eHKv22OU2O61h7A9RBbSRvx yJvhGwsw==; Received: from [2607:f2c0:101:202:8013:ad3e:5316:1b92] (helo=node-131fee54bx1ng9lsb6.ipv6.teksavvy.com) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1da6pC-000DZc-Tt; Tue, 25 Jul 2017 20:53:03 +0000 From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 25 Jul 2017 16:53:02 -0400 To: dnsop@ietf.org X-Mailer: Apple Mail (2.3273) X-SA-Exim-Connect-IP: 2607:f2c0:101:202:8013:ad3e:5316:1b92 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false Archived-At: Subject: [DNSOP] draft-ietf-dnsop-refuse-any: points from Stephane Bortzmeyer X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 20:53:17 -0000 Salut Stephane, tout le monde, With reference to: = https://mailarchive.ietf.org/arch/msg/dnsop/wwQV0yUMdx1mwO8ig9UyNbMMMWI > My personal nits, only editorial: >=20 > > "ANY Query" refers to a DNS meta-query >=20 > meta-query is not defined in this document, in RFC 1034, 1035 or > 7719. Opinion: just "query". >=20 > > Below are the three different modes of behaviour by DNS responders > > for names that exists that are used, listed in the order of > > preference >=20 > Is it obvious for everyone that it is the decreasing order (most > preferred first)? Thanks for those suggestions -- I will apply a gentle sponging action to = the text and make it shinier in all three cases. > > Implementers SHOULD provide an option for operators to specify > > behavior over TCP. >=20 > If this is because, with TCP, you have some certainty about the client > address, and therefore do not risk reflection attacks, then I suggest > to replace TCP by "transports that provide some guarantee about the > authenticity of the source IP address, such as TCP or DNS cookies". I think mentioning other future transports is sensible. I also take = fanf's point that ability to believe that a source address is legitimate = is not the only reason for wanting this behaviour. Perhaps the middle = ground is to acknowledge that the approach is applicable to multiple = transports, but that implementors SHOULD provide individual controls for = each transport to accommodate the full range of desired behaviours? Joe= From nobody Tue Jul 25 13:53:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA31131F2D for ; Tue, 25 Jul 2017 13:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org 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 Qzs2x_G3-Yz9 for ; Tue, 25 Jul 2017 13:53:26 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [67.215.197.156]) (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 CB676131F02 for ; Tue, 25 Jul 2017 13:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:Cc:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=QOM5e4UmvAxvkosgz18VD+Y1UPwtMrsNOe3AqpZ/4GA=; b=qCN+dK/85AkStkeLcUk0cKr7+t jQ8xxDs7AvrSxtU4qVzNQZvanmNnwOKc6n0gpK9UH7Y47cAe7c4KFehLZwTZdeNrL+pOAZ0FgT/8X qDXb+AwoHBmvds2AzteV5oQch1iS9ZqWGNgFHAvfSVnzULVa2f6dgRsy48TG8QWlHXKOdQgGSvKMT wLgVkhkYmBzHQqbE/jg2lEyOR5c+u4FlnfCXUQ3EQEbmC0xLY+FlbNztwWOp8bq9pZKZngDk/6KGi R8IP/2n3hz8zRE68NaiE57Ro43bMTd9QIuqplU95ezJqE7MkmIRmJG2K6PvPgtnNpgVePm4ecDymN q56UvHmQ==; Received: from [2607:f2c0:101:202:8013:ad3e:5316:1b92] (helo=node-131fee54bx1ng9lsb6.ipv6.teksavvy.com) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1da6pH-000DZc-8a; Tue, 25 Jul 2017 20:53:07 +0000 From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9002F172-4171-41EE-A0FF-61C7A5ACAD32@hopcount.ca> Date: Tue, 25 Jul 2017 16:53:07 -0400 Cc: =?utf-8?B?UGV0ciDFoHBhxI1law==?= To: dnsop@ietf.org X-Mailer: Apple Mail (2.3273) X-SA-Exim-Connect-IP: 2607:f2c0:101:202:8013:ad3e:5316:1b92 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false Archived-At: Subject: [DNSOP] =?utf-8?q?draft-ietf-dnsop-refuse-any=3A_points_from_Petr?= =?utf-8?b?IMWgcGHEjWVr?= X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 20:53:28 -0000 Hi Petr, all, With reference to: = https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg > 1. The casse QTYPE=3DRRSIG should be made more prominent so it is > understood and not misused as ANY. There are implementations like Knot > Resolver which are work around missing RRSIG records in replies using > QTYPE=3DRRSIG. >=20 > Personally I would rename the document from > Providing Minimal-Sized Responses to DNS Queries that have QTYPE=3DANY= > to > Providing Minimal-Sized Responses to DNS Queries > that have QTYPE=3DANY or QRTYPE=3DRRSIG >=20 > ... and extend Abstract as well: > The Domain Name System (DNS) specifies a query type (QTYPE) > "ANY" or "RRSIG". The operator of an authoritative DNS server might > choose not torespond to such queries for reasons of local policy, > motivated by security, performance or other reasons. >=20 > 2. Section Updates to RFC 1035 should use normative language, = especially > regarding RRSIG. Proposal follows: > RRSIG queries have the same potential as ANY queries of generating > large answers as well as extra work. In the wild there are > implementations that return REFUSE, others return single RRSIG, = etc. > It is RECOMMENDED returning a single RRSIG in this case. >=20 >=20 > 3. Text about necessity of fallback in applications trying to use ANY > query is burried under non-descriptive section name "Motivation". = Given > the confusion is caused among application developers, I would like to > see it mentioned and explained again in section "Behaviour of DNS > Initiators". >=20 I understand the points you're making, and I've read fanf's subsequent = reaction to it (and your reaction to that). I don't have any objection to any of those suggestions, and I'm quite = happy to come up with text for them in the next rev of the draft (thanks = for your suggestions in 1 and 2). If anybody else here has thoughts = about specific text or violent objections to including QTYPE=3DRRSIG in = general, please let me know (I looked in the mail archive but couldn't = find any there). The general approach I am picturing is one in which the issues for ANY = and RRSIG are both described, but that implementors are free to address = just one if they have particular circumstances that make that sensible. = As we discuss (see Stephane's points) in the case of multiple = transports, perhaps we can also recommend that implementors provide = configuration options to allow administrators to deal with ANY, RRSIG, = neither or both. That way we get flexibility that matches deployment, = but we also get a reference for handling RRSIG in a predictable way. Joe= From nobody Tue Jul 25 13:53:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E718D131F0E for ; Tue, 25 Jul 2017 13:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org 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 Ej330_8_ysvr for ; Tue, 25 Jul 2017 13:53:39 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [67.215.197.156]) (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 BC3C1131EFC for ; Tue, 25 Jul 2017 13:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:Cc:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q60no94Ndy5d5yZOecV6Kr/Uee8Y+zl8b3affHH1SEA=; b=UGMhautxkdTIbDeEjMKKl4cl4T 8V22rbTDUsgIYkBt5eXu2eGQyrlKNvRQ2hjcqpDBCIUzbupPSUy7HkVkeYiqb9l8+7W/G/8nGziUo JiiGHgdSCnsXROyrbn+aHwF/AA1XfPIlS+a3ipXGQoErtd+rjNDSsKutx9y50QILh+oBw2rpAFGow 1QTrWYaikPP3JiHJLIgYQzGSZQ/Hndtei8KiV0U02i1CjEO4UPAgZasq72mogdH6gbYapWaWP0CPp ewE82QF+jS8Z9Y7TZIH9VP+JFAnEOg/BtBbexMnoBvYLGmQJjl82XwHtnvBOMZVjpd/vn6juaYqSf lxLwDRUA==; Received: from [2607:f2c0:101:202:8013:ad3e:5316:1b92] (helo=node-131fee54bx1ng9lsb6.ipv6.teksavvy.com) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1da6pN-000DZc-1D; Tue, 25 Jul 2017 20:53:13 +0000 From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <08EEC562-8BD2-4485-9D7D-73665CF94EC5@hopcount.ca> Date: Tue, 25 Jul 2017 16:53:12 -0400 To: dnsop@ietf.org X-Mailer: Apple Mail (2.3273) X-SA-Exim-Connect-IP: 2607:f2c0:101:202:8013:ad3e:5316:1b92 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false Archived-At: Subject: [DNSOP] =?utf-8?q?draft-ietf-dnsop-refuse-any=3A_points_from_?= =?utf-8?b?56We5piO6YGU5ZOJ?= X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 20:53:41 -0000 JINMEI-san, all, With reference to: = https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k > I've reviewed the 04 version. I still do not think it's ready to move > forward as it still abuses HINFO. I understand some other people > don't care about this point, and some others may even love the idea > (those who are using it right now). But I've also seen yet some other > people have the same concern, so it shouldn't be only me. I don't > think we have a clear consensus on this point yet. The draft at present doesn't require an implementer to abuse HINFO; it = provides options to avoid doing so whilst still meeting the described = objectives of the proposal. Since abusing HINFO is not mandatory, I = presume you are objecting to the proposal sanctioning such shenanigans = at all. If I have that right (please correct me if I'm wrong) I don't think I am = the right person to make the call, being just a lowly document scribe. = If this remains a concern for you, I suggest that we defer that question = to our chairs and ask them to gauge consensus. My own personal views of = pragmatism vs. elegance shouldn't enter into it; this is a working group = document. > To be hopefully a bit more productive, I have a specific counter > proposal: remove the mandatory text about the use of HINFO, e.g., >=20 > - remove this bullet from section 4 > 2. A DNS responder can return a synthesised HINFO resource record. > See Section 6 for discussion of the use of HINFO. > - remove ', in which case...' from Section 4.2 > If there is no CNAME present at the owner name matching the QNAME, > the resource record returned in the response MAY instead be > synthesised, in which case a single HINFO resource record SHOULD be > returned. >=20 > In fact, in terms of externally observable behavior, synthesizing > HINFO is just one form of "selecting one RRset of the QNAME"; the > HINFO is added and immediately removed at the time of answering the > ANY query, so in that sense we don't have to bother to mention it with > normative keywords. This text suggests that my interpretation above is wrong, and what you = are objecting to is just the way that the HINFO approach is described. I = think the specification is more clear if we spell out the whole = synth-HINFO approach in its entirety and don't try to subsume it into = the "return a subset of { RRSets that there } u { RRSets that we just = synthesised }". Again, I am not entirely confident that I understand your concern, so = both my reactions above might be nonsense. Please try again if it seems = that I don't understand your point. > Regarding the choice of HINFO in case of synthesizing, it may make > sense to specify a particular type as part of normative spec if many > other implementations are going to implement it. But, as Section 8 > explains two major general purpose open source implementations, NSD > and BIND 9, seem to only support the "subset" approach. I suspect > it's actually not feasible for those generic implementations to > hardcode HINFO as long as their users could also use that type as > "real zone data". Some special purpose implementation with full > control on what it configures, like in the case of Cloudflare, may > freely explore the approach of synthesizing HINFO at their discretion. > But I don't think it necessarily has to be a part of normative part of > this spec, at least at this moment. I am not sure I understand the benefit of not including it, given that = it is observable behaviour for a large number of domains today (even if = that is so due to the volume of domains hosted at a single operator). I = think we do better service to operators and implementors by describing = what is implemented. As you point out, Cloudflare's implementation may = be less general-purpose than BIND9 or NSD, and that might be a reason = for the implementation choices to be different. Cloudflare is unlikely = to be the last non-general implementation, however, so perhaps the = mechanism most appropriate there will be relevant to others. > I've also noticed a couple of other points I raised in my previous > review ( > https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html > ) > were not yet addressed. These are (section numbers are for 03): >=20 > - Section 3 >=20 > 1. A DNS responder can choose to select one or subset of RRSets at > the QNAME. >=20 > 'one or subset of RRSets' sounds a bit awkward to me I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a = subset" seems wrong, actually; since some vestigial fragment of a set = theory lecture in the depths of my pre-history is telling me that the = empty set is always a valid subset. > - Section 4 >=20 > A DNS responder which receives an ANY query MAY decline to provide = a > conventional response, or MAY instead send a response with a single > RRSet in the answer section. >=20 > "a single RRSet" doesn't seem to be fully consistent of "one or > subset of RRSets" stated in the preceding section (see the previous > bullet). Agreed. That should be made consistent. Joe From nobody Tue Jul 25 16:01:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AB4132011 for ; Tue, 25 Jul 2017 16:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 CEW2kzAsqegQ for ; Tue, 25 Jul 2017 16:01:08 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 D9F59131F81 for ; Tue, 25 Jul 2017 16:01:07 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id k43so74293711uaf.3 for ; Tue, 25 Jul 2017 16:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=cNExM445VYfJgvedn6jy+bIL+72WUrmDEHy3tA84hME=; b=wfdVyLlkgBmLPqvNjL1a4LyzUNBrru7hLLE4XJSORYJ3HhIcBN/jXI4L6SK473hPtE oS+ihRE11KXXw7IzF0KMo4VJuGb2W8IkyjjDjzpiuauYmLy0BxRzFx8U123fM4w4c8hf LdEytUwIzmErq1y62bnXU54kTT6w79Po3NPxsTUQacCMaNwS9XwD0skVWSzm6dWvme8W YzSJlywjXfqIGTr4tWlvsRssY/dYadzPqHfoOHos8rnwbg1rlPyZqnuBottKogwwHdRZ YB3sOSfuiSrhZVum8s7KwLN1dJSxkmpw63+XxIhhcglUFJExb6rV3NXpodfV47cAGUCW H5OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=cNExM445VYfJgvedn6jy+bIL+72WUrmDEHy3tA84hME=; b=fIFTJQM1H0KdZeEHJVCyQZ63kAJDohTZDvIU2RmTTx1U0/k0pPb8ZdXUPVv+2xGFbh R1i9egvmdrhdH7x7O3ygZj65cU7UUy7JSUGxOylRqw3/ihgOY1tIAC3TDIoBM4LC6Rmq 4y6IuizF972pGKvICuMWyvo4/Rg1redXyLmxuJpmBwgg0ZJr3ARJ00/TaKj4KW2tkoyB MCi7zfvA4FQfs6aWVtmF6plG9HAtH/hzkBr0YoBFM2i5B/8SKnXPb4jEux332UONMXbO /B9zctNaViiC6I35B6tFWw7innLagr8QwP3+pa0MpoesbD4GsQhAY7b1NiRRVFeO7+Vs f77w== X-Gm-Message-State: AIVw1138h0M3HRGXxzJva1O4ku1GvwXXufQW8kaH7uImw+NX2xsXxuuJ x6JAcWn70nENali3ga3g/P3NJUW9Es62 X-Received: by 10.176.23.3 with SMTP id j3mt16541145uaf.128.1501023666907; Tue, 25 Jul 2017 16:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Tue, 25 Jul 2017 16:01:06 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:dd13:9400:f21a:47b9] In-Reply-To: References: From: George Michaelson Date: Wed, 26 Jul 2017 09:01:06 +1000 Message-ID: Cc: tjw ietf , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 23:01:10 -0000 read, support adoption. suggest that favourite band sections be marked 'RFC-ED REMOVE' because the last time somebody thanked their mother, the backing band, their agent, the producers, the other candidates for award... it wound up on the ietf list and we don't want to go there. I am unsure about the R flag and proscriptive language. It seems to me that it can't be a single bit flag and suggest BOTH retry, and retry another NS. Also, the rest of the flag word is set zero. Surely thats '...at this time' And then the list of when to set, maybe set, maybe not set.. I think thats still a bit up in the air. But thats now WG matter to discuss I guess (assuming it got adopted) On Wed, Jul 26, 2017 at 5:46 AM, Peter DeVries wrote: > I have read the draft and support adoption. I plan to review and > contribute. > > Peter > > On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: >> >> This draft was the only one which seemed to have broad support in some >> form during the meeting last week. >> >> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error >> >> The draft is available here: >> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 8 August 2017, 23:59 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Tue Jul 25 17:11:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBBE132133 for ; Tue, 25 Jul 2017 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 rM6Dzy7p9Y4z for ; Tue, 25 Jul 2017 17:11:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 E64BC132103 for ; Tue, 25 Jul 2017 17:11:20 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id A97D724AE08; Wed, 26 Jul 2017 00:11:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7A2D916006B; Wed, 26 Jul 2017 00:11:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 64AFB160069; Wed, 26 Jul 2017 00:11:15 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jc4xYFUVgJrE; Wed, 26 Jul 2017 00:11:15 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1A17716003A; Wed, 26 Jul 2017 00:11:15 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 457F97FE2F63; Wed, 26 Jul 2017 10:11:13 +1000 (AEST) To: George Michaelson Cc: tjw ietf , dnsop From: Mark Andrews References: In-reply-to: Your message of "Wed, 26 Jul 2017 09:01:06 +1000." Date: Wed, 26 Jul 2017 10:11:13 +1000 Message-Id: <20170726001113.457F97FE2F63@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 00:11:23 -0000 In message , George Michaelson writ es: > read, support adoption. > > suggest that favourite band sections be marked 'RFC-ED REMOVE' because > the last time somebody thanked their mother, the backing band, their > agent, the producers, the other candidates for award... it wound up on > the ietf list and we don't want to go there. It went to the IETF mailing list because it was added in AUTH48. If I've read concensus of that discussion correctly there would have been no issue if it was added earlier in the process. The problem was timing not content. Too many times IETF members take procedual decisions out of context and apply them elsewhere. This is just one example of that. > I am unsure about the R flag and proscriptive language. It seems to me > that it can't be a single bit flag and suggest BOTH retry, and retry > another NS. Also, the rest of the flag word is set zero. Surely thats > '...at this time' > > And then the list of when to set, maybe set, maybe not set.. I think > thats still a bit up in the air. > > But thats now WG matter to discuss I guess (assuming it got adopted) > > On Wed, Jul 26, 2017 at 5:46 AM, Peter DeVries > wrote: > > I have read the draft and support adoption. I plan to review and > > contribute. > > > > Peter > > > > On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: > >> > >> This draft was the only one which seemed to have broad support in some > >> form during the meeting last week. > >> > >> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > >> > >> The draft is available here: > >> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 > >> > >> Please review this draft to see if you think it is suitable for adoption > >> by DNSOP, and comments to the list, clearly stating your view. > >> > >> Please also indicate if you are willing to contribute text, review, etc. > >> > >> This call for adoption ends: 8 August 2017, 23:59 > >> > >> Thanks, > >> tim wicinski > >> DNSOP co-chair > >> > >> > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > >> > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 25 17:16:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCFE132146 for ; Tue, 25 Jul 2017 17:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.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 kdEV0ScSyx0Z for ; Tue, 25 Jul 2017 17:16:42 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 7EF7D13214D for ; Tue, 25 Jul 2017 17:16:37 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id p193so14363243vkd.0 for ; Tue, 25 Jul 2017 17:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=02y+hs1AesGlvCz5U+YO3auAzxmxO1NXsFzg4Ti+Uc0=; b=Q/EDzFXfAsH2EEOXUTVf2gpe7W1eiAzLWBiGo51mmpa3djJQWclIXblCy/VIY3KXna 9lWryjUAsXvrK5qQjKSEo9gimQZwrRapI1i5SGrIc/U6hRBUhVfAp5DbktRkz0kqLq6a yKZiPZzXta7mg08PglgdDkLYwpbboKdpNfejrpGlZe4Sn3D4KNnFRP2/polqyoWDz14R oyM3a2kpuy4rh+vVIDyGvP6TvMnI72UAO7UTLckbkljLDtW+VozjFeH0E9wFiYIYlbut wLEOX3XLi4AKq46Gj8Yee0fZT51TwYx0WzgEeKBvdtG2RbxMJ2cIdzr5bK9LX0RMIBqq unXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=02y+hs1AesGlvCz5U+YO3auAzxmxO1NXsFzg4Ti+Uc0=; b=eaLsZ8vLHfUKVyg7PsXPcXPfB4HeidnFdbm/PnIIWYbRwj9+VfEhZDPoR30SFQL6qF 3Rj2CXBt4QExKJK2ESycPyBFdOaeqTF4oqh5S5B0lS93c3yNyC/+X2Ep7xfirXLjcYGA Jb0PJdYevfWJ3HNjB6/1ZCVT7I94P1o8z0hof1PfwoURmhrN0HH+KtQnBySGfu2f9O/F gxcEeaGXQcCkRKrqAKs2a2HAq/oaFEu0dxgdTucV3K4zi+6Jw2BDJrOqrpZH9RvYDT1K 8iiRGUfmHn4vGq5A16g0dFHZe+gJ/qDTGCz+aVd+pKG103//b94ImFy6DsmGWZG4VjFp x8fQ== X-Gm-Message-State: AIVw111RSVb0YoKSBYCsw5oJ/okKsSWSiYRxy1Gmc+uiiyCKT3/X0Z9o WP9pjhhi/3s1hnmjs8QMtuu3N5AT/NGt X-Received: by 10.31.166.21 with SMTP id p21mr7722544vke.117.1501028196509; Tue, 25 Jul 2017 17:16:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Tue, 25 Jul 2017 17:16:36 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:dd13:9400:f21a:47b9] In-Reply-To: <20170726001113.457F97FE2F63@rock.dv.isc.org> References: <20170726001113.457F97FE2F63@rock.dv.isc.org> From: George Michaelson Date: Wed, 26 Jul 2017 10:16:36 +1000 Message-ID: To: Mark Andrews Cc: tjw ietf , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 00:16:46 -0000 my next draft will definitely include "....I'd like to thank Mark Andrews for hitting me with a cluestick repeatedly WAIT WAIT WHY IS THE ORCHESTRA STARTING OH MANNNNN" On Wed, Jul 26, 2017 at 10:11 AM, Mark Andrews wrote: > > In message , George Michaelson writ > es: >> read, support adoption. >> >> suggest that favourite band sections be marked 'RFC-ED REMOVE' because >> the last time somebody thanked their mother, the backing band, their >> agent, the producers, the other candidates for award... it wound up on >> the ietf list and we don't want to go there. > > It went to the IETF mailing list because it was added in AUTH48. > If I've read concensus of that discussion correctly there would > have been no issue if it was added earlier in the process. The > problem was timing not content. > > Too many times IETF members take procedual decisions out of context > and apply them elsewhere. This is just one example of that. > >> I am unsure about the R flag and proscriptive language. It seems to me >> that it can't be a single bit flag and suggest BOTH retry, and retry >> another NS. Also, the rest of the flag word is set zero. Surely thats >> '...at this time' >> >> And then the list of when to set, maybe set, maybe not set.. I think >> thats still a bit up in the air. >> >> But thats now WG matter to discuss I guess (assuming it got adopted) >> >> On Wed, Jul 26, 2017 at 5:46 AM, Peter DeVries >> wrote: >> > I have read the draft and support adoption. I plan to review and >> > contribute. >> > >> > Peter >> > >> > On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: >> >> >> >> This draft was the only one which seemed to have broad support in some >> >> form during the meeting last week. >> >> >> >> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error >> >> >> >> The draft is available here: >> >> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 >> >> >> >> Please review this draft to see if you think it is suitable for adoption >> >> by DNSOP, and comments to the list, clearly stating your view. >> >> >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> >> >> This call for adoption ends: 8 August 2017, 23:59 >> >> >> >> Thanks, >> >> tim wicinski >> >> DNSOP co-chair >> >> >> >> >> >> >> >> _______________________________________________ >> >> DNSOP mailing list >> >> DNSOP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> > >> > >> > _______________________________________________ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> > >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Jul 25 18:00:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6EC132189 for ; Tue, 25 Jul 2017 18:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 uWMYapzaGdUy for ; Tue, 25 Jul 2017 18:00:15 -0700 (PDT) Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (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 B4F5A13200C for ; Tue, 25 Jul 2017 18:00:15 -0700 (PDT) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1D139535A for ; Tue, 25 Jul 2017 21:00:12 -0400 (EDT) X-Auth-ID: bgreene@senki.org Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 333DC53E8 for ; Tue, 25 Jul 2017 21:00:10 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [172.20.10.2] ([UNAVAILABLE]. [114.124.142.240]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Tue, 25 Jul 2017 21:00:12 -0400 From: Barry Raveendran Greene Content-Type: multipart/signed; boundary="Apple-Mail=_DB783421-FF8F-4E9D-9976-DB9234960201"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 26 Jul 2017 08:00:07 +0700 References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> <59779B68.2000906@redbarn.org> <20170725204158.isyxgyb7l5d5degr@mycre.ws> To: dnsop WG In-Reply-To: <20170725204158.isyxgyb7l5d5degr@mycre.ws> Message-Id: <4924243E-7771-4C1A-ACD0-1EB40452E635@senki.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 01:00:17 -0000 --Apple-Mail=_DB783421-FF8F-4E9D-9976-DB9234960201 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The irony to the privacy and client-id discussion is that we have = another =E2=80=9CDNS Privacy=E2=80=9D WG which gives me wonderful ID = from the crypto termination on the resolver. The reality with client ID is just like RPZ adoption. Operators need = flexibility to face reality. If the DNSOP=E2=80=99s choice is to not = face reality, so be it. The code will still get deployed. Operators will = still drive adoption. The choice is to have client ID and RPZ in the working group process. --Apple-Mail=_DB783421-FF8F-4E9D-9976-DB9234960201 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZd+mYAAoJEFVuk3AWv0XzhY8IAILyzp8q0FNcsexfvbSCDIT4 QjGjA4ipFGDbYiLiDsWc6a+HyAXjjQu6K81KeJBIDoUquxw1Lcv1YOzySTFhPtr/ rUcblqOzx90x7scqiwBnJ4EAd5wf6BG0MglCYlaOhCtkDoDhVdSjv2hpB5hl1y0F Ml10MrhESBIKKo4We7LpSsxcK4FxnYNaB+hvTZypT8pyfmEFl8FPcBfPO4te5qU2 KTTTzRiRypvkikAt8ZDbzUOW7zgF/Pjgz0qAMLDd5IFZkZ6+SbX+zuHrEc7/ydjH 4nVKhuL8fEqM2KGspnmFE4xc07d8dUSfjXwaaN2MKpfkxobvCh8FJuCgEr8W8iE= =C1Wz -----END PGP SIGNATURE----- --Apple-Mail=_DB783421-FF8F-4E9D-9976-DB9234960201-- From nobody Tue Jul 25 19:20:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4181321B7; Tue, 25 Jul 2017 19:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 Swf1O5oDRLYd; Tue, 25 Jul 2017 19:20:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9453C124BE8; Tue, 25 Jul 2017 19:20:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 858F6B81AA4; Tue, 25 Jul 2017 19:20:03 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dnsop@ietf.org Message-Id: <20170726022003.858F6B81AA4@rfc-editor.org> Date: Tue, 25 Jul 2017 19:20:03 -0700 (PDT) Archived-At: Subject: [DNSOP] RFC 8198 on Aggressive Use of DNSSEC-Validated Cache X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 02:20:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8198 Title: Aggressive Use of DNSSEC-Validated Cache Author: K. Fujiwara, A. Kato, W. Kumari Status: Standards Track Stream: IETF Date: July 2017 Mailbox: fujiwara@jprs.co.jp, kato@wide.ad.jp, warren@kumari.net Pages: 13 Characters: 27918 Updates: RFC 4035 I-D Tag: draft-ietf-dnsop-nsec-aggressiveuse-10.txt URL: https://www.rfc-editor.org/info/rfc8198 DOI: 10.17487/RFC8198 The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. This document is a product of the Domain Name System Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jul 26 02:36:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FE71318A8 for ; Wed, 26 Jul 2017 02:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 xAKUnxZrUkkq for ; Wed, 26 Jul 2017 02:36:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 7202C1287A5 for ; Wed, 26 Jul 2017 02:36:13 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id B7FCE623B9 for ; Wed, 26 Jul 2017 11:36:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1501061771; bh=O+iEko1lDaiQ5Y9cmAu29fyjYIr0VLDi7+EdVSHqUWo=; h=Date:From:To; b=rD9325q+lcYVT0vi2hqCNKdNMF2F/LFRDQW29eAoyvZPWurxT+Wr4sDx4/8OlQ/PN svLW8Olcn5HIjPW6LcFSMjwhcT+Noc053Ej+akl8HfkmpxZYK2gpt+rC0pr9JBlkOH 5GzvFeGbsA3WNSPbpiX38iRv2ytPvEmVQ4ayCzhA= Date: Wed, 26 Jul 2017 11:36:10 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: dnsop Message-ID: <244306066.8219.1501061770443.JavaMail.zimbra@nic.cz> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.9_GA_1794 (ZimbraWebClient - GC59 (Linux)/8.7.9_GA_1794) Thread-Topic: Call for Adoption: draft-wkumari-dnsop-extended-error Thread-Index: 1TFbK3nVMcAev2YEBGGB7zSkNZEIMA== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 09:36:16 -0000 I support the adoption. Will make an effort to review if enforced with sha= rp object :) O. -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "tjw ietf" > To: "dnsop" > Sent: Tuesday, 25 July, 2017 18:04:04 > Subject: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error > This draft was the only one which seemed to have broad support in some fo= rm > during the meeting last week. >=20 > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error >=20 > The draft is available here: > [ https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 | > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 ] >=20 > Please review this draft to see if you think it is suitable for adoption = by > DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, etc. >=20 > This call for adoption ends: 8 August 2017, 23:59 >=20 > Thanks, > tim wicinski > DNSOP co-chair >=20 >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed Jul 26 03:56:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08C9131C2D for ; Wed, 26 Jul 2017 03:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 s83ji1s0Nka2 for ; Wed, 26 Jul 2017 03:56:43 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 4A2D5126DEE for ; Wed, 26 Jul 2017 03:56:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:48325) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1daJzd-000Gj5-dD (Exim 4.89) (return-path ); Wed, 26 Jul 2017 11:56:41 +0100 Date: Wed, 26 Jul 2017 11:56:41 +0100 From: Tony Finch To: Joe Abley cc: dnsop@ietf.org, =?UTF-8?Q?Petr_=C5=A0pa=C4=8Dek?= In-Reply-To: <9002F172-4171-41EE-A0FF-61C7A5ACAD32@hopcount.ca> Message-ID: References: <9002F172-4171-41EE-A0FF-61C7A5ACAD32@hopcount.ca> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] =?utf-8?q?draft-ietf-dnsop-refuse-any=3A_points_from_Pet?= =?utf-8?b?ciDFoHBhxI1law==?= X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 10:56:46 -0000 Joe Abley wrote: > > If anybody else here has thoughts about specific text or violent > objections to including QTYPE=RRSIG in general, please let me know (I > looked in the mail archive but couldn't find any there). I think it's helpful to mention RRSIG explicitly since it isn't immediately obvious that it's a stealth ANY query. (It becomes apparent to implementers fairly rapidly tho!) > As we discuss (see Stephane's points) in the case of multiple > transports, perhaps we can also recommend that implementors provide > configuration options to allow administrators to deal with ANY, RRSIG, > neither or both. That way we get flexibility that matches deployment, > but we also get a reference for handling RRSIG in a predictable way. I think the draft should recommend a simple on/off switch and describe sensible behaviour when it is on. Mainly because I think we know what that sensible behaviour is, and I don't think it's a big enough feature to deserve a lot of configuration and documentation complexity. Having said that, the initiator side (section 5) needs a bit of work. Something like, ANY queries SHOULD be sent using the same choice of transport as other queries (typically, try UDP first, and only use TCP if the response is truncated). As an exception, debugging and diagnostics tools MAY have a special case for ANY queries. (bleeding-edge versions of `dig` use TCP for ANY) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Bailey: East becoming cyclonic, 6 to gale 8. Moderate or rough, becoming rough or very rough. Rain or showers. Good, occasionally poor. From nobody Wed Jul 26 08:13:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C141294A2 for ; Wed, 26 Jul 2017 08:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 zw2kRl17UGzD for ; Wed, 26 Jul 2017 08:13:02 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E97812EB5D for ; Wed, 26 Jul 2017 08:13:02 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 26 Jul 2017 08:12:59 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 26 Jul 2017 08:12:59 -0700 From: Edward Lewis To: dnsop CC: tjw ietf Thread-Topic: [Ext] [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error Thread-Index: AQHTBV+qNnxcvNHjIkSYl1hJMYs/dqJmauCA Date: Wed, 26 Jul 2017 15:12:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.1.170721 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3583912379_1135136622" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 15:13:04 -0000 --B_3583912379_1135136622 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 7/25/17, 12:04, "DNSOP on behalf of tjw ietf" wrote: >This draft was the only one which seemed to have broad support in some for= m during the meeting last week. =C2=A0=20 >This starts a Call for Adoption for=C2=A0draft-wkumari-dnsop-extended-error >The draft is available here: >https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02[tools.ie= tf.org] >Please review this draft to see if you think it is suitable for adoption b= y DNSOP, and comments to the list, clearly stating your view. >Please also indicate if you are willing to contribute text, review, etc. It's funny that the older you get and the more you see the same old questio= n the less clear what the right answer is. I thought the intent of EDNS was to extend things like the response codes. = "Extension Mechanisms for DNS (EDNS(0))" [https://www.rfc-editor.org/std/st= d75.txt] includes "EDNS provides a mechanism to ... provid[e] extra data spa= ce for ... return codes (RCODEs)." So entertaining a WG work item/draft on = EDNS'ing RCODEs is a no-brainer, I mean, bring it on. But the draft itself isn't exactly the way I'd go about solving the problem= . Does that mean it shouldn't be adopted? I suppose not, I suppose the ans= wer is to adopt it and change it mercilessly. In a separate message, I'll send some comments about the draft. I don't kn= ow if I'll be tuned in enough to follow up (I don't often take time to read = the list like I used to do), so I won't promise anything beyond that. It's = a matter of time and priorities. --B_3583912379_1135136622 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUMq1hOVA0y3ogb9cp AfYmOPUyCSYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NzI2MTUxMjU5WjANBgkqhkiG9w0BAQEFAASCAQBEikY5FaoXCtVEt/UkcLAY6dFabEFTCB40 4nzQyjd+B2gaHKBnSHKdgWFkVH+us6LuG2rTcv6Lvi2BmXe0ruFUHL0Y/XNQrbGnPHPevPAR a63mgqEbgIW3f0Tz9JxISg1ABTFkD2lv4wenVkLz83+SZ8sMPI+lwzddhG+NdhGq9PMizj5W IP9SQuf7J5+TOwsrUdhJsj97v3RjED/2xO87aMex6pCbJQkJJSJuHeomRw/tNWNeVwfGVyC9 sVX75pvFWSFpfJlaMbhohnFFAiw5y4X1IysEcQ73k1CkIzxeC3y5JgDuwYa0Xhg1tbjK560i kmGn2R38Vliraeru+POo --B_3583912379_1135136622-- From nobody Wed Jul 26 08:34:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE15131CF3 for ; Wed, 26 Jul 2017 08:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 2CTEnIKbFrKd for ; Wed, 26 Jul 2017 08:34:45 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F65131CD3 for ; Wed, 26 Jul 2017 08:34:45 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 26 Jul 2017 08:34:42 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 26 Jul 2017 08:34:42 -0700 From: Edward Lewis To: dnsop Thread-Topic: Thoughts about draft-wkumari-dnsop-extended-error Thread-Index: AQHTBiSzKlkUelFtTUGzx3wDNEirBw== Date: Wed, 26 Jul 2017 15:34:41 +0000 Message-ID: <78D23998-822B-42C7-8DEA-04E6D5B7D29B@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.1.170721 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3583913682_1109143530" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Thoughts about draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 15:34:47 -0000 --B_3583913682_1109143530 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit First there's a need to divide and conquer. Or maybe conquer a different target. Why express (return) an error condition notification? To let the requestor know what happened? I don't think that's sufficient or even the true goal. Another reason for returning an error notice is to tell the requester what they ought to do next. In DNS there are a few choices, here are some (I may miss "corner cases"): 1 - try again in 5 seconds 2 - try a different server authoritative for the zone 3 - the zone (admin) says "no" 4 - try a different recursive server 5 - don't try again (ever, for a while) for this name or anything "under" it 6 - change your query to something else (like HTTP? permanent redirect) 7 - probably other reactions Note that the above list is meant to be independent of what went wrong. The other reason is to inform the requestor. Doing some navel gazing, why do this? For the most part, the other end only needs to know how to react as above. We do have a great tradition of wanting to know why a service someone else runs misbehaves in our eyes. This can be good, helping in the identification of problems, but as operations become more "professional-grade" this may be an outdated romantic notion. (Although in a speed test of public-twitter-angst vs. nagios-alerts, twitter has proven to win at least some races.) But if we are going to get into explaining why, here are some considerations. One, different code bases will have myriads of errors to report that are related to their own threads. (Recall old-time BIND INSISTs?) Do you want to have that be reported? Two there are protocol "errors" - so long as we don't add to the mythical DNS server protocol state machine, the set of errors can be enumerated. I can see that knowing if a state is transient or permanent can indicate what a requestor ought to do, but then see the first part of the message. The difference of transient and permanent may be just a perception of time scale, with permanent ending at a reboot. E.g., what if a resolver gets a response and finds DNSSEC telling it to reject the data for X seconds. For those X seconds, the resolver will not send a response, so it's "permanent" for X seconds in some sense, transient that in X seconds the negative DNSSEC cache will expire the lesson learned. In short - instead of error conditions, define "exceptional reactions" a requestor ought to pursue. This will probably be much more quantifiable (in that the mythical protocol state machine for the requestor is simpler than the server and less likely to be radically changed in the future). And - you will get away from having to localize the error explanation into different human languages. (I hadn't forgotten this, but this issue is a red herring.) The DNS protocol need not be human friendly, it's meant for machines to to talk to machines. Trying to make it talk to people at the level people understand might just be too large a task. Mental exercise: what does a querier do when it see's NOTIMP now? Switch servers and hope? REFUSED vs. SERVFAIL for lame delegation, which is better? Protocol-wise, "what happened" isn't all that useful, "what to do next" would be. --B_3583913682_1109143530 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUFfLvrY0DOyGLPgiw EXimjGL72t0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NzI2MTUzNDQxWjANBgkqhkiG9w0BAQEFAASCAQCxtdqVtZtvQT8tVUXYyzYC+StoUBgPv28m ujnYIepdnSzF7Ija9PiVHYlpyFO4fTBFOGUE0sageBmCAMBY7avXep3a3NM7SMcZv+og4Ef9 D/pmzG7TLG2W2FkK7x3WcEboMtlDjKUgmp2BctY1YIg0BlpRDHLt2SKz/G2VhPB4G+lGS7SY cv3cYbHds3PrGvyyD06nMqiLqasr/CYNaa/Yk2D8Mw657LVsMRSv++4X39rTTVkL0VxjFHOu S6cnsZFuNAvkxx/1J6/CnUJMMmvS7YNk6sCdvULp8f5b1u2SBeCOwp4vFd602TyHnIVrnldq j+YV+KVTAfbQnenBlWNf --B_3583913682_1109143530-- From nobody Wed Jul 26 10:28:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75BF131D70 for ; Wed, 26 Jul 2017 10:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 1lFyPP72VByI for ; Wed, 26 Jul 2017 10:28:43 -0700 (PDT) Received: from mail-ua0-x245.google.com (mail-ua0-x245.google.com [IPv6:2607:f8b0:400c:c08::245]) (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 63417131CA1 for ; Wed, 26 Jul 2017 10:28:43 -0700 (PDT) Received: by mail-ua0-x245.google.com with SMTP id h2so122710087uaf.5 for ; Wed, 26 Jul 2017 10:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g5tIR88e7yqxTyuV7ML9H4PT/CBL3AQticCpsHvGLaw=; b=iNxV7XwPVA0FnLw8velTGLOkKUa7XaydrkkU0wO/BfaiIB6Xb52jCLKi0SxfrXJhCE AEewSgoSEsqqwdsNrWTRqCtabiZM3OR10LoAgPGd14sxYFNoQDlfQ4Isf03B5gnpOk0r SY8unZlnsf4uJ4DbXY0HrEST5e4oHkisHMcQQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g5tIR88e7yqxTyuV7ML9H4PT/CBL3AQticCpsHvGLaw=; b=X9ciKIulogjxL208WzRixpBCB/OC1g9zKw7bd/Q/Mvyqgv+3GJ95D0KLW9GL+7P4+Z IUVB+R2V2qEIvaW4uYsIxBild/8C37Q5FWN2etQKqYpNNPEPZ4/XzUGTLlzGWFD9gb+p w4XtZa/qit7r/vqj4pgGZ3kehsAAjJXHvUSb63aHdNBNlULZx9xckapIV611zPNPbnuk nlFtiF6Bdwd8TRHroE+nuVq6nQDqjXn5uTFhMWOKFhfMkgqytTEnCWcF6ewJe4T9g9Vj WopC/u7XVX/CzH/OlxRsJHuc3AYNGrEog5u6CrJWxTzeb63xwMU5NSRYpIvzG8rLvn2T 8czQ== X-Gm-Message-State: AIVw112F3fRN+xAhVNKr2TMjiAsptHrZDeZIjXr9hvGKYFRXeJlqf14d 2y5pQqWN/n7rxN1NID9qYKcmh8jldkBkVIYFBQ== X-Received: by 10.31.63.151 with SMTP id m145mr950186vka.59.1501090122464; Wed, 26 Jul 2017 10:28:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.83 with HTTP; Wed, 26 Jul 2017 10:28:22 -0700 (PDT) In-Reply-To: <083C34A2-92B9-4A9F-A331-9C38E22417C7@hopcount.ca> References: <083C34A2-92B9-4A9F-A331-9C38E22417C7@hopcount.ca> From: Richard Gibson Date: Wed, 26 Jul 2017 13:28:22 -0400 Message-ID: To: Joe Abley Cc: dnsop Content-Type: multipart/alternative; boundary="001a114dbdf68693a205553bc735" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 17:28:47 -0000 --001a114dbdf68693a205553bc735 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley wrote: > > - There is no mechanism for signaling section 4.1/ section 4.3 > "partial > > response" behavior to clients (e.g., a new OPT record EDNS header fl= ag > > bit > > dns-parameters.xhtml#dns-parameters-13> > > ). > > Correct. I presume you are suggesting that there should be one. I have no= t > heard anybody else require such a thing, and new EDNS code points are > thought by at least some to be thorny things to pass undigested through > middleboxes so I think it's a non-trivial suggestion that would require a > proposal that itself would need thorough review. That feels out of scope > for this document, but perhaps something analogous to extended RCODEs in > the sense that it's channel metadata. > The need for such a signal also came up recently in https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#secti= on-10 . But in this case particularly, middleboxes should be a complete non-issue... anyone expecting QTYPE=3DANY passthrough is already asking for trouble. I think it would be uncontroversial to note explicitly that the mechanism > described in this document contains no such signalling, however. Let me > know if that seems like a pragmatic solution. > I remain concerned about issuing incomplete responses to ANY queries without indication of such, and predict that it will hinder operational problem investigation and remediation (especially pertaining to IPv4/IPv6 issues). My preference has not changed, but an explicit acknowledgment of the gap at least provides a reference for future improvement. > - "Conventional [ANY] response" is used but not defined. > > I am not sure why it's ambiguous without a definition. To me that phrase > seems pretty straightforward; if your core objection is that the DNS > standards are not written down with great accuracy, yeah. The only > definition I can think of really is something like "A response to a query > that had QTYPE=3DANY which follows convention" which just seems longer, n= ot > more clear. What did you have in mind? > How about updating document text to replace "conventional ANY queries" (section 3) and "conventional response" (section 4.1) with "conventional ANY response" and defining it in the Terminology section: In this document, "conventional ANY response" refers to an ANY Response that would be produced by the algorithm in section 4.3.2 of RFC 1034. Conventional ANY responses can include include records from an arbitrarily high number of RRSets, up to message truncation. Also, it therefore appears that this draft needs to be noted as updating RFC 1034. > - "ANY does not mean ALL" is misleading=E2=80=94RFC 1035 > > < > > https://tools.ietf.org/html/rfc1035#section-3.2.3> > > is clear about > > QTYPE=3D255 being "a request for *all* records" (emphasis mine). Tha= t > > said, the proposed *response* behavior is consistent with that RFC. > > All records that the server constructing the response knows about? > > All records that the server can fit into the response given the > constraints of the available transport? > > ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to > Blackadder the Second that probably pleases nobody but me. ("Kill Bob!" > "Never!") > > I think to that point we can implicitly acknowledge between ourselves tha= t > less ambiguity would be nice, but that on the whole this text as-is at > worst does no harm, and at best helps illustrate the philosophy of the > approach being described. > > Let me know how much of that you can live with :-) > In light of the above, referencing RFC 1035 actually seems misleading... the relevant definitions come from RFC 1034, and this draft is consistent with it in acknowledging use of QTYPE=3D255 for *requesting* records of all types, but inconsistent with it in specifying *responses* that intentionally omit matching records. On Tue, Jul 25, 2017 at 4:53 PM, Joe Abley wrote: > > 1. A DNS responder can choose to select one or subset of RRSets at > > the QNAME. > > > > 'one or subset of RRSets' sounds a bit awkward to me > > I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset= " > seems wrong, actually; since some vestigial fragment of a set theory > lecture in the depths of my pre-history is telling me that the empty set = is > always a valid subset. Suggestion: "A DNS responder can choose to select one or more nonempty matching RRSets". This works because existence is guaranteed by the preceding text ("for names that exists that are used", probably better phrased as "for QNAMEs with at least one nonempty RRSet"). And it has the added benefit of correctly covering wildcard behavior. I also discovered some incidental issues while confirming the above: 1. The draft should standardize on one of "RRSet" (capital S, 17 current instances) or "RRset" (minuscule S, 7 current instances). 2. Section 4.1 appears to have some errors in grammar and use RFC 2119 terms, and should be reworded (removals in strikethrough, additions in *bold*): A DNS responder which receives an ANY query MAY decline to provide a conventional response, or MAY instead send a response with a single RRSet *= one or more selected RRSets* in the answer section. The RRSet *or RRSets* returned in the answer section of the response MAY be a single RRSet *MUST be* owned by the name specified in the QNAME. Where multiple RRSets exist, the responder SHOULD choose a small one(s) *make selections that minimize response size* to reduce its amplification potential. If the zone is signed*, covering* RRSIG records MUST be included in the answer*.* --001a114dbdf68693a205553bc735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 25, 2017 at 4:52 PM, Joe Abley <jabley@hopcount.ca>= wrote:
>=C2=A0 =C2= =A0 - There is no mechanism for signaling section 4.1/ section 4.3 "pa= rtial
>=C2=A0 =C2=A0 response" behavior to clients (e.g., a new OPT recor= d EDNS header flag
>=C2=A0 =C2=A0 bit
>=C2=A0 =C2=A0 <http://www.iana.org/assignments/dns-parameters/dns-paramet= ers.xhtml#dns-parameters-13>
>=C2=A0 =C2=A0 ).

Correct. I presume you are suggesting that there should be one. I have not = heard anybody else require such a thing, and new EDNS code points are thoug= ht by at least some to be thorny things to pass undigested through middlebo= xes so I think it's a non-trivial suggestion that would require a propo= sal that itself would need thorough review. That feels out of scope for thi= s document, but perhaps something analogous to extended RCODEs in the sense= that it's channel metadata.


= I think it would be uncontroversial to note explicitly that the mechanism d= escribed in this document contains no such signalling, however. Let me know= if that seems like a pragmatic solution.

I remain concerned about issuing incomplete responses to ANY queries wit= hout indication of such, and predict that it will hinder operational proble= m investigation and remediation (especially pertaining to IPv4/IPv6 issues)= . My preference has not changed, but an explicit acknowledgment of the gap = at least provides a reference for future improvement.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">>=C2=A0 =C2=A0 - "= Conventional [ANY] response" is used but not defined.

I am not sure why it's ambiguous without a definition. To me that phras= e seems pretty straightforward; if your core objection is that the DNS stan= dards are not written down with great accuracy, yeah. The only definition I= can think of really is something like "A response to a query that had= QTYPE=3DANY which follows convention" which just seems longer, not mo= re clear. What did you have in mind?

Ho= w about updating document text to replace "conventional ANY queries&qu= ot; (section 3) and "conventional response" (section 4.1) with &q= uot;conventional ANY response" and defining it in the Terminology sect= ion:
In this document, "conventional ANY response" refers to an ANY R= esponse that would be produced by the algorithm in section 4.3.2 of RFC 103= 4. Conventional ANY responses can include include records from an arbitrari= ly high number of RRSets, up to message truncation.
Also, it therefore appears that this draft needs to be noted as upda= ting RFC 1034.

>=C2=A0 = =C2=A0 - "ANY does not mean ALL" is misleading=E2=80=94RFC 1035 >=C2=A0 =C2=A0 <
> https://tools.ietf.org/html/rfc1035#secti= on-3.2.3>
>=C2=A0 is clear about
>=C2=A0 =C2=A0 QTYPE=3D255 being "a request for *all* records"= (emphasis mine). That
>=C2=A0 =C2=A0 said, the proposed *response* behavior is consistent with= that RFC.

All records that the server constructing the response knows about?

All records that the server can fit into the response given the constraints= of the available transport?

ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to Blacka= dder the Second that probably pleases nobody but me. ("Kill Bob!"= "Never!")

I think to that point we can implicitly acknowledge between ourselves that = less ambiguity would be nice, but that on the whole this text as-is at wors= t does no harm, and at best helps illustrate the philosophy of the approach= being described.

Let me know how much of that you can live with :-)
In light of the above, referencing RFC 1035 actually seems misl= eading... the relevant definitions come from RFC 1034, and this draft is co= nsistent with it in acknowledging use of QTYPE=3D255 for=C2=A0requesting= =C2=A0records of all types, but inconsistent with it in specifying r= esponses that intentionally omit matching records.

=
On Tue, Jul 25, 2017 at 4:53 PM, Joe Abley=C2=A0<= jabley@hopcount.ca<= /a>>=C2=A0wrote:
>=C2=A0 =C2=A0 1.=C2=A0 A DNS responder can choose to select one or= subset of RRSets at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the QNAME.
><= br>>=C2=A0 =C2=A0'one or subset of RRSets' sounds a bit awkward = to me

I agree. Perhaps "One or more of the RRSets at a QNAME&qu= ot;. "... or a subset" seems wrong, actually; since some vestigia= l fragment of a set theory lecture in the depths of my pre-history is telli= ng me that the empty set is always a valid subset.

Suggestion: "A DNS responder can choose to select one or more = nonempty=C2=A0matching RRSets". This works because existence is guaran= teed by the preceding text ("for names that exists that are used", probably bett= er phrased as "for QNAMEs with at least one nonempty RRSet"). And= it has the added benefit of correctly covering wildcard behavior.

I also discovered some incidental issues while confirming = the above:
1. The draft should standardize on one of "RRSet&= quot; (capital S, 17 current instances) or "RRset" (minuscule S, = 7 current instances).
A DNS responder which rece= ives an ANY query MAY decline to provide a conventional response, or= MAY instead send a response with a single RRSet=C2=A0one or more= selected RRSets in the answer section.

The RRSet or RRSets returned in the answer section of the response MAY be a single RRSet<= /s>=C2=A0MUST be owned by the name specified in the QNAME. Where mul= tiple RRSets exist, the responder SHOULD=C2=A0choose a small one(s)= =C2=A0make selections that minimize response size=C2=A0to reduce its= amplification potential.

If the zone is signed,=C2=A0covering=C2=A0RRSIG records MUST be included in the answer.<= /b>
--001a114dbdf68693a205553bc735-- From nobody Wed Jul 26 11:25:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE78131C8D for ; Wed, 26 Jul 2017 11:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org 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 UZ1mZGp-CspV for ; Wed, 26 Jul 2017 11:25:12 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [67.215.197.156]) (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 A152E131A50 for ; Wed, 26 Jul 2017 11:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=EcoN2fUlz6e1xVktuGI2Zlja7l8aKXv9rZwgiO0pdl4=; b=iGmCJq8N2an/YV/p65uO6VgGZX KMEqxQdyih8RLn5lUhER0iKYTjXCNilPA4/eKt1P2cpCaK4T5f57TtTP6ezqyKno/k8IazA49rOAD IdQ3yBnRRpa4Rw8moMXXd8oZUqd8mefpdnDeUZTxAzBID5p7Ud6JDD4jc618gYpnOeD9NRC5rb71P zObUzbePW1Mfdn+tzCKuFUvb+0NqpKipkhnhpkiRP3mXnvnj0lOAqnUgqZJ5w27CdJP0ScfclZ0ah dR0Xx/wgbgRofTzn2lw9QiEuKBczDUPpqQItdOFODp2bFYZtuJImCvHoMbL02soFodcXXY9wHV9VK cXfPFN0Q==; Received: from [192.0.145.35] (helo=[199.212.92.9]) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1daQzM-000NJI-Kr; Wed, 26 Jul 2017 18:24:57 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Joe Abley In-Reply-To: Date: Wed, 26 Jul 2017 14:24:50 -0400 Cc: dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <2E157D56-EEFB-475A-B122-F85C142E3010@hopcount.ca> References: <083C34A2-92B9-4A9F-A331-9C38E22417C7@hopcount.ca> To: Richard Gibson X-Mailer: Apple Mail (2.3273) X-SA-Exim-Connect-IP: 192.0.145.35 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 18:25:14 -0000 On 26 Jul 2017, at 13:28, Richard Gibson wrote: > The need for such a signal also came up recently in = https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#sect= ion-10 . But in this case particularly, middleboxes should be a complete = non-issue... anyone expecting QTYPE=3DANY passthrough is already asking = for trouble. We may be imagining different things by "middlebox" -- I think you're = thinking of a resolver, whereas I'm thinking more broadly about stateful = inspection, firewalls, ALGs, proxies, forwarders, etc. I think there's = an entirely reasonable and observable expectation that QTYPE=3DANY = passthrough works in that broader sense. Mark's = was = an easy-to-find example of trouble in the real world.=20 >> I think it would be uncontroversial to note explicitly that the = mechanism described in this document contains no such signalling, = however. Let me know if that seems like a pragmatic solution. >=20 > I remain concerned about issuing incomplete responses to ANY queries = without indication of such, and predict that it will hinder operational = problem investigation and remediation (especially pertaining to = IPv4/IPv6 issues). My preference has not changed, but an explicit = acknowledgment of the gap at least provides a reference for future = improvement. OK. Your future tense is Cloudflare's past tense and I have not heard of = an example of the kind of operational confusion that you're predicting = there, but perhaps I'm just not listening in the right dark corners. I will plan to add text to acknowledge the lack of signalling but not to = change the mechanism to introduce any. People should throw rocks if that = seems bad. > How about updating document text to replace "conventional ANY queries" = (section 3) and "conventional response" (section 4.1) with "conventional = ANY response" and defining it in the Terminology section: > In this document, "conventional ANY response" refers to an ANY = Response that would be produced by the algorithm in section 4.3.2 of RFC = 1034. Conventional ANY responses can include include records from an = arbitrarily high number of RRSets, up to message truncation. OK, I'm fine with that. > Also, it therefore appears that this draft needs to be noted as = updating RFC 1034. Noted. > In light of the above, referencing RFC 1035 actually seems = misleading... the relevant definitions come from RFC 1034, and this = draft is consistent with it in acknowledging use of QTYPE=3D255 for = requesting records of all types, but inconsistent with it in specifying = responses that intentionally omit matching records. OK. I'll look at this again. > I also discovered some incidental issues while confirming the above: > 1. The draft should standardize on one of "RRSet" (capital S, 17 = current instances) or "RRset" (minuscule S, 7 current instances). Noted. The RFC Editor is well-practiced at dealing with that kind of = thing, but it doesn't help to give them less work ahead of time. > 2. Section 4.1 appears to have some errors in grammar and use RFC 2119 = terms, and should be reworded (removals in strikethrough, additions in = bold): Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks! Joe From nobody Wed Jul 26 11:50:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF52C131E17 for ; Wed, 26 Jul 2017 11:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 8BjesjxYs9Cq for ; Wed, 26 Jul 2017 11:50:46 -0700 (PDT) Received: from mail-ua0-x245.google.com (mail-ua0-x245.google.com [IPv6:2607:f8b0:400c:c08::245]) (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 C6CD8131DA5 for ; Wed, 26 Jul 2017 11:50:45 -0700 (PDT) Received: by mail-ua0-x245.google.com with SMTP id k43so87954105uaf.6 for ; Wed, 26 Jul 2017 11:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q6aR+erylrIM7RK9XNNzX6xTcuYnwxWIlx8kvUvs3mw=; b=I20KYUFVuZPnSJdrLUZC2Z0Sfh+5Bw6wNkICJPdnElta7zBsjGgLxiNpvp3VPDJ7CA VnNxhW+jrKFG50Hwktf9K7nZb7fmHb+eMPfK2QQ4RoLKObOcDKXt8YlcXfZwAWaJN5jK oTAYxXw+Zxn4bpPthnHwvOoqzuu8Gd51jlEFg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q6aR+erylrIM7RK9XNNzX6xTcuYnwxWIlx8kvUvs3mw=; b=YjNuSeKTe9NU3V/timnIVrrbVMgz1sv5EiApEb1WfCa80Q1VfWfxxVUhj/XPu9a3N/ SPkDbShF8Q2poulB6tIB6Ki0wMkCpJHH1o2PE/OJoF1loOI6eIoHFVVAORJN6SSjlrK9 5ncTmcxJBIS/06nCgsRKYTjRD1DUh/SOuz8qTrvFZFUCTiHzi8t/m9zlB9djtSaWYH70 l4GXFbI2vwO3bSfiqAKojJr521clIKqiFZRPFbkUmKVZcbN3iZSAY3grwdJT8PTpeArR Ibp1ILjkBPDx2G74e1ZH71IQy/EjTy4MHEeZ1lGwssJA8n9kUYMlpPssN6LvjrfmZrBO PmKg== X-Gm-Message-State: AIVw112blnIMwyLZRAKyVsoKJLuFxIQH5Ep/DyHQWDeypu6LZZuaKQT+ 1/2Dq/7FYMb1UStxnP2yfaOXqwGZUsgH X-Received: by 10.176.7.70 with SMTP id h64mr1282691uah.134.1501095044945; Wed, 26 Jul 2017 11:50:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.83 with HTTP; Wed, 26 Jul 2017 11:50:24 -0700 (PDT) In-Reply-To: <2E157D56-EEFB-475A-B122-F85C142E3010@hopcount.ca> References: <083C34A2-92B9-4A9F-A331-9C38E22417C7@hopcount.ca> <2E157D56-EEFB-475A-B122-F85C142E3010@hopcount.ca> From: Richard Gibson Date: Wed, 26 Jul 2017 14:50:24 -0400 Message-ID: To: Joe Abley Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c12339aee454505553cec48" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 18:50:51 -0000 --94eb2c12339aee454505553cec48 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 26, 2017 at 2:24 PM, Joe Abley wrote: > > On 26 Jul 2017, at 13:28, Richard Gibson wrote: > > > The need for such a signal also came up recently in > https://tools.ietf.org/html/draft-wkumari-dnsop-multiple- > responses-05#section-10 . But in this case particularly, middleboxes > should be a complete non-issue... anyone expecting QTYPE=ANY passthrough is > already asking for trouble. > > We may be imagining different things by "middlebox" -- I think you're > thinking of a resolver, whereas I'm thinking more broadly about stateful > inspection, firewalls, ALGs, proxies, forwarders, etc. I think there's an > entirely reasonable and observable expectation that QTYPE=ANY passthrough > works in that broader sense. Mark's proceedings/92/slides/slides-92-dnsop-7.pdf> was an easy-to-find example > of trouble in the real world. > Yes, color me corrected on vocabulary but unconvinced on interference... those slides seem to mostly demonstrate noncompliance by name servers theirselves with respect to EDNS data in queries, whereas the data I'm suggesting would only appear in responses. I will plan to add text to acknowledge the lack of signalling but not to > change the mechanism to introduce any. People should throw rocks if that > seems bad. That works. And I'm all out, so you're safe from me. > 2. Section 4.1 appears to have some errors in grammar and use RFC 2119 > terms, and should be reworded (removals in strikethrough, additions in > bold): > > Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks! > Ha! I'll use Markdown conventions in the future. --94eb2c12339aee454505553cec48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --94eb2c12339aee454505553cec48-- From nobody Wed Jul 26 12:01:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE747131E6B for ; Wed, 26 Jul 2017 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org 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 J047aOsExrvy for ; Wed, 26 Jul 2017 12:01:20 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [67.215.197.156]) (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 110BF131E6A for ; Wed, 26 Jul 2017 12:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=oe+g1EqwtS3C2B/8S3c2ngtBF6Swu+1+0FJ0YsoSs4s=; b=DxuGg8iKdEs5C9lXd3xKeBTLOB 3HPIPOEedLNWNg9v0nP2P2nj+ZOjpFZ17KtVQjBFA7Mjbkh3lShKErrEcBngD7mVegMT5+3s9Y54D WfjBxFrNYaIQ1EayOZxbfP3KLIlkI/xhkwaHs19e27o7qb75PHuom0LANNykfRKfG0dVRNY1AzzpP wXOPeJASHZimDRqFpybO+Cqg19C05XyiPQpbDjwuysme+yDe8UJmqkfGyOF9WATFuMzd1Xgq3RGIY GNl0ctPREmil6YrHgYQ2FeYahhwb1B3EiPDikOPS/JeXxnkUHbhIRw161Q3KSUUtnW6KMOPglwVw4 fVzfUF3A==; Received: from [192.0.145.35] (helo=[199.212.92.9]) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1daRYK-000NZF-5N; Wed, 26 Jul 2017 19:01:02 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Joe Abley In-Reply-To: Date: Wed, 26 Jul 2017 15:00:58 -0400 Cc: dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <083C34A2-92B9-4A9F-A331-9C38E22417C7@hopcount.ca> <2E157D56-EEFB-475A-B122-F85C142E3010@hopcount.ca> To: Richard Gibson X-Mailer: Apple Mail (2.3273) X-SA-Exim-Connect-IP: 192.0.145.35 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 19:01:22 -0000 On 26 Jul 2017, at 14:50, Richard Gibson wrote: > Yes, color me corrected on vocabulary but unconvinced on = interference... those slides seem to mostly demonstrate noncompliance by = name servers theirselves with respect to EDNS data in queries, whereas = the data I'm suggesting would only appear in responses. My recollection was that the machinery Mark was using wouldn't = distinguish between problems caused by nameservers and problems = introduced by middleware, but it *was* a while ago. Anyway, I'm not = arguing so much as trying to explain myself, and... > That works. And I'm all out, so you're safe from me. ... thanks for that. > Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks! >=20 > Ha! I'll use Markdown conventions in the future. That would be a significant sideprovement. Joe "text/plain" Abley From nobody Wed Jul 26 12:46:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36BB12EC11 for ; Wed, 26 Jul 2017 12:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Nco32gYW73nd for ; Wed, 26 Jul 2017 12:46:28 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9145D12EAA5 for ; Wed, 26 Jul 2017 12:46:28 -0700 (PDT) Received: from [10.8.193.39] (unknown [136.179.21.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1ECDE61FF3; Wed, 26 Jul 2017 19:46:27 +0000 (UTC) Message-ID: <5978F190.1070007@redbarn.org> Date: Wed, 26 Jul 2017 12:46:24 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Edward Lewis CC: dnsop , tjw ietf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 19:46:30 -0000 Edward Lewis wrote: > > But the draft itself isn't exactly the way I'd go about solving the problem. Does that mean it shouldn't be adopted? I suppose not, I suppose the answer is to adopt it and change it mercilessly. agreed. -- P Vixie From nobody Wed Jul 26 13:19:06 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4B3124234 for ; Wed, 26 Jul 2017 13:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 VaU-DRSdaWIP for ; Wed, 26 Jul 2017 13:19:01 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53B112942F for ; Wed, 26 Jul 2017 13:19:01 -0700 (PDT) Received: from [10.8.193.39] (unknown [136.179.21.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9C69661FF3; Wed, 26 Jul 2017 20:19:00 +0000 (UTC) Message-ID: <5978F932.2000102@redbarn.org> Date: Wed, 26 Jul 2017 13:18:58 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Robert Edmonds CC: dnsop@ietf.org References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> <59779B68.2000906@redbarn.org> <20170725204158.isyxgyb7l5d5degr@mycre.ws> In-Reply-To: <20170725204158.isyxgyb7l5d5degr@mycre.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 20:19:05 -0000 Robert Edmonds wrote: > Paul Vixie wrote: ... >> some of run our own rdns. some use vpn's. some use opendns or similar. > > The internet now has billions of users. With the possible exception of > OpenDNS who have gone to admirable lengths to populate their knowledge > base with device-specific configuration instructions [0], I don't think > any of the choices you've listed are available to the "average enduser", > who almost by definition lacks the specialized technical knowledge > needed to select an alternative DNS resolution provider. italy's experience in blocking unlicensed online gambling sites proved otherwise, as would would SOPA had it passed. any rDNS service that blocks lookups in a way that does not align with a user's interests, will not be used, other than to locate the nec'y bypass recipes. most of those recipes do not require deep technical knowledge. a minute or so of searching turned up these: https://www.howtogeek.com/167533/the-ultimate-guide-to-changing-your-dns-server/ https://support.hidemyass.com/hc/en-us/articles/202720776-Changing-your-DNS-settings-on-Windows-Mac-Android-iOS-Linux also, there's an app for that: https://play.google.com/store/search?q=dns%20changer%20no%20root foot-on-neck disease, and unilateralism in general, have never been practical where the internet was involved. humans are only sheep-like when presented with a politician's lies. if you try to take away their porn or gambling or $whatever, they will balk, and become thuggish. -- P Vixie From nobody Wed Jul 26 13:35:34 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A12C13146C for ; Wed, 26 Jul 2017 13:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 sGI0ZB-vzDZE for ; Wed, 26 Jul 2017 13:35:31 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E8112FEE2 for ; Wed, 26 Jul 2017 13:35:31 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id 910E512C18AB; Wed, 26 Jul 2017 16:35:30 -0400 (EDT) Date: Wed, 26 Jul 2017 16:35:30 -0400 From: Robert Edmonds To: Paul Vixie Cc: dnsop@ietf.org Message-ID: <20170726203530.ftyykxxlr44jnjtr@mycre.ws> References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> <59779B68.2000906@redbarn.org> <20170725204158.isyxgyb7l5d5degr@mycre.ws> <5978F932.2000102@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5978F932.2000102@redbarn.org> Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 20:35:33 -0000 Paul Vixie wrote: > Robert Edmonds wrote: > > Paul Vixie wrote: > ... > > > some of run our own rdns. some use vpn's. some use opendns or similar. > > > > The internet now has billions of users. With the possible exception of > > OpenDNS who have gone to admirable lengths to populate their knowledge > > base with device-specific configuration instructions [0], I don't think > > any of the choices you've listed are available to the "average enduser", > > who almost by definition lacks the specialized technical knowledge > > needed to select an alternative DNS resolution provider. > > italy's experience in blocking unlicensed online gambling sites proved > otherwise, as would would SOPA had it passed. any rDNS service that blocks > lookups in a way that does not align with a user's interests, will not be > used, other than to locate the nec'y bypass recipes. most of those recipes > do not require deep technical knowledge. > > a minute or so of searching turned up these: > > https://www.howtogeek.com/167533/the-ultimate-guide-to-changing-your-dns-server/ > > https://support.hidemyass.com/hc/en-us/articles/202720776-Changing-your-DNS-settings-on-Windows-Mac-Android-iOS-Linux > > also, there's an app for that: > > https://play.google.com/store/search?q=dns%20changer%20no%20root Yes, you and I are well aware that there are apps and howtos for changing DNS settings available online. If you can find, read, and execute one of those guides -- congrats, you're not an average user. -- Robert Edmonds From nobody Wed Jul 26 14:01:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1CF131CF3 for ; Wed, 26 Jul 2017 14:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Yb7zMc3_s4by for ; Wed, 26 Jul 2017 14:01:39 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D426131C2E for ; Wed, 26 Jul 2017 14:01:39 -0700 (PDT) Received: from [10.8.193.39] (unknown [136.179.21.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5310E61FF3; Wed, 26 Jul 2017 21:01:38 +0000 (UTC) Message-ID: <59790330.4090502@redbarn.org> Date: Wed, 26 Jul 2017 14:01:36 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Robert Edmonds CC: dnsop@ietf.org References: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca> <8d27cf2a-a883-7186-11bb-eeacd0bce68c@eff.org> <5976FC55.10301@redbarn.org> <59779B68.2000906@redbarn.org> <20170725204158.isyxgyb7l5d5degr@mycre.ws> <5978F932.2000102@redbarn.org> <20170726203530.ftyykxxlr44jnjtr@mycre.ws> In-Reply-To: <20170726203530.ftyykxxlr44jnjtr@mycre.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 21:01:41 -0000 Robert Edmonds wrote: >> also, there's an app for that: >> >> https://play.google.com/store/search?q=dns%20changer%20no%20root > > Yes, you and I are well aware that there are apps and howtos for > changing DNS settings available online. If you can find, read, and > execute one of those guides -- congrats, you're not an average user. i think that when 8.8.8.8 started getting spray painted on walls during political upheaval, the average user's capabilities were changed. see also the GFW which has made bypass expertise common within china. see also italy, where the gov't mandated dns-level filtering by all isp's of known-to-not-pay-taxes online gambling sites. gamblers shared information about what 8.8.8.8 was and how to reach it, in online forums. cussedness can be predicted, and in this case, relied upon. people learn what they have to learn. the average, can change. -- P Vixie From nobody Thu Jul 27 01:08:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215EF131F6F for ; Thu, 27 Jul 2017 01:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OvK4A-TL69-N for ; Thu, 27 Jul 2017 01:08:35 -0700 (PDT) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF96131D30 for ; Thu, 27 Jul 2017 01:08:35 -0700 (PDT) Received: from 030-192-128-083.dynamic.caiway.nl ([83.128.192.30] helo=earth.zonnestelsel.tk) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1dadrW-0002Hn-Cw; Thu, 27 Jul 2017 08:09:38 +0000 Date: Thu, 27 Jul 2017 08:08:27 +0000 From: Shane Kerr To: tjw ietf Cc: dnsop Message-ID: <20170727080827.365d64bf@earth.zonnestelsel.tk> In-Reply-To: References: X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/fdykgX9v/LLy1lT2qa3oO=E"; protocol="application/pgp-signature" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 08:08:37 -0000 --Sig_/fdykgX9v/LLy1lT2qa3oO=E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Tim, At 2017-07-25 12:04:04 -0400 tjw ietf wrote: > This draft was the only one which seemed to have broad support in some fo= rm > during the meeting last week. To be fair, I think that we could say that this was the only one having complete support during the meeting. Several drafts had support with only a few people whining because it didn't help their own operations. ;) > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error >=20 > The draft is available here: > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 >=20 > Please review this draft to see if you think it is suitable for adoption = by > DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, etc. >=20 > This call for adoption ends: 8 August 2017, 23:59 I support the draft, and am willing to contribute text and review! I have a few points now, in fact: 1. Does it make sense to divide the response codes up into those corresponding to each error type? That is, something like 1xxxx for SERVFAIL, 2xxxx for FORMERR, and so on? 2. Do we mind having lots of error codes? For example, we can go really far and do things likes DNSERR_BADCOMPRESS "name compression used in RRTYPE that forbids it", or DNSERR_NAMETOOLONG "name longer than 255 bytes", and so on. We could end up with hundreds of error codes. As a developer I don't mind this too much, as these provide hints about stuff you should be considering, but I can see why some people would prefer to keep it simple. 3. As a concrete proposal, I suggest DNSERR_CENSORED, with the code 451 for consistency with the HTTP response code. This may be a useful addition to the RPZ draft. ;) Cheers, -- Shane --Sig_/fdykgX9v/LLy1lT2qa3oO=E Content-Type: application/pgp-signature Content-Description: OpenPGP digitale handtekening -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdhRx2J+MnJeBOVlgNzKXnPlnswYFAll5n3sACgkQNzKXnPln swZRhg/8DvSjbXV/ivKUBuM/RVMSZtX2UpWYi/eeMnBraYMsCCt11oGm92QPrVoB YYEfr6X/d3/LiHwtXVBuH2WBnJVftyfPBDepV9ozOA9aCZ7GZqwOnEfeGcdR7feu jfs0gp0EUrIIqxUpS4OU7+A7udowX5RMPmqnxUyJmWXXtyoG3Dv3Ky48sgPwf8ui n0UgGcJr8p24vq2P7QT7/0U83HcTfsWkp38vSMdQ8S5KWVeg12X7yCB/nRMOQrkE E2oyGkHDIOCwD7nCjN6+CXWzeS1EHePYOYsBIgTSA0qncQ/LDXNDKWrBtqwhSuaz FJaipwMq0zjY5kFcudIkwMi8t3VdpQIbsrmAWUUH1zCaSbvv4nETNbecRFwqb7un jcIda3eKEFeo+lP9NSl3cWkQsPicWfbMlkf4RszjNSaqqx5FiOa2CwStmIs3l+13 /BR80w+If6K+d+4lKHZRjoICDIoJFbAcv4DhIY51tyv+LR3qQVWJOcwFD780X3uL Wc0whf729vbtiCqX/7UxGkimFYmBFkoh61P58rnIZ5QgE06nv7YkWjmVdSWX8VWO rkU7H8XPTjCYBgaC0t7BjaI/yulUMqauRPvOT1wGLd5wUPnNsJY6z9CtzGX5DSv3 M2yviLjMJlLfu3gHynHCQgDN6ZP66WZLXaCyw8mjUfgskv4Dc1w= =Nwfz -----END PGP SIGNATURE----- --Sig_/fdykgX9v/LLy1lT2qa3oO=E-- From nobody Thu Jul 27 01:49:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F273127136 for ; Thu, 27 Jul 2017 01:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 xErY-Tm5t7pL for ; Thu, 27 Jul 2017 01:49:12 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 B27EC126B7E for ; Thu, 27 Jul 2017 01:49:12 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50671) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1daeTm-000z2S-e8 (Exim 4.89) (return-path ); Thu, 27 Jul 2017 09:49:10 +0100 Date: Thu, 27 Jul 2017 09:49:10 +0100 From: Tony Finch To: Joe Abley cc: Richard Gibson , dnsop In-Reply-To: <2E157D56-EEFB-475A-B122-F85C142E3010@hopcount.ca> Message-ID: References: <083C34A2-92B9-4A9F-A331-9C38E22417C7@hopcount.ca> <2E157D56-EEFB-475A-B122-F85C142E3010@hopcount.ca> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 08:49:14 -0000 Joe Abley wrote: > On 26 Jul 2017, at 13:28, Richard Gibson wrote: > > > > I remain concerned about issuing incomplete responses to ANY queries > > without indication of such, and predict that it will hinder > > operational problem investigation and remediation (especially > > pertaining to IPv4/IPv6 issues). > > OK. Your future tense is Cloudflare's past tense and I have not heard of > an example of the kind of operational confusion that you're predicting > there, but perhaps I'm just not listening in the right dark corners. The only minimal-any confusion I have experienced recently was when the BIND 9.12 development version of `dig` started using TCP for ANY queries which made me think minimal-any wasn't working properly :-) But I think in most cases this change will reduce the confusion Richard is worried about. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Portland, Plymouth: Westerly 4 or 5, increasing 6 at times in north. Moderate, occasionally rough in west Plymouth. Showers. Good. From nobody Thu Jul 27 03:34:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C531318A3 for ; Thu, 27 Jul 2017 03:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec 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 3ayS8oyRGc8z for ; Thu, 27 Jul 2017 03:34:24 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 B69CA1318A2 for ; Thu, 27 Jul 2017 03:34:23 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id c184so103256527wmd.0 for ; Thu, 27 Jul 2017 03:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=sSSqNrlSh+gw3Wn5xfEUFHxe1DD0uIsnvK6/5gjMasI=; b=L2pJizjoRPUpYoAfLFgeESRkHTzhPK+G6WSpkOUgPoy8HgOhmtrNvhvHrz2y2UKAGJ Ccd3sQtsM/6zNMUzvpyyvxlEWo6u1wQV8k/K9Rr02XaHDqK21NWzgJc8CMC6mk6sLQhL fOrNy4g5IH8fl9fZB8OPOF0fiGXCadeekxdKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=sSSqNrlSh+gw3Wn5xfEUFHxe1DD0uIsnvK6/5gjMasI=; b=OAfVsqoxNI/NES3AVeeOKq5NcyAQWMvhQ0nuDa1u4xYwh472jk3vjSjFeconAE2Dji Gx2qIwBwDnV/0stn3df1Q7XJFe+kmSjwAdACymaGAtFgqpbMJvfdwMLTcinJyFRaMds3 mBIfjn+lGAw1mhBZv6e1BKrH2wtcQbhwYwUtsCPbDGVezSksyJmbDpzgFntxXM99PSTl Aqe/RdnIf6bt7vRRzNVZe72SaZMHKT8Rk6xBMG6BSilMx+YURXZVoPynfMox3XqeOrWx WKkFYeV0qzOMteZg7Hal5ff/QAvm3ZVRvc0OBpJ1WIaMVYvbmfWuNqjKHJVJ0BJkrUIn zdXQ== X-Gm-Message-State: AIVw1116VK6tiBWqepYRQ6YKRsdReewx+wjzwwVheIOPAAj7OZi7SrIx 5wTYIy1JBBkStBLc X-Received: by 10.28.126.193 with SMTP id z184mr3033413wmc.46.1501151662046; Thu, 27 Jul 2017 03:34:22 -0700 (PDT) Received: from [192.168.1.82] (host109-148-53-126.range109-148.btcentralplus.com. [109.148.53.126]) by smtp.gmail.com with ESMTPSA id t14sm19896868wra.44.2017.07.27.03.34.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 03:34:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A8549C04-2BA3-4CC1-B5AE-F3F60F878FB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Roy Arends In-Reply-To: <20170727080827.365d64bf@earth.zonnestelsel.tk> Date: Thu, 27 Jul 2017 11:34:20 +0100 Cc: tjw ietf , dnsop Message-Id: <4DD39053-3E33-4BD1-A83D-F81219484519@dnss.ec> References: <20170727080827.365d64bf@earth.zonnestelsel.tk> To: Shane Kerr X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 10:34:26 -0000 --Apple-Mail=_A8549C04-2BA3-4CC1-B5AE-F3F60F878FB4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 27 Jul 2017, at 09:08, Shane Kerr wrote: > > I support the draft, and am willing to contribute text and review! > > I have a few points now, in fact: > > 1. Does it make sense to divide the response codes up into those > corresponding to each error type? That is, something like 1xxxx for > SERVFAIL, 2xxxx for FORMERR, and so on? Loving this idea. 3xxxx for REFUSED. > 2. Do we mind having lots of error codes? For example, we can go really > far and do things likes DNSERR_BADCOMPRESS "name compression used > in RRTYPE that forbids it", or DNSERR_NAMETOOLONG "name longer than > 255 bytes", and so on. We could end up with hundreds of error codes. > As a developer I don't mind this too much, as these provide hints > about stuff you should be considering, but I can see why some people > would prefer to keep it simple. Really like this as well. I think it is really helpful. > > 3. As a concrete proposal, I suggest DNSERR_CENSORED, with the code 451 > for consistency with the HTTP response code. This may be a useful > addition to the RPZ draft. ;) Sure. Roy --Apple-Mail=_A8549C04-2BA3-4CC1-B5AE-F3F60F878FB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZecGtAAoJEFXBwuBQOW9ET0AQALwzLPNq1puNgIQ786DJ+ccF HwiAwWNqKLq/ys9BvpT1w4IdqBC/wfySCuqCyE63bhjgGBMFHdpPWkAaWvGbNeUr /5+AxNDUI1/Xntv77RJ3gssIOpcxpFjTVNIycp9NBdL5ABv6LwINzZ3ByNjxo6WV MKDyLsP4JcbvweL65in99w+AXRm8mLcBxXgof4ogSLWcnt6I49yXR5mfELkxczFn 7eumLfxY1SbN0oeTBd44EbmYrKOGwfGwt5NJ2fhMcuElAf7rOeUKwJ+8Xuajt0S+ 1nLrHIDHzhuBXMEvZ93GsqLBxXUP97dN/fypY0eed7HVI5AD52MEFN+nLgvspI5u A4mThkYH3zfSt0B2p/ekypmZgrGsiDISNjca58ayNIw8Ounf3Scovd1O4UL7TBqk ugji6xa6cWAd72LIKzeS+yUGu3hd7nsJvBHnMiI402J57UdamWY+Dp+3/9FBocYM LwU7t7WGAeRP0lngzCvWJ4yN7Q2s6RFD29XLlp6qGWD7/OVVCg5g/5/McLUuaQ0g Yv+xaMZPjs2CuQeIA5DPZBCuI8pd6MOIy43UWe8OPHtZ/cJQTQk2kdinJpnSZHlP xH1Zf3g6z3HxS85RmKGxgXv/BZgVelY89xkr1C4Pdkra1NWOrta49qUF/hHv2S10 oj2NSdczEQsPmodOkCWx =fLDs -----END PGP SIGNATURE----- --Apple-Mail=_A8549C04-2BA3-4CC1-B5AE-F3F60F878FB4-- From nobody Thu Jul 27 08:55:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326BA131C2A for ; Thu, 27 Jul 2017 08:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 cuIlqHVjeLve for ; Thu, 27 Jul 2017 08:55:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 88CD912EC4B for ; Thu, 27 Jul 2017 08:54:59 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:3810:31ff:fe35:2438] (unknown [IPv6:2001:1488:fffe:6:3810:31ff:fe35:2438]) by mail.nic.cz (Postfix) with ESMTPSA id 39326622B2 for ; Thu, 27 Jul 2017 17:54:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1501170897; bh=12p29K4IHSHTnmCxAMJxdhjDSM42aRbg712G90JofAQ=; h=To:From:Date; b=CVScPZ6HPN9IONcQm8qfn7yxnlSDSd/LhWQ/o25SRPo5iAUmK+bHOg2Ae7sx21BYU mpwuMT0xT4qTvtLs6VtPdbl1jkqtheuvEh4poyafny3FREQ9jV8P5exzDR1UsrHBmO GMpdL1rvYfJ+6Lgm7nfanQOxaglULDhUITS04CNQ= To: dnsop@ietf.org References: <5978F190.1070007@redbarn.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <95081c34-2fe4-944a-f907-e2bb30ee65af@nic.cz> Date: Thu, 27 Jul 2017 17:54:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5978F190.1070007@redbarn.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 15:55:03 -0000 On 26.7.2017 21:46, Paul Vixie wrote: > Edward Lewis wrote: >> >> But the draft itself isn't exactly the way I'd go about solving the > problem. Does that mean it shouldn't be adopted? I suppose not, I > suppose the answer is to adopt it and change it mercilessly. > > agreed. I agree. The draft needs more thought and work on text but in general it is very useful concept. I will be happy to review it and propose changes. -- Petr Špaček @ CZ.NIC From nobody Thu Jul 27 17:54:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B192131EC4 for ; Thu, 27 Jul 2017 17:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 PktKXTCCJZ0U for ; Thu, 27 Jul 2017 17:54:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 EAA73131EC3 for ; Thu, 27 Jul 2017 17:54:52 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F1D293496AB; Fri, 28 Jul 2017 00:54:49 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DD3F4160036; Fri, 28 Jul 2017 00:54:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AF9B0160074; Fri, 28 Jul 2017 00:54:49 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NfioY9hzeTxN; Fri, 28 Jul 2017 00:54:49 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5F9DB160036; Fri, 28 Jul 2017 00:54:49 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1A1C9802EA24; Fri, 28 Jul 2017 10:54:47 +1000 (AEST) To: Roy Arends Cc: Shane Kerr , tjw ietf , dnsop From: Mark Andrews References: <20170727080827.365d64bf@earth.zonnestelsel.tk> <4DD39053-3E33-4BD1-A83D-F81219484519@dnss.ec> In-reply-to: Your message of "Thu, 27 Jul 2017 11:34:20 +0100." <4DD39053-3E33-4BD1-A83D-F81219484519@dnss.ec> Date: Fri, 28 Jul 2017 10:54:47 +1000 Message-Id: <20170728005447.1A1C9802EA24@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 00:54:54 -0000 In message <4DD39053-3E33-4BD1-A83D-F81219484519@dnss.ec>, Roy Arends writes: > > On 27 Jul 2017, at 09:08, Shane Kerr wrote: > > > > I support the draft, and am willing to contribute text and review! > > > > I have a few points now, in fact: > > > > 1. Does it make sense to divide the response codes up into those > > corresponding to each error type? That is, something like 1xxxx for > > SERVFAIL, 2xxxx for FORMERR, and so on? > > Loving this idea. 3xxxx for REFUSED. > > > 2. Do we mind having lots of error codes? For example, we can go really > > far and do things likes DNSERR_BADCOMPRESS "name compression used > > in RRTYPE that forbids it", or DNSERR_NAMETOOLONG "name longer than > > 255 bytes", and so on. We could end up with hundreds of error codes. > > As a developer I don't mind this too much, as these provide hints > > about stuff you should be considering, but I can see why some people > > would prefer to keep it simple. > > Really like this as well. I think it is really helpful. > > > > 3. As a concrete proposal, I suggest DNSERR_CENSORED, with the code 451 > > for consistency with the HTTP response code. This may be a useful > > addition to the RPZ draft. ;) > > Sure. > > Roy Well if we want to add new error code we need to bump the EDNS version field or otherwise indicate that the client supports new error codes. NXRRSET instead of NOERROR with NODATA NOTAUTH instead of REFUSED when not configured to serve the query's namespace. We already do this for AXFR / IXFR. If we want to reattempt to add new labels types a more precise error code would be useful. In this case the use of the new label type would be a signal that the error code (and EDNS) is understood. Query minimisation is also required to achieve this as then only the servers for zones with such labels need to support the label type. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jul 28 10:17:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0D131F6F for ; Fri, 28 Jul 2017 10:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 l2BRiJ08tUG8 for ; Fri, 28 Jul 2017 10:17:24 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DC7131D15 for ; Fri, 28 Jul 2017 10:17:24 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id AE51312C190B; Fri, 28 Jul 2017 13:17:23 -0400 (EDT) Date: Fri, 28 Jul 2017 13:17:23 -0400 From: Robert Edmonds To: Dave Lawrence Cc: Lanlan Pan , dnsop Message-ID: <20170728171723.6vyqrtm5enan4ttg@mycre.ws> References: <150025655295.32691.13544492065984079858.idtracker@ietfa.amsl.com> <22892.32000.730535.635648@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22892.32000.730535.635648@gro.dd.org> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:17:26 -0000 Hi, Dave Lawrence wrote: > Have you had any feedback from authority server implementers who are > interested in using this? As an authority server implementer at a CDN -- we have no interest in using anything like this. > I'm having a hard time picturing many CDNs wanting to switch, in no > small part because geo is not the only goal of mapping. The > < COUNTRY, AREA, ISP > tuple that is defined is insufficient. Yes, as has been made clear in previous discussion on this document. Even if it were sufficient, using only a tuple to direct traffic makes it incumbent on the resolver operator to accurately geolocate the client IP and faithfully transmit the result to the authoritative operator. If the resolver operator is an ISP, this proposal would give the ISP an enormous amount of counter- traffic engineering power by spoofing the COUNTRY/AREA fields. -- Robert Edmonds From nobody Fri Jul 28 18:09:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F2D1321FA for ; Fri, 28 Jul 2017 18:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=gmail.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 l2M09WHmXX_K for ; Fri, 28 Jul 2017 18:09:34 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 A235C132001 for ; Fri, 28 Jul 2017 18:09:34 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id u139so65344581qka.1 for ; Fri, 28 Jul 2017 18:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tkDULE+EniOstxO0ZXOVw3oNzUpQUF1mSv3nzswughA=; b=o0MvKo2Wm3r3U9pds604f8CgbWQ9KiG5WGecTGvLgzmST3LEuZrYjPBmHehz7cVoH7 gY3+OkDsUZ68hMhL/AFc35aYXhp/y/vXwp0c5hHuVDxNiL0KM+OAhbbgQ65RVJoBo36r INlBk2rS3EVLOb7sJIw1Prtj3Uximrgw5KWhyVmSLlz5IAmLLV6mlu8IfsKozfbtgXOp Fzml9rcCGVDZotpLCAS08ostHTtZFzqsFIp8iNXNreYf1dGiXnMnRgS9ruHfzARVFON4 XRrvZbJSIY8ToYq0UC44JrMHwLetNw9zsfYqbAMv6BBJjO2dYwbAQ4l0nbfkfoZJM06M 21JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tkDULE+EniOstxO0ZXOVw3oNzUpQUF1mSv3nzswughA=; b=N3kPHkxGRJqMAwcbjrRcWjVw8xt2489jOa17vxhYQdd0l9tFnQt8nZLjmzZjFPgCpk rhUz1PN1Be3qnPaZSNApR2hCBnqiiNDZDX9yEMj6aMdTxkqyVLd7+TUg/wedk4aWOA2F gj/U7wp0ZUx7LJSNB0WnNKl9N8kXxiK/ud9sMEAK1Nqr2kxOw6I4lr3wHHI3pMYgBzIm v6FBvH26ycd1kJRl2ZDmUDpVC/pigBi54oxlNbIRQA04Z0FjI7HSQbTsjPWlC5+ZfTm+ RXm6aD8RusTQ9w8haAP88a7vXBuO2kiPC6HirP/+Od4YA9TrlMg2nNvCYbid1W2SOL9H 5wqg== X-Gm-Message-State: AIVw110Gd+b9Tqg0IpjPxlunDotBdbnI9hs6c3xMOinesP69UP8axBAv cTOLeixc6lmagBlK/gU5nklzdNNd1Q== X-Received: by 10.55.19.152 with SMTP id 24mr12090836qkt.78.1501290573487; Fri, 28 Jul 2017 18:09:33 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 28 Jul 2017 18:09:32 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 28 Jul 2017 18:09:32 -0700 X-Google-Sender-Auth: GS5yzvcKjfrm0acozj2aoktSiOw Message-ID: To: tjw ietf Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 01:09:36 -0000 At Tue, 25 Jul 2017 12:04:04 -0400, tjw ietf wrote: > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > The draft is available here: > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I support the adoption of the draft, if only to provide a way of signalling more helpful DNSSEC-related errors than a plain SERVFAIL. I may or may not support the specific proposal for that goal in the end, though (I simply don't know at this moment). I've reviewed draft-wkumari-dnsop-extended-error-02 and am willing to review followup versions. My comments on 02: - I wonder what if a forwarding recursive server receives a response containing an extended error (especially from an upstream validating resolver sending an error regarding DNSSEC validation). Is it expected to forward it back to the downstream client? - Can more than one extended error code be included in a single message? - One possible idea of another extended error code: one that indicates a type-ANY query is responded with just one type of RRset when there can be more. Technically it may not be considered to be an "error", but at least it indicates some special condition, so I think it's worth discussing. (This may also be related to question 1 of Section 6). - Section 1 Editorial - Section 1 When a stub resolver queries a DNSSEC bogus name (using a validating resolver), the stub resolver receives only a SERVFAIL in response. [...] If this is a major motivation of this proposal, it may not be very effective depending on how modern the stub resolver is. I suspect many existing stub resolver implementations still don't even include EDNS(0) in their queries (at least by default). It doesn't necessarily mean this proposal is completely useless, but we may have to note it won't be as effective until and unless the majority of stub resolvers become more modern. - Section 2 o FLAGS, 2 octets. We might just define the R bit and keep the remaining 15 bits "reserved", unless we know we'll definitely use these as "flags". Editorial nits: - Section 1 - e.g the answer was marked REFUSED because of a lame delegation, or because there is a lame delegation or because the nameserver is still "or because there is a lame delegation" is redundant and should be removed? - Section 7 and do don't get any of the protections which DNSSEC should provide. s/do don't/don't/ -- JINMEI, Tatuya From nobody Sat Jul 29 05:53:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2C9131BB3 for ; Sat, 29 Jul 2017 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 kJ7Si_lcX4iZ for ; Sat, 29 Jul 2017 05:53:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 A83FF131B99 for ; Sat, 29 Jul 2017 05:53:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xKQdC0zJ8z3Nw for ; Sat, 29 Jul 2017 14:53:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1501332831; bh=6dskfLe3VDRNQEao2TfFLADBEwu4LAkkCIzRJUGd2T4=; h=Date:From:To:Subject:In-Reply-To:References; b=Cbe5fD4qxFV6kPXOH6mucHSj5wTwaH0wOY+NaT4i3B/KVav4C9Nmj6sKDxVSUIbrW f5f/iYf9/pr9FgistuxDmpnXkq9PoSKThhB9S4ySZLwOZL4fUkJ1UqOQBLrlyKbXTv Fy058aW+2+sm4ToXkf/4hil9aMh1lnJxo/9xS3tQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qfLM0UIVkcRi for ; Sat, 29 Jul 2017 14:53:50 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sat, 29 Jul 2017 14:53:49 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D147330AFA9; Sat, 29 Jul 2017 08:53:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D147330AFA9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B649140D3592 for ; Sat, 29 Jul 2017 08:53:48 -0400 (EDT) Date: Sat, 29 Jul 2017 08:53:48 -0400 (EDT) From: Paul Wouters To: dnsop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 12:53:58 -0000 > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error I have reviewed the draft, and while I think it could be useful, I'm seriously worried about sending unauthenticated errors back to the user, and fear that software will start using these without first validating the response using DNSSEC. I would like to see more discussion on this topic before adopting this document with a focus on how we could secure these error codes. Paul From nobody Sat Jul 29 06:05:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65F9131EC3 for ; Sat, 29 Jul 2017 06:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vBIwAwFTfhGE for ; Sat, 29 Jul 2017 06:05:56 -0700 (PDT) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098E5131DFE for ; Sat, 29 Jul 2017 06:05:55 -0700 (PDT) Received: from [188.207.106.55] (helo=[10.175.112.115]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1dbRSP-00045v-6z; Sat, 29 Jul 2017 13:07:01 +0000 Date: Sat, 29 Jul 2017 15:05:42 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----MNEEIF6W4G3K88EQ4HRT5HOQC719S0" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org,Paul Wouters ,dnsop From: Shane Kerr Message-ID: <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 13:05:58 -0000 ------MNEEIF6W4G3K88EQ4HRT5HOQC719S0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I guess that I understand your concern, but we don't have any way to authen= ticate servers in DNS today and we already send error messages back=2E=20 I'm happy with error codes that are informational, but don't change client= behavior=2E Yes, I realize that users may be tricked, but that's also the = case today, right?=20 On 29 July 2017 14:53:48 GMT+02:00, Paul Wouters wrote: > >> This starts a Call for Adoption for >draft-wkumari-dnsop-extended-error > >I have reviewed the draft, and while I think it could be useful, I'm >seriously worried about sending unauthenticated errors back to the >user, >and fear that software will start using these without first validating >the response using DNSSEC=2E > >I would like to see more discussion on this topic before adopting this >document with a focus on how we could secure these error codes=2E > >Paul > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------MNEEIF6W4G3K88EQ4HRT5HOQC719S0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I guess that I understand your concern, but we don= 't have any way to authenticate servers in DNS today and we already sen= d error messages back=2E

I'm happy with error codes that are informational, but don't chang= e client behavior=2E Yes, I realize that users may be tricked, but that'= ;s also the case today, right?

On 29 Jul= y 2017 14:53:48 GMT+02:00, Paul Wouters <paul@nohats=2Eca> wrote: 

 This starts a Call for Adoption for draft-wkumari-dnsop-extended-error<=
br />

I have reviewed the draft, and while I think it cou=
ld be useful, I'm
seriously worried about sending unauthenticated erro=
rs back to the user,
and fear that software will start using these wit=
hout first validating
the response using DNSSEC=2E

I would =
like to see more discussion on this topic before adopting this
documen=
t with a focus on how we could secure these error codes=2E

Paul<=
br />

DNSOP mailing list
DNSOP@ietf=2Eorg
https://www=2Eietf=2E=
org/mailman/listinfo/dnsop


--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------MNEEIF6W4G3K88EQ4HRT5HOQC719S0-- From nobody Sat Jul 29 06:28:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F551318A8 for ; Sat, 29 Jul 2017 06:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 SaTk6FaIjM2C for ; Sat, 29 Jul 2017 06:28:01 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A46D112783A for ; Sat, 29 Jul 2017 06:28:01 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:57836) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dbRmg-000bnM-ck (Exim 4.89) (return-path ); Sat, 29 Jul 2017 14:27:58 +0100 Date: Sat, 29 Jul 2017 14:27:57 +0100 From: Tony Finch To: =?UTF-8?B?56We5piO6YGU5ZOJ?= cc: tjw ietf , dnsop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-1086627875-1501334878=:23659" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 13:28:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-1086627875-1501334878=:23659 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > - One possible idea of another extended error code: one that indicates > a type-ANY query is responded with just one type of RRset when there > can be more. Note that it is almost always the case that ANY answers from non-authoritative servers are a subset of the records :-) And it seems difficult for a cache to determine when to use this extended error code. If the cache was populated by an A query (say) it can't know if this is a subset of the owner's records or not; if it populated the cache from an ANY query then the records can expire at different times, so it would have to keep track of this to know if the extended error becomes relevant. Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Northeasterly 5 or 6, increasing 7 or gale 8 at first in west. Moderate. Rain or showers. Moderate or good, occasionally poor. --1870870841-1086627875-1501334878=:23659-- From nobody Sat Jul 29 06:36:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA9F12EACC for ; Sat, 29 Jul 2017 06:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mv-1SWZfQTrn for ; Sat, 29 Jul 2017 06:36:36 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AC612783A for ; Sat, 29 Jul 2017 06:36:35 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6TDJZYc052454; Sat, 29 Jul 2017 15:19:35 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707291319.v6TDJZYc052454@givry.fdupont.fr> From: Francis Dupont To: =?UTF-8?B?56We5piO6YGU5ZOJ?= cc: tjw ietf , dnsop In-reply-to: Your message of Fri, 28 Jul 2017 18:09:32 -0700. Date: Sat, 29 Jul 2017 15:19:35 +0200 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 13:36:37 -0000 +1 (in favor) Francis.Dupont@fdupont.fr From nobody Sat Jul 29 07:04:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EAB131CCB for ; Sat, 29 Jul 2017 07:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 DqbL95T7Svwj for ; Sat, 29 Jul 2017 07:04:10 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 35ED8131822 for ; Sat, 29 Jul 2017 07:04:10 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v205so91879310itf.1 for ; Sat, 29 Jul 2017 07:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mNxRQFVNfl600AcOaWh9G+QsW8ckcYpiVisl7nQv3zs=; b=Tv+T70whFO4JiodYpuRSgWtONSLuvvXCPKjPYSS81M80jDLyVqSIzhLuOuvnmdwxON yLs+xUtdrhv/ArtuR85yMoR4OAD6paayI+/AlMLlb2nF0B+KPONW1pXQBQL/XIbThFID jITX2GtUykAQj6e2a8yW0MkdxXPJEMVfH/Q+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mNxRQFVNfl600AcOaWh9G+QsW8ckcYpiVisl7nQv3zs=; b=OQQy9KrRqnZCZCDeHGW1JqrFhqNCi27XW4PG2WgwH7tMsrj2m5oryCyDwElbwtQfgl AxwKcyXRHwnT7LmiJE6jlpJA+k4NGYyGb/UhPCd8c/7deUflSredufHYopQekbtrLQ4o qKi9lgnr4rDjMVflvpXCn0D+NGMBp750Jr8Nj5ehhXUZl+5BcJRicYzCJlrlTcBV49eO ObcRVnxw45LZAT9vHmSdS9D9j8wRA9BAcI231vlAp0yxmcEmcEWQGO/Qw7hj66TW0o5a coGu8XSXn6mxTzYH5DurMRI1pP9anltK37ZxDxO7QFqgcMrc+tipsxszLz8n1RNSKpoT c3Gg== X-Gm-Message-State: AIVw112ECeuxdaK7vbA6ie9uyM0f7fJYpYVFkRi7aQjXmbb5mhDrvK27 vDyM6kdtX4l0xUoETyqvDg== X-Received: by 10.36.14.201 with SMTP id 192mr12094257ite.81.1501337049005; Sat, 29 Jul 2017 07:04:09 -0700 (PDT) Received: from ?IPv6:2607:f2c0:101:3:a02c:7b54:9191:917c? (node-131dv5a6sb193pmmpo.ipv6.teksavvy.com. [2607:f2c0:101:3:a02c:7b54:9191:917c]) by smtp.gmail.com with ESMTPSA id o131sm3290299itc.44.2017.07.29.07.04.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jul 2017 07:04:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (14G60) In-Reply-To: <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> Date: Sat, 29 Jul 2017 10:04:06 -0400 Cc: dnsop@ietf.org, Paul Wouters Content-Transfer-Encoding: quoted-printable Message-Id: <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> References: <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> To: Shane Kerr Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 14:04:11 -0000 Hi Shane, On Jul 29, 2017, at 09:05, Shane Kerr wrote: > I guess that I understand your concern, but we don't have any way to authe= nticate servers in DNS today and we already send error messages back.=20 >=20 > I'm happy with error codes that are informational, but don't change client= behavior. Yes, I realize that users may be tricked, but that's also the cas= e today, right?=20 In the case of validation failures, today a DNS client (of whatever kind) ca= n receive a SERVFAIL of unknown authenticity from a resolver and has to do m= ore work to figure out what that means. It can't just assume that there has b= een a validation failure upstream. Ultimately it can re-fetch records with C= D=3D1 and do its own validation if it needs to understand the reason for the= failure in detail. The motivation for extended RCODEs is to be able to provide more fine-graine= d indiciations to a client than are currently provided. In the case of a con= ventional SERVFAIL response, for example, the client might also receive some= information that further indicates that the reason for the SERVFAIL was an u= pstream validation failure. It feels like there is more potential in this second case for a client to be= lieve what it was told and avoid further checking (this is an example of you= r "change client behaviour"). Without an authenticated response, should we n= ot be concerned about the threat that a bogus response from a third party sy= stem might mask an otherwise legitimate and positive response? If client beh= aviour is not supposed to change when you return an extended RCODE, why both= er returning one? I'm not saying this particular threat is credible or high-probability necess= arily, but it seems sensible to think about this with a little more energy t= han "it's no worse than what we have today". Maybe the answer is to say "don= 't use this mechanism to indicate validation failures". Maybe there's a diff= erent approach that could accommodate signed extended responses, and writing= that up from scratch is more sensible than adapting what's currently on the= table. I'm not presupposing the answer, just thinking aloud. I don't have a strong opinion about it, but it does seem reasonable to consi= der these kinds of things before assuming that any particular draft fits the= requirements and should be adopted. Nothing against Warren's fine draftsmanship, of course! Joe= From nobody Sat Jul 29 14:00:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F118E131D36 for ; Sat, 29 Jul 2017 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 p40QRPyGw_KU for ; Sat, 29 Jul 2017 14:00:56 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 6798912EB9B for ; Sat, 29 Jul 2017 14:00:56 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:40462) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dbYr0-000OkG-dP (Exim 4.89) for dnsop@ietf.org (return-path ); Sat, 29 Jul 2017 22:00:54 +0100 Date: Sat, 29 Jul 2017 22:00:53 +0100 From: Tony Finch To: dnsop@ietf.org Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: [DNSOP] CDS/CDNSKEY RRSet authentication X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 21:00:58 -0000 I think I have spotted a lacuna or possibly erratum in RFC 7344. In section 4.1 bullet 2 it says: o Signer: MUST be signed with a key that is represented in both the current DNSKEY and DS RRsets, unless [unusual case] This allows a setup where * the DNSKEY RRset contains a ZSK and a KSK * the DNSKEY RRset is signed by the KSK (of course) * the CDS and CDNSKEY RRsets are signed by the ZSK (weirdly) * the parent contains DS records corresponding to both the KSK (of course) and the ZSK (weirdly) In this weird setup the ZSK's DS can't authenticate the delegation (per RFC 4035 section 5.2) but it does authenticate the CDS/CDNSKEY RRsets. Is this intended? Or was RFC 7344 supposed to say something like: o Signer: MUST be signed with a DNSKEY RR that authenticates the delegation as described in RFC 4035 section 5.2 or any subsequent updates, unless [unusual case] One particularly relevant update is RFC 4509 which has extra requirements about ignoring SHA-1 DS records if SHA-2 records are present. Should this check also apply to CDS / CDNSKEY RRsets? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Portland, Plymouth: Cyclonic, mainly west or southwest, 5 to 7. Moderate or rough. Rain then showers. Moderate or poor, becoming good. From nobody Sat Jul 29 14:22:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFEB129562 for ; Sat, 29 Jul 2017 14:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 VHwgqYaqcOWn for ; Sat, 29 Jul 2017 14:22:19 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 E2B3C1274D2 for ; Sat, 29 Jul 2017 14:22:18 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:41076) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dbZBh-000YuC-ef (Exim 4.89) for dnsop@ietf.org (return-path ); Sat, 29 Jul 2017 22:22:17 +0100 Date: Sat, 29 Jul 2017 22:22:17 +0100 From: Tony Finch To: dnsop@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] CDS/CDNSKEY RRSet consistency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 21:22:20 -0000 Another one: It isn't clear to me if the preamble paragraphs in RFC 7344 section 4 are supposed to describe requirements on the publisher or the processor or both. In particular, is the parental agent supposed to check this? - If the Child publishes both, the two RRsets MUST match in content. If not, maybe that paragraph should have been in section 5 not section 4... Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Shannon: West 5 or 6. Moderate or rough. Showers. Good occasionally poor. From nobody Sat Jul 29 17:38:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D097131CF3 for ; Sat, 29 Jul 2017 17:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 CNRrRGe-snDt for ; Sat, 29 Jul 2017 17:38:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 AD73212420B for ; Sat, 29 Jul 2017 17:38:39 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BB48D349DBD; Sun, 30 Jul 2017 00:38:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A33AC160045; Sun, 30 Jul 2017 00:38:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 92854160075; Sun, 30 Jul 2017 00:38:35 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bGfpmYUlQU06; Sun, 30 Jul 2017 00:38:35 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3F1CE160045; Sun, 30 Jul 2017 00:38:35 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EF6828069BE6; Sun, 30 Jul 2017 10:38:32 +1000 (AEST) To: Tony Finch Cc: dnsop@ietf.org From: Mark Andrews References: In-reply-to: Your message of "Sat, 29 Jul 2017 22:00:53 +0100." Date: Sun, 30 Jul 2017 10:38:32 +1000 Message-Id: <20170730003832.EF6828069BE6@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] CDS/CDNSKEY RRSet authentication X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 00:38:41 -0000 In message , Tony Finch writes: > I think I have spotted a lacuna or possibly erratum in RFC 7344. > > In section 4.1 bullet 2 it says: > > o Signer: MUST be signed with a key that is represented in both the > current DNSKEY and DS RRsets, unless [unusual case] It just means that signers that know about ksk/zsk have special rules for cds and cdnskey. This is from BIND's dnssec-signzone and causes the cds and cdnskey rrsets to be signed with both ksk and zsk dnskeys. } else if (set->type == dns_rdatatype_cds || set->type == dns_rdatatype_cdnskey || iszsk(key)) { > This allows a setup where > > * the DNSKEY RRset contains a ZSK and a KSK > > * the DNSKEY RRset is signed by the KSK (of course) > > * the CDS and CDNSKEY RRsets are signed by the ZSK (weirdly) > > * the parent contains DS records corresponding to both the KSK (of > course) and the ZSK (weirdly) > > In this weird setup the ZSK's DS can't authenticate the delegation (per > RFC 4035 section 5.2) but it does authenticate the CDS/CDNSKEY RRsets. > > Is this intended? The purpose was for the CDS/CDNSKEY tools to not have to fetch the current DNSKEY RRset to be able to validate the records provided they have a current KSK. > Or was RFC 7344 supposed to say something like: > > o Signer: MUST be signed with a DNSKEY RR that authenticates the > delegation as described in RFC 4035 section 5.2 or any subsequent > updates, unless [unusual case] > > One particularly relevant update is RFC 4509 which has extra requirements > about ignoring SHA-1 DS records if SHA-2 records are present. Should this > check also apply to CDS / CDNSKEY RRsets? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode > Portland, Plymouth: Cyclonic, mainly west or southwest, 5 to 7. Moderate or > rough. Rain then showers. Moderate or poor, becoming good. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Jul 30 00:42:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A88129ADA for ; Sun, 30 Jul 2017 00:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 af7ubUuPD2Ag for ; Sun, 30 Jul 2017 00:42:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 380C1129AD3 for ; Sun, 30 Jul 2017 00:42:57 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3A067349442; Sun, 30 Jul 2017 07:42:54 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 19D84216C1E; Sun, 30 Jul 2017 07:42:54 +0000 (UTC) Date: Sun, 30 Jul 2017 07:42:54 +0000 From: Evan Hunt To: Joe Abley Cc: Shane Kerr , dnsop@ietf.org, Paul Wouters Message-ID: <20170730074253.GA33522@isc.org> References: <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 07:42:58 -0000 On Sat, Jul 29, 2017 at 10:04:06AM -0400, Joe Abley wrote: > If client behaviour is not supposed to change when you return > an extended RCODE, why bother returning one? It's clearly helpful for human debugging. But, yes, you're correct -- diagnostic information included with a SERVFAIL is about as trustworthy as the AD bit, and in the absence of an authentication mechanism such as TSIG, clients should not rely on it or base policy on it. Some of the error codes might be trustworthy enough if you're using COOKIE or TCP; that would enusre at least that it wasn't an off-path forgery. The ones related to validation I wouldn't trust without a signature, though. This should be spelled out in more detail in the security considerations. (And, considering I'm listed as a co-author on this draft, maybe it's time I earn my keep and submit some text...) -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Sun Jul 30 06:39:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1845128D86 for ; Sun, 30 Jul 2017 06:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 OcCOA_HwEtwM for ; Sun, 30 Jul 2017 06:39:26 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359681275F4 for ; Sun, 30 Jul 2017 06:39:26 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6UDMNd5043453; Sun, 30 Jul 2017 15:22:23 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707301322.v6UDMNd5043453@givry.fdupont.fr> From: Francis Dupont To: Evan Hunt cc: Joe Abley , Shane Kerr , dnsop@ietf.org, Paul Wouters In-reply-to: Your message of Sun, 30 Jul 2017 07:42:54 -0000. <20170730074253.GA33522@isc.org> Date: Sun, 30 Jul 2017 15:22:23 +0200 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 13:39:27 -0000 In your previous mail you wrote: > But, yes, you're correct -- diagnostic information included with a > SERVFAIL is about as trustworthy as the AD bit, and in the absence of an > authentication mechanism such as TSIG, clients should not rely on it or > base policy on it. => TSIG can be in a response only if the query is signed... Regards Francis.Dupont@fdupont.fr PS: I remember a similar operation vs security trade-off about IKEv2 NOTIFY messages: in some cases it is better to get unsecure information than no information at all because security is required. BTW in the case of this proposal it is second order because the real/main error is the SERVFAIL (or others but after a short study of bind9 code the first time this idea was proposed it should be at 90% or more SERVFAILs). From nobody Sun Jul 30 10:36:32 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFBA131CF3; Sun, 30 Jul 2017 10:36:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150143619012.17703.6263456348626337808.idtracker@ietfa.amsl.com> Date: Sun, 30 Jul 2017 10:36:30 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-tale-dnsop-serve-stale in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 17:36:30 -0000 The DNSOP WG has placed draft-tale-dnsop-serve-stale in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ From nobody Sun Jul 30 20:06:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F7E131CB6 for ; Sun, 30 Jul 2017 20:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 k0R4lw9hfm77 for ; Sun, 30 Jul 2017 20:06:04 -0700 (PDT) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 C7894120724 for ; Sun, 30 Jul 2017 20:06:03 -0700 (PDT) Received: by mail-qt0-x241.google.com with SMTP id u19so14476851qtc.0 for ; Sun, 30 Jul 2017 20:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kBT+goJrkCxgBI7jNB6/flyyHY4I3YGRD339dOmcw88=; b=RRcpJ0uVS/q0+ItkuUEMrhdsjg+UVX881eehnIpRDQfO+UKnpb5EIAUY1+7ctx6/Rh wgU8eXqzULJGAvADixlRY1qi32v3T0MaNluXuZA6IhyILk30YbYW3wXu1TaBv9iFQ0qC RbM0A+Q5Yh9m/byNpe3zuyFoezN8PGl3qBayWsKfvYMFx1o8CDRJMkGD9vaPLkSnJQd5 5IpAkvYZxPPHdvSsD/7tv6Sa54oxNf5zv54rdJoufwv9B0puACoZp5Z+yjI3wjDwikzh 1t9aImDhEPbnG+N6Xdwr8JKzCI+CIYO8RJ0554jEGF+YbqpDWlBFYiUn/DwRJsmGj73+ vtjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kBT+goJrkCxgBI7jNB6/flyyHY4I3YGRD339dOmcw88=; b=E8WyivPNoiWYq2rtGs/GRC7Pyv7jxNe3JuTkbPiAjJifl8HfPlVbBB8KCRR/TiXQ7q s8fC3taoVtU4gcMiH11WH2sYCAFBGzW4QWwbkYsOMoTh+nkDpGLrDyGraqhrOTuMvGmc NkzwTOWssjpVppGYqzD30qdUldguPqZe2HYBmotX4iex9PU4WPc0L7y1dYWxllwQbfoC chL5lMAxC+5Z9IqBvN8QizcZ9iOxGhjEZ4lIQSbYKy4jX2ZFiq/KXegWn6TCrA5O8x0u qKljVl3oXWEQM+s2PRY4qXF7zXJP3aHpSY2SKIOsPRGpNi9q4OfYZafG2UUM+P97RUOK r4JA== X-Gm-Message-State: AIVw1130IiHkLDmpgQqMM74zNzRGNrz0Kq7xCRZSuamBvK8AjQXb7FUF HaHntAR5WA5ZPiv3I7KWj6qzo9+deI0g X-Received: by 10.237.59.140 with SMTP id r12mr18793468qte.47.1501470362874; Sun, 30 Jul 2017 20:06:02 -0700 (PDT) MIME-Version: 1.0 References: <150025655295.32691.13544492065984079858.idtracker@ietfa.amsl.com> <22892.32000.730535.635648@gro.dd.org> <20170728171723.6vyqrtm5enan4ttg@mycre.ws> In-Reply-To: <20170728171723.6vyqrtm5enan4ttg@mycre.ws> From: Lanlan Pan Date: Mon, 31 Jul 2017 03:05:51 +0000 Message-ID: To: Robert Edmonds Cc: dnsop , Dave Lawrence Content-Type: multipart/mixed; boundary="94eb2c1907b49fe6b20555944f21" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 03:06:07 -0000 --94eb2c1907b49fe6b20555944f21 Content-Type: multipart/alternative; boundary="94eb2c1907b49fe6af0555944f1f" --94eb2c1907b49fe6af0555944f1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robert, Thanks for your comments. Robert Edmonds =E4=BA=8E2017=E5=B9=B47=E6=9C=8829=E6=97= =A5=E5=91=A8=E5=85=AD =E4=B8=8A=E5=8D=881:17=E5=86=99=E9=81=93=EF=BC=9A > Hi, > > Dave Lawrence wrote: > > Have you had any feedback from authority server implementers who are > > interested in using this? > > As an authority server implementer at a CDN -- we have no interest in > using anything like this. > Fastly support Creating location-based tagging , offer HTTP header like Fastly-GeoIP-CountryCode for geographically sensitive content, and Geolocation-related VCL features . Fastly has something like this, give tailor HTTP response based on client ip's Geo Feature. Hope you have interest to support something like this on DNS level in the future, welcome cooperation, :-) > > I'm having a hard time picturing many CDNs wanting to switch, in no > > small part because geo is not the only goal of mapping. The > > < COUNTRY, AREA, ISP > tuple that is defined is insufficient. > > Yes, as has been made clear in previous discussion on this document. > The "sufficient" vs "not sufficent" has repeat many times. Seperate path calculation and tailor DNS response : CDN can do all analysis based on client ip *without ECS and EIL*, because it is data provider, every client will visit. Geoip enabled ECS vs EIL : The < COUNTRY, AREA, ISP > tuple *can be sufficient for GeoIP-enabled Authoritative Nameserver*. See also 3 pictures in attach. > Even if it were sufficient, using only a tuple to > direct traffic makes it incumbent on the resolver operator to accurately > geolocate the client IP and faithfully transmit the result to the > authoritative operator. For user privacy concern and realistic geoip-enabled authoritative server, EIL can be an alternative feature, not many cost on geoip-enabled authoritative server to add this feature. Generally speaking, the global public dns, which make resolver's IP not close to client's IP, is the origin of "response accurate problem". Their GeoIP database's accuracy should be no less than authoritative service providers. With ECS, authoritative server incumbent to accurately geolocate the client IP. Big company with huge number of users has advantage. EIL can be more fairly for small company and third patry startup authoritative sevice if they have less accuracy GeoIP database. Common security concern, if resolver not "faithfully transmit the tuple to the authoritative operator", would it "faithfully transmit the client-subnet tuple to the authoritative operator" ? If the resolver operator is an ISP, this > proposal would give the ISP an enormous amount of counter- traffic > engineering power by spoofing the COUNTRY/AREA fields. > ISP resolver (or all type resolvers) can redirect traffic because its key position, between user and authoritative server. Use the same logic, we can imagine that, ECS can give the ISP an enormous amount of counter- traffic engineering power by spoofing the CLIENT-SUBNET fields. > -- > Robert Edmonds > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c1907b49fe6af0555944f1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,

Thanks for your comments.
=

Robert Edmonds &l= t;edmonds@mycre.ws>=E4=BA=8E2017= =E5=B9=B47=E6=9C=8829=E6=97=A5=E5=91=A8=E5=85=AD =E4=B8=8A=E5=8D=881:17=E5= =86=99=E9=81=93=EF=BC=9A
Hi,

Dave Lawrence wrote:
> Have you had any feedback from authority server implementers who are > interested in using this?

As an authority server implementer at a CDN -- we have no interest in
using anything like this.
Fastly support=C2=A0 Cre= ating location-based tagging , offer HTTP header like Fastly-GeoIP-Coun= tryCode for geographically sensitive content, and Geolocation-related = VCL features.
Fastly has something like this, give tailor HTTP resp= onse based on client ip's Geo Feature.

Hope you have = interest to support something like this on DNS level in the future, welcome= cooperation, :-)


> I'm having a hard time picturing many CDNs wanting to switch, in n= o
> small part because geo is not the only goal of mapping.=C2=A0 The
> < COUNTRY, AREA, ISP > tuple that is defined is insufficient.
Yes, as has been made clear in previous discussion on this document.
The "sufficient" vs "not sufficent" has = repeat many times.
Seperate path calculation and tai= lor DNS response: CDN can do all analysis based on client ip without= ECS and EIL, because it is data = provider, every client will visit.
Geoip enabled ECS vs EIL : The < COUNTRY, AREA, ISP > tuple can be sufficient for GeoIP-enabled A= uthoritative Nameserver.
See also 3 pictures in attach.
=C2=A0
Even if it were sufficient, using only a <COUNTRY, AREA, ISP> tuple t= o
direct traffic makes it incumbent on the resolver operator to accurately geolocate the client IP and faithfully transmit the result to the
authoritative operator.
For user privacy concern and realistic = geoip-enabled authoritative server,=C2=A0 EIL can be an alternative feature= , not many cost on geoip-enabled authoritative server to add this feature.<= br>

Generally speaking, the global public dns, which make resolver&= #39;s IP not close to client's IP, is the origin of "response accu= rate problem". Their GeoIP database's accuracy should be no less t= han authoritative service providers.
With ECS, authoritative server incu= mbent to accurately geolocate the client IP. Big company with huge number o= f users has advantage. EIL can be more fairly for small company and third p= atry startup authoritative sevice if they have less accuracy GeoIP database= .

Common security concern, if resol= ver not "faithfully transmit the <COUNTRY, AREA, ISP> tuple to t= he authoritative operator", would it "faithfully transmit the cli= ent-subnet tuple to the authoritative operator" ?

<= /div>
If the resolver operator is an ISP, thi= s
proposal would give the ISP an enormous amount of counter- traffic
engineering power by spoofing the COUNTRY/AREA fields.
ISP resolver (or all type resolvers) can redirect traffic because its key = position, between user and authoritative server.

Use the = same logic, we can imagine that,=C2=A0 ECS can give the ISP an enormous amo= unt of counter- traffic
engineering power by spoofing the CLIENT-SUBNET fields.
=C2= =A0
--
Robert Edmonds
--
= =E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2= =A0 Pan Lanlan
--94eb2c1907b49fe6af0555944f1f-- --94eb2c1907b49fe6b20555944f21 Content-Type: image/png; name="11.path_calc.png" Content-Disposition: attachment; filename="11.path_calc.png" Content-Transfer-Encoding: base64 Content-ID: <15d96758717e969929c4> X-Attachment-Id: 15d96758717e969929c4 iVBORw0KGgoAAAANSUhEUgAABE0AAAJbCAIAAACeov3KAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAKpvSURBVHhe7f1fjB1XfucJ+mEx24/z2G9du09+ 2wH2Yf1YT41+WLBt9M5OzzTWMAz0or1wMQtYoMbahuE11lizS1JWe2YKPb2trOqqtkt/yBoxPXaX bZXKJZL5R6Ikiqkii1kkkyKTUmaKKVEkU+L/5P5OnBMnzr+IOHHzZmbcuJ8PviCYceNGxI17I+7v c8+JE7/2DAAAAAAAYFjgOQAAAAAAMDTwHAAAAIBes7v77MmTp198cUfljpdb29vrGXzwi1+e/eBD NysXVs1jjXz2+efBGvVmyCbpAPQWPAcAAADgoBFD0NIiImGUYn390uWrZ899qLP09tllh6Xlt39y +v04x3927s/m32/NH756/ls/WnHzx8c/COZJ5uTPzwVr1DGbVbL0znt2y+VVmNezvv757dvyGu/e u4cRwcGD5wAAAADsC9pkPtnYkIr/wqXLgcBoYTj5ViUqf/rjc9ZD/uX3f/Ev/sOFScnv/eBDu+Xy Kuwr+qtTSpP+7sx7+iXLa3ddaGNzEwuC/QPPAQAAABidp09VjzLdLHNl7SMp4t9+77wu67XJzP2N ajn5kxMfaA343e+FkjA9EXlzXeiHf/eBa0HvvH9e9t61j67bhiD8B/YCngMAAACQy5dffiUluBTi KxcuSV0u1bnuUaabZZ5/XTXIfPPPPwzqe5KT/+dfKAWaPan2pG4I0v4j8nPh0mXZ52I+9x88QH4g EzwHAAAAII1uq7n58cfWan6+9J6U4FKI//HxD6QuDyp1sh8R+fmTE6pNTMzn1NK71nw+2digzQca wHMAAAAAKu7evafFRqpp3Vbz7/7qHFbTq2jzmfsb1e1Nt/isXFj95JNPdr78Eu0BC54DAAAA084X X9xZX18/e+7D5eW3/+7Me1psfv+HdD+bjMg7Je+XaM/PFt9fevvseysXbt68yfAGgOcAAADANPLo 0aOtTz/94Be/FLf5yWk1ONi3frTy2y9N0ihnJM7vfu/Ccy+fF1MVXxXnOX/h0q1btx4/eWLedZgm 8BwAAACYIh4/frKxufn2e+fPLJ19+afn/vDV87jNUCPO88fHPzj+s3OLy2o8662tTxGeqQLPAQAA gKng89u3Vy5ckpL3h3/3AUOiTVu+9aMV0dqF5bO/uHT5iy++oEvbNIDnAAAAwMD57PPP337v/F+d UlfdBOUvmar89ku/+JMTavSCs+c+/OKLO8jOsMFzAAAAYLB8+dVX77x//uRb52jAIW6+9aMVsZ33 Vi48fPgI2xkqeA4AAAAMkN3dZ9eur/986X3GgyZ1ee7l86fffn9j6xaqM0jwHAAAABgaIjm/vHzt P/7tB4wxQJrzu9+78OO/P3fj4035zHDRzsDAcwAAAGBQSLV6/eYnP3rzfFDRElKXvz59buvW53jO wMBzAAAAYFA8efJ06e2ztOSQ/PzeDz5ceue9x092BfMxgskHzwEAAIDhIHXqJxtb83//blDIEtKc n505+/ntu093nyE6gwHPAQAAgOEgder1G+t/e+psUMUS0pwzS29/8ulnj1STjvkswaSD5wAAAMBA kAL1ydPdmxtbf7/wzu//kIGkSW6ee/n8m2fO3vz0868ePZWPEKozDPAcAAAAGAhSnT5+urv+yeZr b77/Vz8/+7vfC8tZQuL83g8+lE/LT06/f2Pzsy8fPlGeYz5QMNngOQAAADAQpDx99GR3/ePNH71x Tt0I8q13uHkOac4fvnpeJEdU569PvX9947OdB0/UaATmAwWTDZ4DAAAAA0F7zo3Cc6SE/Zff/8XJ n5399399Tv7jlraESMRtfvg37738xnu63U97zj3xHNpzhgKeAwAAAAMh8Byd518/93en3sF2iI0Y zvd/8p58Kv74+Ad2omnPefiU9pzBgOcAAADAQEh6juS3X/qF2M7Pzrz92k/f/ZMTH3BrnenM737v grz7P37zrBiO/Cd4lH5rwwPPAQAAgIFQ5zk2z718/vs/ee/U4tvy7x8fR3imIlpvfvg374noyvv+ rR+lL9nCc4YHngMAAAADodVzdERvdOG7sPT2y2+896c/Pvd7P2AQ6qHl93/44fOvn/vxm2cztRbP GR54DgAAAAyETM9x84evnn/pP7//d6fekYj5iPNw453JzTf/XLmNbrr5yVvqoqy61ps4eM7wwHMA AABgIIzgOTa/94MP//j4B+I8Uh9LlfzjN8/+2fz7YkE09fQ5IqXyrsk7pdtt/urnang9mTLCmBN4 zvDAcwAAAGAg7MVz3EiV/K0frUj1/PIbalQuKaCljP7u//r+86+r9gFuP3pY0e/L7MlzIjPyjiws qUabH/7Ne/JO7f19wXOGB54DAAAAA2FcnhNECmi3vBbtkQpb/vPSf35ft/nIo8FTyB6j97luqxGT kb29vLys29mscI53GAk8Z3jgOQAAADAQ9slz4kiFLXX2n/74nG7z0VW4lh/dvCB57mXlP3R7a87v //BD2UviinqnvfbTd/XO1G1oemeK7cg8wRPHHjxneOA5AAAAMBAOzHOS0fKjmyBsyf53p96xCiT5 /k+MBelWoAMo3w83ep+4u0U3zkhktwg/eesd+b+4on5Uy2GwkIMJnjM88BwAAAAYCIfrOQ2x5f6f nDDlvm4FsuW+oDtl6Vgd0tHPtRlvf6386L5kNuIk7kZagZGcWnxbvygreLaZSzfOSIKFH3rwnOGB 5wAAAMBA6K3n5ERfZK9jdUjH+oOOyIO2iAasYGTGPK0R3ZfM5rWfvutupBUYySQO1YDnDA88BwAA AAbCRHvOeGNbkDITPH0Kg+cMDzwHAAAABgKeQ0YOnjM88BwAAAAYCHgOGTl4zvBQnvPy6auEjJY3 Vz7WnyQAAIBDB88hIwfPGR7Kc/7psTcIGS3/+kfv6k8SAADAoYPnkJGD5wwPPIfsKXgOAAD0BzyH jBw8Z3h4njP309Uov/pel3z/zQ75j0F+FueyzQ9a8/dVftg9/0nn50GudMqfu3lrxPxFMqeSudqc HzXkdG6Cjmo6f/bXF/AcAADoG3gOGTl4zvDwPOfWF/edPNh2c8fks5p8ftfNQ5vbOve8fBFnR+VO lUc2dyVfJnLP5qsqOyqPw9x//GVjvpI8CPIkyH3Jw6Y8cPMomacPgzwO8yiZJ14eq+wm8rTKk+bs 7j718iyR4tuiLivXP8dzAACgb8g3FJ5DRgueMzySnvMgKTmB2Lhpkpw8w3EkxzeclOTUG04kOZHS BEkZjmT/DUcyouGkJOcADUcHzwEAgB4i31B4DhkteM7wiD0nYTgjNuP4hiNpM5xIciLDkcSGU0pO aDjNkqMMp60ZRxlOo+QcvuFIMiVnN0NynmVJjgTPAQCAHiLfUHgOGS14zvDwPGdshtPajLMXw/El Z4SOajmGI+lgOJJQbyRPR+yo5huO5CAMR+KbTHPwHAAA6CHyDYXnkNGC5wyPlOfsq+FImg0nJTnj MhzJ3g1H0mY4kpEMRzJew5GM23B08BwAAOgh8g2F55DRgucMj8hzGg1H0iQ5vuFIkobjSE674Uhq DCeSnEhpgqQMRxIZTn4zTug2OpHhSEY0nJTkjNtwRpAcCZ4DAAA9RL6h8BwyWvCc4eF7zsjNOJ0N J5KcSG8kuc04w7oUR9KrS3GSwXMAAKCHyDcUnkNGC54zPDzPCcTGpslwIsk5UMORRFYT5EA6qg35 Upxk8BwAAOgh8g2F55DRgucMjxbPqTMcIznNhiNpNpyU5Oyz4UjGaziSkQxHMl7DkRyI4ejgOQAA 0EPkGwrPIaMFzxkeTZ5TJzl9uBSnvaNaqDeSyHAaJWcUw5GMaDgpyXEMp0Vy8gxnXJIjwXMAAKCH yDcUnkNGC54zPNKeM1bDiSQn0htJbjPOOC7FkezdcFqbcUK30fENRzIpHdWC4DkAANBD5BsKzyGj Bc8ZHqHnNBlOJDmh4Uj2z3AkkdUEma5LcSSHYTg6eA4AAPQQ+YbCc8howXOGh+c5TZKTZziO5PiG k5KcesNJNOMEShPk0C7FkbQajmRAhqOD5wAAQA+Rbyg8h4wWPGd4JD2nyXAkbYYTSU5kOJJ8w2nv qBbqjSQynEbJOVjD2ZvkhIYjSRjOvkqOBM8BAIAeIt9QeA4ZLXjO8Ag85wANJyE5vuFIIqtxw6U4 od7o+EKyT8FzAACgh8g3FJ5DRgueMzwSnsOlOE5aDEcS6o3OeA1H0hvD0cFzAACgh8g3FJ5DRgue MzxCz9mnS3EkNYYTSU6kNEEm8FKclORMrOHo4DkAANBD5BsKzyGjBc8ZHp7nBIYjaTOcSHIivZHE hlNKTmg4e++oNrBLcdolZ/8vxUkGz4H+c3NxyZ7cghw5trJs5poYlueLLZ/fMn9HtM4AMA3IN9RQ Pee5cw/cL2KT2w8+vvbpd0+EM5MRgucMj1rPGafh+JLTi0txJKHeSHozZnSfLsVJBs+B/qPr/mTw HIChIt9QQ/Wc717zvoiDiO08Fz2FdAqeMzwSnhMajqTZcFKSMy7DkezdcCRthiMZyXAk4zUcSb8N RwfPgf4zsLofzwHIQb6hBu4519adiZefO7F+9nbZznN7D6rz5p29LmHyg+cMj9BzkobjSE674Uhq DCeSnEhpgqQMRxIZTn4zTug2OpHhSEY0nJTkjNtwDl1yJHgO9B88B2AKkW+oafIck+e0pdQ8mhU8 B88ZIp7nNBpOJDmR3khym3F6cylOazNO6DY6vuFIBnwpTjJ4DvQfPAdgCpFvqCn0HEnZq+3B/GjX 6uA5eM4QSXnOvhqOJLKaIAfSUa03l+JIWg1HUpy7+xM8B/pPTt2vxyo4Mrd200xw2F6bkYeOLZ3Y NhOePdu5uboyM2dOmPLQzPzacvWoZufEXPms7bXZYmb9Z8d1hYzqOTvL80uycHlIMjO3Em2wsKfX BdAr5BtqOj3nX/yH9bPFy//43GVn4uXvnrvzse3YJo/efnD2TXeGmuENvOW0L2QYwXOGR+Q5zYaT kpx6w0k04wRKEyS3o1pkNW7aDEcykuFIMJwyeA70n6z2jUIwZLbZVTPBEmmJKvT1x/7I3NLMnBnM Lar1Sx9YXNEz6Kjld1hXgpE8p9pm2WC99uQG63lGfF0AfUK+oabVcy7P3y5mqNpkjPkUEx94ouK4 0HNvKof52D5UzFmYTIeFDCN4zvDwPceTnMpwjOREhiPJN5z2jmqh3kgiw2mUnFEMRzKi4aQkxzGc FsnJM5x+So4Ez4H+k+U5ZZUfN4Po6TOLO/pvs7Q5t6Fjx050/MTRhmNl48n2TjFD7rqSjOA5CX3a 3pqd8wRmHK8LoEfIN9S0ek45g/WcE59+/OzB2XPrble0svUm6t5W12+t00ImPHjO8PA8p7YZJ9Ib SX0zTnfDSUiOZziS6boUR6LOIP0NngP9RxfrcYJBpY0MBCNNBx3JavuVbc0Wy3SaNUqZScyct64a RvAcPaVJn8b0ugD6g3xDTa3nlPpx57vRQ05M+0zZXFOm2/U5NQuZ8OA5wyP2nPEZjiSymiBcipNI ce7oefAc6D+ZnpPsTha0hJg/U44RuYTxgZoOXbE/pFpdUozgOZVW1ZjJ+F4XQF+Qbyg8p9FzTPe2 vXlOzUImPHjO8Ag8xzGclOTUG06iGSdQmiCHdimOpNVwJAnDSUnO9BmODp4D/adVDErKlopqTjMl 6LSmphRXsLjR0+Pn1vlAtFXhuupofTmpGbb0gAFq+WoEgnAVY3xdAD1BvqHot+a7yuXvnvv07DVz 1Y29wKaj5+QtZMKD5wyPhOfkX4pTSk5oOO0d1UK9kUSG0yg5h284kkzJCQ1HkjCcCZIcCZ4D/adV DCpW1bX1VTuP6c1VNftYH6hLh3aPtnXVMZLnCGq8NZmuc2Ru6cRqZTvjfF0A/UC+oaZ9HAJnhrqx 1CT5ntNhIRMePGd4eJ6z3x3Vxn8pjiTUGwmX4ux78BzoPx08x+9OFvfm6rKoVh8w69IK0dBzLMBs Q233tuZ2IW/kaLttY31dAL1AvqGm1XOicaW1usiUa+vPVQMGdOy31mkhEx48Z3j4nrNvhiM5kEtx JC2GIwn1Rme8hiMZqOHo4DnQf7oU8e7MiYI+8xKagnYfcJbWQR7Ms2pbfhJX/kSUA6mV+2S8rwug D8g31HR6TjwGWs383Tyn20ImPHjO8GjynBrDiSQnUpogXIqTiDoZTXDwHOg/nTyn6k62mupIZh7N GWoswwfsKGfJddVRjpeQfEVtFlSiX4gVm/G+LoAeIN9QU+g5z5WtLu6jev7oLjfrZxs8JxrDoNtC Jjx4zvBIe05uM844xozuz6U4koPoqDZpl+Ikg+dA/+nmObY7WXEJfvQsU+UfUVfzm0mam6trszLR /CXk+ICZRyd7C43MSGbmndvdbFdX4Pid1mQtS7OLW05bTfkqqjWO93UBHD7yDTVVnvPcifX5a+X1 M35rTDX8mu1vdsL4iSRUFHWfHD29UJoTl3UvtW4LmfDgOcMj9Jxcw5FEVuMmx3Ake27GiS/FufuK U0DYHDm54RrOR2dMWVDNML/hiY3NGA1HUpwXBhA8B/qP9pxkki0Ydv6a9o1q7DKZoRiUzP7Z2Qes seS1pVi8QQWCRFfmmC2RHKndWmGcrwvg0JFvqIF7Tk3U9TPhU8wVOyq3H2iN2X1mRkuLFKUcxqBM 2YbTaSGTHTxneHieMxbDkRxaR7WqAefumZPmRR09ufGRYzgqZevNRxdXjsp3+fzG9cBtdDINRzJN hqOD50D/sS4RJ20XtmNY/bX+y4vV1fwSsQLVYOItKtMHTPNR3rUxHje3xUyW9KaqJYicuM07Ht4G F3O6zTuWMb4ugENGvqGG6jnJcc/EN86ec0cI8OO29igX+vS7J8xyEooiM5cDRu/evmOv8+m2kEkO njM8fM8JDSeSnAkaM/qi6ncueeFiwnB0Hj/ZePHYGy9ebDKcFsnJM5yBSY4EzwHYG0YbaoZHA4AR kW+ooXoO2e/gOcMj7Tl9vhSnsRmnMBydwHN8w5EUl+JsJjwn23DaJWeIhqOD5wDsCTsUQYdOawDQ jnxD4TlktOA5wyP0nPF1VPMMR7LnjmrthiMxkhN4TsJwtNX4npNpOJJWw5H4YjCwjO45j2/vbnz/ 2f1r5k+AqcSMkdC90xrAtLF7/U+ffflL80cG8g2F55DRgucMD89zks04gdIE6cGlOCaV4eikPCca Tq30HAynYzp7jtabX/zm7s9/TfLs9t+b6QDTiHerUABoQH9r7L7z67vX/ihHeOQbCs8howXPGR6B 53iG095RLdQbSWQ4jZIziuFImg1Hx/ecwnACySk951IsOfdes+O0zl9dvLV7fWHltW3fcLa3js9X lwLPzK8tbduOajvrq2uzxaOzq892t9f0cEYyz3rpCZOeXM/x9cYGz4Gpxt6rx/wNALUEXx+twiPf UHgOGS14zvBIec44LsWRHNylOEF0643jOSnDKfK08pyqxaaYeGR+87r+89bmi3OqG/1x13NU3/ql 2Us7RQPOzlIhRcU8cobdOu4MhTS7aEZwUjPMrUlZY1VhotPiOTV6Y4PnAABADsHXR5Ua4ZFvKDyH jBY8Z3hEnhNZTZADuRRH0mI4klBvJGX/NNdzEsOpSUwDjvEcR3J2ry8sibG8dqucosRmc7byHBEb 1edk9pLbUW3neNFiIyZjWmzsALVGfoaWtOe06Y0NngMAADkEXx+J+MIj31B4DhkteM7w8DwnUJog h3YpjqTVcCSu5Dx5+rjOc8ouahLddBN4zmJxfbCaaFtvdndvLKyIrmiruaFEaGXJGI6p+81VxZXV mP73qt9aOc+Q4nlOtt7YPHv3v3r2wdfJvufKN/VxDgBjZvM/hocb2Z8EXx9NKYRn98tf4jlktOA5 wyPLc3I6qh3mpTiB4egkPceTHEm6PUeeJcYyu7B5o1Kdsulm1zTd1KUUm6nwnG/+D//zxb/p8iVE DjhSJQDAfvDR/zs83Ehv8vSdX//s4r/Bc0jX4DnDo8VzcgxH0sFwJKHeSDqOGW3jG46kuhQn8JzQ cHTEc5wuapLd3SfbV6srapTtbN2oJEeiBEZfQOzW/VGmpT3nhVf/cnf9O7vv/lfB1wzpRfAcgH0C z+lnFv/hs1/9q8ef/Yz2HDJC8Jzh0eQ5ezccSZvhSEYyHEmd4QSekxhOzcb3HNt6s72pR0jTKWxH Dznw7GkhMHhO4vqc+9fyhefZ+nfUJTpkv3PvnHl3AGC83L8WHm5kfxJ8faRT6I2av/iGot8aGS14 zvBIe07KcCSR4eQ344RuoxMZjmREw/ElJ/Icx23clJ5jDcdEKc2N7a3ZOTO6tGRmcae4GidTYKbP cywZwqO/jQAAAJoJvj68OHpjkW8oPIeMFjxneISek9NRrT+GI0kYjs6tq0eLF3V04V6kN2UurRyZ u3o9JTk2Ny7ZkdN0G045tNr8li36q6yq4QqK/0+x51jqhQfPAQCAHIKvD5WU3ljkGwrPIaMFzxke nuccSEe1fbgUJ4jppXbvVTPW81VzJ5wgu2potSPzm4HhuEOrqchJsxgk2vZV00OrSSKHEQWy/dnw HIdIePAcAADIwX5xNOuNRb6h8BwyWvCc4eF7TqPk7NlwJCMZjqSb4agok7lUdV3zDEeyu3vj0kox PHTYhqOGjZ7fMoZjoqQleW+c2cUtM/HZzvL80kzVyGM8Z2Zxp5wyqHTzHEspPHgOAADkkKk3FvmG wnPIaMFzhked50SG0yg5oxiOZETDSUmOYzhGcopcv7SinWRmYdO06ojhbG8en1c3Ay1u/VkZjo54 jpp/fm3Z9EATgVFK493uc9Us1s2RqjHn2fqiUax097bJz4ieAwBw4Jj7m81vmb9h0Mg3FJ6zf/nu taIMuLYeTB9G8JzhEXvO+A2ntRkndBsd33Akuc04QW5tvja/NOOOnzZn740TSs7TZ89uLCrDWReT KZ8yIwLjSo7O9pbIklngMdWSYxt24hvsDK9VB8+ZVLa3TjiHg/7o3tw2D8J+c3OxGtrERs5I+oeV HpLcYDklnljdMXMcHjcXV2bz9hueM1XIN1Q/Pee5cw/cr1Gdj2/fmX/zcjDnwee5c3fOXvv0uyfC 6XHwHJgsAs+JJCcSGzdtknNgl+LUGI4b0z/NJjIciX/2IQ3BcyaRZM0qUT0we1C2TgP26r5kxHZu mhn7QsMGH5k71K21/Ycz7AXPmSrkG6qfnmMMIZnbnz4XzX9wOfHpx3ozMuwFz4HJIu05ezYcSWQ4 klbDkWA4kxA8Z+KwkuM1HWwX15Up1VG9LgfLqupHmluXd5q5I6mCe+emM4T96Ovdn81ObPD2zomy KXtm8RD12I710r4NeM5UId9QvfYc1xBOXJ6/Zhp5Pj53iK0662eLbTib0bKE58BkEXrOWDqqhXoj GdFw9iY5oeFIEoaD5IwQPGfCKIpgSbrUU3U2nlNy0J5juNn8HrVyYJ5TYKZPiB7jOVOFfENNjOe4 05/d+a4/vZ/Bc2Cy8Dxn4i/FsdmlGWd/g+dMFDsnzBjr+1K7TwCT4DlCKQ9LJ0a4VudgPcesbrRN PXDwnKlCvqEmy3P+xZt3ii/WB/MZl8ccevAcmCx8z4ncxiZHcpoNRxLqjc54DUeC4ex/8JxJoryS oVMvo5ura7YzlXruXPIaHmVQptgtRjjQM6sLfha3/II7f07Lzk1nOBCZs/5i/Z3lRWdOdVm/GVyh 7pKk5K7Inzlv5yRoK7ir8ejNBIV+dbWry9vsloXU0cVz3LdY9k/xxEiEmnedfi1pWzP3MbMLNPY+ u6r/tJiumGb58klo2u05n7Gs1wX9Qb6hJtxzLs/fLv888elZ9X/3UZPn3pSHqoENPr79IOh1ZoY9 SF75Yy7ICdb47OybzjzF9O9ee2Au3ZFVXFuXRdV7zuXn3rzzsdlayYOPEwMbZL20QwyeMzzaPWcU w5GMaDgpycFw+hc8Z5Lo/NO7qSDjRAVoWQJKDR3P7JWV+XNqqm1Q3lJWxqlXsaVLzyB6U4sq1ql6 i0UVtbV5skvezPk7J0Gb55iFO4sy5lNMrPaDxGpMxma3L6SOUTynHFVfx9mMjF1XOnn8BkUKZJbm z1m9Upsjx1aMnISvotqexs9Y6+uCfiHfUAPxnHN6uokjIUZLEnGtphxdILKXWIGSnmMu2vFzx8hJ +CqcTbr9QKSrnD9wmNaXdsjBc4ZHk+ccvuFIMiUnp6Mal+KML3jOBGEKxOxLKUxpWwzCZmvK5bLR ILYXM70atE39oK4nJmvctjkVZhvm3B/X1Z2s9ERHJ8xiVRlqmwWKwRW82Tr16WqcucvOSVCrDSXh a1R1f9jkVb6hfjnesNn5C4mo2eByt3urc99iNRa/YtvupcxdVy65Zo2OmJkp8WfM+TAUrVjF8uNl 2l2d+RlT01OvC/qGfENNlOeUhhBZR5E7pknkxGUrMGY5z1QDjn3Kd+2g1dXyy+XUrNEZ+cBMSanU g3LYa1nFHdu2EyzTbNJttwHnsp1YqVfbSzv04DnDI+05nuFIQr2R9GbMaC7FOYzgORNEqnSrp/UH da8ytpVlWf8ZaqvSjDnNNqRKcDvElvk7t6lqXJ7TbeckqNGGijwpjfaD0Ok1KlILiUhssBq1Qk2M nmvf4tROyN516T2Q+EiY1VULrFtFOd1/FfECNfFuaXxd0D/kG2piPOfEetl3q8YxvMaQIq2tNM6z yin+CAdhpzVJ5Dl1aymn+68iXqCOHcbNTml8aT0InjM8Ep7TZjiSkQxHMl7DkWA4hxQ8Z4Lo5Dmm ysyt8qNasySqj/PnLLchJQN65qrLVsPWuozJczrunAQJbfBJV/khqZ3Z2XNq3xEXvcHJRH3emhbY Ydel9mTq6eHqGlaxl89Y5o6C/iDfUL32nFT8QaUj63CScdVNi66klhCusWEtsa2ZmcNWIxU9c2PD Ub+C5wwPz3NGMRzJiIaTkpxxGw6Ss0/BcyYIU+S1lM6GxkLcFHw5JWBUR+bPWdXW9lITGz3dzty4 tQ5j8pyOOydB6wabGcK17ywvrs3Oh/vB25ntrzFjIRH2vbAphnlIDgjR5ANddp3505k5uW/D1TWs In7Ivi67N2z09HjtzTsK+oN8Q02M59xuuFg/LQOJRqEq5omxVzjzx/NUE+0aG9YSP2Rf18fFlTlu 9PR47XgOHBgpzwndRifSG0l3w5FwKc4AgudMEEYksnrdxCWmS1xu1paAY/GcugQFcbNaKMbjOV13 ToLGcl9IrELvn2S8ndn4GnMXEtG2wS61b3HnXadfizVz08csEPVwdQ2bGj+U/RkTGl4X9BH5hpqw cQjCNMhA7C1uUg5jBjkou66ZFp7gXj3j8Zy60J4Dh0jkOaHeSHpzKY6k1XAk0TFGxh48Z5IoqkZJ TqHWWNdG9Wh9Cbh3z6nZBo/cOcfjOV13ToK2DTYXhwQVv5pSjpRdkNqZDa8xfyER+e9F8wI77jrv Ipn4E1IQrq5hFfFD43pd0EPkG2q4ntO8kJTn+BfJ1PQxG4fntL8uCZ4DB43vOaHhSEYyHAmGM+jg OROFqRpzCn1T/yXn7HJ9zl48x0zZ49a6jNdzcndOguby2rxwp+WtZv7Uzmzd7JyFRDRvsE/TArvu Ome9dYsNpzd8bOJXkf8Zy9xR0B/kG2r4npN5fU4RZ711Sw6nj3J9TnKTwuA5cNA0eE5kOJIRDScl OY7htEhOnuEgOQcZPGey0FWdJN3aoEbQKmvr8rf/uKorq3C3+1BtCWhmrirL/DnLkj2no13dnFI6 uyWsmS3rCqWmmbvtnAQN2nCzXLj7qJ4/etfMiGfeZtRvdoeFRDRscESjD3TddfblrCY7rQnR6upW sWqGlh7xM4bnTBryDTVgzyn7oSUeNb4R9klzuq69mey0JonWWLeWN8uhpd1XEd7/pyF4Dhw0Sc9p 76gWuo2ObziSg7gUR6KPOnKAwXMmDVOrSfyLyM0NRpyCz8wpU8q73AjVjW78crm2BNyT59htmAsG odZ303dL3rKpSra/3Fp130z1XMdzqhaDYp7tHaf7VkTTzJ12ToKkNtzc3jpRLiFoYagcwG5D3bDO 9ZvdYSERY/Oczruu7MJXDAyQ2oB4ddUq7IfZ3p8nWkg5c/tnrPl1Qe+Qb6ghe075qHjFWXNnGzXx u9fMRf9+pzUd03XNDAyQ2IB4jdVaSntxbtETLqSc+XZ5S5wyz7356VmZWE1pfmmHHzxneASew6U4 JCt4zgRiyrU4qvR0q8yyYo4zE5abtSXg3jxHqApx2bxiICz7p//Tfmpri2LaPF4QvvZGIWmcucPO SaC1oS7q+hkzo8WU+xI10Jn+T7FD5D/ZrzF/ISHj85zOu87uK9nUVKtLanVl040bZTK69WbEz1jb 64KeId9Qg/acqn9anI9rFm5WrZJsdUmt0TbduBFp0a034YqqGwHJKorB1uyfeA4cJp7nhIYjaTUc ScJwUpKD4QwoeM6EUvxWbSpdiVS96jb5qSJStfN4VeDK8nbsBrUl4J49R/C2QSKVaHpri/YQ+6LS ox7LPHbI4LmVlt5KLTNn7pwE+sUGqX1dGqe1R81cvDq9nHBnNmx2/kJ8xuk5ii67rvSimqtoalZX dMK0y1c7ViamPUfI+YzhOROGfEMN3HNULn/33B3HJcQr7nz3RNySU8aqUfoqmpo1qtuY2jacB2fP ravnpj1HEmySaj5ST/G0Cs+Bg6bec8ZoOJJMyQkNR5IwHCTn0IPnAABAD5FvqH56Dul/8JzhkfKc 7oYj2bvh0IwzQcFzAACgh8g3FJ5DRgueMzx8z/ENRxLqjc54DUeC4Uxa8BwAAOgh8g2F55DRgucM j1rPCd1GJ2E4KcnBcIYePAcAAHqIfEPhOWS04DnDI+E5odvoZBqOJFNycjqqcSlOX4PnAABAD5Fv KDyHjBY8Z3iEnhPqjcQ3HMlBGI7EL6xJr4LnAABAD5FvKDyHjBY8Z3h4nhMajmS8hiPBcAYRPAcA AHqIfEPhOWS04DnDo95zEoaTkpxxGw6SMxHBcwAAoIfINxSeQ0YLnjM8Up7jG46ES3FIEDwHAAB6 iHxD4TlktOA5w8P3nLEbjqTVcCR+DU36HzwHAAB6iHxD4TlktOA5w6PWczAc0hA8BwAAeoh8Q+E5 ZLTgOcMj4Tk5l+K0SE6e4SA5kxs8BwAAeoh8Q+E5ZLTgOcMj9JyDuBRH4hfNZOKC5wAAQA+Rbyg8 h4wWPGd4eJ7jiY1NpuFIMJypCZ4DAAA9RL6h8BwyWvCc4dHoORgOqQmeAwAAPUS+ofAcMlrwnOFR 7zmZkhMajiRhOEjOwILnAABAD5FvKDyHjBY8Z3ikPCfbcGjGmdrgOQAA0EPkGwrPIaMFzxkevudk Go4Ew5nu4DkAANBD5BsKzyGjBc8ZHgnPCZUmCIZD8BwAAOgl8g2F55DRgucMD89zSJDfev7n/92/ P//f/s8f/Oa/+WnwENHBcwAAoD/gOWTk4DnDA89pyn/9P7ytP/r/bPZ08BDRwXMAAKA/4Dlk5OA5 wwPPacp/8z+d1R/9f/adheAhooPnAABAf8BzyMjBc4aH8hyo49+/9bH+6L+1ettMAgAAgL6C55CR g+cMDzynCTwHAABggsBzyMjBc4YHntMEngMAADBB4Dlk5OA5wwPPaQLPAQAAmCDwHDJy8Jzhgec0 gecAAABMEHgOGTl4zvDAc5rAcwAAACYIPIeMHDxneOA5TeA5AAAAEwSeQ0YOnjM88Jwm8BwAAIAJ As8hIwfPGR54ThN4DgAAwASB55CRg+cMDzynCTwHAABggsBzyMjBc4YHntMEngMAADBB4Dlk5OA5 wwPPaQLPAQAAmCDwHDJy8Jzhgec0gecAAABMEHgOGTl4zvDAc5rAcwAAACYIPIeMHDxneOA5TeA5 AAAAEwSeQ0YOnjM88Jwm8BwAAIAJAs8hIwfPGR54ThN4DgAAwASB55CRg+cMDzynCTwHAABggsBz yMjBc4YHntMEngMAADBB4Dlk5OA5wwPPaQLPAQAAmCDwHDJy8Jzhgec0gecAAABMENpz1je2XnsT zyHd8jen31vfuo3nDAk8pwk8BwAAYILQnvP53S/fWjpr61dCWvPbL/1icfmdrS8e4DlDAs9pAs8B AACYIKQ8ffx09979J8vvrXzrRyu2iiWkOf/fH3/wzvlLn9599OXDJ0+e4jkDAc9pAs8BAACYIKQ8 ffL02c6DJ5tffPXW2+e++ecf2kKWkLo89/L5M+9+eOOzr7Z3Hn316CmeMxjwnCbwHAAAgAlCec7u s/uPnn7+5ePrn9498865f/uX5205S0ic/99//uDM2Q/WPv1y44uHt798/ODx06dYzlDAc5rAcwAA ACaLp7u7Dx8/vXv/8ad3H9747Kuzv7jy16fepw8bifOHr57/6cJ77//y2rVb92/efrh979HOgyeP nuzSmjMY8Jwm8BwAAIDJQmrUp0WTzp37T7buPlr//MHqjVsL766I7Tz3Mm07ROWPj38ghrP0/oXV m59/tH1fPiRixXfvPxFDptPakMBzmsBzAAAAJo7d3d0nT599Jarz1ROpXz++/eD6Zw8u3bi1+N6H p5feeekn537/h1y3M4355p9/+IO/PXdq6Z3lcxfFcNZu3b++ff/j2w9v3Xt0577psYbkDAk8pwk8 BwAAYBLZ3X325OmuVK73Hjz5bOfx5p2H658/+Gj7/pXNex9evnHm7fd/tvjuv/srBiqYinzrRysi tz9fPLvwzrkPr6xf3rinDOezBzdvP9i68/DznUfyITEtObTlDAs8pwk8BwAAYEJRrTq7z6R+/fLh kztfPd6+92jjC2U71z+7f+3W/V99fHvlVx9J4Xt66Z0f/O25P3z1/O9+zyuOyUTnX37/F398/IO/ eOPcwvI7C++eF7ld/eSLtU+/EtdVhvP5A1Ff+Ujcvf/kq4dPHz3ZpbvaIMFzmsBzAAAAJpfiWp3d x0/UyARfPjC2IwXux7cf6Oada7qF58r60rmLi8vv/GzxXXEeqY+lSrYVM5mU/N4PPvyTE8pt5H1c WD67fO7iL65+fGXzS9EbMVvxW3nTP7n94NO7jz7/8vGd+09EgB9qw6G72kDBc5rAcwAAACadwnae ie08ePz0q0eqJ9vtL5XwbN15pIXn+vZ9cZ61W/dXb34uziP1sVTJp5fe+cu33v+z+ff/8NXzUkDb Ypr0J7//ww/l3ZH36K9Pvb+w/M6Zt999+/wlcZtLxbU3EvFYeXOV3nzxcOvuo+2dx/LW7zx4cv/R U91RrXAcGCx4ThN4DgAAwADQP9hLUSul7aMnT0V4vnz49O79Unjuqi5tNz9/cOOzopGnKJGvbN67 +NHWyuq1pfcvnFl+V8poKaZ/8LfnZk+e+9aPVjCfg49Yjex5sZq/eOOcvBdLy2+feft9eXdWLl37 5fVbqt2meON0z7Qbn6kBBkRvPhW9ufdI3uh795+I5T58rNr31HgDtOFMAXhOE3gOAADAkJDSVgpc KXML4VEtPF8+fLLz4MkXXz3+fOfxraJXmziPlMi6nedaqT1Xt7785fVPP7yy/sEvry68e17MZ3l5 Wart/+Xvz0nl/ac/VvJDb7dxRTRS9ufzr6t9+5dvvf83p9+TvS1WI3terOYXVz+W9+LKlhEbeYM+ 2lZvlrxlH982TTfyVqrOaV89vveg0puiAUdduIXhTAl4ThN4DgAAwCAJhOfhk12phsV5pCxWzmM6 tj3cvPNI6uabn1fd2/RVPbrCvnT91sWPNldWr7374a+kBFfXhCwv/3ThPfGfv3hD1ei68UfCIAdx RAv1zpEdJXn1TdVK87NFJZBn3n5X9uf7F66I1Vz8aOvS+vbVT80+L6zGNNposREvFTvV7TbabURc v3z4tOicpt5c0z8NvZk+8Jwm8BwAAIBhUwiPqoOlGpaoQQue7EqJLIWyOM/d+6I9Tz7fUTW0VNJb hfZIbW3MR/dzM20+X+lCfPXm7V9e//QXVz8W/9GNP5LF5XekfF9afltKeYnU9Lq4/+PjH+haf3i3 9Pnmn6s2GcmfnPhAv9j/5e+VyUhkVwiihXrniMxILqxt/PL6rUs3P6+Uptix8q9jNaor2sadh6Kg n959uL2jjFS8VN6mnYfq4ivXbSSqcxp6M8XgOU3gOQAAAFOCqokL55H/GOcpLuZ5+FhVz6I9Ow9U a8+dr1RhXZqPaknYvKMu75ES3MqPRDc7qDK9KNmvfqos6ErR+U0iNb1YkBT3asyDotY/87ap/oWf L57VPuAakY5tIKqL1Yxkfnj8v7/5d/+7//GV54Ppbn77JdPMUhd3eyTWXiTqFpwlC++c0y/t7fOX tMlc/GhLTEZ1Ofv0K71DiqjB0LQuqu5nnz24UexG2Zm6E5rsYd0P7TNjNUo+74nYFB3SlNg8Ue+U JHAb/AbwnCbwHAAAgCnEOE+hPVVTj27teaxaDKS8liJbSm2JlN13vjJX+Ij8SEUudbm+zkdi2n/0 BT+fqdGNy5q+FKGiF5yt+69+ev9Xn9zROiRWoIyokAQd20BUFyMZKc4uvfHk5//F7s9/7cu3/pGZ lGJp+e1gmUHc7ZFcvLZZ2IsSmF9t3JXtdxxGRTfL6Fet/3N9+74jM2oXqVaaLx5u3ZFdV/RA23n8 2c4j2aVilaqtpuiHVjbXqNvdSPT1Np7YmHcPwIDnNIHnAAAAgKs98n9rPk+ePlMF91ORn109aPWX D1VFfq9o+Sn8Rw1kLJGqXfd8kxRNQEaBPrmtWi0KEVJ1v0QE4IZqEaosSBuR+bOM7ianjMKXirrI nNc/viSSI3m08I+KFpVQSGpTNb+othebasPUv6oLXyFyavv1a7FtMkr5ioYv3TgjO0FsUPU6KwZ6 tj5zT6KUpmyoeaysUnymaKsxjWzKaxAbyAPPaQLPAQAAgJjKfCr5MYW4VORSlxdtDqrxQfKgbP9R Y7uV/d+0BUmJrxqCvjQjH+jmoE/vqutPxAe2CjHQ/eLEE9S/hRoVbUSqm5xuJsqJuMcnG6vGcxb/ 0XUz+HI4W11EwwofM26mt0RvkrEX1RSjRe6hchjdzcxqzH31epXJFK9dtc8Uvc4k4ocSrYv630Jm 1M4MlKbY1Wb/A+SA5zSB5wAAAEAmnvyoP1WFLsW6o0Cqt5Ut6OXfh092HxRtF0qEinYMPc616JBS gkIM7t5XbR2iCtaLdBuRtqPPdpRRNMTq02fbv9Ke83jxH+kWFTWxmMGdPxU1jpmkkBbVQ0+pi7IX tWGyeXZTZbO/lJRXzhQaoxq75GWql6z/LXaCIzNqF8U+o/4A2Bt4ThN4DgAAAOwdVbjbIl7HFPdO Q5DfIqQjYmANQbUOFff8KdqIjB21xujTgydf3rmiPefp0tf0FS/6oheZIXhKXeyqZTPkP4+eqE5l Zgv1BiuB8V6OozHFSw53gtk/APsBntMEngMAAAAHgDEB1wHcVKqgG4i8NiJlFM3Rs315zXjO8tdC IWmOnq2UFs9b1H+jrdUp5gE4RPCcJvAcAAAA6CelbGREi8d94zm7y18zU3SCmWsCMHHgOU3gOQAA ADAQHM8xUwAGDZ7TBJ4DAAAAAwHPgSkDz2kCzwEAAICBgOfAlIHnNIHnAAAAwEDAc2DKwHOawHMA AABgIOA5MGXgOU3gOQAAADAQ8ByYMvCcJvAcAAAAGAh4DkwZeE4TeA4AAAAMBDwHpgw8pwk8BwAA AAYCngNTBp7TBJ4DAAAAAwHPgSkDz2kCzwEAAICBgOfAlIHnNIHnAAAAwEDAc2DKwHOawHMAAABg IOA5MGXgOU3gOQAAADAQ8ByYMvCcJvAcAAAAGAh4DkwZeE4TeA4AAAAMBDwHpgw8pwk8BwAAAAYC ngNTBp7TBJ4DAAAAAwHPgSkDz2kCzwEAAICBgOfAlIHnNIHnAAAAwEDAc2DKwHOawHMAAABgIOA5 MGXgOU3gOQAAADAQ8ByYMvCcJvAcAAAAGAh4DkwZeE4TeA4AAAAMBDwHpgw8pwk8BwAAAAYCngNT Bp7TBJ4DAAAAAwHPgSkDz2kCzwEAAICBgOfAlIHnNIHnAAAAwEDAc2DKwHOawHMAAABgIOA5MGXg OU3gOQAAADAQ8ByYMvCcJvAcAAAAGAh4DkwZeE4TeA4AAAAMBDwHpgw8pwk8BwAAAAYCngNTBp7T BJ4DAAAAAwHPgSkDz2kCzwEAAICBgOfAlIHnNIHnAAAAwEDAc2DKwHOawHMAAABgIOA5MGXgOU3g OQAAADAQ8ByYMvCcJvAcAAAAGAh4DkwZeE4TeA4AAAAMBDwHpgw8pwk8BwAAAAYCngNTBp7TBJ4D AAAAAwHPgSkDz2kCzwEAAICBgOfAlIHnNIHnAAAAwEDAc2DKwHOawHMAAABgIOA5MGXgOU3gOQAA ADAQ8ByYMvCcJvAcAAAAGAh4DkwZeE4TeA4AAAAMBDwHpgw8pwk8BwAAAAYCngNTBp7j8cVXjy9+ smPz7b+5rj3nlXc23elfPnxingAAAAAwEeA5MGXgOR7iOb/zvYvabery//jz1UdPds0TAAAAACYC PAemDDwn5D8tbQZiE+QnH26bWQEAAAAmBTwHpgw8J6S5SYfGHAAAAJhI8ByYMvCcBA1NOjTmAAAA wESC58CUgeckqGvSoTEHAAAAJhU8B6YMPCdNskmHxhwAAACYVPAcmDLwnDRxkw6NOQAAADDB4Dkw ZeA5tQRNOjTmAAAAwASD58CUgefU4jbp0JgDAAAAkw2eA1MGntOEbdKhMQcAAAAmGzwHpgw8pwnd pENjDgAAAEw8eA5MGcpz/umxN0hd/q//4zv/l3+7GEwkNv/6R+/qTxIAAAD0GjwHpgw8pyW/9e03 f/Pf/DSYSGzwHAAAgMkAz4EpA88hewqeAwAAMBngOTBleJ5z64v7UR5su7lj8ll9Pr8b5KHNbcm9 MF/E2TG5U+WRzV2dLxO5Z/OVlx2Vx2HuP/6yLV9JHsR5EuS+5GFTHgR5lMxTycMgj8M8qsuTMI9V dhN56uVJc3Z3n4Z5Jln56HM8BwAAYJLAc2DKaPAc33AkbZLTYjg5ktNoOEZyIr2RdDWcVskZl+FI RjQcSabk5BuOpIvhRJKjDAfPAQAAmEjwHJgykp7zYM/NOJXhGMlpNRxJazNOpDc6SckpDCeSnEzD SUhOynA6NeOEbmMT6Y1kT4bT3owTKk2QRsPRwXMAAAAmDDwHpozAc/pqOF2acdKGI4mUJkiN4UhS khNZjRvPcCSh2+hEeiPZZ8PJkRzfcCSh5EhWruM5AAAAEwWeA1OG5zme4ZSSE1iNG99wJL7hRJIT 6o1krIZTSk5nw5H0sKNa6DY2acmJ9EayD4bz9JkKngMAADBh4DkwZdR4zh6acZKGIwkNR1JvOEZy Ir3R6WQ4Wc04od5IUobTqRkndBubSG8kvuFIQrfRyTccSRfDae2oplIYzm4RPAcAAGDCwHNgyog8 pycd1SK30Uk246Q7qnEpTo7hSHIMR1IaDp4DAAAwkeA5MGX4ntMHw6mRnA6GI4mUJkiN4UhSkhNZ jRvPcCSh2+jYjmp3r124+srJpaPH3jh6+m6W4UhGMpx2yQkNRxLpjcQ3HB08BwAAYMLAc2DKCD0n EBsb33AkvuFEkhPqjaTRcIzkRHojSRpOKTnKai6/tWhfgptvvHUn0BudcRmOpIvhKMl5ZU4Zjt48 13NCsbHxDUcyLsPp2lEtCJ4DAAAwYeA5MGV4nhO4jU0nw5GEhiMJJSfLcCRJyUm24Vz+8Lx+FUde uvzWx6Hb6HQwnE7NOKHb2FjDcfJ44wXfc0K30ck3HMnYDUcSuY0bPAcAAGDCwHNgymjxnDrDMZIz iuF4kjPWjmqffFt7zuufBHojyeyo1tlwJKHb6ER6IzGtN5XnhG6jkzac9macUGnijMNwdPAcAACA CQPPgSmj1nN8w5H02XB0jOfE3dUO6VKc2HAyPGckw2mXnNBwJJHeSOo7qgXBcwAAACYMPAemjITn tBhOjuQ0Go6RnEhvJEnDKSUnYTj+eAMJzzm8S3GceJIjqfEc33AkB9pRLdtwdPAcAACACQPPgSkj 9Jy9Go6ktRkn0hudpOTkGY6O5zk1HdVShtOpGSd0G5tIbySh4WiliTzncA1HEmlMa/AcAACACQPP gSnD85yk4RjJGYvhdGnGyeioFqTynE6X4ly5cP7oS2YPHDm29PypjStJw3l453QxHrSe8+jc+dMb geHcPXN6xc4gizp6cuOaZziR56QNp0Zy8g1HEhqOJNIbSSQwmcFzAAAAJgw8B6aMpOccsuGUkpNv ODql55y602w4krIN584rL4mQnD+1Yf48dXJJliBTlMO4krNxRQTmyMmNtaL1Zu2CGttNTOaVjUpy XplTa3/hQjGK2qaRGXmKYzi+55wJPaefl+Ikg+cAAABMGHgOTBmB5/iGkyM5jYZjJCfSG0lXw2mT nMdf3f/k+eJV+J5TZzgqp05qV6mm6ImyEKU62nCU2CgzOTJ3RUtOEWM1ojHGcy6sqD/nrtoGnGun tTKtLGR4Tp8vxUkGzwEAAJgw8ByYMtKec3iX4kSSk2U4+lKcwHNShuNIzn3dJvPSFdtLTWKbbuSh o6fvaKtZK4zF/mk6ql1QXdSOnr6rPeeMtiPHcx5dLMzn2NKrm47kKKvxPGffOqpFeqMTGctowXMA AAAmDDwHpozQcybkUhwTf7AB13NSkuP4jMS025zc0H9WXdSKzmzqIdOAc+eVOdPs0zTYwMVSe6zS BJ5TNt24nnPAHdUCV9lL8BwAAIAJA8+BKcPznFhyQr2RNBqOkZxIbyRJwyklp7PhSKLBBtKeExtO ESMzR0/dkT8dyakacEq3KTqteZfiOClbb3SM4WzeXShHLDCeU0mO6zn3Qr2RdDScA+uoFgTPAQAA mDDwHJgyfM/Jk5yuhiPpZDhZzTie4ehsBJ4TdlTzYmY+cnLDNRydLM/xDUcihvPR5sYLRePPC6c3 PrLtOVue5zx+svFiseqE50yC4ejgOQAAABMGngNTRtpzQr2RHEBHtQ6X4sQRsak8p9FwdEyjivGc 0nB8zzl/WilN2fxSXooT6I2kaMZRbThqtpMbH+kpkeeUl+JsJjwn33AkOYYjieRkjMFzAAAAJgw8 B6aM0HNCvZEcgOFIIqUJ0mg4OsZzdFe0ZK6cOq+aaIrWm9N2XDVfcirPmbt6TYlNObSaM8aAzUen V/TlNwvl1T6F8xRi43iOP9iA7zmO4bRLTmg4kkhvJJGWjD14DgAAwITxcGP3g6+rXPznZgrAoPE8 p5PhGMmJ9EaSNJxScjobjqTNcDI9Z+P5l8rRoiXFeGuSFy4EnvNUK9ALF0wXNT1CtJpy0ZOcR4/v vjp3tWi9MW0+MoNuuok8p2y3cT1n4V4nwzncjmpB8BwAAAAA6DP1nhNKTpbhSJKSU2c4Wc04od5I AsPRl+JUl9xEhqOydmqpuhpH+YwaSE3N790Yx3RUKxtzimxetYMKvHDRjqh2d+H00tHTd4v/N3vO 7vWLK69erPWcUGmCZBqOJLKR/QueAwAAAAB9JuU5jc04feqoZg1HacyVU6Z9JrgljuTBxp3TxcUz qunGSI6OGjZAPWXuymk9zMDGhhpFem7ljDYc23pTDButl28jLmQuxXnydGG+mHJsZUFdjXP3+pmV o3OmFUhNn9+07TnXF5T/qIlzV68HShMnNBxJpDeSyEP2O3gOAAAAAPQZ33P6YTiSDs04ynAqo2jI ETN+WpA7p0+Lk5TzzC29cOGuasmxhlPmkRpLzaxIzXa6HG/ANODcfXXePHp0TmynaLcpFnt0fvO6 lpyn914tV2Tz4qXIbXRCvZFEeiM5qI5qQfAcAAAAAOgzoeckDcdITqQ3kqThlJKTMJxxdlTzG23i mC5qOqHe6DxtuvWnKznJ2C5qZWrv+ymZ2EtxksFzAAAAAKDPeJ6TlJw6w5EkJWdPhpOQnJThtElO huFIIr2RTIThSCLxOODgOQAAAADQZ2LP8Q2nSzPOyB3VagxHkpKcyGrceIYjCd1GJ9IbyZ4Mp0Zy 8g1HEhqOJNIbSaQchxI8BwAAAMbFsr7OeX7L/A0wDgLPGdFwSsnpbDiSAzacHMkJ3cYmLTmR3kgc w2mXnFBvJJHeSA61o1oQPAcAAIbHzcXEFb9H5pZm5teWt808fSO5zTNzKydWd8wch8TNxZXZ7P2G 58B+kPCc9o5qeYaT1YwT6o0kZTidJCd0Gx0uxRln8BwAABgeutqui9jOTTNjj2jY5iNzh7fB22sz ehvy1AXPgf3A85x2w/ElJ91RbSouxWlvxgmVJk6O4Ugix+hD8BwAABgeqWp75+b21mw14OoezGG1 uLHeuN0jsc3bOyfKMWBnFg+rVWdrttiA2bxmJTwH9gPfcyK9kXQwHEmkNEFqDEeSkpzIatx4hiMJ 3UYn0htJpuFIRjKcdskJDUcS6Y0ksov+BM8BAIDh0VBt3ywspe7RLA7McwrM9GMry2ZCr8FzYD9o 8pyk4ZSS09lwJOMyHEmO4eRITig2Nr7hSMZlOBPaUS0IngMAAMOjudouzWHpxGjX6hys55jVjby1 BwueA/tBreckJafOcLKacUK9kaQMp1MzTug2NpHeSHzDkYRuo5NvOJKxG44kkooeBs8BAIDh0VZt m75YfmewneXFlZmyY5t6dG4p6KyVHCpA4iynfSF1ZHvOzom58s/ttdnixuWxBd1clYfaX0va1opr csplqtXJnLOr+jGXneX5JX31jlrF/JYsquZV7Nxcld1i5pQlpwaEyHpdMJ0kPKfecCLJGf1SHMmk GE57M06oNHEGZDg6eA4AAAyPNs8xtbtT5RvzKSYueaLiuFBRrDuVfTFnoRD68ayF1NHZcxbVdBvH Q8yri+NZTTnAQCwwvgLVeU71Ym2OHFsxfuK9imp73N0SOUzr64LpxfOcDoYjiZQmSKbhSLoZjiR0 G51UR7VMw5GMZDjtkhMajiTSG0nvO6oFwXMAAGB4tHlOOYOt+1XRvzS7qFokLKbcj5sU6vqtdVpI RF1LiJYEZ3WONhxbMa0i2zt2pWY5siWrduLOctkS5Sy/XHLNGks3M3/6vlE+V16XaSYqGrLKQtRd pt3VTgPOTrj/FS2vC6aZyHMcwyklp7PhSMZlOJIRDUeSKTm+4UjGZThZzTiTZjg6eA4AAAyPGmeo KPWj+eJ+O9SY+dvQ7fqcmoVEJLZZDRCnJvpPdxwjdqfWVhrnWemd4HVaE1KeU7eWcnr1KsKlWeLd 0vi6YLrxPSfDcLKacUK9kaQMp1MzTug2NpHeSMZuOJKxG44k8odJCZ4DAADDY0yekyrxhW6eU7OQ CL3NyQTXETUs0Lyu5LbFcpLSlWgJidU1rCXY82bO1Buh53QvbcrcUTCFJDxnvzuqdTYcSeg2OpHe SPZkOO3NOKHSxAkNR1JazfbO0oLqgSrnxyVPG3aOF4eoHLTOxF4HzwEAgOHR6jlmhrBS31leXJud N1fd2CtJwsq7xXPyFhIRe466mqXmen15NLnAxhdunhirhTN/7Tzu6hrWEjxkX5TdGzZ6erxqPAdi Qs8Ze0e1t143C2/N0VN38g0nITmZhiNJS06kNxLHcNolJ9QbidN0s71WHZzF70CONuA5AAAAh09j uS/E9b1peUgm33M6LCSibZstDT6QeF0O5lHHYcrXYtu1TDczt5krsboRPKcuzUIFoPE8J9QbyZg6 ql25cOVosYojJzfcdpsid65cOC+PiueMaDiSTMnJNxxJF8PJ6qj27NkN3Q4bes7kBc8BAIDh0eYM 5uKQqsguyn01ZX7rZtV+UlN513lOp4VEjMNzmhdinuh5jn+dTKqbWWJ1DWsJHsp+UULujoIppN5z Rh8z2jMcSdFR7c4rLxUf2YTnqKydWpKHGg1HEumNZE+G096MEypNkK6X4ji/f7jaMHHBcwAAYHg0 l9emmneud6+Zv6byrvGcbguJyFaCpgWahST71KWuxhGc9SaXnJhodmBqLcGraJgzIndHwRRS4zmR 0gSpMRxJSnKUydR6TtmAs/GC9pzQbXQivZEcruFIQsORRHojcQ0BzwEAAOgrDc5ws2x1cR/V8/sN HYIZ7iysvJ0awKXbQiIattmn0QfKVxc/WtpduNnVy1mNO60JqdXVrWXVDC1dvQqz8Jwh1PAcqCXy nEhp4nQ0HJ2055SSUyR0G52sjmqh29ikJSfSG4ljOO2SE+qNJNIbSTxmtHOO86ZPWvAcAAAYHkln uLm9dWJe1frqIb+FoXIAW46nx3QuqBpGCqXZ3tG91LotJGI8nlM+KmphNk+xs1y+8EjDhLIXX3H5 cbQBydVVa7HDT9tb9PgLKeecc3ZLwc3VtVmZaP4Sml8XTDW+50RKE6SD4XiSIwk9Z1yGIwndRiff cCRdDCero1rdXXHwHAAAgL6inaEu6voZM6PF1PoSNcqZ/s8xMyxYVHmbitymlIdOCwkZk+dUGhZH XriZx8furlTDS83qyqYbN0pmdIHkraiSPb03Zqo/8RzIwvOcwGrc1HRUyzEcncpzAsNZO33+lQ1X b3SU0ly7sHLU+Yi/cHrjmmc4dz+6ePWFk0tHj73xwsWnjzavvlDMfHReTdHPKp64siCGs3XVnSh5 8aIxnAXnpDazcK9UmnuLC84NeuUAm9+8XrnNvRuXrqrBH+W4uqTGUtOH4sz82o1CcqwPrMvxXDwk S5hd3El5zs766trxYlFyviufteVNUb/rFD+W6IVUzy1TzlDOs7UezDDu4DkAADA8dNNKEKmw5YvV GSHAx2ntUTMXAzrr5SQqb5nZfl/PrVRu0GkhPmPzHMXO8qKpW9QylV2sLG/HLTklpRqlLqSpX11U tKjnJjxH8LZHknov8Byopd1zagxHkpKcUG9sUp5TKM3pk0u+5+h2m7uvFPeZObOh23DunjmpDgk1 ZVNJzqPHG6/OVT7zwulKY47MXV14clfbi5xElOSU7TbXL6qjSHL0zD23DefxJVGalcVbtt3m3mvF MfPipUJ7bm2+qJc8v1lIzubx8ucWyexC9fuHHOeuwMipRw7g46vaTFTjr/5txvGcHXdR2mrUbO6U 6PcVq0MmxU8jsurCbdRK3ZnllOHNPKbgOQAAAADQZ1o8ZxyGo+N7Tmk1a2q8aes5VUe1MyeVIbxi JMdEJqolHFtZsJ3TNo3eyMyvbgUd1TZETtTMpeQUufdqITBiLFZyxGQW50VprOTsPrlU/Kgwd/W6 /L/oqHZjwfjJku2oZn/DEJPZTnRUW19c0g85E819chzP0anGqQynzK8UP6UUE7fNxFJpqjn9FcVL G3/wHAAAAADoM7We08Fw2iSnaL0xnhOn8BklOdpwVC4YzfB7qT19WFrN0dN3y+twNl4opqh+a47k 6EtxdJOO6Z9W5nppLAvWap5uvnhsZbH6U2mP3oCqo5o2H6002nN2jU6ofmuRBuhGmLgtReRHr73N c0ojmvd6oCWenrrgxzRhezo05uA5AAAAANBnEp6T2VEt23A8z1HtOWVjjsrGlRdsu00Z025zcsOV nMJq7prWmLmrH+kpT0LP8caMLnqpqaYb/adqvTHtOZKqAefSisxjJUdPEUuZWbhXXo3T6DmroQNI tGkkWlTS4xDUek64hOjpSXEyE/EcAAAAAJhWPM/JNBxJF8Mp8ujOK1pRPM9RHdWunV7xPOexujJH 5jx6+q5jOCYfndZl/dKrm1psKs/xDMdEXVcjDrBQdlF7fOvq0flN01xTuk3Yac26jc72vaXyghnP c0o5SXmOsZTEQ+P2nOQC8RwAAAAAmHJ8zwn1RtLZcCS+4egEnuOMGX3hauU5SmyMuuj2HFdyPM8x V+OYmV9UnuMajonpunbJeM7i/JJSGtM4o/uqOZ3W/DGjb2xvzqqxEJZmF7ZuuO055lKcBs+pf2js npNaV21r0viC5wAAAABAn2nwnJThdGrGMYaj43pOaTVuqi5qlecEkiP56IzpprVgLsVRgw3IlOAi HBNxG+0npulm80U9tIBym+JZhfOoR8O74qg2HJlhZn5LjRMtcTynrPXbPSdhGuP3nPJaIJlYbNu6 nmc/G3MkeA4AAAAA9Jk6z9mb4Ug8yZFUnlNvOCYL8bhqkkJsjOfMXf3I9FKr8RzbUa1QGlnU4lM1 AoG9PY7tuiYTxXYcw1FZMo9ulZfidPUcYykJ2dgPzyk6qukRq4tHuX8OAAAAAEw7sed4hiPZs+Ho mKtuPM+JDMcoTXmXGzW6gCM5Et0PrbwaR5SmbJmxnlMZjopVmhcvbb425wyqVnrLzJweKtpGrKYU mEul5Dx79tQIRqbnmJ5jkkBUksMG7NFzZJn7dJOchuA5AAAAANBnAs/pZjiSDMPRl+JEnlMnOSrO uGql4RRRXdrUcM9aaRzPUff99CXH+IxVmrmlGXdQtV3zxCPm1p/acHQcz7F3xXE8Z3115bhym1hO nDg395wpW1fWF1f0DYB9X5LEi6pZeOw5xYpm8BwAAAAAAIe053TuqBa6jY1purl2wd7Qc+WVzQbD sdl4oVSdBT3kwNaGyM+ROe++n9fPqLpfzebf99OP7rq29Nqt4s/yUhx9689Z1WnNGo6J6bcmOqFs ZEf8xPYKK9alpEImun8msqoGp7bPUnPOremLZ9T/VVOS6dVWLcpOsbPZm4SqmEYeSeU/5ZxxZBWz qykHG0fwHAAAAADoMwnPGVNHNWM4+mY4cfSw0ZHeFDGtN3cXzqwcLSv7I3NLL16857TkVHfCsTla Xn4TZHFeiZD6v2m6KbJ9daZoVwkkR0WMohiHQDJjTGNrtljdjLpxZ+UbNjWtOuZZaob5wmEKLZH/ H1/dKZQmsag4auGRz1RSVPSFq0uyW93eg+cAAAAAQJ/xPGesHdWitLfhFDGSUyW6K04Zp5daqhnH TziimiTSG4ntqDY5Ud3hkjKzvbOsBG9furThOQAAAADQZ3zPiazGTYbhSCK9kfiGIwndRiffcCQY js7qStPFOfJosqFpz8FzAAAAAKDPZHnOIRlOezNOqDRxcgxHEtXxExI1XEGDySzPL9FvDQAA9pOd E0UHbPm6gd4zJW9Wf17mAWwJB2ATLZ7jGY4kdBudVEe1TMORjGQ47ZITGo4k0htJVMFPUsqLdmbm 15a39QU/OjvrxaVB+zfeNJ4DAAAFlFkTBJ5zwEyw59xcXJlV5aX5c0Jp8pwRDUcykuFIxmU4Q+6o 5mVnuRwvIc6+DjaN5wAAQAGeM0HgOQfMxHpOeX+UI/NbZspkkvacDMORRHoj8Q1HErqNTr7hSMZu OJKocJ/crG9vHZ9fsmNYqxGrC/8OZhtv8BwAACjAcyaIAb1ZRZeWI3NrN83fLnhONrW7sbyZ5OqO mTCZhJ7jGY4kdBudSG8kezKc9macUGnihIYjifRGEpXsZITgOQAAUIDnTBB4zgEzuZ4zEDzPyTGc hORkGo5kJMNpl5xQbySR3kiG0FGtL8FzAACgAM+ZIPCcAwbPOWRSnhO6jU7WpTiS0G10fMORHGhH NQxn3MFzAABq2FleXJkpKg/Jkbmlmfmtm961vHqG6upK+X/UOUTVLkeOLZ2QJ25vnSgvxZQps4tb GRVJzdPdFdVN98jdVHnIL7PMbbKjzv07N1ednVN2tM5gnDvtZnF/7XRtV1yWYBbSROu7rLi5ujY7 2jZ3e6f0QlaWi/8vl13Zi90bfFqSb5am7a0pL9iYWfQ3oH2P5W+epuW91m9fHGfD3JdZXcksa8w7 fDTNb3HOB1Ko2+HNC7d9xszfluX5Yn7vsEquon3z2nZj7Ucl41Mt6De9/WAsqT4YxTLVPfrHgu85 odvYRHojmQjDkUQ1Otl78BwAgBSmvg/ilNSmgikmLnmFiFc+llWCFCvlDDYZVwY3PV1WpCra1HTz bEOHTZWJTj1USo4UK2aKxsxZPFQt0BRDTYx7p5Ule6KGa1CgitZ3WahebJB4tj2/U3ohUhqa1+Wm FAyN2arohVdb2/DWmJ3jLTBZeQfkb57Q/l4XPubWxGo2ifOiype5mFpj++EjNL/FmR9IIbnDc88S 8eczz3OyNq9tNya33EyMEx0yas6sg1FRLdZuUsZpIYtWz4n0RrInw6mRnHzDkYSGI4n0RhJV52Rc wXMAACLMt7X6hrY/cG6r3ymrIkCVejXNC973evXFL9PLn0urX6bjAsjHe7rZmO0tOzE5Paw4O25q UB5FklOWaHNuK4G8IjPRL5J8xr/Tyo2sqbeiatWlfK7dgULwLtsXW2xGOXFnudhmf73eNo/4TqVf uCpkzcRodcHnJ/utMQV0tUDd6yncnoD8zct/r7P6relnjXz4VHtecN/i/I1M7PC2hSv25jkdNq9h N8Zbnv+pFszT7fx6YvItMNvmboO6OUq0qSPR4Dk9HTM603CQnH0NngMAEGJqvhG+nuOyxhZDQf8N M72xEBdqnq4KoNrpeVteu6nFlHK9cdlUu4rakq6NPe20suyL1a5tP+S8y+V+jl9UVG6O5Z2qe+Hx yzRzehvW6a0p5aSYmPne5W9eHbVbkirQhbo1mukth8+IB3Jyb0Q7PGvhtTs2y3PS1CyzdjdGi+3w qRY6vAX6RbWd00Yk6TlcikNagucAAASYL/t04dVMXKnU1i6pQiem7ul19VNtXRXRtKlm21J7wOyc 1GaPWuXscaclXnLOO7jXecJicSzvVO0Lz1ld17fG7MxjKyfq326f/M2rI7WEDM+JF5v6JITkvMUp kisNJ+YtvPZ4TG1//e71qJkt23O6fKqF2q2KX4JZcqTBYyH2nEhvJHsynPZmnFBp4uQYjiQqx8k+ Bc8BAAjIKaFKdpYX12bnTYd4iT6j5lQJDVWpQ93T66Y3eE7upurU/Tavd47ELsfGPLF9v415p0Xv l3l6s3HlvMuN8wRrqdvmuukdPSecPzFn97fGLFM9lNXokb95ltb3ekTPyTl8ct7igoyNjLYkb+G1 x2Pq6XUvNmfzOnhOl0+10OktqC5YKkYg6PqTRxOe54R6I8k0HMlIhtMuOaHhSCK9kUSF+P5nZ311 Td+gU97X6NGBB88BAPCJv+nT6K/5ZJyaoFOVEFP39Lrp6bqq26aW13wnt80W03Vp3m/7stN0hWfF rPhNus7TSswqGrfWzJNXEdZtc9305DtVN7MQzJ+Yc4S3xl5l0dYuocnfPEXee71/nmOeO44PpBBs SdbC645HIdNzsjcv33PMn3mfaiGxVZqat6C6dEc9OudcvLQ3Gj1nJMORjGw4i40Hm/LR+bWl7Z3A cA5Fco7LxtgNw3MAAKaext87S4qqQn1x+GPURjVB1yohoO7pddNTddUIm1o+JVp+3s6pY792mnnV ujjL27FZL6RxHrORZUVYt81105MVcO0Lj+ZPzNn5rSk7KemkVhqQv3n577WZ83Dac/I3MpqYt7eT 77Ii9fRovR02r2E3dtpyM/MePEfjDW4eP3cEajzHNxxJ6DY6+YYjaTQcN9cvmUHojsxvVm0421vH S9WTd+5GKTlB/X2wqU6R0UMDD54DABBg6oDGX7hraoW4JhitSrDUPb1ueqKuGm1TzbOi7kxmsxt3 Th37t9Ocrap9bkCHdzk5T8YFMwV105MVcP3Gm0Yq+3Yk5uz41pglSOVTvtetowjkb17+e73/nlO/ QzpsZDSxdeEFe/KcLpvX3XOSWx5+qoWa1WW9BeVHq/FtyiTynD0ZTnszTqA0iSir2dRvcOE5TtPN 7rOl4pUXD20FlfdhBM/BcwAASnTFEF+xIEVAWRzo72/nV0+N6Z4+pipBqHt63fRaz+m+qebPsPyt 2zkZ7ONOs3X2qv5Pa8me9S7reZq2pFrRGN6pap/XjeXdvLoub42//WZjMj+NGZuX/17bzQ6XWVC3 9/IOn7a3uMNGxluS8/mxeyzYzuLjGk0PV9Fl8xp2Y3rLE0tIfKqFcbwFSafqiO85OYYjGclw2iXH NN24nrMVeM7T3fKgKvZmUHwfePAcPAcAwGK/oarO5aobhvOFXRUEtspRd4pQz5I4NcHeqoTap9dN T1TPe9jUcj94ZYqZTRW7foVX3F49Wa0a9nOnmafotO1VTfu7XL3Y6s4hQnUFglOD1m1z3fTEO+W+ CmerduyNTdpWV25t61tT1tnV0+trX4f8zct/r92NKZ6+vdPeR6vpk+DS8hZ32MjEluR8fswqiifa 3WX6OqnnetsfrqLL5jXsxnjLzZSMT7WQ/xbInMHdfsoVZR2PLdR6Tug2Or7hSMZlOP54AzWeoy7F 2Tle7uXj22HxfeAxH1Y8BwAAFGXR4KYoC8zjtspR08vrPGUGPRpSXFJkVAlJ6p5eNz1ZPe9hU8vy 1y99qmJLL8d2xFc1mZknyT7uNFtQygJz25ra3+X0PDozjUVqSad3qpx5viqFbZK2mVhsMV3NX/vW mOf6u7Gc6K0lIH/zhMz3WjCLtWnTOUXe4dP6FnfeSG9izufHWUU1z9zKiUIqkm+B8/T8zRPqdmPu luv4n2oh/y2oNkBtrf1/yzkhl4TnhG6jk284ktENR+I02rieYypsPKcXwXMAANJsb0ktYquBmXn3 HvMFxQz6UTuD/u53aoL8KiFJ3dPrppuvs3D6HjbVbGcoD8XP0sX8OlJ7qZ9yWwVjH3daWXI0VeoR re+ywnuxRaG5Eo2ZO5Z3yplZ/XJvdpRUjcFN8Rt2UbC1kvCtMR2cUh2u9Pye07rkb15B1ntdIHNW S1txNqz2ZTZ+Enya3+LcjazZkpzPj7MK2e16X6W2P7WK3M0rkJkTu7FuH+Z8qoVOb0G0zPnUB2Mk PM8J3UYnbTjtzTih0sQJDUeircb3HLfCLg8nOR+tu9NtiuEKgo+OP8+OM56BenR9cSVWpnVnwAf9 8UqtLvAc42A28u4G0+UVOU8v0rTBauhqNfa5XtT2mv65ReZJv/YDDJ4DAACDwBRk9WV6/6mtKftB zzcPhkyb56QlJ9IbiWM47ZIT6o2kbLcJPMcrrythKBXCj7Ig1Wuw+NN0GRRLcTRGLVkWazyh6LDo zyBRa9H9GvWf5XLsFJvAcyQiUcWWR81NspBqvTZNG7zlDl1t70ugZphbW3YXchjBcwAAYAgUv5/K N29up7U+gucApKn3nHzDkXQxnFRHtSCV55jCenvHNrAcmUs0vxRRz/L9p+zkVjb+rC8uRQYiz/Km LM8nLaVYTtFZ0Jkee45Wl/QSIjdr3+Cq/Spa4OEGzwEAgAFgvt87dVrrHXgOQJqU56QNp70ZJ1Sa IFmGU6T0hyCqHWPbMQo/hcMEHmL9xEiC/jPwDa/fWjmSXarhRT3XU5qk55Su4q9lazZaZs4G21UE 23zowXMAAGDyqb7HzYSJBM8BSON7zj4ZjiQ0HEmkNxJTRpvzTtmeU/7Z1KZRdWlLRnuCqIX8X5ZT c71NqRmJm/NELS0qSc8p1+IuZHUlmCdzg/EcAACA/cJcWz+ekZ0ODzwHIE2T5+QYTrvkhHojifRG osaMtmV04DmmmUVNiVtaTNRT4uaRMGWzjFpUwnaMe0ROomIdyXGttOeUG1PNuTwfG1reBperwHMA AAAAAPJJe06t4Ui6GE5WRzXPcHRMce82iWjNkCQlJFsbRHWqQeLVKpTt2AUm1mvTxXNMu1A5PdFp LXuDzSrwHAAAAACAfELP2beOapHe6EQFdJGkb1QdvVJFfzcfWHdGcJdUQpJYr0npOa6ZmPkT6uVe 55PotCbJ3OBur+vAgucAAAAAQJ/xPOeAO6oFpbOTGt+oBh+Lm0HK62dSiiKmkbywZ301XGA5DECi mcV4Tsb1OfYh3fiT6rQmydxgPAcAAAAAoDOB5+zVcEbtqBakxnMk9kKd6F40WlEkkRKIURhvSdwS 1AwDXYpNufzYK/Ty/ekNnlMq0/xKqtOaSs4G4zkAAAAAACPQ6DljNxxJVDGnUu85jh6EquPcasYZ YEDdfHOmXM76orpZp5nfRK3LaaUpm1lCOQlmqybKzEnPscqUflSSscEtqzi84DkAAAAA0GdqPCff cCTjNByVddtocyzZ38yU/mqGuZXjqzuVe6yuaHNwI/PYTmi679nM/NqyWaxIheldZpagYgYqEKsx s21vify4y9FZXyy3M91io5QpWrif9g2u2q+qZ/UgeA4AAAAA9JnIcxzDaZec0HAkkd5I2juqmdi2 miBha4YzPLRO1a1LnGTeDDAgjjHjt/msLyp1EY+aKYc0mBGpSHjIzvJiNc+RuaVZ16aKGXSzj5u4 a5lqPqrptFaldoMTq+hPqw6eAwAAAAB9xvecLoaT1YyTbThksoLnAAAAAECfSXhOqDRBxnwpDpnI 4DkAAAAA0Gc8zwmVJk5oOJJIbyRRWUwGFjwHAACGxc6Jorv47Kr5G/pMOartlvkbIEW254R6I4n0 RkJHtekIngMAAD3n5uLKbDHyUB4T6Tk3iwGWktH3zAjZ3joxv1RdgVxcGHwz3kV6NruoOTUwbGK2 wyPTc/L3T3KB2NSkk+E5XIpDouA5AADQa+zNG3KL1In0nLoBnCSx59QV/WI7s6s7ZiaZrRz2NsiR ubWbZpbDJ9NA8vcPnjNIGj2HS3FITfAcAADoN+YuFG4F/6yo4Gvq9X54TtMWJsgvxK3k6LtrGLaL u/bJEmzRb/2wuLuG5mbRvDO5npOzf/CcQVLvOaHhSCK9kUQVMJmG4DkAADB5TK3nlE006Tm3t2aL e/cJWofSfd76BJ4DOaQ8J9QbSaQ3EjqqTXHwHAAAmDym1HPMS8tZrFlg9gYcFpkGki8qyTnznw79 xPccLsUhecFzAABgf9EV/7GlE8Hl70XHqsT0qqOa/tPzlrpLU2YWba82d37Vm0vPoK5dWdxKFv03 V9dm56rFzhR3FTePVQRbVRHU0BlbmCCrEC+7ojUvSrO39hx9m/XWfaJ2tXkHix5xeub6XW0615ll zqt5Mg0kX1SSc+Y/HfqJ5znthiOJSl4yhcFzAABgn0kbQnWdSVC1Gy+yBbrvOauq/q5qZfl/EWfh 5fyLxgrcRJWumTlO1BKS7TntW5ggqxCvM8Yk1fU5K9lD1WnMKy2eq7Zc/18S+VXpOSJF5Tw20Wup FlvNc2xlttj/rQaC50w5nuf86PTV5rw8ZfmLU1e//Ve/+s5/vhxMJ3/21xf0ZwbPAQCAfaKh9Iyn m4aIaqLnOYaMfmtqhmr8saphx12O2bBitnJRO8ulgPkblus5hn3ot9a1icZtWfIGLWhGCVLYIFOu OlCs/F1t5lRLsLM5dtT8woWc/aNJzpn/dOgnnueQIP/sOwv/4j9ckPzW8z8PHiI6eA4AAOwXYRON 4DQaeNNjqxnRc9RiU0V51ShRtnjE6pIq6w/Cc+K4O8esKHuZgmpccpbWwXZCki9/z7vaNjrleU4c /8OjSL4d6fcIJgc8pyn/zf90VnuOCE/wENHBcwAAYN9QVbKnDUWBe2RuJaye9fQW88nynFYhMTKT XEiiLp9IzynwW06qhpdOJPfqGHZ1eu9F5OwfTXKBmWuB3qI8J+iSRGz+4LVL2nO+/Ve/Ch4iOm+u fKw/SQAAAGNHF5r2B35d+MqfwfSUHozNc0y1XRa7jbWvWUi1YQfiOc2FuJknquzzqGzHb6eqQ+Zf m503FxfZq3QyPSd/V+e8cCFzNiE5Z/7ToZ8oz4E6/v1bH2vPeWv1tpkEAAAAB0Xwi77Unaba9n1A 16OOXQj75Dlmtprat4+eY7Y/y1JqyOsnpleUDJ4DhwKe08TZa3e153x8+4GZBAAAAAeG6ZCma3Td jU23S7hd2tz/W/bJc5pr3z56jl5mchvyMStq2LByLWrc5+qNSO5VPAcOCDynhfPr9z7avm/+AAAA gAPFqYm1A5RFp65B1XRz0U5QgqeK6TF6TnIhh3R9TlshbrYhf7ExTa+6oGZL9uQ55s/USvNeeO5s QnLO/KdDP8FzAAAAoL/Y2lf/pyqOS+3R0/1Oa0K956SvVMktvvVCmub0lm8WG9bKdT3BmrYwQWYh rjdMEu2lgu2t2bnmXm2lKdWvSG9JtHxZspru76s97+pyOLjWF47nTDl4DgAAAPQY03VN3RrSEwBv elymp4rpqr2lKMe3d9p6WCnC4tuqizcEWXX7l6DWt45R3Sim4Q4wTVuYILsQN9ss8QeJNhvj9gAs ZrD3BZJtMK6S2skVlePZeconSkb0HGdXl6uWDTb7058zzX57zs2OXgoHDJ7TxKMnu2+t3j577a75 GwAAAA6aqkb3uzDVTdcki+nqKTqOkyTnV0TFd2UjcWYSNbFpDHFzZG7lROFFUQ3dsIUJdCGeTKQl 4ZJtlLCZtSQ2VUfNE+0Zn+q5R+aW9P6RZ+kh10b1nKrpxo3svWUtGPUGosnfPw2ek4x+Xyq700+A noHnNCGSo8ch4BIdAACAw0JXk7a4tNRNL6gppre3TpSDHSvZqCrdLsW3omgJKc2hKOhXlrdrnERW Wrb2FFKxJVZWs9iGLUxg90CcoI7X3Fxdmy0lRM0zV2yMO5usXb2uarFKWryhBepxXqZENxzpLRzd c4SiW51ept17poNfm+fk75+k5zQ83fOcPVz4BPsKntME40oDAAAAQAojbM1tbnCI4DlN4DkAAAAA kEC3KdGY02PwnCbwHAAAAACIUI05yc6B0B/wnCa4TygAAAAAhBSNOfRY6zl4TgvcJxQAAAAAYOLA cwAAAAAAYGjgOQAAAAAAMDTwnCa4TygAAAAAwCSC5zTBfUIBAAAAACYRPKcJxpUGAAAAAJhE8Jwm 8BwAAAAAgEkEz2kCzwEAAAAAmETwnCa4TygAAAAAwCSC57TAfUIBAAAAACYOPAcAAAAOmuX5N/7p sTeOzG+Zvzuzc2JOLWF21fwNBTvLi0szx9Sekcwsjrx7JwU+BtAEngMAAACGm4tLukTeg4Fkgefs B3qvqh07p2znyNzazWL6zcWV2fm15e3ij0FxOB+DnMOk9RMezGDfu+bYV9qy/NUV9eixpRMDfNM7 gOc0wX1CAQBgmjBVY1EhrSybiftCaxXYBp4TszXrl8KG7TXdwrOHvd1bDuVjkHWYdPScapnNwXM6 gec0wX1CAQBgiigK4iNzK7P7Xzvmeo4u18p2CQc8J0K/fYnK2/rPjpkwcfTqY5B3mHT0nAgjKqN6 FJ5TgOc0wbjSAAAwPejeODOLO/o/qbJybOA546etMp5g+vQxyDxM8Jw+gOc0gecAAMDUoH71N4WR aRnYxyIJzxk/eM5BkHuY4Dl9AM9pAs8BAIBpwSslTfk4sxj3dFIPlXXe1on58oLsY0uzi1vJH7bl KcvzziBg82q21irQXuodpNwkt8BVy9ePNm/GzdWVmeJZes6ZxKX5I7y6mJ3lRWdFc7KirZtRuXlz dW12rnqNM3NLUb+y3I1J7ivzRIW7ryqKDfCeYlPOWXPBT/rtc7fWLNnZBk3OW+BxSB+DenIPEzyn F+A5Tdj7hH5695GZBAAAMER02WQrtvo+OWU5K6W8U3fqpKouUyt7sx0z1zY0VIFFMerYkfy/SFlz lwXuovpNXc9jk1qsmV89WizH/D8qxDu+upitpDz4e7LamCDxbDkbE+wr/QJn5myJXO4rR1dcJbB7 Q/1ZPPfEXjxnUVXYNs5zq1fd+BZ4HNLHoJbsw6TNQ1pnwHPGAZ7Twse3HyA5AAAwdJzeOJraPjlO pXjMNkFUP6X7NbGZWS3HzulU7Q1VoMH7+dyl02aUReGc+8u9zGwmJg0kZ7ER8euVPame7q7FrLdY fjlR3fdGr8LZJx03prYyNsup5rdvrt1Iuze8d6Sz58hENV22Qe/nbfsC89+CFAf9Magj/zBJ7iKP lhnwnHGA5wAAAEw9iTrSVJBRnxwzvaplDan5iypQJoaFcjm9oQo0tBW4+ZuRqvniOr7LYmNyisu6 fWIbB6qnd9yY2srYzG/XaFYU7Hyzl9ynj+I56Zff4S1IcdAfgxo6HCYH5DnNafkoTgF4DgAAwLSj a6agVqvpkxMWzZa4bttLrx5DW4HbYTNS64peeIfFxjS8XkvTPKECddyYfnhOPLPQ5S1IcdAfgzTJ 2ere0NQu8miZAc8ZB3hOE4+e7P704ucMQgAAAINGlbOJkigsuzW1lWVcRzZUcq1VoKF7gVu3GRJ7 dYeNnu7M3GGxMTkvqnEes/ayku64MdmeU87pvuM7JxIbNjbP6fIWpDjoj0GSTodJ+4ehZYY8z2l7 Op4D9fzkw209DsHlra/MJAAAgGGhK0JVFYX1n5oY1VKdK8tkKdZaBRrGWuDWJac9J60WHua5jc0C Zp6a5QRL6LgxtZVxvBwzpZhfvdf2/35ZPH7PqUvjTjv4j0ECvUBJ3mHS/glvmQHPGQd4ThOMKw0A AEOnKnnr4hdbnSvLZCnWWgUaxlfgtq9L0WGxMTkrapzHrH3fPUfPOb9iB7ZWtpMYXnnMntO8Z5o4 6I9BjFlRQ4I9b1aX2GaNWWCtXNW+m4aWl2OejudAPXgOAAAMnNqLswsSfXI6VJZmSqrUyy06x1Hg NmxGRIfFxrSVtoqmecK93XFjaivjcDmyDXkV8Ng8p8tbkOKgPwYRnQ+TcnW1olK7bw14zjjAc5rA cwAAYNi0FX+mjnTKqS7Fd1FsJWZeNUNL11Zpluza3VK3GXk1X5fFxtStSOpgu4fr9kmiMu64Mbn7 yvw5037nUzNnuKKyrPen126tosNbkCL3pVXs7WMQYpbW4TCp20uG6L2OqH3JBjwnBzynCe4TCgAA g8aWvLVXJuyt+C7rv6reqm4UE82covqlvNjC7Z2b5XJG2Yy5YPThZzdX12ar+2kKnRYbY36kV6+3 vDWNutOlWrUtkat9Ut7vRahu+eK8Fx03JlsGdInsxlxzorqueZ8EvSJJdWua2tsf1W5tQfmq29+C FAf9MQgwT+xymCjs3vP6BBb3UzLT6xeI54wFPKcF7hMKAACDpSgfW4qhqsTUf3eqLFW9ZctiG1Vo 6jqsrkqrMKuzKUvDjpshBlIuR16vd/m4V0p2XWxEubvcFEpjHlek5tGZ8ZbfeVeriRmeY6eUu8KU 3Tp+8W3MzY28fSeKSt3fgNqtLcl8C5KYhdvs88fAZ5TDRFMpTZwmyRHwnHGA5wAAAEwpphZsuWKh rIlNRdW1spQSUIpLU+1J4TWru0vleo56+gn7dKmwTd3WfTN0W0RZ10qkzFUb4xWCIyw2QjZ4fsma TOr6fsHbmKLmXgnaUjpvTL7npHe+aWoLl1C8HJlePGTevtQG1G6tQ85bUMOBfgw8zKK6HSYVN4vP v/08qPc6/ZHwwXPGAZ4DAAAAMD2oJpqaAlo/NO3FMQwGPKcJ7hMKAAAAg6KhoSCngxbA5IDnNMF9 QgEAAGBQlFeShOOtqY5hRVeolg5aABMDntME40oDAADAwHAvjjcjrVV/1l4QAjBx4DlN4DkAAAAw PIqRlCu9kczMrZxY3aElB4YEntMEngMAAAAAMIngOU1wn1AAAAAAgEkEz2mB+4QCAAAAAEwceA4A AAAAAAwNPAcAAABgCrh/bffnv6ay/DUzBWDQ4DlNcJ9QAAAAGAh4DkwZeE4T3CcUAAAABgKeA1MG ntME40oDAADAQMBzYMrAc5rAcwAAAGAg4DkwZeA5TeA5AAAAMBDwHJgy8JwmuE8oAAAADAQ8B6YM PKcF7hMKAAAAQwDPgSkDzwEAAACYAvAcmDLwHAAAAIApAM+BKQPPaYL7hAIAAMBAwHNgysBzmuA+ oQAAADAQ8ByYMvCcJhhXGgAAAAYCngNTBp7TBJ4DAAAAAwHPgSkDz2nie2c+wXMAAABgCOA5MGXg OU2cX78nkvM737v4xVePzSQAAACASQTPgSkDz2nh07uPkBwAAACYePAcmDLwHAAAAIApAM+BKQPP AQAAAJgC8ByYMvCcJh492X3lna2ffLht/gYAAACYUPAcmDLwnCbsfUIvfrJjJgEAAABMIngOTBl4 ThPcPwcAAAAGAp4DUwae0wSeAwAAAAMBz4EpA89pgvuEAgAAwEDAc2DKwHOa4D6hAAAAMBDwHJgy 8JwWuE8oAAAADAE8B6YMPAcAAABgCsBzYMrAcwAAAACmADwHpgw8pwnuEwoAAAADAc+BKQPPaYL7 hAIAAMBAwHNgysBzmuD+OQAAADAQ8ByYMvCcJvAcAAAAGAh4DkwZeE4T3CcUAAAABgKeA1MGntME 9wkFAACAgYDnwJSB57TAfUIBAABgCOA5MGXgOQAAAABTAJ4DUwaeAwAAADAF4DkwZeA5TXCfUAAA ABgIeA5MGXhOE9wnFAAAAAYCngNTBp7TBPfPAQAAgIGA58CUgec0gecAAADAQMBzYMrAc5rgPqEA AAAwEPAcmDLwnCa4TygAAAAMBDwHpgw8pwXuEwoAAABDAM+BKQPPAQAAAJgC8ByYMvAcAAAAgCkA z4EpA89p4suHT7535pMfv/ep+RsAAABgQsFzYMrAc5qw9wk9v37PTAIAAACYRPAcmDLwnCa4fw4A AAAMBDwHpgw8pwk8BwAAAAYCngNTBp7TBPcJBQAAgIGA58CUgec0cXnrK5Gcf/mDS9xCBwAAACYb PAemDDynBTGcLx8+MX8AAAAATCh4DkwZeA4AAADAFIDnwJSB5wAAAABMAXgOTBl4ThPcJxQAAAAG Ap4DUwae0wT3CQUAAICBgOfAlIHnNMH9cwAAAGAg4DkwZeA5TeA5AAAAMBDwHJgy8JwmuE8oAAAA DAQ8B6YMPKcJ7hMKAAAAAwHPgSkDz2mB+4QCAADAEMBzYMrAcwAAAACmADwHpgw8BwAAAGAKwHNg ysBzmuA+oQAAADAQ8ByYMvCcJrhPKAAAAAwEPAemDDynCe6fAwAAAAMBz4EpA89pAs8BAACAgYDn wJSB5zTBfUIBAABgIOA5MGXgOU1wn1AAAAAYCHgOTBl4TgvcJxQAAACGAJ4DUwae46EbcJrzO9+7 SPMOAAAATBh4DkwZeE7Id964EYhNkP+0tGlmBQAAAJgU8ByYMvCckI+27wdi44bGHAAAAJhI8ByY MvCcBA1NOjTmAAAAwMRw5ZvPPvi6yfu/8eznv6Zy6h9UEz/4+u61PzIzAwwLPCdBXZMOjTkAAAAw Qexe/1PThtOQje+buQGGBZ6TJtmkQ2MOAAAATBK2r1pdTv2DZ4+5SSAMEzwnTdykQ2MOAAAATBy7 7/9G6DZOnq38EzMfwODAc2oJmnRozAEAAICJo6XrGp3WYLjgObW4TTo05gAAAMBE0tB1jU5rMGjw nCZskw6NOQAAADCh1HVdo9MaDBs8pwndpENjDgAAAEwutV3X6LQGg0Z5zr/+0bukLv/376/83n9c CSYSm5feXNWfJAAAAOgpya5rdFqDoaM8558ee4PU5bee//lvffvNYCKxEdXRnyQAAADoLXHXNTqt weDBc8iegucAAAD0n0TXNTqtwdDxPOfMhc0zF+NsLQT5pclibj51syS5FGY5zqrJ2w35VTrvpHLW 5FaYy7fezcmVONtB3tO52pT3s/KZ5FyctbxcC/NBQz7ycj4jKx99Nv/OR3gOAADAxBB0XaPTGkwB nufc+uK+nwfbQe6YfFafz++6eejmtuRemC/i7JjcqfLIzV3Jl+ncs/mqyo7J4zD3Vb5szFc6D+I8 CXJf8rAlD9w8qsvTh3Eeh3lUlydhHqvspvO0ypPW7O4+LSOqg+cAAABMEG7XNTqtwTRQ5zkPQsnp bDgS33DGITnKcGokJ2k4peRgOFFGNZzScz7HcwAAACYIr+sandZgCog9Z/IMR5KUnIZmnEBp4nQw nDbJ8QxHErqNztM9SU7acGokxzGcdsnZjSXnmQTPAQAAmDBs1zU6rcF0EHiObziSzpJTGY6RnD0b jpGcyG10MJwg+204eA4AAMCEoruu0WkNpgTPc/bbcCSh4UhGbcZJGk4pOQnDoaNaruFIQsORVJKD 5wAAAEwipusandZgOkh5TmfDkfiGM45mHAxHEoqNzX4aTkMzjg2eAwAA/eTznYcfXv+cJLN69YOn b/1vL167FkwnNjsPHptPEkw+vudkGI6kznCM5OzZcIzkRHqjk5QcOqqFbqPjGE675OQZjsqzZyvX 8RwAAOgjb658bAsbEudHf/5/C6YQN6I65pMEk0/CcwKrcYPh1OVQDEdyYB3VTJ6p7OI5AADQV/Cc 5vzX3/7rYApxg+cMCc9zAqtx4xuOxDeccUgOHdUkodvY9MZwdPAcAADoJ9ZzfvvPfv6tH76zx/z3 /2nsOWvzB635873mubHnL0bM/6tD3t1TfpQbqWFs/rt/+/f6Y4PnDIl2z8FwGpJpOAPoqGYNB88B AIA+Yz3n37y+4twYsPbOGUHZ46ap/mktflorn6jmkSTLntH6reRUO609VjLqnFSRM1KFk1PbhJVM kLCqkSRKmriqkUg9oz82eM6QaPGcuiM89yCXNB7nDYe6pP5oH+WAl3QwnMbDXuId+ZLwsNcZoOHo 4DkAANBPUp7T+d6AdfVP8hfesPKRdP9tN7Pmufzh5W+/tKhf4JFji9946fzLH96RCufyW+df/thU O1feMjME+capO2G1U1Y1p06GM7s5cmzp6NzSCyevnN64E9Q5Y6lwMsubsJhxk1nYRPWMDZ4zSGo9 p+4INwe5f4RLwiNcMlDDkWQYjiQ6+CWZx7/EPwVIak8BksyzgE54IpBEJwJJzQ8eOngOAAD0k8hz DsFwnOLHL3tqKp+45inLHq/geet1JTDfeP2Ty6a8uXP5w/PfeEm9WHEe8Ry308qVC+f1fjjy0pW3 NqJqJ6ptJFdOmaccPbmxtlHVOWsbG6+cXDJLmzv/ijwUlDc6ORVOfnmTX9vkVTVBJRMEzxkkCc/x j3BJy0EuCQ9ySaPktB/qGUe7Cpfi5J8FJOGJQBKdCCSNhqOD5wAAQD9xPccznFJyrNLEaap/Wouf 1sonqnkkybInWfNcLlppjrz+SVDniO28/FLpOV6d88nzxX448vqGV+o0VTsbLxRPOXrqTqLO2TCP Sl64cLehyAkLG5388ia/thlTVSPBcwaJ5zn+4R0d4ZNmOJIxNuN4hiMJDn6TwXZUC4LnAABAP7Ge 823Xc/bSjNNa/IzZcKKyR5U0n3y7bLQJSh3JVx9f/oY8tBFUOxvac3R3tdZSpyhvHM8JKxyJFDlm hiPHll7ZGL3CqS1v8mubPXdUC4LnDJI6z6mO8NyDXNJ4nDcc6pIOR7skOsLjYDgm4zYcHTwHAAD6 Seg5B9JRLVn5tP+221rz2F91lckUL+rDqNopCp63Xnc9Rxc5ledklzql55yOPacsbC6s6N17ZO7q te4VTmZ5ExYzbsZtODp4ziCJPac6ws1B7h/hkvAIl4zbcMoD3j/aJXRUyzwL6IQnAkl0IpDkNem6 wXMAAKCfVJ5zcmU0w0nWP2HlIwmLn6zKJ1n2tP+qW3rOkWPn3yonutXOlVPnC89x6xzjOUfFc6Ly xsavc5KeE1Q4d1+ZU/NIXrjYWOHklzf5tU1eVRMULTnBcwZJ4Dn+ET4OyWn/McM/1BuOdgwn9ywg CU8EkuhEIOluODp4DgAA9BPXcwKxcVMnOVnFT2vlE9U8kmTZ0244JuoiHP26VO+1D+9EpY4kKHVa PCdV5wSekx4z+trpckyCkxvpIie/vMmvbfazqpHgOYMk4TnjMpyGQ11Sf7RnHvBhOhhOm+R4R77E HPxBpqujWhA8BwAA+kmr5/TJcKKaJypvqpRNOjrfeP3yW2FHtaDUqfWc+jrHes7dpOGYXKy6rn0U lDeSzPImv7bZn45qQfCcQRJ6DoZTc+S7mSDDkUQnAskefvDQwXMAAKCfNHhOk+FE9U9Y+UiaDadZ clprnrZ+K6ra+fjy82Wrjs43Xt+4Elc7pqpJe05jnVN5TlORs3n1aDHbkWMrC/UVTmZ5ExYzbg7E cHTwnEHiec5YJKf9UPeP9vKA9492CR3VMs8COuGJQBKdCCR7NhwdPAcAAPpJ0nN8w5H4ktNa/LRW PlHNI0mWPaP9qutUO3f0XXRsjhxbev5COaKaV9iEnpNR56Q8J65wYs/JL2/ya5sDrGokeM4g8T2n +SCXYDhB/INfUilNkPxTgMQ5C+ScCLLOBZLoqB45eA4AAPST2HOGYjhONjZeft1cJKNz5KUrV8Ly pvKcjDpH91XxPaeuyAk8J7O86VLY+FWNJFHSjLGqkeA5gyTtOeFBLmk8zhsOdUn90T7KAS/pYDht kuMd+ZLwsNeZ6ktxksFzAACgn7ie02Q4keSElY+k+2+7HWqenI5qiYKnqnOubGy43dii63BSnhNW ODq2tnE8p6HCca/P6V7ehMWMmwPsqBYEzxkkoeeER7gEw4njH/wS7/h34xz/OrWnAEnmWUAnPBFI ohOBZNw/eOjgOQAA0E+s5zxfec6IhuMUP37ZU1P5xDVPWfaEBc8eDUdHlzpXTpWjnx07f8ordUpp 0Z4TVjg6QYWT8JywsHn89CM73tr8Rnt5k1/b5FU1QUEyruA5g8TznPAglzRKTvuhnnO0S+ioln8W kIQnAkl0IpDsj+Ho4DkAANBPIs/xJcc3HEnnyieqeSTJsme0X3Vrqp2N51/fqCt1rOo8f8FMKSoc Ky3xTT8lUYUjeex5TljY6Dy5+2px/5wjx5Ze3Wosb/Jrm8OuaiR4ziCp95xpMBxJeNjr0FGtJXgO AAD0E8dzPhyE4egiZ+P5l65c0aVOXO1sXDlaiMcrG26RU+c5VZFz7fTKKxtuhVN5Tljb6EhVYzut zW/sg+FIEiXNflc1EjxnkKQ8p/E4bzjUJfVH+ygHvKSD4cSHvR/nyC/iHfM2GE5W8BwAAOgnged0 6qiWrHzqftvtUPOMoaOautjGNteEMZ5z/rRX5yQ9xy1vNl6YWznjlTf1nmMKGzODGoFgj5JzeJfi JIPnDBLfcybAcCTuYa/SuRmnOtqDuAd/Ge/4VwmPfBtHb3Qiw7mnm3qPnrmXexbQCU8EkuhEIDmQ Hzx08BwAAOgnrufs8VKchsqnvuzpXPO0GY4udZTnqCtwNsIKR6L7rVXjDZiqpnSSkxvJIufa6SV5 yK9wUp5jC5stKzlLr2655U2Z/Nomr6oJao99DZ4zSBKek5Scuh8zJMlDveFotwf8W6+b9SbzjZcW i3v93mk87MNDPU6lN9WRHyc8+FWcI1+nOuaD2FNAmZo2nNJzFoznhId9nPBEIIlOBJIDNBwdPAcA APqJ5znNktP48+4hGY4kKnVUtWMGTxPHOHpy44q1nY07p08WkiMy49c5a6fP6/1wZO7qWlDhbNw9 UzzrhYtekfPRadMnTZb20eZdW9V8tLXx6ry5BOjo/NWFWHLGbTgHXNVI8JxB4nlO7XE+FsORREe4 5PKH579RrP3I65/In+aY3/jk5fI2WN94/ZPgXr/OYd8Uz3AkzsHvhI5qowTPAQCAfpL0nH02nKjs iaqdIF0MR2fj+ZMb6j8bG6+cOn/UHU76pfOnN7wR1dbK8dCao67n2TQVzsLJ8FE3Sq7mVl48s3G9 0XBaapuedVQLgucMkthzquO84VCXdDjaJdER7uSTb+uj6PVPggPeNvgcCcYYqQ77dDy9kVRW4wbD GT14DgAA9JPAc0LDkeyl90przTPWMaMbklPnhBWOpHuFk1nehMWMm34bjg6eM0gCz/EP9egg10ka TnnA+0e7pH1EtU9MU2zkOfqqO/XQsfNv5R32kowjXxId+RL/4JeER76NfwqQ1J4CJJlnAZ3wRCCJ TgSSw2jSdYPnAABAP3E9J2k4juRUZU9D5ZMse7r/qqsyWYYj2avhSPKqmqDMOPjgOYMk4TntP2b4 h3rD0Z51wKc9Rx/td14uWmb1UInBcR4n48iXREe+xD/4JeGRb5N/CpDknwUk4YlAEp0IdKKD8+CD 5wAAQD9Je86YO6olap6gwgnSvaNaIhl1TqqvSk6Rk1/e5Nc2OVXNYf9ua4PnDJLQc7o24xRH+ygH vKQ85gPPcY/5XM/xjnxJeNjr0FFtbMFzAACgn4SeM2bDiWqeqLwJMn7DkYQVjmRUw5Fkljf5tc0k dFQLgucMEs9zgoPcpsPRLomO8Dj+MW89p7oIxxz2xXjw6qGXrlyJjnmVjY1XTi7peSRHT145vREc 9hI1FEk1z9zKGX1LrHK8RTPd3vq3vAGWRA0Pb47/ux9dvPrCvFrOCxefPt66+qIeOW3+6vXqFHDP G43k1u71hZXXbtnD/t71S1dfm1+aOfbGzMI9+fO1Ygk2s5f0ieDe8XL6kfkt91ygTgfbW8eLJegZ ZubXlrfDA/VggucAAEA/8TwnlBzfcJolx6l5yrInLHiaa56i04pb8Oh4pY6Ejmp9CJ4zSFo8J2k4 6aNdkttRLTjg055z/8GdV8rhRNI3xlIWtPTCBT1avBlXUbf8VEe+vnPWyY1rxTF/7YJyGDvAiMpm aqh4NbSiXpq6DdajJxuvzlWm9OKZq/b/R+auLphTwOaL8uf85nV9Fri1KSIkKyo9R6zG8RPlOXIi uHd8vljIsaXj2965YGl+SSTnRnkuMKeD7bWZY0uzqzvFAbmzXDhV8dzqKD2w4DkAANBPKs+ZV54z pmacRM0TVDhBUoYjqeqcotSJahs/gzScHkqOBM8ZJLWekzzUG472kQxHpxxsoPSc+xt3rlwwYyYe eel8ssfag4fKT1644B75d14pWkKOzF1ZM1PUPKIiWnKK3DXzVDfGumvuaRPc+rdo1Sk9p8iW0RtR i/j2WNcXltT0W+6JQMzHeo6dopagPEefAravivxoV3HPAkvzb8xeMqeD8gjcmj32xuyq/VOyo1t+ jsytrVcTDyh4DgAA9BPrOS/Mf9hrw2mUnBzDGWtHtbCwURndcCReYaPSV8PRwXMGSdpz6o/2UQ54 SeMxbzwnyJGXrpzauBMc9hJ9zK+dEq84f9o/+E8Xo7+LNryyoQ7+a0WbjOqQ5h7/F1dEV3QvteL4 T3mOHPa+5xSngA1tKS9eTJwFFoqWmRcveYe9329NUnlOeRYwvdSM1Zhszc6t3fAPv/VFeb0ry/7E 5ao5yJt+AMFzAACgn/ie4xtOSnI61Dx97qjmuI1OVdW4cfSmLG/2JjkTeClOMnjOIAk9p8PRLomO 8DgZv2pU7TnF4V3d8TdoyXEO+6pLWzIvXJBjXjXdaOdpPP4jz9EHv+M55SnAWIrnOeUp4PqC6UX2 4oLquhaeBXR2N2eLJTie8+yGfqJ7Kc7qysyi7pxmY5pu6uK38xxE8BwAAOgnsefUGY4krnnKsics ePprOJJ0hePH0RudfWjGccTGJioh+hk8Z5B4npN7tEv21FEtOOxLsdE3+pVcOK+3xx1+wD/yiw5p x86fbjr49TzOpTjp49/xHPf4rzzHHvm+5wRngVuqB5rZ7Nh2zPHveo49BagOafIU1XWtaNJdno/b Z/Q8YXvOIQbPAQCAfhJ4To86qpUlTTJ+nZOMW+SUaapwyrjlTZEDM5xJkRwJnjNIfM9xDvWGo318 hqMP+8hzHj65ckq1ckiOntLDDAQHf+w5cS/VtOeEB7/1nDOe5zxu8JxLNSeCYuwBvdnFc8V21HU4 zrnAes6OeyJYKrqflW04qtNadL0NngMAAJCF6zmB2+gcguE0Sk5U5MThUpx9D54zSNKeUxztoxzw kg6GYw77hOfcd3qmmcEGvINfOYx5qPauOGYe51KcVJ6EnlOcArI8Jzzyi1xXtmMkTeJ0UZMoXSkm ep7zdLVYl9abRKc1iXniwfdPqwueAwAA/aTZc2oMJ6p5BtdRzZQ3VVXjJFNyhnIpTjJ4ziAJPWev hpM45iXNh33Sc8yQ0Gp6on9aObTayY3wyJdcXCnacMqh1eaufhQc+WrY6JVXN/WR73lOdQqIPacc RSAYbCCZ65dMNzZZwlJ1Log8x/zgoZtrVHe1VKc1STm02vxW9JBSI8YhAAAA0NR5zj434zSXOokc mOFI9mo4ksptbFUTJaoWJih4ziDxPKfuaM864EcxHJ3Qc6rD3l6oc3KjHCraRA+tJimGHHAPftGb lTPFwa/HW1PzXAxOAeI2Vz8yB7/xnCPzG+6Rv2DuTlN4jjkFNHlONbSaPQWYMaPFc+wpwPEcv0nX jJw2v5LqtKaiZ5BETTqiQIfQnw3PAQCAfhJ7zj4bjiQqdRolp6pzJH55U2bUjmqO2+gcmOFMtORI 8JxBEnhO5wNe0sFw0od95TnekV8c/NZnHNUpDv6N6m42L5wubgOqjvm7Z04uHS3vjfNo05nnoh1O 7e7CmSX3ahw9JLTM8+rFe+rI39p8dX7l1TO6Pae6JY71HHX3m+AUUIy3dmR+0z8XqKtxjsytmdt9 qpSeE/dMK7qupR/SUTcJNds5u7hVupC6W+hMspFnn4PnAABAP3E9p95wIsmJypsg4zccSSU2NlLk 3L124eorUs/ovveZhiNx9EZS21HNMRxJWcnce6342dcrcvaro5rppVJb8xxG8JxBUu850REeZ8+G o3LFNtocU7cEjY58c5mNmmFu5ZULd6ubfl5Qd8LRD9nIPGfcY764W040j2nMMaeA8gagNmpEtUtG PMQrjs5dvV602Jgp4jP2FFCeCPS40jPzV5e29YlgZ2lePVeNolaeCG7YJSQabdQxr+f3pztZXbFD utnI6z2UwQnwHIC9sXOi+JqfXTV/A8C4CD0nw3Caax5V7eiCZ+PyN4698fyF+monKnLcVHrj1Tlu pLy5+8qcMhz9Euw1xuMxHEnCcHR8z9nfS3HwHDggUp6z7x3VTE6VbTVBjp6+4x325YU6NlVftc2N V06azmlKSE5uxJfiPNrceKEcGODI3NILZzYcyTGH/fVSh0QbXt0qjv/Cc47OX33t0r3r5cHvpvrB ozj+bywow7lxaWWmnHNmbmWpkhxzSLsJeqCpO4HWdFqrsr11vOhQJ5HXOzNvG3YOOnjOaNxcLN++ +S0zKaLsxJg7g+3T2BxbT7csX4+KcWzpxLaZAGPh5uLK7PzacrVXD9pz7GfPjZwSZ7yt8rBPkXlu mmkeeob0Z2l768T8UjXa/pxqiL7JhwoOBM9zQsnxDUcSVThB3GrnyqlF9Xl+fSO/1NHJMxw34VhK mYYj6W44UTy9kdhixklUGEx68JxB4nvOQRmOTcaRLwkO/iLObxs64ZFvk38KkOSfBSSZv3ZIosNp 0oPnjIQpbSVHilHCk3T0nGqZzcFzDhPb77Ta7QftOc0+nDQZ9ykziztmqkOd59wsO+IGOTKX9iWA 8VJ5zl8az9m74RT5xHSzP7b08oZT6jRWOxl1ztMHG1dVl3uvyDFjKTWNGZtf3uTXNsmqRs5g7t3M O12KUzw3nNjL4DmDxPOc4AiP08FwGg97iXfkS8LDXqduzOgw4cGvkz4FtJ8Fck4EU2s4OnjOKBTF 7pG5ldnGArej50QYURnVow7Yc/Tqel7+jmEj7dDw1hYOx3P8933n5vbWbNXcHb5A13OSn6i051ip m6taimRFJ+ZVkzWeAweA6zl77ajmpuxmL/nGqTum2onKGzc5dY5UNWdOOuPHmsKm8pywttEZqbwJ ixk39YWN6odvPSeqB5ojpxF5bjCxn8FzBkmu5wzZcCSZZwGd8EQgKa3GzeSPPdIQPGcEdFE4s7hj qsOamq/FQ3JFBc8ZH/uykX3wHINtfgke1U+ZWVyzA6iYB0qSnmMm1n8CAfbKH/3Rs+9/3/w/hfWc F5XnjMNwVIVz5+WXVI81+Vd9wl+6ciUqb9zk1DmmsLlQnGG051TlTb3npCucqLCR5Nc2DVVN0Y1f DvNRShp98sRz4PBo95yaY17iGY6k1XAkGUe+xBEbm+rgNwmPfJv8U4Ak/ywgCU8EEudcYDNow9HB c7pj7pKk/EE37NS4BJ7TO/ZlI3vkOYJ51H/f9cTKzKMPVdJzzKJ6/p7CRPM7v/Ps137t2de+Vmc7 tZ4TVThBmqqdjSvfKLqr3S9adeRgeUX+HxU5kow6p6ptrpUjKinP8Sqc8uZ+rufklzf5tU1jVaOu Otab191V1svBk0Z47qEEzxkkTZ7TW8ORVIe9m/QpoP0skHMiaD4XVImOnEEGz+mMVyubGjd5zUOL h7TOcBCeo7bfzLO9prvhRU/ZuSlfcsVD+tHgenddIscp94nt6FX85ZDa/ubtcR9Vvaf0imSKujJe z1JD20YKO8uL8jKr2eT/Tuc0S2w18RTDzVV5CVkLrH/JCdo+V9Wo92ZC+ZRiink0eHrSc+qkKIPW F9XyoSopBtyvduCKP49ei968as5iabWfh+5vSusnrXkjNZmvd/rQnqOTsp2E5/jlTZzWauet14s2 HFXtmJthHD11J1XnVIPEqnnsuEpOnzf5+J1R5c1dO5CSm1JsfM9RIyqpP+Vj8EJwW/MyakQl59Py 4sLmda+SuXf90tUXi0+dug3grasvFjPPzF+9oUqaezcuXT1ePFreynzHjnvkRk4IZSVQnP3K6cXn s7rpReNzd9ZX18y6yinBWE1yYgymy3mmmOKkGJmpOoiKoyOcp0vwnEFS6zkdDKdNcjzDkVRW44ZL cSYpeE5XnJJRYWrB1G/ebfVo2wwH6TmLamabuIiXqBG97BUgzmKLAs6t89RsRfmoHx/Jc9LbUz1q V2fTsJ+FzI1Uyymm6/+rOR1bKDA7JN5F/gus9luQ6KPS/JITtH2uzKrdFemn6NdS2ov3wUh6jm6u LBaVrN0baH5R1c6p+1AVVLOpNysxj16LbJvZTjepA6daYJCGN6Xtk9a6kUI1T+PrnUpcz0nZjuc5 o3dUc6Pc5vkLpqrRo8UGXde8OmfDjpbmjh9rbl9eeo6uakz/NN2e4xQ2judEd784euauX9jck5ll sQvmjn/37L3OF/UdzJ9uvlZ+0iQvLqj7mOv/H5m7urR777jzaOk5uqoxpiEfYL8MMNNF+NWf29VP IfE80URnXY41HdfnqOgGG8vzS7KEcHRZdfyqnxuKP9WvBsnndgqeM0gSnnPghiPx3UbH1xuJc/z7 SUuOewpwkm84ktBwJL7b6ExBR7UgeE5H1HeAV6DUd11rq0fbZjgoz5HZzIr0nNs7QX0sVaBT5sr3 kJnolYZ6dQnf6+w5MlFNT2yP+6j9Gd58L0oa3MBQt5H6i9b/qT7pA3YbnHXFU8qXVmyk3fjlYoFq eoeXnKDlfXfeNbsQPaV0NrNGdwlpzymn63Rpgmh6UXbzmj9UZpPcN6sYa8F5O9y12M9Dy0VK3d+U pk9axkbmvt4pJfYcndJ2XM+xPhMnz3BUqXPl1NKRY+dP2fKmbJzR5pOqc+6UV9dozykLG30pjvYc U9tUnuPXNqXnzK8cnVtZ2CrKm60Nfb9ykZPrTmGzUNyvz97WXBcwi+aju7JoS5pbRm9k5uPmXn9u VWPOuspzqq/7Gs8pz4pWP9b1p7r46ilnq3MkSbku9/455ddi5Dnq2HGn6Kf7E8t1td6foz54ziDx PKfmmJckDntztNcndeTHccTGxnEbHf/gd+LrjQTDOZiI53z4v/8/VN8u//AfPvvJT/RH6tn9+89+ 4zf296Fz56qHfv3X9/Eh+da0D21sjPKQJlEom5Io+uG/rG9a69G6GfS6ii+bJPrpzZFvmhzPSc9W q3ApdalTiJE8p2az7aNl6WyofQtCajcySXLLzbqcidGUYr9FT1Sk3Kn5JSdo/VyVa6k+Ofop1f4p 9oPEbqF5SmqZqimsmFknz3bqX1T2hyrc5gR2LcHnIbEHRn1TWj5p7RuZ+Xr/8T/2umy51f8/+Ae1 D/2X/6X30G/+5v4+ZM/kwte/Pp6H6jxH52tfu/j/+Y7sJUmD5+RUO2Wpc+eVl4JeaqbrmshJTZ1j PeeuV95Yz6kqHOMzoec8KafPezf9u37GfEoXbG2jxwkobmjulTGl1Ti3+9s0n59LyarGfLrkk+l8 3addxZxPXKkwXz2upXT0nHJ++Xg7E7dmI3VR9xssjlN3otmkPTTp4DmDxPec8ICXeMe8ZHzNOHRU m+Cs/uzt8Kvlm9/UHylV4u/3Q3/wB+Yh+cLb74e+8x3z0Ouvj/JQQbKsMXVSVD2bk/UkeE5c/AkN tW9iP4zVc5Lb0/Bo6642dPOc5OriieGUus+DIlFtN7/kBK0vNq7yo/fLrNRuZMN7XRB237eNJzXU vqj8D1X1Kmo/wPW7LtrP43pTgp3fupG5r1cE4Dd+o5hc/EYTnIUaHhIV0dy+ve8P/fN/bh765S/H 9lCz5xR58//4j2VHJT0n13BsqXPhvHx6g1EHTuuua8fOn07XOTWec9Gcn63n2HYbz3NUVVO256gu ak55Uy5BeU5R0iyYT9dmWMyUtzhXCmQKG9dzopKmi+eI1cjn35tzDJ5TNgq588uK/HnsYusiB6A/ f27wnEHS4DneMS/BcKpEh8e0ZeX65z/5P/2fH/5v/gvzpfLrv66+jSzul9DYH5Ivb/uQfH/Ld96+ PrSxUT30T/5J54cU6oSeMIean4pb69GWGfI8p+3po3uOXr5EXXjgR0/3Vn2ontNQTXq0eI5U82uz 8+HL9FcXb0M4pfF9MTOb6lbR/JITtLzvdgbnZeopzkrNrrDrzduBle2M/LnSWyKxO9lGT3e2YUsP YFDMLCIRm1XDrgs/deN6U6Id1bKRua9XTlavv148o+CP/kg1d+iz0Ne+1vTQ3/+9mS78wR+oxp99 ekjO5EtLZrrwr/7VeB5q9pyvf/39uRN6RwWeU9NpJVXtOIXNqeLmNu4UVd6UXddeuBBUODrOXT7d IsfxnLKq8T2nqm1cz3GqGus5prBRV+bIlKrRxsn1heKDV/VSs56TrGq6eI6bbdU50x7je/EcPd1d iCw5ap/R84TtOXsPnjNI6jyn5bBPJsNwJI7Y2Ph6IymP/yjVKcCk1nAk+YYj8fRGJzoRSKa1o1oQ rs/JR5c4En0xsRNz3AVVVGNppWiZoTeeU5e4bp5cz7Fvbhx/dfE2BFPMnzUbYx7NKanraPtcJTZA P8V7v+xyir2RuwOF0uobZ659Ud0+VM4lMRI57k547UgNuy741CX2iYN5NOdNSe2opo3s+HqnjzrP +frXtXElr88ZwXBUNq4EYwAEUV3XEkWO7zm2vLGWUhU2Vf80v7yxnnPPK2x8z3nydNNcsZNoz4k9 p/yEu55TfbObR+XTZb/rmz1nXV1XppY/u7i1Xn537M1zqtNO8Wei0xqeA52IPSfjsI+C4Uxb8Jxs TOnTkMBJ3DoyRVxd+fTDc2qXHzDRnlNMl6jxiKvdlVxdPDGc0rjfzMzOm177oupoe1+qssNMKJ8S ftKcdsgOnmM3oPaDLdS+qLaNT+INytyw5x3CT9243pT6HZXeyJFe7zQRe05pOJrAczp3VHOiRiAo xlWL65yq61pZ5Dh1juM5bpGT5zlFeWMaajzPkapGX41TjS5Q4zlFMXPDeM7Kkqlkyk+49pywqqlO As7EOlcxol6NJV1+d+zRc8xytN4kOq1JquM0emhPwXMGSeA5WYe9G+/Il5ijPQgd1YYWPCeXoiis 1YZU1zVTEtWKSliKhZgvm0PzHLP9TeWsQ/mVNomeU7Mnk6uLJ4ZTzNKS+y3xOWl+yQma3/fyU+e9 7/opoefYRR1bOZG5AwuaXqCh7Z3K/FB5lGOUVRtZv+uio7Vpm7u8KW2ftHAj9/B6pwPXc3zD0VjP mf3LDyO9keSXOmq8gaOn7qTrnLLrmshMVOQkPEfVM7HnOOMN+OWN7zm2sAk9JxpXzSlsjOfMrd0w xUx5XhXPib7WO3mO/cRWE8vvjr16TvGQXk6q05qkYbFqM1JPyQqeM0jSnoPhVKltxolvdDVFwXMy aatXTGFk6xtFWT95E0vKerRWYw7dc/KWUFK7tak9I6R3TuP2jF59ltRspN6TkQaYSy/81cXbEE0p 1hI9UZF605tfcoKG9715SOXYc6yFJp9Vg3lK48z1L6rThypAP7c6Bs1a1O19zBSD2UXufh7Tm9L+ SQs2ci+vdxrQnpMyHE2951R6o9NS6qgRCMqRBhJ1jrlJzpG5q9fCIqcaLdqtcBaKG4PKx0Z5jils Ks/xyxvHc9zaJvIcPUWi7v7pFzZLxUfa6aVmDkP5iAbf6UWS7pGUitRyyg/tnj3HnqxWUp3WVPQM kuiFyBrVIelPzA2eM0gSntNqOJJKbxJHvo1/2Os0Gs5C0Qpcl6NzS0fnry5s+X1VddyzQGv8E0ER exZw0tRRTY6l5I2upiV4Th6m7klVioakt+iJ6onuaLzFtZ5mev0CywoprOEsDfWuIqvAai6ynTrS X0hxU3l/w6ofxYtXtL1jO4DZnVDdh8QdvMvb/qztiR9trz41NRtZvXfVe1RdX+6vLt6G2imy851x yere9OaXnCD5vt90b9sf2bh+SvLDZt8d9URvmap8KT63zs18yt2yh89VuXNaPlQyW3BHo/KJ1Uaa KWZ7qk9X037e45vif9I6bGTWQTSF/Lt/V2c4mpTneHojyfgxVw0nrS6/qa1zzH0/JS9cCIucM6ZX 29KrF++qCmdz49WTK6+eNifYV/X9cIqYAdP0LXG2Nl+d1/fGMR3Sji4YzzEFTOw5zrhqN7yqRh2M TmOOlDRNdlHnHubUoZVje+v4vPzHzCkf9WpOx3PWV1eOFw+lnqvnb9ySYlG1j0rsD1760iAzXR2Y M8lGnrzgOYPE85xDNBw3H11c0Zf92e6q6kcOdfCbE8rR+c3qDlmO4VQngrqMuaNa8yljyMFzsijO xXIibqrtqhraTCioCqk48nkzcyU5fM8RqnJfFuUNuhBumFmUjfPqzPHlRso+XZf729+8PbWP5npO 7UZWW6gGmdD/KV6v/Cd4Q6NtSG1V+WGII1/eZh5D80tOoN/3uqhLjMyMFQ2e4712b9sS75qOqkha trb5ReV8qKp3qhj2I55BKNcy793hRyeWvbG8KZHnmCXUb6SQfxBBSOQ5keE0VjtFhXPntG57OXll LaxwJLqvyl0tM8WbsvTKpl/kbF4NBjB44aLptyaR+Y/OXf2oKG/0LXFsXryoapvrZSuNvN2Lt2wZ c++18kB27oojlcym+Slh7uqSGnLg2VORijn5s7wyp/jddn2xXGZKBqpH/VYUPdazjXy8ZaL5HpGP omq92ZHn6vOejl1+8rnF9PS6yqiGINlFTT3QioGt7ZLLpalDI5wzO3jOIPE9Jzra3XiGIwkPe52x dFQr24JNM27Vkqt/9ige2jxUw9HBc/CcJkxxU9tpTWOKnrjavlncIt2eylWtk3OzxV54jlA0v5SV mUS+BdVv2PFit7dO2NFyRWPcGdzWhuJ3O9mTKTlp3p7M6rORuo10tlCi3yC9WH918TbUbZW339Sb rn7Rj00j5y3w0FsVpPZNKWj0HPVR0R/OmUV/B8o+CYoe+Rh7QzXU0fqicj5U0Q4MFc5ZS3GImTnD NhaXvb4p0SetdSM1Oa8XEjie84uE5ETljZuiwjFFiM3R03fcOkdVNRuhxkh0LzVb4VQ/2s6tvLpZ lDeF5xydv/rqxbvXq/Lmnv4ZVz4JL168Z3usuVFWU5qPjb4xTlnS3FtacD5U8lG5tGNactS3tulC 5sYpXRKPyse4erTcvNlV5ynlqa84HGSKMXP5MDvqEj+3eV0m6k6gNZ3WqqgGIrMN+iBqmb8teM4g yfIcT28k1dHuZm+GIzGSE3iOMZwy5dAi5aCK7YYjqU4ENr7b6HQeUQ3PwXMAYLLorIgwcSQ9J89w WuqcsMKR5FQ4VXlj4v6A66XLr7c5VU3w3U0agucMknbPyTjyJdGRL/EPfkl45NuEp4ANO05ieAoo f+cQd3+1asmtT3gikEQnAklnw9HBc/AcAJgs8JzhE3jOdBoOktM1eM4gafKcjCNfsh8jqtV4jjr+ K895rdlzDmLMaDwHzwGAyQLPGT6u52RcitNc56SKnJEqnH0wHEmipMFwRgueM0jSnuMd+ZLwsNfZ D8PRZ4HqvlfhWeCW6RGruqUGx7/Orc3XirGe9SuamS+vyavidCotOtOvLyZGW1937t2m+pVWA3q4 CTwn7HVadjmtph+JL/4rOpg6G6w2qXxUDV09WzyqFrW9VnZ+beu0uv/BcwBgMsFzhk/lOf/rL2xh EyenzhlLheOUN1FseRMUM0Eyf7qNvqxJfvCcQZLwnIwjXxId/JLM41/inwIk/inA95zqLGAGT5So ceKDs4Dk1tUZcZJL94pTwL2l8uo30ZjyLKDMRGTjhv7BoxjtVM/gfNaVlpSjiKg/9chXzhSbuD1H JKrY8micEFmIrDf0EzWST3VxXrki/dwtd+jq2cVqzJ8jc2t7GVFkLMFzAGAywXOGT6vnZNQ5UYUj yalwWsobJ1VtExUzQTy9kdiSxkn0NU26Bs8ZJJ7nZBz5kujIl/gHvyQ88m2yTgGO5+izwK171y+Z BpYjcyvpHmu7m2Ids5fcc4FpSBEx0KOO3FhYigxEXMWbsjyftJRiOcUYVs70VL+1cijheAll846N ero/sdpgY0TlkKbxAg83eA4AAPSTBs/JqHNG7aiWVd4UGbfhIDljCZ4zSGo8Jzzsdfavo1oQ4zlB jsxdXbxVDhjvpmjPLRxmZck/F+ibAWtJsH8GvuH1W9OD6sajGZa+4V+Kk/Kc0lX8tWzFt/VVwyaG 4mSFylqNWUXkSIccPAcAAPpJ0nOqCkcnrHAk470UJ1XeOIbTIjl0VDvw4DmDJPKc8LDXOTDD0Qd/ 1Z5THPDln/HYA9WJ4J69BiYZ7Qn6llWynJrrbUrNSNxCK2ppUUl6TrkWdyGrK8E8doF1KcUGzwEA AOhA7DlthiOJKhxJ9wqnrbwx8SqZIBjOIQXPGSS+54SHvU505Ev8g18SHvk2/ilAUnsKkJhTQOA5 u/b2WN7wA95ZQHVaK9pzEueC6nTg3Nk6ZTvGPSInUbGO5PQfS3uOnu7OuTwf9zrT87TeuxfPAQAA 6IDrOQdmOJK9Go7EK2wkUUkjib6RyViC5wySZs+JjnyJf/BLwiPfJv8UIPHOApHnPN29vqA0Q6Lu ChyeCCRGGzzPSXZaLcYe0ItSq1C2Yy3FSEWqPaeT55h2oXJ6otMangMAALAfJDwnLG90uBSHVMFz Bkmd5xxwR7XgRJDwnCfOYGv+YAP6+C994FJ1Ogg+wW7Wle0YcZJUQmLW2+A5rpnUeo53nU+i05ok U2DwHAAAgA6EnlPVNjZcikPC4DmDJPacwzUcnaTn7D7ZvloOPhaON1ANrTa/lfjBYzVxhxzJ+qod zczYS824airGczKuz7EP6cafVKc1SbXB0UPuBuM5AAAAHfA8x9MbnajCkXSvcDLLG6+MCYLh9Cl4 ziAJPCc68iX+wS8Jj3wb/xQgqT0FSJrOApHn2FOAvVBnfksPFW2jx1KTREogRmG8JXFLUDMMdCk2 RTtMaiFGgfzpDZ5TKtP8SqrTmoqeIbWuaoPxHAAAgE7Ue05U4UhyKpz88qaptvFjCxsTr6QxoaPa AQbPGSSe5zQf/JLwyLdJnwLazwI1JwLHc6JfO6zPhKrj3GrGGWBA3XxzpmwzWV9UN+vU/y9TNLxU KlI2s4RyEsxWTZSZk55jlSn9qCRjg1tWcXjBcwAAoJ+kPGe8HdWiwkbSUtg48auaIk4xo4PhHHjw nEFS7zkjHf+SvRmOynXbaHNs5fh2fCIwpb+aYW7l+KWdG/ZjurqizcGNzGM7oem+ZzPza8umVUek wvQuM0tQMQMViNWY2ba3RH7c5eisL5bbmW6xUcoULdxP+wZX7VfVs3oQPAcAAPpJ5DlObaMzUoWT Wd4EJY2XvI5qN1bX7CXEUkXMSKmzqn7rTPRJIeMLnjNIUp6TefxL/FOApPYUIMk4CyyWbTVBZhbu eWcBZ3honapblzjJvHN2mPdGjl5fVOqyLnZRDmkgp4/SedzsLC9W8xyZW5pd3fFNxjT7uIm7lqnm o5pOa1VqNzixiv606uA5AADQT1zPqdzGJqfCyS9vMmobkwzDear6tOsfZKtiwBYtLb+ckr0Fzxkk vuf4B78kPPJt8k8BkvyzgCQ8EUiiE4GEJt1DDZ4DAAD9xHrOdwLPyalw8sub/Nomu6oxIx4lenBk 9BAhewueM0iaPCc8+HXSp4D2s0DOiSDrXCCJPp3kgIPnAABAP0l4jl/eSMLaRidR3kSFjaRLYeNX NZJESVNWNcWVwHUyo3qy4Dn7GDxnkKQ9JzzydfzjX4LhTG3wHAAA6Cee5zhuoxPWNjojlTdhMeNm hDGjyz75dSOs1tymgowneM4gCT0nPPJt/FOApPYUIMk8C+iEJwJJdCKQ0FGtT8FzAACgn9R5TljY 6OSXN/m1TV5VE3yxOqOwhuMe6TAOwb4GzxkknueEB79O/ilAkn8WkIQnAkl0IpBgOP0LngMAAP0k 6TlhbSPJL2/ya5s9VTXqIhy95ar3WjHGWnuK0Yzs4EzOiLKSnfXVtdniUdVGtL2mh5OdUXf2M/Pr lC1IzgbE1wg1rUhSt6620Zh6EzxnkDR6TvoU0H4WyDkRZJ0LJNEHkfQheA4AAPSTwHPC2kYns7zJ r21G6KgWxx9ONnKJKMVFO7PGiNT99+RZ5RU+W8fnKi2ZXayWrG6bIUqj72YeXfMjCxHJCeWkaUWS 5nWVC+l38JxBUuM5/vEvwXCIGzwHAAD6ies5VWFjM1J5ExYzbsZiODZlS4hNcIcMJ2rcAv9iHtMg U93TouoLF13bUzyU8pz4AqGMFUka1jUJwXMGScpz/FOApPYUIMk8C+iEJwJJdCKQ0FGt98FzAACg n9R6Tn55k1/b5FU1wXdoW0yDiY2YQ9mWUkXdoy+6kkcsRc9vW1r0rdUjdZEYV/Ef2pqN7vuXtyJJ w7omIHjOIPE9J/8UIMk/C0jCE4EkOhHoRJ880sPgOQAA0E8SnpNf3uTXNjlVzV5+t3VuI67j33m8 upYmmVI2mtwjcbue1ZXojuSZK5LgOdA7aj2nOAW0nwVyTgRZ5wJJ9JkjvQ2eAwAA/ST0HKe2aSpv 8mub8XZUa8z69pbbjc2RECUVdSOzOWl2D72Qqk0mNXR15ookeA70joTnjM1wJOGJQBKdCCR0VJu0 4DkAANBPKs/5q19YvXEqnKi2keTXNnlVTfClucfohheJ4xtj8RzT/azUp0SnNTwHJprQc2pPAZL8 s4AkPBFIohOBBMOZzOA5AADQT5Kec2CGs4eqZms2Hs25jFWd0iIypaJtttUVedT0iEt0WpPk2wue A73D85zxNOPQUW0KgucAAEA/CTxnHwxHkihp9lzVJJtTyoTDo5UjniXVaNXeUbTVPdQMerGpTmuS zBVJ8BzoHYHnNJ0Fck4EGM6UBM8BAIB+4nrOXiXnAC/F0Z5QKwnGc6r+Y7rLmSR6ipiJ170tNU8V M3Kaunlo2rLyViTBc6B3NHpO5llAJzwRSKITgYSOaoMIngMAAP3E8ZwLYWEjya9t8qqa4PtxD9FN KyvJe4PqfmtevzLnfjWzi/YeO2pM6pmq7cW4R6pDWpmi61rTPFkrkmSsq8fBcwZJjefknwUk4YlA Ep0IJBjOgILnAABAP6n1nPza5nCqGuMJohPq3qDWdrbN7XR8qSiyuqINxM0Rp41lfdE4TLrXmYnq meb0iEulbUWSvHX1N3jOIIk8xzkL5JwIss4FkujzRCY6eA4AAPSThOd0KWz8qkaSKGn2p6opxyHY 3jq+uDLjDictRrFd19hS3WbHCJJ5yFxX46aupUXdCbTh0iCd2hVJOqyrt8FzBonvOV1OBBjONAfP AQCAfhJ6TmZtc6CX4pDeBc8ZJAnPCY/8OOGJQBKdCCR0VBtu8BwAAOgnnufkGI4kr6oJvgrJkILn DBLPc8LDPk54IpBEJwIJhjP04DkAANBPAs8JK5kgVDWkCJ4zSLI9h45qxAmeAwAA/cT1nLCYcUNH NeIEzxkkGZ6D4ZAoeA4AAPQT6zmEjBA8Z0i0eU5oOJJIbyQ06U5Z8BwAAOgneA7ZS/CcIVHvOTTj kPrgOQAA0E/wHLKX4DlDIuU5GA5pC54DAAAAAH0m8pzQcCSR3kjoqDbdwXMAAAAAoM94noPhkMzg OQAAAADQZ+o8J9IbnajeJdMZPAcAAAAA+kzsOZHb6ESVLpnm4DkAAAAA0GcCz4n0RkJHNRIFzwEA AACAPuN5zo9OX43zMiFR/uyvL+A5AAAAANBbPM8hpGvwHAAAAADoIXgO2VPwHAAAAADoIcpzgi5J hOTnzZWP9ScJAAAAAKA/KM8BAAAAAAAYEngOAAAAAAAMDTwHAAAAAACGBp4DAAAAAADD4tmz/z+G XdAi64524AAAAABJRU5ErkJggg== --94eb2c1907b49fe6b20555944f21 Content-Type: image/png; name="12.eil_sufficiant_ecs.png" Content-Disposition: attachment; filename="12.eil_sufficiant_ecs.png" Content-Transfer-Encoding: base64 Content-ID: <15d967675aaafa4a2ef5> X-Attachment-Id: 15d967675aaafa4a2ef5 iVBORw0KGgoAAAANSUhEUgAABHAAAAFKCAIAAAD6zT/hAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAANTRSURBVHhe7f35exTXmf+Nf/+1/DL5JfHzeHJd WZ5Jxv4k9kwcP4PtZ+z4E8b4E5sYzGoyhomxWWyxGBCLxCaCWIUEkgkIhBGgBa1obW3dUkutFvj7 PktVnTqnqrqqVS31cr+vdxxUXV1dXV33fZ9XnVOn/n8/kEgkEolEIpFIJBIpLxFQkUgkEolEIpFK Qy/8JdeoSFX41191EVCRSCQSiUQikVZfgovudgzd7RyqaWr/+sKdr87efmfXOfina6t+9M6eYP/4 vf1iZRjvFW5+NICtwQuLS6VIHfyQ/CCOCb6L+FKfVTfZ3zSM11ddEW8Uh2IokcI2S/FoFK0IqEgk EolEIpFIKy006DsGEudbOnbVNKPR/6v1RwUXCQYAMwAADl2619o5BKfSGfk2f2WyS2JlWPAD/P7u C2KDwK2ffXgI/8DCS3e6OgYTRQUV2BNwjkAm8I/YZxsjxZ/4LuJL1Ta12980jC/f7RZvFNsRh9rm T3Goj117ANYi0MpPBFQkEolEIpFIpIILLfXekalLd7tFvxPa9K9vPbXp24bqaw/Q6B+eSMn1CqaJ ZBofBHgAseCjsQNv7jiNHThY37ryLLGwmL3bMXTw0j3R3YSdAecIZAL/CBAKg5F5y+ZP4Bk+VGCt /aMcu9pGfBVeBFQkEolEIpFIpEIJECX6Rn783v5XNh4HzIh+J/nyquph72hdS4cAPOzeB/vqzzd3 JJLpAlEEIKr50QA+DiAnOojwb9HdJNcoAnUOJnBMiK8iiYCKRCKRSCQSiRSzBEeBoGD8A8yQyS7J 14pS2L0bbb2Ah599eAgUgX0WwwKXKRBIw/1e8Am2CYh6f/cF8CRATr5c9NL46o+7Lxy7+mBogt2F RbJFQEUikUgkEolEikcaR/WNTskXSkqgCOw8EAhwtb266W7Hs6j8sLCYbeB49tO1Vev21Vdfe4Bt ytdKWS2PBgBXv1p/FL/vzprmPI5MWYqAikQikUgkEom0LCXnFg5eulfqHGVqIpmubWp/Z9c5wNX5 5idgh+Axb+CoS3e711ddERxV19JR0PugVlH4iUGJODKAK5BV78hkJZMVARWJRCKRSCTSKghNc4jN iM0nxRa2p8bWjJarsD0FtmoxRZvq3pEpNHCDW/+xaCiR2lXT/LMPD3119nbZcJSpzsGEGA147Gpb Mp0xDyyOw2fVTVgBP9Dlu91FPr4xRg1PpEBWgqX9Dk7Zi4CKRCKRSCQSqYBC+xKtbUDOJT57tbgd 5c0dp3+kzIht254aW7OYkA22p8BWLbapGq1bbNyeGlusJh7KlJhJx8JaHZwxfrX+KNrTFcIPE8m0 GPC281TzUCLJD+MP+Fnxq2FhbVN7ufZHhRFwWqD19mNNldZhRUBFIpFIJBKJFI9AKWJmcNALGtkg GfEoIbS28W/RuSRmCV+ZaQnsqbEFUIldQpPX3qV1++oFaEWa2g5Ihje+vvVUXUuHXFRJAjXhR8QB /PibK/gvftaWRwPytYoXTjmAJXj+j7sv3O0YqhCqIqAikUgkEolEylM2QdlTb6MpKcAJjWyQTNF2 WQxPpLB7N9p6BWiBsmA0goP5CgsP1reCIvBGuaiCdflu9wo8PqtEhfMfEfH2rnPf94yWPVYRUJFI JBKJRCKFlR9BiWcrlfTIt4lkGo1gX7764Yfve0Ze33oKX7xybhAiLVMIijd3nP5gb724qa9cRUBF IpFIJBKJlEOJmbnzLR0Ap3IiqGCZfIWWcXnM/U1aYd1o6wWKf3nm9sJitiyxioCKRCKRSCQSyUMv XrzoGHCeR7Tp24aKmr1NE/hK/otEii4EzsFL917beupBOY4AJKAikUgkEolEciQeJSTmyAZKAaio W4ZEikV9o1Nv7ji9/VjTwuJSOXVVEVCRSCQSiUSKUy9evACTyMcruR+ylNPJuQyaWdgCJDe3UkrM zB279uD93Rd+/N7+9VVX6lo6qE+GRCqEapra3955bnxmrmyQioCKRCKRSCRSNIF2QD6ClAAhX1+4 I2ZogH/Gp+S2H38U1WKScW0Lu2qa8RGX7nbj43pHY35eLTaFzYKgsOf4IJr/mkRaAT3sHWXD/56O rPylk0KIgIpEIpFIJJKvEjNz4A3wzGfVTQJvgDoAHpCPSjtihgY4rl6djPUAJbiaMxuYBx8nnlcr Ph1LsLz50UDHYCIPykrOLdQ0PsQGsanLd7vlUhKJtCJCrnh717lb7f2I3FLHKgIqEolEIpFIjoYS KSAKQMWe2w28gT9rm9oF3hTDrAypdAZ7AgoS+/n61lOgLPz3A/6Y2oa23uDH1PaOTolbpECJfaNT cimJRFpZIZkgZm+WPlMRUJFIJBKJVLlCI0Y8VQkcAnD66dqqX60/CkTBny2PBkrrJqLOwYR4TO26 ffWAJXyRj6uuHLva9n3vqOi/WlhcOt/S8eaO069sPF7X0lGx8/WRSMUjxlR7BVPFOZR3hUVARSKR SCRSZQmtlub2gV01zSAo+6lK4JDWzqFUOiNXKn0NT6Qu3+3G1wRB/eidPW/z+7te33rqYe+oXINE IhWBwFRv7zzXxu6nKlWmIqAikUgkEqkiNJRI1jS1r9tXD4h6f/eF6msPimT83soIX/ars7fVJ0qV Ez2SSCWt4YnUv244PreQJaAikUgkEolUdOodmQJIvLLx+K/WH/2suulGW2+FD3WbSKbrWjrWV135 6dqqN3ecPnTpHhpz8jUSibRKOt/SseHQ9aXnQKrSYyoCKhKJRCKRylCJmfSxq22vbz0FlAIz0NQL nnrYOwraBGqu21ff2jkkl5JIpNXQ9uqmn66tenvXOfzj6wt3CvGYhAKJgIpEIpFIpPLRwmL2fEvH O/x+oV01zZ2DCfkCKVA32npx0GiyChJpdSUm8KxtahfT5CAkxQSef+Qz5SC5gbKKELEIqEgkEolE KgcNJVKfVTeJG4SosyU/9fHp1H+1/uhXZ2/THVYkUpGoczDRwp/lgPAEZQGx8F/82fxoYGFxqRjg ioCKRCKRSKQSFhoTaFW8v/sCMKC2qZ0wYPmaSKYPXbp3o61X/k0ikYpMrfxp48h7P35v/5s7Th+7 +kAMDlwtEVCRSCQSiVSSAkrVNLWDo9CqaHk0IJeSSCRSJelh7+iumuZXNh6Hd9Y0945MrjxZEVCR SCQSiVRiAkpdutstZu2jGepIJBIJ6hudqr72AFj1+tZTNY3tyXRmxUYDElCRSCQSiVQyQvugoa0X zYX1VVcIpUgkEslU52BC3FD66bcNK9NhRUBFIpFIJFJpqGMw8eaO0+v21dPcfSQSiRSsTHaprqXj lY3HP9hX/33PaEGpioCKRCKRSKRi18Li0ldnb7++9dTD3lG5iEQikUghdKOt980dp9/eda5jIFEg rCKgIpFIJBKpeMUm8Wvvf4U/nFcuIpFIJFJEtXYOvb711PZjTYmZdOyDAAmoSCQSiUQqUiXnMp9+ 2/D+7gt0uxSJRCItX7VN7a9sPH6u+ckLLrl02SKgIpFIJBKpGNU7OvXmjtN1LR3ybxKpIjR1eMue H72zZ0Ob/JtEilepdGbTtw1//OLC+MxcXERFQEUikUgkUnHpxYsXDffZoP++0Sm5qFzUX38CbWXu E4dztphHWl+TK+95rX4VDoWyt6avNMq13BrpOXzgxGscCbhPvHagp39EvuhIrGZvbcuJDfVeq62G +ttaN2xR9o19hdbGkRU7/qUBVP31VzawwyL/JJWcWh4NvLLxODJtLF1VBFQkEolEIhWRUNn3X7iz bl99Kp2Ri8pIjQfsZjooorVfLvaWa+UDPXLpCsq1A7o9gMofwE5saHOApL/tirECd64DUnCNAKWM vbK9xYchY1YpAJWN+qtxWpLiEnLsB/vqj15pQ9ZdJlMRUJFIJBKJVCxCSf/024avL9yRf5edJKLI DpAThwMu8Ms265UN4i2rCFThPtqmKd6fIxf+MDLVKHuiLBqx2+JbnNX6eYdVbqASJFYg7mq7IncM +OfqLptqrLdeWolfoZiAyveA92zgB0TlZFKJaldN87ZjTc+X101FQEUikUgkUlEI1Xz7sabapnb5 dznKRpScrCL5JMSahVOEj7Y7nTxXHunZYHXvWNyVV29P4YBKwTyfjQOr2PBF+VcBVRJARSorHbv2 YNuxxuUwFQEViUQikUirL9Tx/XV3yrhvSshBFEkgflxh9wBE6yaKV6E/WjJAmJa33GZ+bfSCte/l XuWHeTGLgIq0CkLu3Vd3J2+mIqAikUgrKpasXrz4vmf0budQTVM7Uthn1U3v7DrnabwqjJWFlz/Q eTlSdx62dy/ADW29WHMokVrdPScVuSqEpiAFURxk8pDSkPWhGj4ObYtzzxL+bYy/Ek1zAQn20DuY TxTB1whWWKCyunfCzJyRXw+V391Z2ieK+SScVz2OiZei7L+hqf42/BDyE60ZLORrmsLtni9QRfl2 4vSQa7IhpvrUIDnOn1wHPIj6onxNPupVDPiU6/PxlnId0orq46orF//RlR9TEVCRSKTCCpnpbsfQ wUv31lddeXPHaVEz8A/wElAKLcjapvbWziFP21hiIxbe+9O1VfjHV2dvn29+0jGYKByo2Hu+bl89 PhGfq+48bO9egMV7f7X+KN744/f2izdi52saH37fO0qURYJwBtQ0tiMc5N9lLRVR5L+9Lv+Ll0Tj 1YtqJIzxt59wNYtdSGABlT2ezeXcSBMWqGRvW+AtYbacwXXYMbkspzi0ODPvsX9zKw162cT3cK4O lmWMQlQ+1PVDmIci/O7JNd2sEunb9XhPreGsmfv8yXXAPXcSivo1Txy2709TnfOUIxVAmezSv248 PjiWzKM0E1CRSKT4NZRI1jSxBuLrW0+hNgiEuHy3+2HvqFxjGUqlM2CtQ5fubfq2QWwfhLOrpvn7 npFl8gne2zGQMPf8RlsvPnH5U64hWQtQxM7jIwRe4r/4N/FVxQo/eHN7//u7L8i/y10uRJFoYTS+ 5XLZvvegGraCfiHfogJ1a2rr1uklcCbZy9VsDQlUUYFE7f0I6M/xkP8INLmr/Gtar7K7nuQHBX4F +V6vzQbLfqPyFaY8txZl9zxYJY+3szPB7hfiU4M4uxT2/Ak44B47CeW1n3J9sZDtJ19ooBppJYQC /dbOs9novVQEVCQSKTYNJVLHrj0Aivxq/VFAQm1Te+dgQr5WSIHTqq89AJn87MNDn37bcOlO10J2 KXw2vNsxBGoCO/34vf3Y+ZXccwg7j4+z+eqDffXnmzuS6QyRVSUIv/L8YhbxMpFMy0XlLtnilC1L 2abURprJpq3V+nS/JUDmGEK7zar3BYVEIKt9bNr1RrlaFCBhHSDKBsNilV/73ur1Mlvh3pzglvcR trFTseuX8uNh84eItnsGq0R6u9ztoO/rI68xqJGAKq+vaZyc3kFBWjF9sLf+SmvPEphKLgglAioS ibRcDSWSNkftqmleMRQxhVZpXUvH+qorQKOPq66wPiv5ii40ZMFRwBgwGFDq0KV7rZ1DmeySfHn1 dKOtd9O3DT9dW4WcTmRV9sKP+/mp5uprD+TfFSCt7e4FNqJd6zQ9QwOV2cb1avUK+bd9VRUOqLj4 bTzONu1uCn/5tO/lYfTcgRDfNDxQqevID/X6XcQGneFz0XZP/9UivT1o5RzyOluiANUyv6at0Cc8 qSBCG+Z3W05mlp7zbqqw9ZeAikQqPSHCk3MZ8ICYGgE+eOmeduuOp5sfDdhviWWaBGwErf9V5yhP Xb7b/eaO02/vOtdwvwdf0v6miZn0wfpWwVG1Te1F2zOgkZX6FUjlIfycD3pGcZbKvytDRmPR6BYw mrD+7UsASeuGA/LmFpitFq7N6t0dYShk01aulqu/y0cqVuXqV/Fp3wfupzwIAT0e8u1BECI3on6E 9a2d+4tsi+X2yhF3T//VIr09cGVNOc+faEC1zK9pK4BUSSsjlN1Ld56ykS5yQW4RUJFIxSs0oDsG EoAfMRsemtdggFc2HkeqFRMz2P7q7G0VnPz8/u4L9lvENAmCK9btq8erwAzBWmFAy0apupYOuago 1do5hG+Hg8ZmsBhIiH3G4SqhEVaCrLDb+AqEVWUj/I7zi9k/fHa62K5EFFpmo1MukW1Ws93p3U6V jU4vKy1U3zZrvEBl7Uwew8wsWT0YOT7Lu30vv6bPez0OqSZr/wOA0OMj5MHxt/WJUXdPLrF+mkhv N7fmrXDnTySgirSfkLkFKQKqVRcaNn85eH0hyzqp5KJcIqAikYpIgqDOt3TsqmkG5yClvr71FP7x GZ8NDxEOPOgbzVEnIglcgW2iyY7ti/uI7M/99NuGY1fbzJkS8E+gFxClyFFKFQ4amARfCvtcDOP6 8tDwhCRYwqryEH7BU40PEdry74qRB6KINqugEckVXgPqPN6yxz0Xtm8b12yzxgtU9v4Eby1Y8rOC uol82/eB+2k25Q3l3n+5EfUjwh6cyLun/2qR3h5qr8KeP74H3HPlZX5NWwRUqy4U3F98fGQusxT+ TioCKhJplZWYmdMICu3m6msPwDlyjdVQ52AC7IG9EjMl4L9o+aEp33C/FygF9CpRLCl12Vh16U4X YVXpCj/c8xc/vL3z3OqG+arIq9HptDU9m6TmQp+Wq9lC9W2zWuSWo08psImsSuJZDhwKlPys5QCV 53s97t4xJQ+UfyeVtYJyKGS7P8RXjrh7+q8W6e1hDqNcJ/f5kxdQ5fs1bRFQFYP+ed2hvvEkn98q VJ0loCKRVke9I1MHL90DPv3sw0PFQFDBEjPRYT/X7avvi7WLjJSHgFXrq658/M2VmbkFIqpSFCr0 4Hjyl+uPyr8rSZ5tWff4Kx1yzLeIJUaXi3z6kNlmZU98kkuk5DZz3fXkubeesr+CsVdcI9i3YHiz kCz4s2TXirHbVpeLb+s81ze1t+CDItaRVHdPviXEQMdou2eQRqS3++0VkMb6aqHPH3tr5tHzwqFl fk1LcuUQZx2pcPrlx0efDE5lQo/6I6AikVZOaEU1PxrYVdP8q/VHRT9Ppd0+QYpRl+92v7b11IOn I+wCGnVVlY7wY6FC7z3/j68v3JGLKkneiGJdv2c2GvTmW5zmqd1oZsQit6C0UC0MYLafSuQ8F8gb fhSFByr1s9xzoNtzTogmPgMnvoL9nCJ153PBidPRwfccG5Hr25+uThXoPNQo5zeFrKPKN1KvjIUb UabNcB0K60ONJxT3t7VucEFspN2TK3v9jmHebqGp84tbk9Rbp1bo8yf3AXfj0DK/ppQJVNaT00yu IxVKAKr2gan5xeds1F+ICktARSpnsSB48eL7ntG7nUMN/Dah8D527YGYoaF3ZAqhJDYltxtdYjqE n66ten/3heprD4YnUvIFEmkZwon05o7T++ru8FNULiQVufBDoUL/64bjfRXZ2euDKHZL1KPp7/UW u9GMVvIJ2dZ/R07UZjbENxxQZye37N0V45L8aG+b8ON8C8NAFPG9lD3XjVY4XyVI+kc4h0uFUrdf CwWETNrTsQybe+hwiDj+rzl/ulv/EXbPizQifTvvldWdD3n+QH4H3GsnoWV+TS4PoLIJUC4gFVz/ vO5Qx9CMvI0qRHkloCKViRYWs3c75OzhYmYFMRsejBYn/hQT2YW3uKlJ3Q7+IZbgpfMtHeZsDabw 6iU+ebeYDiGVzsgXSKT4hNP1j19cmF/MElKVhJAWBsZmKnO8H+Tb5+N/Dd77LSM9h60L/7DoFBLt TqWFqrRZ+aA7uf4W3gMj1wmS1ZD1tHdvEu+csdvo1mepa2LP66/Yk3SLddyzIwQKb3e+yBX3PvCu JAcAQAhXGkeicvuU+ArWRuR2DrcpXWouaR/KZlHXv7JUyN3zI40o346fHvav4PHc5FDnD5f3AffF oWV/TX+gCnEJgBSL0Fr7yZ+qxpIZAipS+csmqPVVV4A6P35vP1BHzB7e2jkEx371FxsUW66+9mDT tw3qbA01jQ+12cbthx1h9x72joqFJFKB1PJoAEwVfj4i0moJKQK/0nePn72985xcRCqgAlq9JFKp SJ7GZuctqUBCs+3fttUSUJHKVkOJ5LFrDzSCuny3exVHzojZGsBU2BnkOzHbOFxyDzsilbrOt3Rs PHydmKrIhZ8Hv9Glu08/2FsvF5EKKAIqUulLdN5S99QK6vNTzV+ebx1PLaYXnz8PN6KegIpUArIn xAOl7KppXl2CCpaYbRx89bMPD2GHv75wh6adIK2YdtY0f3uljZiqmIWfJvv8RU3T408PN8hFpAKK gIpU6hLncK7ZSkjxKZNd+sXHRx4MTE3MLtKkFKRyEDgKQPLKxuNwKU6Ihx3G/ouJ0fEP6q0iFVoo A3/47PQXp7871/zkbsczlIBQIxVIKyJWk7kWl57v5oOT5QukAoqAilTi4t1TNNhvJXW+uePDr68+ m1qYTmczS2yQtnwhUARUpKLTUCIFfBIchTZH0XZGhRdQCl/kV+uPbvq2gTqsSAXV8EQKJxvONDEG FTAvRsbWND7sGEwQXhVUgKXekam7nezeThxzHHnb+CHYoB3LP35vfzE/d66MREBFIpEiKJXO/PqT 6tbeyZGZTGo+u0gP9iWVotAQWbevHuBx6NK9MuAoTZnsUl1Lx+tbT+E7ykUkUoEFmEfDHQH1WXWT 6Cz99NuGS3e6Esl0yCJB8hMOYMdA4ti1ByBYINMrfDpQ/Bf/Bk3hmIs5bISpg5pEIpGKX5+fav7b 2bv9E/OJFBvvF/IGKoiAirT6Qrukoa0XrT00RG609cql5St6CBVptYRmPah+fdUVcY8f2v29o+wx a6SQsiFq3b76n66twjHcVdMMoAIyld81IBKJRKooNdzvffeLC0/H08PTmZn5bCYb4Y5kAirSagqt k7udQ6LThsbCkUgrKUTcoUv3Xtl4/I9fXEAVQdWgPis/JWbmNIi60dZLj5UjkUikslHf6NSrm04+ GkoNTC5MzmXldBTyxdwioCKtmnpHp8TdBYRSJNIqquXRgBhqe+xqWzKdIayyhUNx6W73+7sv/OzD QwRRJBKJVK4ankj98uOjW47d6k2kx5KZ1MJSlt09JV8NIwIq0ipoYXHpYD2bBr2VbssmkYpDKCdg BmAVYhNlJFolKTv1jkzhaICj1lddAXDKpSQSiUQqO3UOJt7ccbpvdOrzU83v/E/ds8m5hayYLV2u EEYEVKSV1ve9o+LmjUx2SS4ikUjFoVQ6g9j8w47TTwbGK5CoUD8b2npRWV/ZeLz62gOaSYJEIpHK W3UtHe/sOmdn+5ZHA/+64fjtx8/406cilEECKtLKCafm+WZ24tLd2yRSMeshv+rx5ZnbC2zKWLmw 7NUxmEB2WrevHl9fLiKRSCRSmWp4IvX+7gubvm3QxnIDrt7edW73mdsof+ErIAEVaYWEk3JnTTNO XOqYIpFKQgcv3fvDjtMzcwtlj1TJucyummYahEwikUiVIDRExZxMASO6UQE/PdwQftwfARVpJbSQ Xfrj7gvV1x7Iv0kkUimoczDx9s5z07Nly1Solceutv1q/VHKTiQSiVT2mkimvzp7+2cfHgpz48n5 lo6Nh6+HnOuPgIpUcIGmPthXTzd2k0ilKIepwg99KBElkul3dp3bVdNMc/eR4tPU4S17fvTOng1t 8m9ScahUf5fGA2y3f3SgR/5Nylc32no3fdsAlDp06V74nH++OSxTEVCRCiucgp9+21DX0iH/JpFI paby66cCHH7fM0Jj/EjLVH/9lQ0HWhtH5J9cBFTFKQKqSlQmu3T5bjc46qdrq9btq8+vLRqyn4qA ilRAMZo6XBE01d/WumHLideQ9aRPvMaqLM29EU399SesA2j6SqNcS9FIz+EDJ17jZZIbh72n39W4 4RKr2ZvacmJDvddqJH+hJn30zeXnL1hQl7pAU83tA+q0TiRSPhpplVnF1dgloCpOEVBVnEBTv1p/ dH3VFbRClzkMoaapfduxxmCmIqAiFUo47041Pvysukn+Xa4aAUrxfOfpLV4YQPKRrBze1o+kP32d 2NDmoGx/2xVjBe4trf1yFVIovbblVHvfWNRHcxSbBE2t21dPs+MUViLuijnKYtjDng08magJh4Cq WEVARVqWPq668vd/dLGrij4VkICKVBCh1TI+M/fa1lNlfg247YrV76F1ekw11lsvlV8eLFhTKXzl sGmK9wTKhT+MTDXKniiLvuxLyFuc1fp5hxUBVVQ97B1947PTiyHvzy1KIS/1jky9vvUU0VTBVRFA 5SkCquIUARVpWUJr9l83HJ9MLbCLil5VkICKVBDhbNt4+HqZD/ZTGus+JRlYxQahyb/KRqsOVGIH /NYc6dlgdQxa3EX9hPHoj19cuPGgr0SRCkkpOZcRj8OXi0iFEwEVAVVxiYCKtFydb+nYcOh6lhOV XKSIgIoUv3CiPRlIvLb1lPy7TCXTXAU21lcZqGRdDLMDcoPF3KorKVVfe7DjxK0MqydySQkJJfDj b65cvtst/yZ5SATXicMj6mBm/qejqf62K+4bF12zMviNxX2tXnCsPUyO/6XIK/wD9kd9ifc5yw/i gwXEu32Uaw+F+CiDLc6a+Ld7aB/k2Ub3XMgkbrUN3CAU5idQFWb9HD+ZtRFRy+x+frGm78GM/nXC /Ezqp2ObV9z7KZTz63hK/V1yfscwv75QvDvs3hrfsUhAFeJHifqLkFziVxX7Pa8qElCRYhZaLTjT th1trG1ql4vKUlb3lLsGh1SY9Bq5DkXcpmfpzVFFwjVEoPwKXrjKEeXIUw9VvGrtHFrz+dl0BtUE kS4XloQq5CrPsmWliHqrE5hbYQPZKmXeckLJFU4a4bGvNjHZajyTiNfzAiqP/XFesj/LcWAOybWH kNxJZv6S/LeeduTRcH+XoIUe1i/3BHxlT+VcX/lo13dxZX6+DmDAGnbhspk/8/k6IX4mZ7PsF5Gr qfsJhfk6npJv3FDv9R1ddzuH/PWheHdY+VzHV2Slzg1Uygdpdv0oYrV8AocEDU+kfvnx0Uz2Oe+m clVBAipSzML5lc5kf/bhofJ+tMsyWuoh02ukrBd5m9YKzFbpzV1FQjREoJA746FQQCXH++XeGpMz LNPzwiEpmvpGp36zoTo1v7S4pNeSYhZ2FcXvD5+dftg7KheRvKUEL2te82UjU3ZrTEaockci3mIv dLWkffux8wAqYW1/1Jfs6z7sAr9Y6E8glgJ62lne0C9dWTlfzTxyHzwToLpQfjW+n9Y22YBwvjD8 V/ZUjvXD/WSeB5MlfLnQnZPz/To5fiZ5hNVfhI3fdqX6cF/HU6G/Y9hfP94dtnfvxGH7KKnV3/0T mAr9o0T4RUieQim50zmcRRGUC6QIqEgxC6dY08P+P35xQf5dpgqXwT0UPb3CObJeXts0Sm/oKhI8 5C/0znhIrhZYOaxdCouy1vrMITvKSH7qHEz8dvPJ6XS2tEb9YU8Hx5K/Wn9U/k3yldKqMyNFXp4w X/JipJiByvxQ+yUrlUnJ5bl7sAPzmJfMPZef5f4uxkLrso75lb0SbMBX9lTg+mF/Mnsj2sH0yrd5 fp3cP5M4AYJ+uEhnoK4o39FDHh8R5w77HVVreQ6givCjRPhFSJ46eOnezpoWs5OKgIoUp3BuLT1/ 8bfT3x26dE8uKlN5N/3ta12KXekpQj0InfXy2aa5sp+8ClVAQyTCznhIHlUPO6VOrhOhGcQ71pSt EVblrbqWjj9/c21qjgFVqRCV6J769krbrppmuYjkK5kiPONUtsy8GnYeLctYgcprf3xf8k7OpiID lfmJnvugL5THLShh5txmgILWD/2T+W/E2MO4vo75M1lNfx14bEU7A3VF+I5e8nh7jDsccFTDnM8B bze+XYRfhOSp4YnULz4+OpdZ0u6kIqAixSmcW9mlF58cKvf5/fxSjxdQqetEqQdhs14s2/SX11v8 GyJRdsZD8qt5eFlAxeUePuF0+pEi6KNvrlTfeFxqQPUDyt7Wsr+rMx4FpQg7PO2xvrZlWKmBv3pA FZCFXMoNVEgarRsO6F9T+UTPfdAXen0vW3LlZWTpoPVD/2QBG9F/r7i+jtfP1GPd2YsdBqXoKTra GagrwnfkyvnrQ7HtcMBRDTzgUlF+lEi/CMlbb3x2+nbHMH+ICPVQkQojnFsAqnf/VtfyaEAuKlPJ /BVYjEXaUtNT+PQaPuvFsk1FIaqIf0Mkys54KLAqSFkfEXbIn1sqVoXvpiMxTSTTP//oSE9ijg35 Y/dQyeVFLuwmyt7aPRdvtPXKRSRfBaUIO7r97LpcUuJAJTfiZeUTPfdBWyj/9Nkf+WqhgcrPORvZ xu8V29fx+ZmcYe3MW+wbipiinYG6wn/HkL++UDw77HXySwW8ZCnSjxL1FyF56NPDDcdvPF5wj/oj oCLlI5xAdzuGGtp6v75wB15fdeWdXefgt+Gd5/75w0N95f6kFyvhBjTrPXJclHoQNuvFsk2hsFUk BFD5ObDghakc9k4uA4esIRBUOSLp81PNX5y7OzS9MDOf1a7MFbOwm4tLLwiowikoRYQJT0clDVTi JeSrA67HtRuf6LkP+sLA4yZXDp+lDQWtH/onC9iI/nvF9XUCfybXPLHhPjqnQn/HsL++quXucMCa YTYS5UfJ7xchuYR27/+c/k6O+rMqIQEVKZSScwuX7nZ/Vt0Eavrp2ipEHf6xbl+9AKrLd7tbO4ds 91XCczOtnOuTXiGZttT0FKUehM16sWyTKXwV8W+IRNkZD4V6e+4jn1vyg3wuTpNMIahf3XSyc3R2 LJmZXVgyJzgqWqHeLWSf76xpKfsbO+NQUIqQmSdk1PhmiRIAKp9EZH6i5z7oC4OyTZSbjnwUtH7o n8x/I3IPnQtYcX2dED+TNZuRtU60M1BX2O8Y+tc3lf8OB6zpsz8uRflRlvOLkKRQTf56ojk1n1Wn ZyKgIvkK3N1wv3dXTfPrW08BotZXXaltagcvlfd86KEls5J/J5W1gpKeotSDsFkvlm1CEaqIf0Mk ys54KEzlsBtkeX8KFFR+SIYy2aXfbj55o314cGphcm5xfvE5vyxXGkiFPc1kn5+48fjTww1yEclX QSnCupYRrnNYrmymR4/EyGQ1+9zLA/bH96Ww7ULfPZT5wehOlzfMKJ/ouQ/GQvlB/rvq2oeAr+yp wPXD/mRyI+7HMTHJVKnuYUxfJ9TPJD7LTtRhv46nwn7H0L++l/LeYb+jas+oFOZAhfpRlveLkLjY /ExV12YAVMoTRAioSB4aSqS+Onv7Zx8eWrevvvrag87BhHyBpMpKYT7tcit9q+kpfHoNn/Xi2CYU oYrIT9TLElOEnfGQLGy5ErpVIcy95TKeBGLIQjKqHCEEmnp/94W3dp7vHJ0dtbunSqaDig35W8g+ /74v8ZsNx+Uikq+CUoST04ynuvW3tW7Q2qnOdXEepCNTdr+3Hb/O0yB8n7cTsD+hM6Sfcu+h8jVZ VuG75/pEz30wF1rHzTUXjnPvjTuPBXxlTwWvb310jp/M3kNYfQ5S0B4u8+sYPxPW1J7bYX2Qax2+ JMwZqMvebTjoO0b59WPcYXv37OLl7Jt7m55y3p7rR5FrhvhFSL5CC/lvZ/8xk3aNfiegIjnCadHQ 1ovG06/WHz106d5EMi1fIPnIyrw8iyGxOvlXaSK40lPk9BquDi13m1DoKoLlvg2RKDvjoZBA5XwK 6oRrDnT7sIuaxMCJr6A8FtP5UnlSX0Uplc6s21ff8migpvHhv2+vfdCXsLqn5ArFL+zq4tKLmfns H7/8O91GlUtBKYLLyQmIID7fjP2nFt1OkAorTTrriobqLVcOi8afV8L02h/fl0K3C8PtIb6j/Lec XEf5RM998Fpo978Zfk3fz4Cv7Kmc64f5yayNHFDI1rZ5xTCOr+NbyOCg8yr8GahJbB+VOud3jPbr y9WWv8Pux3tIo2iKy5Q5z+ewP0r4X4Tkq4++uVx94/E0Ayrn8iIBFUmqYzAhbosq+wn64pX2jCPD J4y0FTK9Rsp6y90mV8gqAimFhNt9STLvgmcPvfC0xj/6PihGyRT749VukzZ/F5IupIJXNh63E0Ln YOIPn53+++2u5y8YpZSKUO1Q81ILSw0PB9/4rFYsJPkoOEUI8csWSvQhxl2Xk2yN9By2p/cEL6kr 4CVnbjR5md8rswXsj+9LEdqFYfdQXrgRW1Y+0XMf/HZMO25IjFfMibYDv7Knwqyf8ydTNsJ7+OWa eg+MquV+Hc+fW9/mAc9PD30GuiT2hNeRnN8x1K8Pxb3D6o5ZcSHHfYTinDA/SqRfhOSt3205efPR EJ+fiYCKpCg5lxE3SrV2DslFpGia4t0vTv4Viexwm9Ix4lKY9Bo16y1rm1Jhqwhf068hwhS6frgl v5q3PTqUxGF3gNb8FOwn2xNls1jfNesGyUNIBev21b+/+4LWTZ1KZz6uunL21hNUkFJhKuzm0vMX 6czzsWTmzb+eoSxHIhnKVRpIJJIllMWX1x18NrWQnF+iIX8kKZwHHQPjQKnqaw/kIhKJVKkCL9W1 dLy54/Q7u84FjI779NuGc7eelMq0FNhL7OrC4vOpuezDgenfbj5Jg5lJJLcIqEiksDp29cHGI43D M5nUAgcquZiAqoKFdsbdjiG0nIYnUnIRiUSqSIGj3t994adrqzZ92/Cwd1Qu9ZfCVCUAVdhJlL3Z zNJYMnPhTu+7f6vLZJfkayQSiYCKRAqtNz6rvXx/ANVEPodKLiagqlThFDjf/ARNKJoDnUSqcIEu Dl26F/XmyT/sOH3/6QgySfEzFfYQZW8hyzqphqYXvjzXuuHQdWIqEskSARWJFEqdg4lXN53sn5if mNWfIEJAVYnCr9/c3g+aoiYFiUTKT6grr205xR5rWPRABWEns0sv0ovPUQUHpxYOXH747t/q6HIS icRFQEUihdIb22sv3usfml6YSWcz6mN9CagqUGhYzC9mf7X+KN1IQCKRlqOdNc3fXr6vjnkoWjHs e/EDmGp2YSkxuzgwOX/uds/vt9f2jZrzkpFIJBKJpOtGW++7X1zoTcyPpxbnMvyRjPIVJgKqihOa FduPNdU2tcu/SSQSKS9lskv//OGhidQC76YqdqrCDmI/M9nnqfnsWDIzMLlw49Hwq5tOHqhvlWuQ SCQSieSlVDrz60+q7/ZODk0vTLPuKTbdkVr4CKgqS/jlB8eTv1p/VP5NIpFIy9Cnhxtqm56UzMA/ PoV6ZglMtTSeWgRTPR5ObTl2643ttZ2DCbkSiUQiVbaGJ1JfX7hzo62XEqOtd/9WV9Pc1Wd3TxlV j4CqsoRf/9q9ng/21su/SSQSaRlqeTSAMrOQfc6f9ls6TJV9nuJj/55NLTwdT/+9te/VTSc/P9VM A6FJJBIplc4AqNbtq39966kfvbPnlY3H3999AUsu3+2uzCSJ6vC3s3dRLIb53VO85BFQVbDw06Ml 8d8nb9FTp0gkUixio/7WHRqbntdGkxezsJ/Av8WlF3OZpcm5LApk38R891j6f87e+flHR7Yda6In SZBIJJKtvtGplkcDAKr1VVd+9uEh8NWumuYbbb0VMrHZqcaHHx9o6BqbG5xamJxdTLtnS7dFQFVB ws+fff7i3S/qos6PTCKRSH761w3HH/YlwCclQ1T86hIK4uLS8/nF5zPz2fEUm/qvJzHfPpT6su4e sGrj4QYa60IikUimwFfV1x6s21f/4/f2v7njdG1TexnPmLqv7s66r692jaX7J+bHU5nZBT4XhVex I6CqIOEUQANi85FGmpGCRCLFpbd2nm140A8yKZVRf0LYVeysPfxvcnZxZCaDkvl0PN0xOre//vtX N534zYbqg/X3qMOKRCKRPPWwd/Sz6qaffXgo5EPhS0u7z9z+7GRL5+hcX2J+LLmYnGdTpfvdMkxA VUHCGZBZer637u5XZ2/LRSQSibQ8AaiutfXLZ8aXTieVEPYXHJhdejG/uJScX0qkFoctrEIRvd4+ vPnYrZ9/dOSN7bW1Te00xzqJRCKZymSX6lo63txx+pWNx5Eqy2AoYCqdWbvn4n/X3GY0NTE/OpNB gchk2TPi/aocAVUFCWfBQvZ5z1jyFx8frZCRryQSqdD653WHngzNyIEQclkpCTsNEBR3VaUzSzPz WWDVyExmYHK+ZzzdNQayStfd7fuo6vq//KX6Fx+z0YAVe2c2iUQiBahvdOqz6iZg1Y22XrmoBNU5 mPj37bXHbjzpGmUj/UaTGWsiCnYNzk8EVBUktBsy2efT6ex/7buEBoFcSiKRSPkqlc785E9VqDcp AJX/pbviF/Yce7/0/IXAquR8dnJ2Ed/r2dSC6LDqGp3rGJlrejy6/+L3//H5+R+9s+e1rac2fdtQ fe1Ba+eQ3AqJRCJVvIYnUuv21b+z61wp3ol6vrnj9a0119uHxX1TY6CpeUZTAX1TQgRUFaQXL15k l16g3fNocOa3m0+W9RXWqcNb9qDFs6FN/l0qajzAdvtHB3rk3yWmoj3sPRtwVEvwfCh+1bV0fPjN VYDH7IL3xEelJYFVvLeKzVeBLzWdziZAVjOSrGpbuv+0px4Mue1YEzgKX39XTTPaDTi7Xtl4fH3V la8v3KltasdLcPibr8T6LY8GsEG5iESKoFIteaQyFnLa61tPldA9Jn2jU+9+UffB/qsPh5JPx9MD k+yRU/y+KTaEIWd1I6CqIOFsQItnLrM0nsr8/U7vW5+flS+UoQioCqCRnsMHTrzGDyz3idcO9PSP yBe5PA57f/2VDQdaG12rrbwEUJ04vLzd8Px1+utPWAfE8Wtbrhxuq4j7bdZ8fvbCnR5UnfQiv4BX 6kTFhW+Bb4Kvk+VPAQZZpeazJ288/u3mk3/8os6vex/FGC8BqD6rbgJiwb9af1ScD2hViCWaf/ze frGC+PP93RfomRalq/621g1bTrzm5AFkSKS+lckDJVPyiqMikFZOhy7dW191pchvM8Hu7T5z+9VN J0/c7OoYnesZTz+bWpiYXZzNLKEEhLxWSEBVQeL3CbxYyLJpgoenMwcvt7/7t7oyvZmKgCpmeWID 94kNDjkYh32kVTYvVvkbFRCo5EJPb2ntl2uVpzoHE6hAA5Pzk3PW+PLyICoufBd8GeTMc7ee/HL9 0U3f5j+ROt4o+qA0072sZaIRoJQR/ra3XGmU6xVOJVLyiqUikFZUl+92v7/7QtFOrV7X0vHrT6r/ WnP7+2fJ7rF0X2J+eHphai47l1laXOJz+skVc4iAqrKE0wKonV58DvIenFqoben6/fbacpy6ioAq Ttk0xS+4yoU/jEw1HhCXY+3mgnnY7bF2hT/H2q6wnfRmmMIDlbpwZOrwAeuI1ZdzP9XvNp+8+uDZ 0PRCch6Fp5xgignfp/nRwOv8RimaOZ3kq7YrVq/UiQ31aqf9VGO99VLBU3qRlTzfbLyCFYFUTGrt HHpn17liYyqg1C8+PvLB/qs3n4x1jqZ7EvNoGI+nFmfS2flFflcwu0ooV84pAqrKEs4OnBxg7lk2 8G9xYHIB7aFXN508UN8q1ygTEVDFJ1Ea/fZqpGeDc/11VQ97EFCJHVvudeKwQMUllwd+aCa7hDJT oo9EPHq1beO3jX38nt25sriBSlVyLvPH3Rfe332hFG+qJq2c7C4X3+5oYBUbHS3/KpRKBahIlauH vaNv7jgt/1htWSh1penxWMfIXPdYun9yYWQmMzmXnV1YyogpKESLObQIqCpOOD2e8+n+UvOCqeYf D6e2HLv1xvZatO3kSiUvAqq4JI9kuNJIQKVIgmhQt1jf6NQ7u879dG0VjH98Vt1U29ReEp0hyBVv 7TyP1PFsig2N4PfsRqs9RSt8i7sdz17ZeLzl0YBcRCL5KMx1kxURARWpBPTV2duHLt2Tf6yGUF6/ PHP75XWHPth/VaBU1xh7zNTQ9EIitTgzzzqmFpd4OZPviCACqkoUThTAd2bpBUAc59Dg5MLT8fTf W/v+sOPMms/PlgVWqdXFHpkG83kUxCou8bEZW5zbhPBvrzEJ6qbYxANed9ZO9bdhU3Id/ol+N+C6 t8Z3LBJQiXugrQ/y3Wd+KHizns8qYa3PR6fIdfxlXX8NN3TNLOoBZT7MgQq18373dyn7LLajNXrC /JouxQ5UtlLpDOIONAWm+tX6o2jN76ppLtpI7BxMvPnXM/f7pvsn55FA0pnnJfoEKlP4Ggfr7wFu 6TFTpNyKlh41ha8UYVJ9QKYNWSkgUQflaj/awsula5dyF8pc2dh3P1einJFWW5ns0ps7Tq9Kt3/L o4GPvrn884+O7Ki5/V1XQqBUb4JNPjGWzEyn2R1TGetO4Lx4ioCqUiWZKvt8LvN8cnZxeHoBjN41 lj7zXc8bO878ZkN19bUHpdyksLJ2vTUeQ7V+i7Ac1c1fOuGqFq4yKbfJljtTOWnNZWcd96bMVrXy oY6vyDubcwOV8kGa9YuCVgWyR/OrzvlBUajAOey5gSrkgQq187xdoqIR2yDs2baw5OyA8t4cX7Nw QKWpb3QKAYhmPeDq0KV7RTUm0KKpmV7n4fH8tt3SRyp8gU+/bSihSX5JqysLHvLongqZACFlTc2u VC9XC8q0mvVK0eM9r4azWqhCmSsbe+5n+J0Ua+ZbzkhFoBUe+IeP23as6eV1h9Z8fu7AlfYnI3Md o2yAH1q8GkqhSZxfx5QtAqrKFc4bnD3iKZYz89nxFJumomc8Day63j78yeHGl9cdXLvnIhp2aN7J 95SM1ATtXOhCrvfIvOwqo359y6qUTnmTS9T8zm4fctU/2bbeol5onLIXKtu3d++ENbm2cvsynKsw yG3yr2Ztlo3U93q756FgnTNiYSB1RG0xyM9StmkuYYp+oOBcOx9lkEmYX9OU3EP3r+O50NnzcPvj p+GJFNr3P/vw0GfVTcVwgePSne7Xt9bc651GohieYaUozOMOS0IL2aU/7r5Aj4EihZdXygql0AnQ WjN3qg/MtKHfjjWd5z3waYec/QlXKKV8s7HHfobeSShKRSAVq366tqrQVwk7BxM7TzX/4uMjKFi7 6+591zUBlELj9ul4un+SDfBDi9dCKfZ4DIFSy7wsSEBV0WJXlV/IrqrZhaXJucWRmczA5HxvgvVW dYzMHW14ArL6l79Ug+83Hm4AXJXIgEA77erjuEITgj0ZkfxbJP2goR1y+IfZKNc3ZQ8U0bO/tdxo nbvl93bv8uZ3KOTy4MEqnjXeX2axNJdEOVCRdj4KUOX+Nb0kj4b71/FYyNiML/T6jfJQJrtU29T+ ysbjhy7dW62JtvG52442/u+v6h8+S/awWWUzU3PZefnsqZLnKXyBD/bW32jrlX+TSCHkmRBkInLb lWqWXyk8Un1Apg3xdrnP5i7llJm0ucID1QqWM1KRaN2+giTbiWS6rqXjo28uo7366qYTu87caXo8 Bo7qHE13j6XRrB2cYtNOsHul0tl05jnavXGhlBABFcnuqpLPr5ycy47OZEDwfYl50PyN9uF1+6/i BAXu76ppfmfXOaQttO3e333h6wt34Mt3u0FZnkb7T6yz4vfZe1UXIf/07Za+BYfEfEqOXMGLhbTm u1zTq+nvXaHdCni717fzPRRhPkuuEytQhT9Q0XY+ClDl/DU95XnE5EIvx1vdU+nMV2dvv7711MrP WvGwd/S3m09+deF+x+gcypKgqXRGzCrLJNcrTWHvPz3cQH1TpKjyTAieQKWuE0ulMFK9f6YN8fag NXPIJ0WHBqoo3xGKUhFIxarqaw/QmBT/XqY6BxNogqIy/m7zyZfXHfxg/5UDV9pFfxSqFb9Lan5g cgE1ayzJylZqfgkNXXWAX4z1i4CKxMQbRS9whmWXXuBsm80s4cw7913Xv2+v/c2G42hqaNfF+0an Wh4NCFhaX3UFlOVpnOVYYTUuq/umXd8ramyMQeuGA3LAN8yys2s1p9uBT2Cgt5XthrW9BdtiuZ3r A1J/mKoQuI784mGYJKCu27K+VJxD/sIfqGg7HwWocv6anvI88vbXcYzv4n9/+TKF0ANTrdhNvRPJ 9MZD11/fWnO9fbiLjzsf4SP9kCWsZ3SUPE2da36y6dsG+TeJFFoy9oNyjsxgatIInwA9E44luWUr 1ftn2hBvD1xTU85CyRUaqKJ8R8jjawqFKWekIhGalHmn3Ie9o7VN7duONa35/Cx+8Vc3nXj/q/od p27X3x9kEKX0R/XzufvAUZOzbPq+uYWlhSybP4mPqmCZP/biRUBFciSaRzjbRqfm3vui7oO99Th3 5WslJt+06wlUMhd72b0FZ6w28xZluLlSJv1sV4WAEhKisMmvtjIVyDoyIYeCmJ/l8enhD1S0nY8G VFDQr+kpz18nxE8Ws1LpzDu7zhWaqYYnUhsPN7y87uD++u9RpVCiBiZRnNhgCUZT7DG+THLt0hT2 f3xm7pWNx4tq2g9SqchKjwHXm2QGU/ND6ATo8V5F8lVtZTP3hni7tilfhS6U4YEq/E4KaW93FKac kYpEYj5b+UegMvxRjYcu3UMx+t3mk/iJX99a8+eq67vr7tW2PH08PKtC1NNxdsnP7o+anMuiWs1l 2NirRc5RhR5RQUBFcgmn2vnmjtJ/Botv2vUAKpH6kbVdU8QGbME13a29QviGdcCaYTYSuE7cFcg6 OF7HwZT5WR6fHv5ARdv5yEAl5P1respzz6N8ndg0kUy/vvVUgaapAKqJ6WX3XXwgbuTt4XPLTswu pticfuIKXyHr0koJX2HbsUZUd/k3iRRJudOjzGBqfgifMaKk+qiZ1vX2ULsUqVD6ZmN9/SjfEfL5 OAKqktKmb+UQ6+GJlLg9BElYjHh694u6NZ+fFb1P8D+9t/+NHWc2Hb257+L39fcHUI9sguoaZQQl eqIGJxdQoUaTmcTs4hQ4ap7NNiE4qqBdUpoIqEiOFrJLH+yrx7le+tdrfdOuNSzb6XLxSej+W5Cy JmWy3igTeogGfcCaYQqbXMfzg6IMOg9XgSR/hgMV87M8Pj38gYq283kClZD+a3rKc50wbyyELt/t Xl91Rf4Rk1oeDaCevbrphJhetnN0DhULtQqFaprfxSuu85U8SHHha4zPpH+5/uhqzfNBKn3JBOXf SWWtoOSH8AkwSqr3SJXh3x60piWfROeToqMCVajvCPl8XNhyRioK/fLjo+zHemfPzz86Al6C/1x1 fevxZvj4za7alqe892nu8fCs6IMCPtl9UCpBiZ4oCVHpbGphKb34fIFxFLtFasU4yhYBFUlK0FS5 zHNllTH9kVNW+lbqn1iiXAMTkvfYmInbkVYz5AW8EKPj5JoeRUjUjxxVwe/tdlFxVfflViBrm+Yh 4nLNNm5+ltenhz9QkXZebjZg+E2gxNujNyl82hkroXd2nWuNY9ZNRD0f3cee1HHiZpfVKzU/MMnu mJqcW0zNs+nR5YRI5YFTHKhO3ngYcuQJieQtKxv7pA6rEnlkqmVUCo9UH5BpQ7zdb5eANNb3ilYo 5QbNbGzsZ4TvCEWpCKSi1MPe0de31jzisKSM2WNzSHBwYtUH7NQ9zvCphxFUmhHUFCMo1KPx1OKE QlCiJyqTZU8A4hWKTbEmytTK1yoCKhLTwmIWNFXiw/xUWWWMWX3Wk0jQrqrgZG27lnhMe40Nao/g sD7CyeDWEjbJgVwkxJ8B71EVlAKmPHbDtU1POW+3HsQBOXcEuWueXHkZFcj+uD3uuRawz4IAIwKV vcHQByrUzjuXM/nXH5lyP+NfFTab89f0ULEBlRgjIf+IqFQ6c/lu90ffXP6n9/b/5xcX9l18wB4e j2I2OocaNsB7pSbnssl5ecdU2QzzE8L3wDf6r70Xaap00jJlVRCYZxU77YzYGVLLD5ETYIhU75kq w7/dGonglEv+iF4ssYAqXKG05JuNzf0Mv5OQ59dk8ipn1riDwMtkpBXWxsMN++u/Fz1OnJdYjxM8 MMksup6GpjPD0wyfxpKLidnFyTn2zKjk/NIsCGoBBMWewwuCsnuiFIiSn7IqIqAiyb6pMqIpSKRd lDflabm29fRq1xK8ZD/iXc5fZCVuO+nzdex/61fgnAIjtuC7pt0ZpRqlVFyuy9k6t8qV6df090aq QH5Svr5uHGSnChqf5ffpIQ9UpJ3Xd9JdiVUpawb9mrqKDageRnzk/PBECvwABlvz+dmf/Knq/a/q D1xp//5ZUoypQHlDbRMj0YFSfHrZJVSs52yumlUuVLELxRf1eAWeL0mqBEn28DVQQa5pKXSlCJvq fVJl+Erhvaa652EKpS2/bOy1n4UqZ/YO50jspBXTRDL984+OPBpO9U2wx2+g1oynJDJNzWVBTfAM PM+u5YkOqPQim1VigREUGyWhE9Rq9ET5iYCq0oUz8djV2J4JUDQSaZf3nPAxaSI7owxoD3qXGuk5 rEz4JvphRIJWEje/3OgUiRPs3lz5kiptNTY3ruuypS11xxiW8K2FBComY3/Y9U4TISJVoCDxq6d2 HbUOput7mZ/l++nhDlTEncfv6PzWVwJH1IT8NV0qOaDqG50Sz+gAQf3Te/tRyf7ziwtbjzfXtjy1 B1qIUemDbGYkNsPs1NwiypjSK1VuKCWEb5bJPscPJ/8mkZarKZEhrZTCswqyUNuUT2IJXSlCpfrw mdavUsg6aGd4j2c/hCqUlryzsd9+htzJSBWBeqiKTtuONe35+73+yXlwFKiJ9TjxMXti2F5mSfY7 ofrY+MRH8YmLepyg+D/k5opMBFQVLZyX84tLv1p/tEDThZFIpMKprqXj/d0XWjuHRL8TLJ7OAb+8 7hBaEv/yl2rxjA4Q1IPB5OPhWUBUxyibA/3p+HwfH5g+zEelT84tJueX0hnnjl4u+UFlJnwxfEGU cBwiuYhEIpFIhVTnYOLVTSd7xtOjyQxoCrVG6XES9z5xamL/z7ueJD6xhXITxS0CqooWTtPdZ24f vHRP/k0ikUpHwKdXNp18Y8cZ0e8E86dz9ACfxKPiRTcUf2C8HLDex6eaEHf3ismRknyGWTGgghc2 IfkRZSl8O3xT0OOP39tPU/yRSCRSoYVM+/vttVfbBgenFibn2K25vN+J1Rr+33IoOQRUlSvRqnht y6lCPyGURCLFLjEY/cEguwNKUJOYW5bNksQISo7lswlqeCYzOpOZ4KPV7RlmM1n5mA67R6o8Cluw 8A3xlecyz3+7+SRlPxKJRCq0Pj/V/Lezd1GSxpJsVPkifzS8fK1cREBVucLZjLYUXaMlkUpRqE// c+ZO1yib35xPkbQAi7llGT5NZ/gUSawbihGUvMGX390rHnfojLKAKoKjbOG7cqBaWrfv0uW73XIp iUQikQqg880d6/ZffTqeHprOTM2xh3AgA5dfzSGgqlDhXMb5PDwx+88fHpKLSCRSiUh0Tz0eSYn5 zXm/U3aKzy2rTZFkExSMGmZ1Rsnh6ZUpAVTpxefX2vrf2nlWLiWRSCRS3GpuH3h3998fDaFazSdm F1GVsuXYPQURUFWoRJPi2USKgIpEKjnJuZIm2FxJfDIJdhMUzJ/O4ZoiyUVQ/EqK3EQFCwfh+Ysf gJqTc4u//qS6b9RrxjMSiUQiLU+cpi48HEr2TcyPJTOp+SxqkxgZIdcoIxFQVahwLqOlNbewRHcR kEilpaNX2zZ+2yjmSgJNAaIcarJu8LXwiQjKWzgqmaXn0+ls7a3O/9p7US4lkUgkUkwSNNU+lOpJ pEdmMjPprKhW5VqUCKgqVBKoMktbq29WX3sgl5JIpOJWw/3ed7+40DWWHpxcmJxblHMlMUIgcIog HKzs8xezmSVA6Zt/PdPaOSRfIJFIJNKydfRq21s7z4OmehPzwzPs1ilUK0ZT8vUyFAFVhQontQCq pkfP3vgs6NmgJBKpSNQ5mHh9aw1KVD8fPjHL5koq38t9hZRIgHzUX7b1aeLft9fSs/hIJBJp+cpk l/789eUN3zZ2jrKZZkFT02nQ1BIvVuVcrQioKlQ4ra32xOInh27UNLbLF0gkUlGquX3gzb+eud83 0zsxPzrDH4yYLdvB6CsgHLfs0gtA6Wgyc+l+/5rPz9J8pyQSibQcTSTTyKUHr7Z3jM71JNIWTYmR fmVeqgioKlc4txeXXsyks32JuV9/Uj08kZIvkEikIpMYPnGvd7pnXJYoTlNs6BopP4lOKhxGHMyh 6YWDlx+u3XORmIpEIpHy0/nmDjQm6+72dY2l+ybmR+RIv/LvmxIioKpc4ezGWZ7OPB9PZf5+t/f3 22tT6Yx8jUQiFYcmkul3v6jb8G1jx8gcoyn2HA9261SFlKiCCgcwu8RGPk/MLg5OLdS2dFMaJJFI pKjqG51a8/nZD/Zfbe2d7h5P94thFBXTNyVEQFW5wimO8zzDO6nQSrt0f4Bm/CORikotjwZ+/Un1 iZtdHaNzbDD69IK4tbdcn+OxwmIH8cUPYuBfYnZxYHL+6oNnOOAPe0flGiQSiUQK1IH61lc3nTzd 0tM5Ovd0PP1sagHpNLWwlMmyW0sqp1QRUFW0RCcVv5OKDXr5rmv837bVNNzvlS+TSKRVUudgYu2e i2t2nr/bO9U1OieGT4jB6FleoiqnShVUOIrsulL2OZhqPLU4OLlwt2fy9a01++ruyDVIJBKJ5KW6 lo5ffHxk87Gb3z9Lijo1PL0wObuIdCpnSJcrVoQIqCpdON8Xl57PLbBBL8+mFp6MpN794sJH31ym Oa9IZaDapvaS621o7Rx694u6VzedONLwpGOEXfBDK3+MP3LKHj5BNBWjxHWlzBJjqgSYamoBx/yz ky2/2VB9o42uLpFIJKnhidSummb5R2ULufF3m09+sP/qzSdjHbxjamCSPWh+Zp5d9Vtc4o9GlOtW igioKl0453HeM6biNxIMTbPGxKGr7T//6Mj+ujt0izappPX61lMlNIoVKLXm87Nv7Dhz/Gbnk5G5 Lj7nLEISgcmHT9B9U4USjunzFz+IfipxaaknMd/QPvyfX1zAL0IjAEkkEgSKWLevXv5Rqbp8txso hdxYf3+wY2Sue4zdMTU8k5mcU+sUa1vKN1SMCKhIctCLuDl7co7dT9WTSLcPJbefaPnFx0cO1t+j 3ipSKSqVzvx0bZX8o7iFOi1Q6nRLD0OpsXTPeHpwamEsuTidzqbZBT+a06+wEmkQxzmdYQ+TGJ5e 6EvM44c4813P61tr1u65SPOgkkgVrtqm9s+qm+QfFSbU02NXH6BN+P5X9QylRlmd6k2wO6bGU3IA BZqRlVynCKhITPxywg9ZNunfEhpwIzOZgUnWVfWPpxObj918ed3Bd7+ou3y3W65NIpWCcMaur7oi /yhKgaM2Hm74yZ+q/vOLCxKlRhlKDUyyKZIm57KphaUFOcyPRSipoBJMhTQ4v7g0k86OJTNoK/Ry rDra8OTnHx2hNEgiVbLe2XWutXNI/lExGp5IbTvWhAT4yeHGpsdsgF/3WLpHohS75De3sJRZojpF QEWyhFBAJCAkFrLP0YxLzC4OT2f6EvOInM7RuZM3u97/qh4tv7V7LtY2tdPFWlKRK5XOvLLxeHF2 rqocte/i93d7p9jVPj6P3+DUwmiSo5QzEp1d8GPBSSq8eBpkM1MhDc4uLE3NZfFzDEyyEYB2Gnx5 3aEvz9ymHEgiVZRQTX724SH5RwUI3xeNvd9tPgmU2l13r7V3uoONnpjrnZgHSo0lF6fmxOQTbHwT h6lKFwEVySXRmEAzLr34fCadHU+xu6r6J+afjrP2BCLqSMPjP1ddR4D9ZkP1tmNN1dcexHjBhtoo pLi0bl89uEX+UQTCuW1y1JORuc7RdDcbOMFKFEcpNgxdjJ3gF/yoTK2CcMhFV5XAqsnZRY5V88Cq rrH07e6Jv9bcFh1WdS0dNCKaRKoEbfq2AfEu/yhfpdIZfE0kt5fXHURjr/7+oKhTT/nTpUSv1NRc djazhPSIJClQigoVREBF0oW4gMU12nSGYdXE7KIYBNg7ITusOkbmrrcPf1l375PDjW/sOPOjd/b8 ZsNxRODXF+7Al+92g7L87uTuG53Cq8LgMay/5vOzv9t8EhtBG+UXHx85dvUBTYZBWo5ONT5EMfin 9/bj1Prq7G2Uh5WfmgLt7JZHAzi9EReAKJzbnKMeuDhqYn5wcmF4mk3iN8VRCkG3SChVBBI/AH4I kC34Fj/NJO+tGmTzVaS7xvALsg6rD/ZfwZmG9LXzVDN+bvlmEolUXkJ75s0dp+Uf5Sg0zNAeE9UK aU1MjCTmnOCj0BeGZzIJMcAv89xCKZkn5SYqXgRUJA+JEEGjDu2JDLtLe4m3JxbR7EPjD02KPtZn hVYF4CqNkEPgga8QgVuPN8Pvf1UPynp9aw0YyfS//KUarwqDx7B+bcvT+vuDj4fZdpoej2KhGFRD l35Jeehc85N1+68+Gp59MJg83dKz49R3H+y/+uqmEzj3wFfbjjXVNrUD5mNELPC/uECALYOg1u65 +IuPj6Cdvebzczi9ERd3e6cfD88iUtAKVzgqM55aRDN9Zj6bRoniM08QShWV8EPgx8CPgp9mfnEp NZ+dmmP3Vg1NZ+wciJ/10v3BXWfurNl5HgyPX//QpXs4GVLpjNwKiUQqZQ1PpEBT5dcgQeVqeTSw 81QzChYaZmh62RzVZXVJDU3LUeisTi0+zyyxrntZpqhQuUVARfKVCBeBVdkl2WGVnGf3FSRSi6Mz aFUsDEzOI+R6EzZfsUvvHeK/HLT8zBuXck28EUZDExvBf/Hve73Tf6357ucfHdl4uKGixgESQy5T ze0Db+08jxMMp6I4r2CcZuJsPN3ydHdd65+rrgPmBWLBoHeAFvzRN5dFF2tOf3X2tngL3ostoBkt LhBgyyCoIw2Pmx6PifNc7Aa7yJeY70vMI15Ef5SoT3OyS4pxFJWoohXHKtZpL9LgXGYJv12C99sD jCVZsVQ29/2zJH79TUdv4mT4yZ+qxKmFE+by3e6+0Sm5uVj1sHdUdIRuO9aEz/r8VDPlEBIpRoE6 Xtty6o9fXKhr6ShQFK+YxLW/Q5fuodj9ZkM1H8RxbteZOyhY4pIf56h55LRnUwvIb8hy02k2uk/c 0CvrFG8cyi2SFBFQkXKLtydYIIkmRYaR1RJiLMmu1y5OzC6Op1jbAnyFIESTkVEWb2cAtHoS7P4Q 1WIJGpf9fE0Y78J7h2cy2Aj+K9ooaIO2D6X2138PrFq752IlPAoGye7NHadLPWWvokBT7+7+e/tQ EvSCs2ho2jkncb71jDNiR8HQaP+7ronTLT21LU8PXGkXXaw5vePU7Vr+FrwXdUhsR1wjsC4QsAcd 9ibYSAnsACBqNMnGS0zNZZPzS6w/SuMoKlFFLzsNihzIxgHOZ9HaYFeXWJ8Vu9cUmU1cEsJpgFPi djc7tXDCvP9V/b/8pVoAvEBx5DQB52KAdE6jMSfWhwU7CZh/fWuN6AjdXXcP5yTaRkiYhFUkUlxC qH5Z17r7fOsH+68gin/ypypxlaTl0UBJXO1F9qi+9mDj4QZBUG/sOLPp6E0Uu2sPh0Xl4jVrDvXR 4Sg+tA/5DS090SWFUsUSoNwkyVsEVKSwspt9kqz4MBjesGANxNkFdtUWRhxOcspCTAK0xpJsXJNq sQQrwFgT64s3pubZwEJAGpZgBdFAQasU0X6k4THaDUgHyGLlzRtI0O/sOldRnXJx6UB961s7z4Om 0KgFwODsmuGnln1CsgGrHPsFsYN2sCZOMEZZY+zKXCfvL4VZj1ag+WrsLQKcwG89iTS7RsDH8okL BKMzOM8zk/wKH85qBAia4JksixriqNKV9av98PzFD4vW1SUkLpxpOM2QuMQlof7J+V4+l4+424qd NhbAC3o/0vBEwLkYIJ3TH+y/Kta32InBvNggJ3nn1H34LPk/ZwmrSKQYhCD6n7N3rShjV+Lu9k6J qyRrdp5HlIlLJGJ0AxBrddsnaDmI6y/YGRCUuDUd2eOTw437Ln6vEhSrX2xMEKuDA5NyXB+qJKoV 4yhWquwh6DTNbFgRUJHykR1jAq4EX2WX2PSAmaUXC4vs8i08l1nyNMJVrIA1sT7ehfeyLcgesBdi MgwgGVonFlax27S2nWj+l79U/+LjIztPNa/8NAMrI3wvMBX1U4VXKp1Zu+filmO3UCcYTc1kUBXY pbUsmysP/xUnJE481vBNs9tgUDlAO0AsYM/wNDMoCB7k3VloEPO+U/zXNHsVq4n18caRmQxKETaF bU7OsY1zgmJduDjPF7KsMrHT2x4vwUsT/w+phMVyIE+AICskLvzK7Bzjl4RwDuBMAFyJniucJzhz wNsC4Lv5EFDei8WbaAql29ClGgsFMtmrscaQhHm2TT6UlH2EOHv7eMJ8OCSxatuxJkomJFIe2ld3 Z8fJFoSb6L1BUwT/7XF6oWWEgq/E6AYglt0RDZgRfdFoqwBv4BttvYJ2lnN3pX2/rpjQCxsXn/JP 7+3HhyLexfUX7AwISkzQBysExe7g7UcVE1f9+NVtJCtWsMQlP9YeYw+Rl6WKylQUEVCRlisRdaKN yCVvuwowwlX8lwet9UZsgW9EvJ1NhrH4fGbenmOQDdkSY2maHo/uOnPn1U0nX153CM0FJBe5K+Ui MNWbO07TI0TDCMfqt5tPHm14ghOjJ5EWNDW/uIRTyDq1nBMSpUL0KqBy4OxC8xfYk5pnPUgwWAvv hXmDmJUZL7Nhe1gHZ6Z4F+oQDFrDNllByrLtiwsErjOcn9typ0llJPb78v+KtMYYnk8MKAAeLRWc LThzkMdA3WxU8zQbjGrSuzlMWo6O5s04NOZsmMd/BcyL9hC2jO3b5y1/hCDrIhNY9WXdPTTy3the W9fSgdaY3GlSfEJDuVyv7lWydp+5/dnJ5q5RhlJsFByPMjG+F/GFAERI9iYYojC+4v3DgBb7mghg RvRFo60iOpb/84sLgnZ+8qcqDbo0/+Jj1vHlaft+XTGhFzYuBp8/GEziQ8X4c3YJhl15MQmK5R9x 7U+UMCQocdVPXNSWRZNnM1IeIqAiFUSsBcnEWxve5i97SbwgGsGIczRNEPbiUTDIYuISkbg+dLt7 As0FkaE2Hm6obWovm8KGL/LKxuObvm2gQTt+SqUzqHmvb60BYHeNzvUlWNlDnbBoynV2ib+ZLWK3 m78gH1FOxBBWtIYBRagxfubryArE/uu+UuAmKPYPuQekcpf1o7P/k2eX7HJnpw1DrAWGWKybVKf3 LPIbWjnaMGnxDyxkyMQHSAuYh8FpgHlsCtvEluWZucQ6YwFyeIlh1UyGY9U8mnp1d/s+2H9VXIGi Dqt4hUT0+tZTNE67bJTJLm04dP2/a26jmYH2BsIQAZXml8zY3ePWjQkIyfEUu6iBQLOuj9gd0bIX SzRUOGvJKbgEcQnyEdBlmk8RgXVMq/frqv3VbPJYsFMPv3EX+ywuvgxNsxuibIKSGYN/EdETpVz1 k7lLHgJSXiKgIhWvRJMUAY/IRwpAIkNSEJeI2PUh2WfF0kpr7/T+i9//ueq6PTv2V2dv32jrLSEa EV35X/NJt9Hu+Tl/bNGmozd//Un1gfpWurSsqaaxHUfmrzW3Hw4lUUhQP3jZY6UCDdmchYGtIcBe nGZyiRArMMHm7+Vy3i6XyA8gVbbEuWCdV+yMEsjN6Z11YJr0jlOXtdg4EakWLTmYIZML5ll7SGzW OiflB2E1vAvYJnqrEB0sVY7O3eudFh1Wv9t8svraA7pYE5fo3teyEfD43b/VfVP/fdcomzR8LLmI soIgFYEmjAAUV0kQrWiWsEsk/DKHuCwyzudABmWJ4b6CtURHtOyF5heFRdcWM/4RxgKZAGy8vxoW /dXY/hAbtS7ZCYzHrr9Yd6ebBIX9R5uKpwv8R/5DfnnS8kRARSp2iYBHFkAuQGMCqWGWtxWQNayp 2xd6+bBmds2GX785zZ8+BCB5ed3BX3x85KNvLosnwxQblnQOJmqb2sXNo6IrfyufdNu53Zyz4pZj DKvqKuAZ7WHU8mgAh+ujquu3uyc6R9k1OVQUNBxR2FDkeKmIrTywkqNILiWRokucQawFIyzl0Lto q4muLdPiQjIs8iH/f4fk5WdwiYV4C5p9wKrkPGvn2d37aJMhai7dH+SP+zu45vOzSEHLuamDJIRk DqaiI1nSwo/4280nz3zX0zWW7rcu0gmacmJW/kPE4w/i0ga7PsKfqYD2id0RzbuRWVsFbDPFx5Cj 0ZLgPc9ouoB/AF0AobDmb0Eg4+18/KE1+NwCJ8FOYDx28YURFNsrIqiVFAEVqTRk5wJkB0ZWPHOh DY1sgsyCFDM8nRnkw5rRwgZcISGCRsAkN5+MHbjSLp4MI27c/P32WtGF9TWflmcFbsF62DuKTwHU 4RPX7rmIT3+ZT3n86qYTf666bt482s2nnuvl904IVmzuGP9g/xXAYSVj1Y22Xhy6NZ+fw+ECOeOw 9E+yy3KoK+kMu2wvyh6JVHJi+U1KtHhUS8lVw8nOlmhUIVWisYW213hKdFgtiCSJIELbESnoJ3+q Ql5CbiEeWI6Q5N/ccboSnvBRljrf3PH61ho0GBAa1pCHLFoafmVFBCULNOvfWBEriyYKbPckYyOi RwuRyIiL9TyzkLRnNg5jgUxo84geJ1hsllGTu/eJ/5fvG/sPywP8/0kFFwEVqcRk5wiWtlgekfd/ J9kTh9kN2Qyu+Jhm0XMFMrHHMQtoqbvTV9vydMep21v5tDwALXG7J2+sMwN7NAvu8jRe0laG7Qe/ ii0jTeNTAHW8A+qJMeWx7M2XN49OLoi549jtE/zrDE1n+jhW3XoyJm6EOHb1QeU0ffBN8X0Bk//5 xYXTLT04aPhBexNpHJZEanFmPosTALVElBASiWRLtKVECw9tL+RJxMvkXFaOmuYdVuza08jc0YYn H+y/ArJ6Y3vtoUv36D6r/ITj9s6ucziA8m9SKWgimX73izrUVjGAHCUYlYUNeYh4kY6VICaLspQl 2IyNW8IWdDEiCmOxvv120WUtAlz5OGH8k7QKIqAilapkHmFpRcIVWgwCrsTlWH7PqBwWyDqvJsXd onzUsnOrqDMtDxrrQJ1a/ogJzYK7PI2XtJVh+8Gvj4flxjk4OXPviCmP2cOL+P2jaNyIAdBo60xZ c5jii4gh2uLSshixgzfe7p7YcLhRXFS+fLe7aG+vEneFLWf30DrZdqzp5XUHPznc2PR4jKHU6Bx+ RBwKHBAcFhwi/Oh8PIM4HUgkki4RG6I9h5YZkuRshmWVCT6BKpqPYiigIKu6u32bjt4UT6dA9N1o 66UbOCMJh+urs7ff332BblHDEbAvOH70zeU1yvOscV4VyS1n55s7fv1J9YmbXajOYgA54gJld3GJ QUu8RYWXKcjin/xM9a5YRUBFKnmJ1IL/2FeAkArRzhb3jAKuxCBmsArjK/l0V9mFpUzLwwcKcuCx WIsZSda2oC/8QwCSzUiqrTcyahLkhi1j+2iy2HeRAvDElMcgKOTuqTl226vdlZ/hPfiwuAqVfc5G Zs9xrML62O3eBLtFFZ9ytOHJ+1/Vg6xQq4qErFA+d55qFrO+irvCxDDL32yoxnK8KtcL1MPeUbRI frf5JFp1u+vuff8siUMNkuzlB3AsycaOs8uHfHZydpVOvo9EIgVJtMbY5Sd2Pyq7wyrFc2NCkJV1 k1UXn4us6fHol3X3/vOLCyyQt9cCrupaOspmGtUCqW90CkcJue4na6uQmY9dfVCBOIqDUH3twe+3 1/Kb9M6Ji4wHrrTXtvTYz7PGefXzj44gyQOuVuukau0cwg58sP9qa+80KjVO/uHpBRQXFGJZWai0 kKKIgIpUVhI5ULQbkBAFkCwuyeHLSJRoiNuIxShrlg2rEx1ZSKbAFWG0LWDgFlrwA9YzXsXUOki7 YmZSwUjiJb6O5CVYbITNvTPDbj/F9hPs8XnOXaRiSLQkKDEM2urHx57LbyH+zS8ti/63ucxzbEEM ArSH6zwcSqJWCbLaeLjhRluvPBYrKzQjXl53COVz15k7jY9HRdfc4+FZMdPrtYfDWL5m53ms4/l8 rVQ6g+XYf3yL17fW7Dh1W9xXBm7E18SXxfHEF8fXx3HDr4nDJVCK/4dEIoWVSC8iPSLzILGIC09i yDTICrGGiONPp2ABiDCsu9u3u64VTc9XN50AX62xplGlee1wBHAcQAU4Jjgy//KX6g/2X0GuO3+n 927v1CeHG3/9SfVq5eSVF1Bq7Z6LOAj44nV3+nDmiByuXGpkFn/ipUv3B7edaMZJhaO3klgl9vON HWfq7w90js6hxKB8o0yjNKMio7iI4ksiRRIBFalsxdoNHEjEP9B6YJdm+YOD8N9FPiePAK10ho2B EaAl5swRuAWjBQ8QEg+KwX/R4OAAxu7emZAPh+GPkeGrYWUbmcR2sE1sGdvHpwh2EvjEbld1BkOL HWQZnP+/LvEqwyrrRgh8BHZAXFQWzxZEVfj+WXL/xQfiijLqE2p8y6OBFbjVCk0KcZ1P3BiGPemy 7grr4cY/WO8fG2aZvt098b+/qn9je61oiqGwHbp07/fba8FRYMJ9F7+/2zstNzLG3gtYBZTiy+Ir gyfxe+Ho4aAJiR0gkUh5SCQcBJNIjJnsC0ZWos+Kd+azwdLWnagIYdYUHmF55jS7B5VNo/rzj468 vO7Qu1/UrVi2WXXhO7by51vgW+O7i+dbbD3ebD9cFYeIAwPLYDhiN5+MYQUk5PKerGIimd52rAko daThsTgIXRxUcPIAzu1LjdL86qQ4r7AaVj7zXQ+w6qNvLhca0fHzfX6qme/nE/xMXWPsAYbD0wuo 4CjWKK9UXEh5i4CKVCkSSZJxi/w3xChFUA1HLDlbjgAeBj+8kSG4S6AXpy85M6mw/SqbqFTyktyI DW/iI0B0PFdLQOK7wf4t9y+XxLuwBdb0EcN12EVlPnMXvxGid0LMHZ8WLR7U+DU7zwNUxMTx1dce FKKio23xvzadFNPuoQEhyuezKUZBo+yusEXY7v3rm5ivv9f/Tf33/+9/n/vndYfQHEFh23T05vk7 vawG88uW+Ar2RtCkQ50Dl4Ih8ZVxMHkPnjgSJBIpHolEJJIhEhdiDZltls8/NjnHOvBFt5XdDmbX R6zh0Le7J07c7GLZ5vNzdrYBb9S1dCA5lHoXVobfCCoICt/rNxuq8R3f4M+3OH6zU1xCEscB2Q+H pYd3p+NA4XDBA5PsqUFotQMYXt9as3bPxbIcM4nj8+tPqr+saxXXwoBJIoHjtMHJYw/NsC0uU9rn FVbGW/DGg1fb/9fmkw33C9Khh5/yQH0rAHjXmTvYT5zAOJPx6WPJzEyaPbcXhZXVF7k6iRRZBFSk ipZonbP2hCAcZ4kQAxjFYkJSLGT/sBlJtWiaSDnblAvlpy5DYiv4IHw6CgAoDrCRnF9CfUJhALcw slLmNkTlEBPHf3K4ERVdTGYopoy/fLd7mS2eS3e60bZo7Z2254oAPgGBUDLFmMaBROpW++CXZ2// n/2Xf7flJD79jc9ObzzcgE/HR2NPTt7sFCT2dJwNoWT9UdPy1jIUOTTp0LADoPJDzY9nHMeQRCJ5 imUq/l+RXgBXC7xLnPXe83ZwwjWNKovZHvAVbw2r2Qa88cH+q0gOaL8i6kFZCHYBWrVN7Yj9viKb RRCcg73CvmEPkaCwt7/bzPIVu3+MTz6Eb4Tvde3hML6jwAZYPN9CJC4cEBwWHBwcIpsfkAyxBC8x rBplUymK4W0h7yYtCZ1qfCiqQCcfno0CBEzCQcDXd24Mdi418iuVygh8rIaV2WiLyQW8/X7fzLtf XDh6tU1uPQ5NJNMH6+/hJNx87JbYT5y0OHtH2RjyRTHwASc8O/mpvJCWIQIqEim3GMY44s0Ot+R6 KyixD4KsRLsnnXk+w68oc7KSV/44XM0LuAK6oCkghuugffD+V/V2i+dldvuTMwUT2hY5faOt9+UP Dp682fXttUf/XfPdrtPffXHm9rt/q3tr59m3d577143HsdmffXjo7V3nsEHAm3lpNpXO/H577a0n I6htogajIcL7o1i5RdEVoyLZN5XvIJFIKyGR1OwMg0gUTWHRDgZfCVoQIwPZMwCdQVxWtrESzuPh 2abHo6dbegRo/bnqOtLOv/yl2kw71dceaElm+dyFLWjbBMyIj8NHw0Am7Ak4B3uFfcMe7rv4fW3L 0/r7g+ocrfg6+FLi0g++puiGEnMLIXGJq0g4LBY/SGxAWhbMMJZcHJxij//CFs581/PWzvMAtrrS f6jgtqONHx24joPTzZ+EizSOAoTjkGZjCpwbg1kWd4qmuAppT47CBn3gLXgj3o6NYFMbjzRuOHRd fsYy9LB3FBj/8rqDQKnb3RPYTzAbfju2n3wqP/xAfOADO9tJpGWKgIpEKmGJ+oT/iXaPekWZtXjE fBviXgg+4k52XvHGgdri+a4rgRbPkYbHaE/AaFsE+5VNJ3/ypyo0R95iF56viAYKjMaKaLWEbAkN T6R+u/lk3/hscp61RRZYfxS7WAiz78W/oFyVRCKtuFiCsSJRJBmRZwQtoCmMVimCl/OVk21E/1U/ 6y2Xd1ECJDho8YGCnE+QdtDGVdPOJ4cbtTwjuEu16Ozy9O+312orw9iCtk37QRfiyRbixidGTdaO YSfF3mK3YfZ4QP5wCxAUvhq+oBjGhq8sZmfFQcChwAERfekwy14sLbOxDGiv41UODNnRmcwAf6py 12j60v3BD/Zfxdf58sztEh0Y+fmp5r/W3EYpwTfCLw66xgEBT+L0wBe3Tht25sg3KGJHyFoBK+Mt eCPejo1gU9jg3r/fB63JtSMqk12qbWr/zYbjr2+tAcaLHxc/JX7H4Wl7P9kYP15o+K6QSMsWARWJ VA4SNQH/sclKvZyc5DeaT3C+Erczga/EiB0gVo81RJC3eFh7grUtuBl38daG5nX7r55vjufy6rFr Dz47ftO5Umh9EfkyiUQqGsnwZP9wBh7DGd4gFtlGTOozNScSDruXcoQ/DFBc1mF9WfzJVxZosbtZ 1LQjco5n2nk8PNf0eAwMZj0zkD02UPwDS+ru9GEFYe2NMNs4H6pnfQr7UDZ9Dt8N7Ax2CTvGwEnO 0eo83AJNcNEHJeYZkt1Q1vMtnB4YeWSc3MUWy4TMbktLsbHZ7KnK+AgkXuTbW0/GwCQ//+jIG9tr 61o6SmhWD+R/VAEcRnyR4Rk2/2o6w5BSopRzDHJLrM+x6gU2gk1hg9jsxiONxyKO/euTjy489Oeq 62J8Jn5lhlK8O1GgFABYoC+XfCOJtHwRUJFIZSVRJHhdZyWKtXhUvlpgT55BUUHRmpxjExWyi8pW i4eBlmhSyIng2TAemHEXRy9GX+Ppa98P/W7LSfl5y1Ymu/SHz04/7B1jlVguI5FIJSAr1bCcY2cb xlesx4YhRJpRlpjfgt2FZYNWgt+LhbQjBifzhOPkHCQc61oPa6/zf7CLPt3i4X4cw/APcQEI/xX/ Zgv5OliTPzZdpixm6ykXMD5C5Dd8LowdwG6Ie5+wY8iK2EPsKnYYqRJ7LvCJ9UFZ8wzha1rYgP+w fwRLrMkOjsAqPpmQvLcqwXYY36Lubt8H+6++vO7gKj76Irwe9o7+4a9n2odSOKrgQ/ysrMNneWPn 8Ea8HRvBprBBbBYbf2vn+eb23PebDU+kqq89+J316MLW3mnAM04J/PT4ufH74sfFD4qfEmcmR6nc vxqJFFUEVCRS2YrVe6vFgyKCQiJaPIyvlti0hJ4tHtHomYR58yKRko/qQgtADOn5qOpavKP/sbVP Dl7HXlGRI5FKVGq2wT9EwlGu6cjLOuLKTjrDWrei8xyZR6QdZBuRdhhxpZycg/8i7TD64vOFAoHg IWbZlST+zZfjv+wfWJ/PMirfjv+yPMaH6uEjkN/EJ+Kj7UcCYpewY+L2J+yqYCf8V6RN1ghXCIr/ fzSJd2FTOBTAM6Rc7AD2DXvez+dj6BpNP3yW3F///X9+ceEn/HHtxdlnlcku/eLjI/94OgFcwXFG 1cBxw/cSkivlJbEFbAobxGax8fbB5K8/qZ5IpuUabvWNTn194Q446ucfHfnkcKP66MI+ZZIk/L78 l2U7yXZTvptEilkEVCRSpYhXq9wtHn4/gPOQLli0foQTqYV/Xnco3jKPrf1kbRU+SFz3JZFIZSCR Z1jCEeZ/Iu0gzD3TzgLvCDJzztyCfCC7MGcwNvpOXANi/+X/FsvZOpKRWIe8vRHOS1ZfE6iJzziH j8Z/sRsiE3LzfWb/sXeb/Sm/0rIltoYPwodiN7CH+AogPeAfAKBPTiCebu2dPnCl/YP9V9ks7dtr q689WP78HHFpX92dz0629PCRfmBCHFIcvdgOED/m2CA2i43jI7483/r5qWb5Gldr59BXZ2//ZkP1 v/yletuJZj59yCwOWpfx6EKcNvi5QcU44OzIyw2QSAURARWJVLli7QZeZqSlRKNHmNU28V8YjY+W R8/e3nlOvj8+/eGz0//oHEblYx9PIpHKVyLJOJnH+lPNOaZZfxFLQaz7iFEQN/5t/cN+id2NKRjJ NDYuPoV/IpfcB+EVSj7ik7Eb2CXRZSc6rMathwr2WEMBO/howE8ONwIeAFfiGcogitXquZpIpn/+ 0ZHHw6kh9jDcRUlTcR83bBCbxcbxEb2JuV9/Ui3mZlzz+dkfvbPnjR1ndpy6fe3hsOAoHCjQXT+f uX6UPbqQ3yjFyRmnAUep2HeQRPIQARWJRPIWr0NC+DdrdqA47Tn/DxQ2uUZ82n6s6durD1ACeXWm 6kciVah4AhDiacdKPh62pS23rW6BWaxbLBJ7g/8BHsCBIKs5+VBBTlbT7L4y0WfVNZbuGJm72zsl nqEMogBc/WbD8Y8K9sR2P2071rTn7/ewV4nU4twCu2+qEIcUm0zMpG8+7P/q3D/+v/+p+6f39sPb 2MSMT+0pRlh/VILdGic4asJ68hUwDAeTw7M4vEX0i5PKWwRUJBIplFCXUKW2HG2sbWqXi+LToUv3 /vtkM9oT/HqnXEgikUhlL2Q8ZD1kPkFWCyArflPrFCMrdvMYmKFfPENZTsTKoOJ6+/AB5Yntb2yv 3Xmqua6lo3CDAzPZJYDck5HU8HRmZj4LAozr+hc2MpRINbT1fn3hzju7zv3sw0Pw+7sv4M+WRwPi c+/1TeOLAy/FVBND/E45yVHy/jf55Ct2POWGSaSVEwEViUQKJZSpxaUXa/dcLMQkVGgHfFR1LTWf ZZc85TISiUSqFAk0wX/EoEdGVnzSoBQnq8Ss+xnKVs9V5yjrvAJf1d3p3XXmzgf7r4rBgWs+Pwu+ EkASVxcWMv+7X/wdMAOMkYP95CsRhC+YnFu42zF0vqUDu7duXz0ICkD4q/VH8W8sae0cMmeh2Hi4 4cDl79n9UdMLY0n2WN4Zqz+Kzb6ocBQ/iiTSKoiAikQihRIKVUGB6s9V15LzWTQjqCKSSKSKFRKg RVaiz4pNEQRyAD8klWcoj7BnXWQGrMcJMr6ynpt8t3fqdEsP+Grr8eY1n58TXViCskAmgBYYaVw8 hF1+agjhvVWXvx+eyWA3sFeeeZrtPNdQIgVquts5JD7us+omgJNgp5+urcI/Nn3L9kTshnyzv7Da H7/8O741OCqdYZ142AHiKFJRiYCKRCKFEgpWZun5piM3CjTk77PjzWgr8DpNpZFEIpFY1kU+FGQF Z93PUObDAuXjBIf5o5MFX4nBgaL/is1swbuwWnunQVn7Lj4AZcH/+cWFN3acgUE4Nm6p3nasSbCQ bayz8Ujj/5y+/dW5f+yru7OfLxSYJPz61lNia/Cv1h8VC8V7UTWi8psqNupvbdVYcgHfHRzFp5og jiIVlwioSCRSKKGoL2Sff3HmNqqjXBSfth9r+uZSG4AqQ2P+SCQSyS1xnYn9l0/vzuDKmsqC8RWb LJ5NHz/JnxzIBweyWe/AV+JBybILa4zN5cDvwmJ9WeK/YpoH0akF17Y85e7ZXXdPoJfwXw41AqgE HakWmCTcOZiQu1sA/W7LqdbuUWviIrmQRCoeEVCRSKRQQg3LLL1o/H7grZ1n5aL49MZntdceDFIP FYlEIgWLpUirf8buvAJcscGB/BFefHBgdkY8Lpk/JXlMPBl5ms1vMchAi7mfzyII1urhuMU7teas ri2GW7bBXX9v7UOWlnuwGnrvi7rLrT2gRzETulxKIhWNCKhIJFIoMaDKPh9LRn6wb6s1jB4+dOme eRWTPdj3T1VD0wtoAdA9VCQSiRReDK8kX7FxBBZfyZuvxP1XrAtLoSwGWnPZCc5a47xHi+EWJy7k YRjcxdBrkpv3dJ282flfey/Kj4yuvtGp6msPAEW/2XDcHhb4xvbaj765XNfSYc5CYWrj4Ybqhkc0 EyypaEVARSKRQglFLLv0YmY++1HVNZRAuTRQ55s7Xl536I0dZ+xxI5uO3nx104lffHyk5dGAXInP SPHh11eHpxdQ8hlQycUkEolEiiaOV7L/SkUsPkRQjhK0QSudWQKizHLcksQ1n03OL4G78A9h0c11 4HLb9mNN8jOiqLVzaM3nZ//lL9WfHG48cbPzevuwGGQI193pO3Cl/YP9V19ed3DtnovDEyn5Hi99 feHOrtrvZjP84VdyGYlURCKgIpFIoYQahkqGetb8ZPh3W07KpT6aSKbf/aIOlfK7rgkUzg7+KEY+ ap/99+aTsTU7z208dD2VzmSyS7/fXtvwcGgsmZFXH+U2SCQSibQscayCOGIpf9qgpeAWnzqPm/9b GgAG7tpbd/ers7flRsMJ6f3PX19+Y8eZ0y09j4dnUQWQ/7vG2NjCp+PMbHihdSvX0YYnP//oyO4z vh8BoNpZ+x1ddCMVrQioSCRSKKEIo5DNLz5PzC7++Zur55t9O6laO4d+/Un1iZtdqKAomT3j6f4J 9ihG+w5pfnt0+uv673+7+eSumuaN3zbi1ck569kmhFQkEolUYLFUy+5HsljLtltIyWCqkzcef3q4 Qb4zhPpGp/59e+2Bq+1PRhhEIecj+Q9OsQfyDs+wEYb8ni45sLA3wVYAVv13ze01n5/1HFK+s6Z5 74V7M/NZ8B52kkQqNhFQkUiksGKVdek5Slr74DSKpecIDdRC0NR3XYmu0XTvxDzq5WgyAwabnMtO zfE7pGfZE1RAUD2J+VO3uv7pvf2tvVOorNjsos+zTUgkEom0KkJSBsM0PRwMPx1R52Di37bVXm8f 7hyd6xlPD0zOI+cj80+ns8n5bGqBDzJkYwvZPV3isVooAf2T7Frb2ds9/+HFVB99c+VE4+Pk/BID KqoTpOITARWJRAorFDEUs7mFJdS/Gw+Hfr+9NpNdkq9Z+vPXlw9da+8eY0V0dCYzNbeI8jm/yIbs Z7LsJmn27P+FJZBV90gKVPbp4YbPa75DraXxfiQSiVRsEkDV3p/41w3H5aJATSTTSOw3n4zxKrCA KjA5l03NsyqQYQ/kZc4693SxooDkD7hCFRiezvQm0udu97z7tzqtuADnLrX2EVCRilYEVCQSKaxQ xngn1YuZdHZ4JnOk4ZE2POPSne7//VU96ujg5MLE7GJqPotiicIJUsIbhfFvFNRnE7N4bzOfmuKN z063PBnCmniVKiWJRCIVj8R1tOGp9E/WVslF/gIFIbHX3e17Os6GJ7AqwC+oYQuiCogU79gqCuxO rcXn0+ksAKx/Yn7v3+9vO9ooN8r1z+sOtQ9OS6CSy0ikIhIBFYlEiiBUMhQ/FMjJuSzq5fl/9Px2 80l7JvQ3ttdebO0fmJxPzC7OsruHWaWUJZRL/PPB05E/7Dj9sHdULLx8t/v/7L+Mgop1xRISiUQi FYOQlLPPX4CL/n17rZ20/XTs6oMN3zY+HU+jOkzOsXEHZhXQJF7B/7DawuLz5Hx2PLU4MLnw6ian svSNTv36k+rhmQx2AztDdYJUhCKgIpFI0YRqtrjEBmmAmganFlo6x1H5Nh5uQK39+UdHeifYSL8U vyGKl1H5LqFEMv1x1ZU3d5xW77/KZJd+srZqei7Dn9goF5JIJBJp1YWUnF16Mbuw9OW5O18GTvSH TP6Lj4/c6ZlAXZjgo7g9q4CfsBbrqlpi8DaWzPz9Tu9bn8u7tg7W39t2vHk0mcFuUA8VqThFQEUi kaIJ5RE1EkyF2oaqidr5dJxN2ffyuoPwnrrWJ4PTcr4+vjLUOzJ17GrbH3df+NmHhy7f7ZYbUvTL j492D0+zSkm1kkQikYpGSMnPX/yQzizd7xn/TeBtVLVN7R8duN4/MT+eYiMUeD5nJUC+HEKSqbLP 2ajy6cy/bZN9Ym98VnulbSCRWsRu0HU3UnGKgIpEIkUWL7HsfmLBVM+mFnoT81WXvn9757mdNc2/ XH/0R+/s+fF7+9/edQ7/xb9f2Xh8V02z+jBfTW/tPHvj+wG6jYpEIpGKTUjLC2yY9+KvP6nuG52S Sw2990VdbUs3m7I1nc3IvqnIyVwwFR9Vvvh5zXdfX7gzkUy/vO7g4OTC1FwWu8Gv1JFIRScCKhKJ lI8EU2WXXsxlllDnRpOZmpud/7X3onyZD/9o7RzSZmry0++2nPxHxwhdfSSRSKRiE7hokT8w40xz l5rkVbGR23+q6h6bZf1I1giF/IR3orKk5pda+EPktx1r2nfxvvVoDYZpcj0SqZhEQEUikfIU6hqr fPxq4kw629Q++MZnp+VrEfXP6w51DM2AzahckkgkUlEJKRmZWTww438psxCpwsL/tenks6mFaat7 Sr4QXXgrPg5lZWJ28Ufv7MFm+xLzY8kMdmA5nEYiFVQEVCQSKX+xIR180lsUv7GZBXCR50PugyVm cBI3HFO9JJFIpKISkjwS80L2+dRctql96HdbTsoXFN1o631v99/ZjERxTMSH92eW2Czqv/joyMmb neA0Nt6PxoSTilgEVCQSablCgRMDQjYcvlHT2C6XhtaXZ2/vOv2P8dSivABJ5ZJEIpGKScjLSPKA JSDTXw421DQ+lC9Yqmvp+D/fXI1r3gi8e3HpRf2d7h+9s6fh+0FUB3w0jfcjFbMIqEgk0nKFEpfl E1Q8GZr57eaTE8m0fCGE+kan/temk2zk/eyinBuQKiaJRCIVk5CWkZxFJ1VvYu7tXedbO4fka1wA qj9/c21ydjGWfiS8+XH/+B92nP7lx0dbn45Np7NUHUhFLgIqEom0XKHKodSJIe81tzrX7vG+a9lU Jrv0++21Vx88kyPv6dm+JBKJVJRCns8+ZxfOxpKZB/1T/76tVn2cIPjq//3vs1NzDKiWmcXxQeMz c6ApbP8na6v6E7P4UN49JVcgkYpQBFQkEikGodQBh5LzS8MzmQ+/ubq/7o58wV+gqW3Hmj6vvd2T SIuR9zSig0QikYpTSM5I0OAl5PmRmUzDw6Hfb6+1Z1Hnk5sfEjNShMziWO9ux7Pk3IL6Bvx7KJF8 e9e5zsFEKp0BUE3wZwQv/74sEqmgIqAikUgxCKUONJTOsMdS9YzPba2+9YZSa4VAULvP3EbR/dE7 e+Bffnz0k8ON3WNp0T2FOk08RSKRSEUrkefnF9l0EUPTC02Ph/9tW6099g8p/cngdM6BBsjyBy/d e33rKVSBd3ad++naql+tP7q9uomR1Q8/fN8zipfERII32nrf//LvCQ5U1EFFKnIRUJFIpBiEGoly t7j0XAwI6UvM/72179VN7BEiotxOJNO/3Xxy+4nm3edbP9h/Fbh1+W43lhy+2s7qpZgYiiomiUQi FbGQpbNL7NrZ5Fz22dTC9wPJP/z1zMH61kx2aWdN8zcX7wO3+KQU3sm8d3TqzR2nvzp7W517fXgi VdvUzrDqWBMQy54qduPhBlEg6BGFpOIXARWJRIpHqHYoepnsCzEgpH9i/tFw6su6e2/sOCO6pOB/ em//f+29WNfSId6CGvzGZ6dbu0fFRU0CKhKJRCpmiTy9uPR8jjHVIpjq6Xh6S/Wt32yo3lXT/Pvt tQGPE0zMzL2+9dTD3lH5t6Ibbb3/uvH4v244rlaHX3x85OHgNMgtGNJIpGIQARWJRIpNKHcopQtZ NoX6WDIzOLXQk5jvHJ072vDkv3xmqmjtHFrz+VkCKhKJRCoJiVS9uPSCM1V2eDrTOzHf0jm+ds+l H72z5+Cl+1Mp121RQljy8TdXLt/tln9zgZqAUm/tPPvHL/9+t3usb3z2NxuOi3lij1198OmRRnu+ IioOpCIXARWJRIpTqJrPX/wApppFrZ1dHJnJDEzOb62+dejSPbmGWyioP35v//wiPYGKRCKRSkNI 1kjXwJx0ZgnAMzqTGZxc6J+Yv3y/H0z107VVf/ziQk1j+/e9o1iN+0X9na71VVfE2zsHE3UtHf+1 9+JP/lT17hcXzt3u6U3MYwvAp8NX2zcebgBT/fyjIx0jKVSQWJ4UTCIVWgRUJBIpZqHygamySy+A Scn5bCK1+Oeqa/ZADlM/WVs1MpXG+qxEk0gkEqnoxfI1H+Y9v8jm/Zvgl89AVt9cvLezprnl0cBn 1U1v7jgtBnu/svH4L9cfBWiJP1/ddHLd/qtHG558/yzZMTr3dDwNGANNDU8vPBlKMsr6Wx0oa2By Hpuly22kkhABFYlEil/ikiSwKpNl01R8zUusfM2t4YnULz4+MjW3mMmyOXmpbJJIJFJJiCds9hBC 5Pl0hk39B/5JpBY//fZGTWO7XImrb3QKQHXuu+6ByYXusTQgCu4aSwOl+ibmh6YXxpKZybns5Nwi kAxAtev0P3oT8/h3cj5LT6AilYQIqEgkUqGEIohSuJB9/mRw+jcbjmeyS/IFRQfrWz870cwvQ4pp 06lykkgkUskIKRuZO8tT/ewCG+k9OJn+YN+lnadcF9F+/N7+3sRc/8R8TyINWOqfXBicZF1S46nM 1FwWb0QJmJrL/GnPxZ+srbp4tw+UheVWXZAbIZGKVgRUJBKpgEIhzGTZlcuqS20ff3NFY6qWRwP/ tq2me2xWzONEQEUikUglJ5a4rSEJqYWl8RSb/e+r861v7TxrT4/+xmenrz0YxPKRmcxYMjMxu4i6 gJXnMkt41+LS82v3e17beupGWy+AqnskyR8/xZZTUSCVhAioSCRSAYVauLj0IsUnUv/yXOuvP6n+ 6uzty3e7v75w590v6t7aeb6tf8aex4nzFNVOEolEKj0hd4shCTPpLBJ+38T8+ds9r246+V97LwKT dtY0773QCkyamc/O8f4orJldejE9u1B/p+udXefW7avvG50Sg8BBXNgIFQVSCYmAikQiFVAohSix 6Qy7ZXlgcr65c3zHqe/e/6p+6/HmEzc7O0fZAHrUztTCEl2JJJFIpJKWYCrAkpj6D+m9eyx97EbH u19c+NE7e0BKO2ta9pz/x766O/vr7mzns1b8dG3V+qor4vnv0MH6e3892QLums1QUSCVkgioSCRS ASUuL/JOKvZkKjDV0/H5rtF011gahbZ/Yn5kJjMzn12ggfIkEolU+kIeRzJn/VTiaYSTC70JpP10 x2hqw6Ebr2899fWFO8K1Te3aQ36HJ1K//qS6NzEHoEpTUSCVlAioSCRSYYWKKOpran4JZXJ4mj1s hM+QmxlPLc6krbun5OokEolEKmEBg9j9VEsv2BwVc4ujyczQ9MLg1EJ/Yu7322v9HqEBuPrd5pN1 /+gR01GgZGAjRFSkUhEBFYlEKrhQEoFMi0sv0uyJJdnpNLMYSZ/J0lwUJBKJVFZCQkdeR86fX2RT /03NsenUx5KL3aOpj6qu/fGLOmCVmK9iIplueTSw/VjT61trb7QP9ybSALDU/BI9mZBUWiKgIpFI KyEURtFVhTIJiMossemb8CeN6SCRSKTyE+MhPvwPWLXAZ1SfTmfBVINTC2dauj/85uqrm07+6J09 L687+NbO81/W3escTfck2DOpQF/WpK9yUyRS8YuAikQirZBYdZVVlsGV/ad8mUQikUjlJZHqn/M7 adMZxlSjyUw/u5mW3UnbOTrXMSIf8tvLaWpyLptefJ6lYQukUhMBFYlEIpFIJBKpUGJ49OIHYNL8 IpusQjyoClgFiGIP+Z2Yx59jSfZkKtAUn9yPrrWRSkwEVCTScnX6dt+3N7rJ5PL209GkPONJpHLX 6HRaO//Jy/Thhq5vG7oON3QfvN5dda3r66td+6927bsi/fW1rm+udR1s6Dp0vfvbBr6ysQVy6boS ygcDqgd9k+QK9+Nn0+KEIOWh1//W+H99Wk8ml7cvtz2TZzyJVO5CWdTOf3IM3niR/+PS/7WJ+f/e VG/9g9lYjVw+roTywYBK+9rkCjSQQJwQpDxEQEWuBBNQkSpHBFQFdAAvbTSWkMvCBFTkSjEB1XJk A9Xn5x/urX+y95KnO/Ytw/sv5+mvPX3F052qvwnvqy5XxeED8DVPdy3HB01fj8eHAtzg5+6QPhzS NyJbG5Xh6bf3N4vTm4CKVDmygeq3u27sRVb3T+zLzO2wlrSjWk/vwnp6t51vnofdqR7W8nZUf3Ol Q2y56kqHf86H9Uwe1Xrah40cvhzrOV+1nvY169k+wHrC97OR50Nay/yxuKLKhwuo/lj1XSx+/0Ah fNv2/w7jgzH4TwXyofy9Npr/Eez3qr4TPz0B1XJkA9Xjganx6XnDC3BC84z0RC5PJjVnVE8Jpzw8 7elZ6RmXF1Unhed8nbKddnlWOuvheea5EE4LL3h6yfQ8nAnlBc2LAX6e8XTWw4sB5lPDa85Ks+nj Pfxc91IYv2B+rvsHb//AzOZXDOe/nnsoTm8CKlLlyAYqNGmMlG7bSOywldvzSu9w2AwP6+ld2Ery y8zzsF+qh2PJ9nBgwof1hA+znJ932of1bK/6uW/yh43kD+s5X7OR/+EcJQDOrwrA3oUANqqA7Yjl IKorqny4gMpMFnq+CJEm/FKDX17wywVBWcAIe9gz8n1j3ohqzT5Bnk9gh4hknxgOGbfhY9UI0aHJ OfHTE1AtR/5AFYRSwXEEu0MJdqJJOD+UyhFcgSXWM8qEVwelckWfsCsGYT0AVfsXVHc8wnokqnZH pXDUOuqqlH6OhFKwUfBymoCKVIHKBVTLyu2wkd5hrwwfKcnDHklez/NwhFRvZPsglIJjoyk94QuH Ryk4SuaHIyR/YT3tqzbyP5y7BMB5VAG4+FBKmIBK5gvPTKElBdUBqSEUSsF6LjBSgBH2cGDYe0S7 FtKmfSI8cmCHi2QjdOGQcesdrkZ8wj4hSkAVi7yAKl6Ugo2AilRoPaqsK7jggtRXI7j8XFooBevB aNuISrhIUCq/8klARapA+QOVV26Hw+V24eD0Di8HpXLn+XxTPbzKKBUu7cN65of1hK+64CgFR60C sJ7z/Ry1FsBGni+QCagiZ4qA7JAvSrkSQUAK8Ix8P5TKGe0FQSlYj15hI3ThkHHrHatGfAr7xycB VSwygMqIIDh0uQ2IJhlQkQqtR2S5gis4vmAnxNxRZgWaT30tTMdU/igF6wFoOyaUgo3AhONHKViv ncJG1RRe3pVIAipSBcoLqHKgVF7pHQ6b4WE9vQtbSX45eR4OSPVwLNkeDkz4sJ7z4dVBKdhI/rCe 81UbyV+42FBqxWgKrmSgMvJFrjQRkBo884KeCGCPRBAqBXhGvnfMh0QpjyDPJ7BDRLJXDIeP2/Cx mis+CahikQJU0x4VN/9a60STX0AJ6zEl7F1lneAKji9hzyjzDTThwqAUnH9N1QNQtRGJwkY8wnok qnZHpXCOOqqEp7AWnt4u/Bg/zQRUpAqUAVQFH+MXkOFhPb0Leyf5yHkedlJ9pGwPG4k9wGWLUrCR /+EcJQDOrwrAxTrGT3PlApVnptCSgmq/1OCXF/xyQVAWMMIeDgz7yNHu36qLHNjhItkIXThk6HqH qxGicLgQJaCKRSpQeQZRcBzB7lCCnWgSjh2l4PxQCl4dlMoVfcKuGIT16FMdU8eUEZVw1DqqBaa3 V2qMn2YCKlIFyg1USlYXDp3bYSO9w14ZPlKShz2SvE+eD5nqjWyfE6XC01TUnA+HT/twlMwPR0v+ sJ72VRv5H85dAuA8qoCwXgWEjRJgezVQSrjigSpEmghIDaFQCg5s8AXEv3/Ye0S7FtKmw6AUHA2l YD16hY3QhUPGrXe4GvEpHDpEh6YIqGKQN1CFK7fuUBI2AipSoQ1RZYNLrFNcvQPNp74aweXn8kEp 2AhMuGxQSpiAilSBUoHKyepRcrtwcHqHl4NS7jzvSvLwclAKDs72xYtSsJ7wVRccpeDcNOWuArCe 8/1c9GP8NFc2UOXKFAHZITaU8kkBnpHvh1I5o73EUconVsPHJw/LYQKqOKQDVehyGxBNMqAiFVqP yHIFV3B8CXtGmRVoyy2uUStrnigF6wFoewVQyic2YSU8c0eobb12ChtVU7gAtZOAilSB8gYqK7fn ld7hsBke1tO7sJXkl5nnYb9UD68ISsF6wodXB6VgI/nDes7XbOR/OEcJgN1VANYTvp9LZIyf5goG qlxpwi81eOYFPRHAHokgVArwjHzfmDeiWrNPkOcT2CEi2SeGQ8Zt+FiNFJ9WKBJQxSIHqAanQ5Zb dyjBTjT5BZSwHlPC3lXWCa7g+BL2jLKgQIMLilK5ok/YFYOwHoCqjTAUdgejsB6Jqt1RKZyjjirh KayHpKejd0xpxSwWE1CRKlA6UFmJPWduh430DrsyPFwglIIjoFSkbA8biT3ABUUpOErmh420b9tI /rCe8zUb+R/OUQKE86gCcGmilHDlApWWFFQHpAbPvKDnAjhna88Iezgw7CNHu3+rLnJgh4tkI3Th kKHrHa5GfMKRQtQdkARUsUgDKi12NLtDCXZFExw7SsFhUSpkoMGlhlLx0JQRlXDuOhopQoWjo1Th yicBFakC5QKq0CgFh8rwkZI87JHkffL8slK9T7aHY+uY0hO+cPi0D0fJ/PCKjfEzMr/qPKqAsF4F hI0SYLtoUEqYgMrlgNQQCaXcucCdAoywF/aMfD+UyhntYVAKjoZSsB69wkbowiHjNlKshg9Rjyba D8NTafHTE1AtRzZQPRmc1sJHszuaYCOgIhXaEFU2uMQ6IeaOMivQfOqrEVx+XiGUgvUAtL0CY/yM qLSthGfuCBUuJpQSJqAiVaBMoNKSueng9A4vB6Xced6V5OHloBQcnO1jQilYz/nwslAK1hO+6hVD qQhVANZzvp+j1gK4yGgKJqDKnR1iQymfFOAZ+d4xv4IoBYeIZK8YDhm3kWI1fHx6oZQwAVUsCgNU AdEkAypSofWILFdwBceXsGeU+QaacEE7poxw87QrBmE9AG2vAEr5xCashKewHpWe1uNUWKmXqleq dhJQkSpQKlBpydy0kd7hsBke1tO7sJXkl5nnYb9UD8eS7eGSQSnYSP6wnvM1G/kfzlEC4PyqAOyN UrBRBWwXH0oJE1CZCSJ3XvDLBZ5ZICAFeEa+b8wbUa3ZJ8jzCewQkewTwyHjNnysRorPwIAkoIpF wUDlDiXYiSbh/FDKL7iC40vYM8qEVwelckWfsCsGYT0AVYcKRmE9ElW7o1I4ah3VQ9LT0TumtLpV OBNQkSpQIYHKSO9w2AwP6+ndtkeS1/M8HCHVG9k+CKXg2GhKT/jC4VEKjpL5YSPt2zaSP6znfM1G /odzlwA4jyoAlxFKCVc6UAWkhlAoBeds7RlhDweGvUe0ayGt2T/CjajOFdjhItkIXThk6HqHqxGf cKQQ1QMS1kORgCoW+QGVO5SEjYAKGVOwVWIDggsuSH014svTUcvqiqIUbMQjrAejbSMq4SJBqRUu nyVREWdmZgZIJaKh4SH5sxWxwgBVcHqH/TI8rKd32+HzfL6pHl5llAqX9uEomR+OlvxhPe2rNvK/ cNQqAOs5389RawFspOtic+UCVUBqiIRSfokgIP49I98PpULRlB7bsFdgGwGsOlwwG6ELh4xb71g1 4lM4fHx6hKURh/APPwxPE1DFIE+gckcTbARUpELrEVmu4JLxFSbE3FFmBZpPfY3UMaVHnLAed3D+ KAXrAWg7JpSCjcCE40cpWI9T2IhT26t0JbL4K+KLH140375ZdXnHnosbycXv67euTE9P42SXv19R KhiojPQOh83wsJ7eha0kv5w8DwekejiWbA8HohSs53x4WSgF6wlftX/yh43kD+s5X7WR/IWLDaVW pRxENQGVKzV45gU9EcAeiSBUCvCMfO+YX0GUgkNEslcMh4zbSLEaPj5Do5QIxRECqjikAZUSR8JO NPkFlLAeU8LxllglynwDTTgSSvlWVj304Pxrqh6Aqo1IFDbiEdaDUbURmHCOOqqEp7AelZ6OVEFX tXYWeUUETT1/8RxA9V81v3j7xI/Jxe/6m2cmpiYQBPz8KlL5AZWR3uGwGR7W07uwleSXmedhv1QP x5Lt4XJGKdjI/3COEgDnVwVg70IAG1XAdomglHCFA1XuvOCXC4KygBH2sGfk+8a8EdWa/YM8cmCH iGSfGA4Zt97haoQoHClEQwakcq4TUMUiG6g6nk0HFFo4P5TKEVyBJdYzyoRXB6VyRZ+wKwZhPQBV x9QxZUQlHLWO6iHp6agXI5WAXRUXO1C9wA+x2Hy7iYCqVHzx5umxieHFpQxIWP6KxScTqNy5Xdgr w0dK8rBHktfzPBwh1RvZPgil4NhoSk/4wuHTPhwl88PRkj+sp33VRv6Hc5cAOI8qAJc7SglXMlC5 80KYjKDnAiMFGGEPB4a9R7RrIW06DErBcaAUbIQuHDJuvcPViE84UojqAQkboQgb5zoBVSzyASon mmRARSq0IapsQeqrEVx+JpSKEKHC0VGqGMpnkVdENMrRNL9FQFU6BlANjw8uLKZ5TOAUK0ZpQKUk dmFXeoeXg1LuPO9K8vByUAouVZSC9YSvuuAoBUetArCe8/0ctRbAJUhTcKUDVb4o5UoEASnAM/L9 UCpntBcEpWA9eoWN0IVDxq13rBrxKRw+Pj3C0ohD2CcUCahikQFUyyu0HpHlCq7g+IKdEHNHmRVo PvW1MB1T+aMUrAeg7ZhQCjYCE44fpWA9ToWNUBUuptpZ/ECVyc7f+o6AqmR88Wbts7E+5BLE2Qt2 ihWjbKB6/8B3bpSKkOFhPb0LW0l+OXle2C/Vw7Fkezgw4cN6zodXB6VgI/nDes5XbSR/4RVHKdhd AlSXJkoJVy5QeeYFPRHAHokgVArwjHzvmA+JUh5Bnk9gh4hknxgOGbfhYzV8fIZEKdg4xW0TUMUi BahmQhZaPaaEvausE1zB8SXsGWW+gSZcGJSCw5dVVwzCegCqNsJQ2B2MwnokqnZHpXCOOqqEp7Ae lZ6O3jGlxenqugSAaomAqpQMoBoEUC3OItRKDaic9B6c4WE9vQt7J3k9z8MRUCpStoeNxB7gskUp 2Mj/cI4SIJxHFYArDKWEKxiocmaEMK09I+zhwLCPHO3+rbrIgR0uko3QhUOGrne4GvEJRwpRPSBh IxRh4+TWTEAVizyBKnaUgvNDKbhsUCoemjKiEs5dRyNFqHB0lCrC8klARY7XpQlUDkcJR75eBnsk eZ88HzLVG9k+J0qFp6moOR8On/bhKJkfjpb8YT3tqzbyv3ChUArWq4CwO/+rLn2UEiag8skIgQ2+ gPj3D3uPaNdC2nQYlIKjoRSsR6+wEbpwyLiNFKvhQ1QPSNgIRdg4rT1NQBWLNKCKXGhDVNngEusU V+9A86mvRnD5uXxQCjYCEyaUCjABFTlelyBQxYZS7jzvSvLwclAKDs72xYtSsJ7wVa8YSkWoArCe 8/0ctRbA5UJTcKUDlZ4I4MBEEJACPCPfO+ZDjvHTYxv2CmwjgFWHi2SvGA4Zt5FiNXx8eoSlEYdw lFAkoIpFNlB1PptZYZSCPaPMN9CEC9oxZUScp8OFIbwCKOUTm7ASnrkj1LYep8JGqAoXfe0koCLH 69IFqgCUgvX0Lmwl+WXmedgv1cOxZHs4MOHDesKHVwelYCP5w3rO12zkfzhHCYDdVQDWE76fK3KM n+bKBSo9EcAeiSBUCvCMfN+YN6Jas0+Q5xPYISLZJ4ZDxm34WI0UnyED0jibg01AFYscoBqa0Uos rMeUsHeVdYIrOL6EPaNMeHVQKlf0CbtiENYDULURhsLuYBTWI1G1OyqFo9ZRPSQ9Hb1jSgvJIjQB FTlelyhQFQil4AgoZWT7IJSCjcQe4Kg5Hw6PUnCUzA8bad+2kfxhPedrNvI/nLsEwHlUAZhQyjIB lSsd+GWBSChlhX3kaPePcCOqcwV2uEg2QhcOGbre4WrEJxwpRPWAhI1QhI3zOIwJqGKRH1DpASXs XWVdwQWHRSnvQPOOtdJCqXhoyohKuEhQqlTKJwEVOV6XHFAFdEzp6d22R5L3yfOxp3rh2Dqm9IQv HD7tw1EyPxwt+cN62ldt5H/hQqEUrFcBYXf+12xk3bIxAZVnLnCnACPshT0jP+/mXRiUgqOhFKxH r7ARunDIuI0Uq+FDtABj/DQTUMUiT6Byokl1iCobXGKdEHNHmRVoPvXVCC4/rxBKwXoA2l6BMX5G VNpWwjN3hAqXL0oJE1CR43XpAZVCULb13G7bSvLuPO9K8vByUAoOzvYxoRSs53x4WSgF6wlf9Yqh VIQqAOs5389RawFcauUgqisbqAITQUAK8Ix875hfQZSCQ0SyVwyHjNtIsRo+PguPUsIEVLFIAypX cbXtEVmu4AqOL2HPKPMNNOGCdkwZ4eZpVwzCegCqNiJR2IhHWA9G1UZgwjnqqBKewnpUelqPU2Ej VIVLs3YSUJHjdRkAlZ7eha0kv8w8D/ulejiWbA+XDErBRvKH9Zyv2cj/cI4SAOdXBWBvlILdJUB1 uaOUcAUDlZ4IQqUAz8j3jXkjqjX7BHk+gR0ikn1iOGTcho/VSPEZMiCNEzcPE1DFIhuouoZm9BIL e1dZJ7iC40vYM8qEVwelckWfsCsGYT0AVQcHY7KnvftIza01n9avuZHUI1H1UrK3vftoLV+zMemO zdTRvexnWtOYCojQUEEKR++Y0qKvVExARY7XJQ1Uenq37ZHk9TwPR0j1RrYPQik4NprSE75weJSC o2R+2Ej7tpWWmGo97at2N8yEg5pntkNVgVTf4+5jtbfe+rT+raYUWxKEUrP9j59Wy5Vn1VqQZzlI zDbfbNu+t/6lT9uatZeK1RUNVJ5ZIBJKWWHvEe1aSGv2j/DIgR0uko3QhUPGrXe4GvEJhwpRy3pA wlYEqjZO2bxNQBWLfIEqBErBBamvRnx5OmpZDUaphhqZSUy/9OmtNXvvH3k4Y4QhnHOYR/LIXgZI YlO+QMUiMXlUXbMx6a6jXkAVKUKFo6NU6dIUTEBFjtclClSu3K46fJ7PN9XDUVGq89nQt6du/oeV DOH/2HP/2+tDXUj4Dzq/HdayvbCe8IWD075m1uh6eN/+UNtrbrDkfyNHjWg78jDpTv669bSv2t0q s52bptxVANZzvnTq2F5GR2KHGVAF1YLZatfKFlAZCTasE0/f2ntLbI2AqjjlAiozEQTEv2fk+6FU KJrSYxv2CmwjgFW7UArWm27C7kabcMi49Y5VIz6Fc8enZY+wFDHpdtwtMwKqWOQNVB4l1hVcMr7C hJg7yqxA86mvMXRM6XEHh6+pTx/eF0jzUs3wUxmGM87CvfdvKJGYC6VUD2/lW/AGKldUWmsyoDKi 0rYSnrkj1LYep8JGqAqXOEoJE1CR43UpApWT2FV7o1S0PA8HpHo4eraf+XYP2/P/ONV5/dmMvbDr QecWvhze8lDL+bCe8+HIKOV45kaNbP2vQSFwcj6zWiN6ZM5P9jxss2pEW6Oe/Jn1nK/alf8dx4dS qke28f0EUIUoBKPb5cqzsZSDgZvsqBJQFac0oAqVAjwj3zvmVxClYFc8uwPYslcDLmTcRorV8PG5 SiglTEAVi3Sg8q6yTnAFx5ewZ5T5BppwDCgF66EHR6ypM0d42UaxdEXfcJdVL7t4fTUiUdiIR5jH YFL2L2lAZQQmgEoUPI+hfcJKeArrUenpSB1TZYFSwgRU5HhdckDlgihh7yQfOc/DfqkezifbPxva zHf7P67bKMVsJXzJWm6g0hM+vAyU4kaGt/qptj5UqgDP/AuLySM8maNGuJL/cLdVI7p79Pzvbz3/ MxcGpbhfpI7xnTeAyl0CpC2gujmrJtX8/aSNHR8CqqKUN1DFgFKwEsye9m/VRQ5sPZI9HHyHhmM9 VoW9w9UIUThSiLqi0S8gC9gyI6CKRS6gKhhKwauDUrmiT1iJQR+gUsZ7AIr0SBQ24hG2wtAAKiMq YR6YgUAVKUKFK2yMn2YCKnK8LnmgCoFScIRUb2T7IJSCfRO+pKmXTg3ZC42cP7TFASo94QuHT/uw kvm57YTvDVSiJeYFVDzbN6o1wpX/vWzkfzg3SsF5VAFYFoJUtQ5U7vyv+gcCqgoGqoD49w97j2i3 g9nPYVAKjoZSsBO3qq2IVa202IT1WBX2DlcjPuFIISrjULURirBxdsZrAqpYpAFVQJUtSH01gsvP hUcpEYMzdrHUI/EhKwbspb3d1kgP33iE3cHoBirvwBSxKYdk6EAVKUKFKxulhAmoyPG6hIHKQil3 nncleXg5KAUHZ/uAhH/9FM+un96/zv80UEq6q+HmfzTMaAlfeFkoBbuyvQZU6kVtN1Cpab/dqRG9 rvzvtpH/hXPTlLsKwHrO97NTC1Sgcud/zawcEFBVKlD5pQDPyPdDqZzNuxJHKZ9YDR+fHk00Iw7h FWmZEVDFIhuouodm/KpscIl1QswdZVag5VNcVftVVm499OA8UQpmQecJVLyaegKVEY+wHozMFlBZ c/epdgemAVRKeOaOUNt6nAoboSpcjiglTEBFjtclCVTeKBUtzwv7pXp4Wdn+WaeYguKlU0OBCR8e /tYAqjhRStgBKnN8kAJUWvLPCVRG8hdeEZQStoFKmbhPs1MOCKgqFqjCRb5vzGvhbdgnyF1RDYcJ 7ByRzBxqjJ8eq7bDx2r4+AyJUrBxUhbIBFSxyACqaCXWM8qCAg0uKErlij5hVwzCTuiZQGVFnwuo 5NQRws4AD6ugwigbTU5UuoCqt926g/nTW9vatcknFKBywpNNd3tUne7W5dRN/pL43Lf2tt1MaKEK G3Fq24iscjIBFTlelx5QhUApOAJKRcr2sJHYTXdevyl2eMsDLc+r1hM+7OT84WHxaAqxnTU1XQ3D rpwPi2zPZpWw5rdABt56Q592glkBKqcBJu0LVHb+9wYqd8NMODs6LJ6TId64pra7adQpB33tI/Ip Gk28HIyPbONz5bHC4VkImtrsQoB13qod6dcLgQuo+h/L9bHy9sfmzBP+QJUYFTOqi896q/Zpc8K9 AvfAk7a3xLHC9rERAqoili9QBYZ95Gj3b9X5BLa/nQYcrAWwYy16ud1xC+uxKmyGawiUgo3IdFuP SdjdJhM2TseCmoAqFilAlYxUYv2iDC5NlBJWgcp1XaPnhjXvk4VPmRFn7j41JHv5mg5QsUh0gKqp Vm7H9praESU2LaASFZQ5dVSb7laNzfFuvPRS7Ugfj9O+x6Ji3ap2mMqIU9vl2zFlm4CKHK9LEahy o1TIVG9k+5woFS7hy9kmXvr0Zp5TorNJg25teTjDk/xMA5+jD2nwiMJUPOGzW2Rf+vT+jWGZ7cVs fsoSy9blMw+gYk/C4HvrBio788NyaLdtd6vMdna0G7u9rV0MRkiJ0oDdPsqZCn86oIVywFO9+FPY XQvkbBPbHvOFiRHBQigN7mbbrA1Ut4xK9FbtqJo8fYEq8fQtANITsXC22drtahdTYTlfqKwmZk4n oCpOeQOVf9jnE+1hUAqOhlKwGrqOjdCFlYgVdgWqbTNW/VAKLgBKrXzLjIAqFnkCVXCJdYqrd6D5 1FcjuPy8Sigl7ACVKwztGZw+VWfFlZVVL5/8OqUEKhmPEqhQYNbUDvfx2Oxrl9uEt7Xb4akDlRWM crm7iLKFL+3t7jOGyPM6asSp7QpAKWECKnK8LjmgKhBKwcHZPkrCZ1NNsKz16f3rIXI+7E77w3ym CvtP2JpbaE9Xl5Lzb9SwDAzKUnO+mG2IMZVc4hrg7QIqd9q3gUqm/RGnRjhjE5QmmWrePGPzDymZ H5YPG2QpXbbQrHJQ28aGHozztD8uF4rVZC0Ql9KUWtDfJOnllqvZJoEKxwH41M8X9j8BILGF8PYn av70BCq20L2atc29TweshQM3b5mIZX00AVUxSgcqz8j3jvkVRCnYjmdmJZIVe43xk9HrWIaoZu9Y ZS02D1scpTTUfFxMt0t5moAqFmlAFaHEKlHmG2jCBe2YMsLN064YhPUAtO0Uy55hGYk9D+1KeWtr uxqS7qkmbNtA5USl00Plik12hZJvGYVQhqcDVO6Q9ACqPl4yscQVp3wUh+8Q+YpBKWECKnK8Llmg ioZSsF+qh2PJ9rBM+MPWDVQ6UFmp3hqApxopWuT2rga03e83KNkeFg9ql/gkcj7fiPXcC8XWIzGQ xp1mmAlUStq3a0TviMz5vdbVMVEjZCFw8r9ju3nW14jdRo1QmmesV0pu5Oi4KAcWYokxCO7Mj7ff tJbcFG/c2+2M8XNGK6glwOmhcpUD1ukktuBAkSdQcVLSiajZ2m1JUHxrL+n9XfQcqqKWC6jMyPeN eSOqNfu06pxmnLD7Gom3nQYcrIWxdPHdLgXbMSmtBqRi4/xbSRNQxSIbqJ4OJfNDKXh1UCpX9Am7 YhDWA1A1Qs8qlntvbd3rjLhAqVhT0904ooVkHkClT4ZuVdC2JhmeHuDEbS5nYzx4DQsXrbARRGVv AipyvC5BoHKhFBwBpYxsH4RScB40xTK83UNlD/nTEz7c9dB6GKBrLJ/sjPIzm6aPZ37ZE2VO32qP SlBnG1KBSmmJcQfViCaBWE7md+xunklS8vO2x6Kp5jw2SqkFVn+UDVQv2BJ+HU25uBYMVDfZHVNq qrSgSKUdE6jk2/0seq7EpvSBgjDdQ1XEcgOVR9h7RLsW0pr9W3WuwI4JpWArelXr0as01FR7h6vT UHOsoBQP0UDb0ehYjUbLxpm38iagikUOUA0ntbJqO8/6asSXp/2DDnbFnXCBUMoKRmU4h088wlYY GkAlgtENVDwwfYEqK1e2L0mGAyrWgcxGybuByohT2xXWMWWbgIocr0sNqG7rKBXyqpmR6uECoJSw ClR6whfmad81kM/K82y8n9ZD5ZX5JTWtuTHjzvzw86fyrldwmtUMs4HKNSRBWCZz1AirECi22mOa jeYZy+e8RlhLvNtpIYDKHEyUSN2yZowIACo1TzJL2rF6mZhNoGJLchGR/Aj3sEBuAqoiljdQ+aFU KJpyIty2V2AroWvaK5hNW3GrWo9bI1aFc8eqYo8Q9XHRj/HTTEAVi4KBKqC+BqNUyOK6QigF6wFo W+siVoDKiEfYHYxuoLJDUgEqKzbl9UiPp0tZ1xEBVDwSQwCVDE8VqIw4tV2pKCVMQEWO1yUKVHGg 1HKzPWyglLR4CBVsPmNKSfu5gUpP+7DM83ICIXcPlUz+YsIhF1DxHA5rQKWmfR2o7Pxv2xrRrdqC KAWolEaasJL2cwGV01pj7k+MbOfDFrY3jfZ79lBZtFNIoJLvIqAqLelA5R3zK4hSsFcka6bbpeIx AVUsCgAqv/oaS3H1q6zceujBIVEKdsUgrAegaiMSA6bE9bDd7+R+upQLqEQ8GkBlh6d6rZE5N1BZ QSrncaLbpQJMQEWO1yUHVDlRCvZL9XAs2R4OTPhZ+y4pBktqznelfV+gwkJ7aJ9P5teAytUMs4Cq rVEsQcI3gMpM+y6gUvO/ZfsWWdW8LqAEyHwuhvbZdud8OAdQ8QknhFmvFFvTmmpCH/Iny0FOoFJp xxuosMQDlhyb77JMQFXEcgGVd8wbUa3ZJ8idZpywEdge9o9k214oBSuNNnfcuq3FqrRorrmtxKdX iLrtBKSw1RrTbJxqq24CqljkCVS56qsRaHBBUSpX9Am7YhDWA1C1TzB6AZUeiY69gcoaxScKp7Ab qNQIFWXPma/JB6hemEBlTei396msoIr7b7YpFxor1wRU5HhdWkD1vwVQKeyk2Un1RrYPQik4NpoS eV7OnA5veWilfXd69wEqayFIycz8D+/bc/ops/npyV8C1d7uHrsl5gYqz7QvgUrJ/LaDmmfSzmwT ohC4sv3jtmNywIIBVOLytwFUt8QdULWjThVQgcpJibmAKsekFPLt5oQTzE9E0bHWcW1KrsCWE1AV pTSg0qNdC2nTPhEum3G240Ap2BXA0nb0WnbHrWXvcNXik1ttqInwC7AVioqtUFRtnGRFYgKqWKQB VZ711QguPxcxSokY1IFKD0bbLBKtylo7rATmc+txIl5A5TxdSkaomJ1p22M7MA2gkh3Idn+UACoW m2JiXHj7Y1fA8nEdRjGrSBNQrZDr36h6dPN+Esf8ZpX2Unm59IDKgCjhgFQPryBKWR7uknP98U4q LcNzewAVsr0gJVh2UjmpfubIXnsy9KBn9TbyLbhG9ylApWd+G6istK85N03x5C+mI4KV5C8MiLIH LLiByh5M5AIqpBGr40gtBApQKSnRF6jETBLuriePviaxmrEmjC1LUrLX0T6FZvkrZvkAVYhoLwhK wXbouqxHL7Mdt5aNoOX2jlUjPoXdDbUgl+YYP80EVLHIBqqe4aRffQ1GqZDF1b+y6nEH549SsB6A toNRStgCKs9H3du24tGZ5badz4c+OnK0tu1oo6xk4vmM3DpQyUi0HsvrxKYGVE6EqkBlRag9163r OfezzTdveVyArEiXN1BtbjlyPzlgfdmB4eTNiy1vsOWPbl6s11cuoOuPDDu7EQRUmx/Zq+Vy8shm 4+2WGbwpn4iVB4YHj1Sxr/xG1aDHd4/xQJUBUDl53kj1cCzZHg5EKVjP+fD8w/tyHj9XH5RtF1A5 Cd+a9xxpcOuNYWtWdPbQ3jXOHVNI/k5ud2bzY2ajAV3dU3AYoEKNUNpmcEiUkh53Zlrf1mTPip66 WXvrLaciKOXAqQUqUIla4AVUsjuIAdXAk7ZqyT8+QOU90bnX4D216NwctS7b8ef22m+31uHvlesM 3GzbLh/sqzFe8bqygSpelMrVnnPiGZZBq9mrAacGLbcRrtzuQIWDYlWJUisOfVwWKCVMQBWLdKAq QHENrKx66MEhUQp2xSCsB6BqIxKF3cHYozxO5Kj1jBGXtcA0RsmzBzVaxRgbWSMf0Sifgg+vsZ4o 0veY0RRqp/sBI9Z7+SMa7Tjtd5a7B/jx2XLFS7Y9xlpUqssYqKoGGSEMD262wOONzS3ADPHFB1YU qLgtWArRQwUAEz+QJzXVb76Ib+ENVOAl/inJgfstbzgr1LPlcpvGd4/3QJU6UOWJUrCR2AMcGaXs tD88vEVQ06e3tjycsbGqa3j4SI2VQhuU0X3CFompfkl2T6nNsOGtFgs1ivknRoZBWS/tVR/Xjjyf bLI/q2ZYu7KmPnLq6KgsBNFQipslfO/s7Txdqo+Dk1h4y5nNVQ72hu0baOWQPyAWG+A323+z7S1O L8IKKTHyEQvBPxJ1+IN97T9tA4Hk27WC8sR7t139TsY6bCOc8di/P731VikUqQoGKiOkNfu36nwC 29+uSHY12mz7XAtXglZYDVTHaovNCVcjRGEzRAOstM+4lWaZauOsKk4TUMUiB6hGkl711SircEFR Klf0CbtiENYDUHWYjik56sO0PiW62wjMvvY2WV/3tskuKQ5Ua2q7j7anOE1ZHh85Zs1mC/Mn36s3 SsnRHaq3P0acOuVTWa4EbGJUXPmDX9qrXjUkly1QSXoZ3KwtBy0wGlkNoHq75SY/5mGG/ImdDOiG 2nzf4yXrXQ4auV2/+T7bAdd3j/1AlS5QOShl0FROlApPU1FzPmymfYFPazhZCbOLU3vuH3k489Qv 8yvExVauEV1VZvJPNt5oW2NlVPYsqfak2jclphTSLKqAPUhPM39cu7thplmtAk7C5+ZFQWyHYYZz fc2jHLDhCRZi2bYusc1W26QEtmFdQKgL/E+DlF4kRrGyWomaE9qIBtmRpdo1xo9vQSznu+1VdFhh ku99q5bjEwcq/Lv6yWxJFKnKBSotqjWHQSk4GkrBdjC7rAUwtxOxst9Zs3aDY2+jPFmdFWpHAqLU FaKmdZSClQaZbeN8KmYTUMUiT6AKqq9GcPm5VFDKtgQnTysQJRz1kqQekp726ECGjTi1XQo9yavr MgUqD3JwzPp/Sh2osIK2nZxv4eZ9X/db7CXxH6hSBKoAlIKDs/0Ko1SA9cwP6wlfdbTkD+s5X7WR /4WjVgFYz/l+jloLYCoHcZuASncxoZQ0D9Fkk3VFXPYpe8WquPgNlOrzj1I9DjWX0Rg/zQRUsUgD qliKa9TKmidKwXoA2i4gSsE56qgSnrkj1LYep8JGqApT7Qzn8gQqa8icQg4uVw2WOlDptm++8vvK tqsGlXUKcKBKDqhWG6VgPeHDq4NSsJH8YT3nazbyP7ziKAW7S4BqKgeFMQFVziDPJ7BDRLJPDAfE rXrXo2+sslsS2V0ZXlGqx6HpkAFpnEYlYQKqnFpcegHLP3ykAtXqoFSu6BN2xSCsB6BqIwyF3cEo 7ApJze6oFM5RR5XwFNZD0tPRO6bUQCAHuLyByo9eVnpSCuECApXoaAq3fv2R+4/YhBPi37EfqFIF qvAoBRuJPcDFhFKwkfZtG8kf1nO+ZiP/wzlKgHAeVQAmlCoyE1BZEe4d5JEDO1wkG6EL5wxdH6By x6oCVJFCVA9I2AhF2DiBSsgEVDk1llz8w8EndQ8Sc5kluciQAlQpvazCpYZS8dCUEo+2c9fRSBEq HB2lqHxGcnkClQ0kzANiwrrcrt980Zm54QdrWjzpzS3y1WFBI/WbrWnxBhw+cVud2oGtExNQbX50 RN+C3LK1bxGc14EK9OoCVUvvxcP/2DoxNyL/9pELqCKiVHiaiprz4fBpH46S+eEVG+NnZH7VeVQB Yb0KCLvzv2qqBYU3AVUolIKjoRSsR6+wEbpwyLg1gMorVi2gCh+iekDCRijCpR+NBFQ5BaD6l68e wq9/8/jEnTFPrAoCKqV2Brt8UAp2V1BhQqkSdZkCldr3wqzRkYfZ+mxmPP6nNVeedQeRMkUehxb3 xuVCdWtsC1huIwqfZE8C2HKBqmpQ3wL/LOac4/08HPVA5fKqA5XYjWCscoDqoAuogmiqLMf4GZlf WM/5qo3kLxz1ghqs53w/R60FMJWDFXFFA1VcKAWHiGSvGA4ZtyJEFaDyj1UOVI/DxadHWBpxCJdL KBJQ5ZQNVCpWTaez8mUub6AqaMeUEW6edsUgrAeg7RVAKc/Y5HZXUFiPSk/rcSpshKow1c5luGyB Cq4/wh+k61iZGVwzGzLnphETaeSwuuHBm8PJm5I65Lx5OvnwO5q0u4/svqBlARXr9dK34PQy5QNU cIQDldtFAlTCflhlAlXFoRRsJH9Yz/majfwP5ygBcH5VAKYxfsXtygUqryDPJ7BDRLJPDIeMWztQ LaDaxoDKCFGYRaYEKj0On6fsqTbfqu2+Oc4eX1PtPKaAB6Q2M2btU/6AAnGizA48ebqdv8qmwkw8 tabXfFpCEy4TUOWUBlTCr+5rP3ALB09ilQ5UpTbGTw9DYXcwCuuRqNqOSsVR66gRpF6O3jGlnfbk SC5noGK2+5ps291Qjjn/+HX72FxkcYsbNqzZIJS3iz4fYyJyjzV97TCSl/2AajkzbYQ6UGFcVEAl bGKVClRBKAWvwBg/d3oPcJTMDxtp37aR/GE952s28j+cuwTAeVQBmFCqFFzBQBUY3jGhFGyELhwy dLVwdYAqIEQ9gYotZFP/iT8TI8Chl9jDp5WYZE+qvrX9sXjo2+wtTl98HZwlo9V7HdDaftN5pvVL e5+6Hs1W3C5voOocTbcPzcJah9Li0guxHAYvyaVcWPP0vfETd8ZgvF0s1GjKto1VLqAyKqiniwSl 4qEpLSq5iwSlqHwu3+UOVNz85ijXF3f1/ATTi93tI1fTR/cZd0YJEvO4nSmOe6g2s40UAqi4cxyo UC5CoBJWscoNVAZECa8ASoVL+3CUzA9HS/6wnvZVG/lfOGoVgPWc7+eotQBWT1rySpmAyiO8o6EU rEevsBG6cMi49YxVP6ByxacHUPU13QIaHRtXw3JkuwQqEX6j29VHf7KWmXxMm/PEa0ZcfImkrNKz DVSv7rwBung2tSBOCyEVPGy6EAKH2OBxqX1SvbMIa4rlMNZRYeZ2T3JTXd9fzvbC+xqHVJjBRsRy +LP6fnVPAC2vf/NYMMx71V3qnuy+/szGG6xzfyAlX/jhh7Unu+2XYPslfCl7a8L4aPESdhWMpL5U 9yCB5eoST7/yZev/vfkqDmPPaEorop5eIZSC9QC0vQJj/NwhqVoJTx6h4exUTdtWeJomlIrPW89e /d2+P/7+4Gvr69bsbHiv2Pw5839eu1m/LKDi3symkXC+uAI8YtheTs4JCVRyNY/Rd3EAFWzcQ2UD Vb5D/tz2P1ChfPbGsX3XN/z39f/v8+vv4ufTftBCe8PF17T90SywKgdQleUYPyPzC+s5X7WR/IWL DaWoHKyWKxyovALbCGDNISLZK4ZDxm1ArJpA5RGfHkB1kz+uGwvVmOxnQ/5kBPYz4mq75Q7FZv4u BZ8YdGGJ6+nXJWUbqMADgg2OfDcqzgzo7SMdNjPAABuxHEzyh4NP1JdAR/ZLGpPsvDIoXgJ0+b0E fFKXwyAl8ZI54s5+V29i3u8l8132HpqfZX9l8yUwIZZrCzXjS726+87/vekSDmNvLqCKepEy/5qq B6BqIxKFjXiE9WBUbQQmnKOOKuEprEalryNVUKqdcfuPp36rtTiLzid/fLnpwvKBSth+XpMCNvEC lbyrqnBAZc7yZ3+pqPATYK8DFcqnrx/ZcPbftYXF5l3XN/xs2wlkdR2o6HYp20b+h3OUADi/KgB7 FwLYqAK2qRystisZqCIHdohI9onhkHEbHKsqUPmGqHcPFd4FNNreNNLvEZCyM8rPFkGVIVD95Wyv ODMC0Mh8SQUqjbVsDIO0l07fGxfL8a73qrvUl252TYuXoP9T+9RernVDqT1UWucVPtevy+v6kyn7 Jey52r12uydpd6/ZU6XbH6EZB0Eb8hcAVPmgVK7oE3bFIKwHoOoI1yb1SFTtjkrhqHVUjUdfR70Y aZzh5GV6bjH1/538idbWLDrnA1Sb7xu3MNm2UcFiHn8EcjkaUHmwTUxA5WF7pr7II/QiHahQLgmg gv+t6v99eVOdC6hojJ+wkf/h3CUAzqMKwIRSJWsCKiuwjQBWHS6SjdCFQ8atd7i6g9MGKmsSP68Q BVDx0X3iTxGHiW7nrieGVaP9rmhkpPTSp2257oYqH6D6+fZroAsgU29iXpwZENAFKGKDhzpCTx3X pw35U0cDqvADAZzsMYQq4Qhhm+Il9YOKQRpHCQuUEivkBKrSQilYD0bbRlTCRYJSVD4L5D/X+ran i8X5AVUAWkj88JhtwrWacIv9ZNuQQOXPQnEDlfrUXWMKjQC/cfGR/U0jHahQLn6g2nvro2uP7oqs LoGqmFEK1hO+6oKjFBy1CsB6zvdz1FoAs3OSXBSudKCKhlKwHr3CRujCIePWO1aN+ITdQKXHobQF VFpY8oko7O/OsYrPP8FaZhUHVGU5KUVc0lBq9/VnGvIFAFWkypo/SsF6ANqOCaVgIzDh+FEKVuPU sVE1hQmlCmxUxJ9tO/GLv+471nylc+x+sfnJ6L1HI7ebWhoiA1VAv4rkBAds/J/jBLDRSSkXUDlb 09a0OnziAio3C4XupHLfghXtQIXxhaZT/+i68XCo5cnI3Y6xe9oPWmifebBX2x/VQKnBqS5kddc9 VO6sHuDAhA/rOR9eHZSCjeQP6zlftZH8hYsNpagcFJUrF6jCBHaISPaK4fBxGz5WEZmPHaDSQ9Ex ByrXfOhOTPYnRrfvlZOnw2/dnOUnQUhSIqCqCNko9Vl9v2fvmSdQRUIpOP+aqgegaiMShY14hPVI VO2OSuEcddRdQWEjML0cvWNKO6XJsbvIK2K+s/yJcXfW06LcFmDjoh2bRn4YuP/InhWdP43X6bby Gctn9js5W8PKcmubH928Lx/sG64TKRdQMWzTutTsz/V9ihS+kdOpxR3xQIVwcc7yZ6OUkApUdlYP dtmiFGzkfzhHCYDzqwKwdyGA3flfNaFUUbqCgcqIYdXhItkIXThk6HqHqxGisB2f491r+J6/1ZTS A9L247aX9nbzG6V8Y7L/sT1fn+iVsib0qx3VTg7mJ2zuCv5vAqqKkEApdTCkJg2o8kGpcGXVFYOw Hn2qY+qYMqISjlhHU8fEI9oCghSOjlLlUj7ZE+3E8+6sCzrF5bIGKpgR0WabFurl05YUTLLMHpjr HBZpp3tKzFduLXTwwyIfDTzMrQGN7C1gr4L7kRwk80Ida3Jzj54lZ4I+TobKfm5uOXI/qdEUHP1A 5XKxAZWGUkKRgCpqzoeXRVN6ttfsl/yTPe3dR2puodW05kYyVP6HjfwvnKMEwFb+Pxom/6vWq4Cw O/+rdmqBbLkVZyKtTBNQ6Q4XzFrocisRK6zHqnCkWHUaaog92VYDMsknSqnmcXirlj1vSotJdUI/ GYp8DnR7mJ+Y0A82YAkRaw8FJKCqCAWglJAKVDnL6vVT8tTy9Jo9t9bUdDUMz+QVg8IxoRRsBCYc BaVEJOYCqgKglB2/nn5r7623ap82J4qh6CKfKI8OJ6CKrvyBSpAA2OPRzWGLeeBhhkM+XS6upzBx wJAvOdRkm+GTA0iWXWPwnMnHhwf5cr4+/n2x5Q0/mrLngQhh35F4m/kXUYkO39rnQ/M6UIEuHqDy RCmhkEAVD0oNdwFytjx0L+TWMz+sJ3zVAck/eWQvQynxpWyg0nO+aiP5C0e9oBYBqJY7xm+VgWrg yVN7xNNLn956a29b9RO2JwM37avwFWcCKv9g1qNX2CuG3Y02WI9V4UixqkSpE4Geo/6ssOx/3MZn P9djks2KXjvqDkVGR57PmNp+c1Qu/GG2uRZNMbvbSgJV6V4OIaCKRTZQ9QGo9JoqrNfUrof3RW17 qWbYibjh4SM1Mh2vqRnu8oxBWA9A2yuAUj6xCSvh6YrQYDtVU7UrWh2HQCnVA0/aZBSrXc2J0Wr+ kG4YsWyF9uq6qDNJmQIVedVcDEAVgFJCOYEqEKVgPefDfr1SXQ182mG1Fmg5X1hP+Kr9kz/spP3h rfxLAaj0nK/ZyP9wjhIAu6sArCd8P5f+GD80DnFglZoyywqQuOJfso8qXb4JqLziWY9eYZ8YdqKX WQ9U2+FjNTA++x7LZtNbTSOsn4rHYX9iBM0mcR7rcciBiq3PrlKLXx2kZJz0VmtM9UtO9xS76iAX eo4MLAUTUMUiB6jGTKDSayrMy+rwFnHyuIso3FDDlouXXDHoG4bCRhgKu4NRWI9E1e6oFI5aR7UI 9Xb0jint7A1hCSpmhNpdWMURvARU+YuAquS8ukAFjgpGKaFgoIqKUrAnSnFbteDTW0eG5cIomR82 0r7wcPeammF38k8e4U38IKAy8j+cuwTAUavAePdbtSN5olTiqXJpe/U9cJMjsccusU4zAiq4coEq XCQb0Qu7QpdZj1Vh73A14hMOGaLjI8dqb4mLAcIv7RXPmDJCEWZnP0Mp+/oB/BZIyTzjlYvZCAn1 2oP5oKpS7KcioIpFPkClF1RYuULpC1RKfb1/I3cYwjF1TBlRCRcJSuV7JdIXqJyXck/muQImoMpf BFQl59UFqpDyA6p4xvipfnhffBC8pmHGaXrlzvxwUPJvrGH1RU3+ACoxAM8bqIz8Lxw/SnHfdN2O odqd/1VbtYBdAS8ioGIJ3Jea2HAnAqqKBKpwwWyELuwKWmY9VoUjxWr4EPVoohmhCOffMitPE1DF IgOo9IIKGzXVF6gWMjNH9vCX+AVL/zCEV2CMnxGVtpXwzB2hwiuHUsIBQCWviRTHtUMCqvxFQFVy LlGginGMn2KW7VEFZM7f0/XUbn0FZX44V/LnD5VRgYqneh+gMpK/cNQLarCe8/3Mb9YwgMqd/zXb 5eCJeG/RAJV1h4jf7fTNtQRUlQdUThj7RrJXDFvhatsVqLYjxWr4+CSUWoYJqGKRG6j0mgp71VRv oOLR5wYqPQaFVwClfGITVsJTWI9KT+txKmyEqnA8AUtAFYMJqMjxuuSAqjAoxc2mo+B5nvdThbiI Bvsnf5gn/J72NvseXXf+9wIqI//DOUoAnF8VgF84t2m4gcpdAlQr5cD7ztjVtXPLvfd4B5qUAq5U oNKjV9gnhkO228LHaqT4dEIxMCCN35gsTEAViwKAyr+s6kAlow/mMz6xl/Z2PdXDkJvPXeHM11TT 3ThsBmOyUV1nb1vTiAhGeVOyXN6YlFFpPSMbRlVokvGY6mvv3lbLtrOt/UV2tHubKMa1bFJNK0hT x5w5Hrpvjr/oa2pjz9GWQZrqe9zNhuPi1abU8xcpbazs9sciSJ0xtCiTesDykbeiYsHKrY857Q9U dgm056FRHeoTZ5XJLfgQYq+qqY4rRmtJmeFGtQpU+nBi66qn6xC5355zh9nM7Nv5CmxriafimeZY LcycHARU5HhdWkD1JwFUOkQJu7K97VAoxd1QY/dK2dNFzOgJn9mdt28kZQPsoStvN/LMb89spNoi KDdQjQ5v5X8iNW21aoHWPOsDm9mZ59Nb2xpH+lztNJbhUSOQW9jEYOOyRqAW8ImXXfmfX/5O2WlT 9VtNs1aDbfZWk3P7Oj7RdauF53vldSjz+ROFyKWeVjb46S0xs19uB32QX8ZuE/+wverVIacrGKj0 GLatEJRtV+uNWbKTZguibIdBKdihJk/rKAWLaHTb+HXJqgmoYpEnUOW6QukAlYNSzDPipmF460Mt DOHnC8Pda1D8HoqCyqiJbeTTW0dGlGAcYc9nw5Z7eQz2irEfn946KpmK11H+EQ5Q8cDsaxRbE0A1 clSZZndbo3zmG1thb3eTjMSRbfizlk8GA4+PoJrigyygSh1T5wRnQIU4RUHlG+FdQ2q03qplc2/2 a2cpH4C+XZYoNs2m/V7Xat72Ayqn/FgFSXGoT2RbxmZlyWHPBzfXYZ/CrlnKhfamzNs1tR4qtBuc Q6SuiS04H2o7xw6PqjOzb78pSZKts/dpmPvHCKjI8br0gErnKNjBJ9W50r7LAqJYnufJ/wafjsj3 OhpL/jZ0WUDF3XNDJhYOVMJy8glUAZnzpS2gQuYfdVK6MBa6aYrNeM7Kwaj8s8nKYE3jop3GaoSd T7Y1dSu5pfumkf+VZpu8soZsppYA+8ra9secr5BXxdZcCVyuYyxUPsvp6o83l/rbukIndyAnhgV9 UHDGLq7qkNMEVKqdoHXsBK20O2ItKxAl7ItScBSUCtUxFc+QoTI3AVUs0oAqXE01gGp45unD++Ja 4Et77xuD/UQXsSjAajxahXNvd4+MR7YO/hQ0xS2LqCyuLBiVsqrGpkQvu4eK9UqJoosUfFQWUScY +5rYRJpKfxQMxLKWyPAckbQggYpP0MQ3iJyuBuytWhNvWEF1L7SqqWfPkm6jHieUqWz3eg7DCPWJ AzflDKLKanija4nHxKF8IduUPjJE7qfTDlAOkbIae3ueh8iq9+Y2c5qAihyvSx+odI6CI6IU89MG pBFr5iEkeWt2CuNSmj0+yJmjzykByPlW3raBSs/5jq3MX9vGhi2M8nJgXV9jz/O0M//SiyaewY5K mpLJHwvFZ1nX1PhkfVZucdcCYXbRDa9a+V/YB6jEjVV7n/Zb7Tc5e54rYXoClbCRSOHYc6mfrb4d 2/6P5QjxQQEZu5iqQ04TUGkxrNgKV9vuWLVsEZRt92UPtwmlVs8EVLFIBarQNVXWMM0v7e26MWwO +ZAB2HMDBbit0R2PjeK6ptVJ1cuvVloDPCzzIfVKf5QDVK7YNIHKKofbHnsE6U1eXF2PgGOU1XYs oYaqDVTOoA6R0+V4Pxmwo9uNosW5RR+VbjFJmNQv66tm1BK/p/qG/ESxRKteriF/4rZpswxbpctV 8q39dF1YFYfI9RHLOUTyI4yKm9sEVOR4XcpApXMUnAdKcbN7Zdm0fk6et8CmZtjO/O5mmBuo7JaY AlRWzvcBKivzv1Q73Ks0z9xjE5RaIBBLaaRlx+UlNtbjJHO+UyPsKiDN2mzaBTVhq1nvBqpbInGp WU4kUlcqc95rLbFtJlI49lwaYNkFZBtvtHqHHIf7oICMXUTVIacJqOK8XQoOg1KwHoqanVAUdoLQ ZePnJAeYgCoW2UDVD6AyKqhpXk212mn9qU9EoQajrKZ+3tqOAGT1EhtxRvd5R6UKVEpIakDFAtO/ WPIeKr7+rW3iEXCwx1UPE6jkg+BYNbXPxidt7ioIy7Lh5xDZX9YJq/Raf/pWx7CfiEKFP7Edn3ui rKLlUfKt1oCr+Hm0A+RHqFtY1iHKv2QSUJHjdWkClc5RwvnSFOuPMrK9Nerv0/s39OTvKgEMqNT2 mJ23nZxvAJWR+fGnczXNuJQme6JqR9RGGswHcvOXwFqyEHjVCKcQGCMUmK00qAIVYplPOOHKcjEA Vey5NJf5PUvqe93ZPuQHBWXs4qkOOV3hQKUFMLcautxW0LrtNNekC4NSsBWBqo0fkpzTBFSxyAGq 8RxApRRU42KkNd7DGkNvVlP2FtQ8ZaC8YysMxToKUBlRCWedsppyBaZdVp3wDAIqe7AHfxfDqn6P ULWKnAJUYqFaJps9JpYV6+gX2KJYfrRTeHh5ZkuMi3ncoT/R6mhim/LAKlnJjArHbMOYeYHQvX68 h0h+RB4lk4CKHK9LEKh0joLzRylusJPSE2XZGfWnJX/hvIDKlfzVS2lKC00HKnb3FFutKWW302CR 9u3raNYAP6NGuC6reVxQ8wAqOU5BcYL19ngNRXPe66ws7ZlI5fL4cmkoD/Aba7Ezwsouhfyg4Iwd 7zcK/qxluXKByoheJWItW+HqtitimV2xqtmIT1/TGL8Cm4AqFoUBKq2aegDV4tJTPloPdg2Rd+wN VO5gdAOVEZgwD0yrXuYCqqDhHMJ8Igqx2/y9t7Y7QztEhMpk7RRUHrCiD8cqMx7DFaLUAz/Lj1ZL r+AZ5aNVR/lEd71kX9xdMtlCj5IfHqjiPUTyIwioyKvuUgeqZaIUy/bWVK5+Rl0w8j+yvQdQsTwf AFS1AUDllfnFn1bat3uo1JwfBFThRii4gMpovwkU4Rl1dCCOHip4RcqNh+1yo2w55AflyNhFUh1y moDKjl6XrUA17ArXlUUp2Pj9yOFNQBWLcgKVR0H1GC4Pq1P8mcEo37K1PSAk5TpiRIdmJTa9gAqB Ke4JtoCKB2MuoOKh2p8Y2b5XVg7Y7IxyFtqnn3qXkcdwBXj5WV5uwV16ZT322nLkT+S1X/nidnnz +FxpC6jUOmcdIu0gxHmIIn812wRU5HhdukAVA0pxP71xy5jNTw5JsO6JVe6VlfkfdgGVk/ZDA1Xu sQmiEChApSd8B6jabsolTo1wt9mEreTmA1RqqkFybuaD5ZzpHGICqgKXm9HtXqle2GYqa8shPyjX asVRHXKagMqOXsdO6KpWAlU4DErBanB6WA9I2I5DxcYvR45qAqpYFABUfgXV9/5jNis6X25MPqHO hOsRku1tvFfKqqN7u+17jq3AfN7X2GZN2WQAlYhNC6isSgn7A5Vx1aP/sT3dU9stJ1RlskbGd8cs Wy4qpddwBTigcLIS4vUWzfKj9S04kxppV+/y/MSBJ/oG5T1UXlcHJVC5Lig6h8hezV4e0yGSH5FH ySSgIsfrEgWqZdGUk/lhlvzdz5tSBnhbj5aS4xSUZpgKVFryx0JkGwlULOd7ABWvAmHHJtiz+Sm1 QFoClXEP1XYdqNz5XwUqn8Ql06a6MC6gijOXmvbsILKsT8oX8oNyZuwYv1HOz8rflQ1UruhldsWt bStEbfuiFGyFKKyGpYdd0ShsRaBq4zcj52cCqljkCVSBBRVWgcp9u5RVUPGSNRO6tLh4CfP5J1Sj fPJquvS8l8/XJNdxxSZKqT0rriyr2j3H9mNGcgCVhVL9TUjK7lCVxcMbqLTTzyqfbX7VSKwAG4ke pSLCSAaPisLrtHhJ/eiQn+jxDF/ri8t1rO2bJUp8hHv5Chyi/EsmARU5XpccUMXVMSXNpqMQ007A 3vfK4nNBLFr+93u6VJN8GmFbk9MkcwGVuKCmZn4dqNxjE+AlvgQ2L6W5JndltUAO6lOAyk7+Sv63 gYqN8fNs63vlqNiAKsZcapp9rm9q1UpD2A/KnbGLoTrkdAUDlTt61Yh17ESstBKrhpW2mhqQHg45 xs8YbktejgmoYpEJVDkKKrMDVO5qymyDk8ZUi/yJvWz5p7e23pDP7QVNoaCusa9EKk+O2tYu7jxG MKaaGm+pRdS6AHnr6GN+2/H4yLHatmNNsnopjxORQOVMkqsEaX/TLSCZO1pZan5p79N+J2D9i5xF HZ71j9npSlInfuA3K3teddMtP9rzEp1dbFxMFe4TB26yRyjaf3LLL26/RVZ9vdRpqzkLsXIhD5H/ R+QyARU5XpceUCm8FGA97cN62ofZuG6P62iKxYN6YXt0t8z/jJ1ksB9t551UI8NHa9qO3pB5+6h4 rhS3zPDsItrz7OjI0VpxNU3mc7+xCQAqK/Obs/kJsy2whU6bzXMeP9tW5gFQKe03CQMiE7Jp8fAP uaarWa8A1cCTtmr+ktd7xfqBWa6A5YZ9LkMmj24iOSTB9aGhPihExi6C6pDTBFQWO5m2YlU4HpSC ZVja1gLSsvFTkZdpAqpYpAJViILK/NSe0+/TtiPD7oLKYlDiFlthb9uR9qTzlF7+RCnxkm2so1yb 9FvH9dBG+3EittkVR+uqJPLvW7yO9nHEYktqR8yrHmL287dqn96Sj+idvWU9zdYO2IGb1hZ0ioAZ dYj13csVP2ET6Yot2Mb3DbxeKC1uaGbrf+o5YENWEbHB6iezcvdCfKKskc7j8FGizC/Cbq3m77VW Q+3H9zV2fgUOkfMROVoGHiagIsfrsgSqcJl/5oboTarp7lFzvups0rmgZj1d0GmDWdfUbLORCHzA Hoz111iDvcWjpWxva2dpv89Zs61p1G6kpY5aV5eUp0vBcsIh1I6b4hLb+AgoC7nlpqsKOLnFaa1Z dl51Jzf7ziJhAVGSlCSZzCJrvaXcoWrnLs/38uXen2W5cOVGlhJsHKAyYG+fT1SI5R48luuDwmXs 1a8OOV3pQOWErmq1ucYdBqVgJTi9rISlZT0gmY0fiRyLCahikQ1UAypQ6aVUWjxpxLQ+Yt6zcIpg ZFclZUVhFVR5RKMVmOyS5DarFL2099a2xhGHpqzY7HssuQvpVXZJcaB6q7b72ONUn3WFUrX74Ywo lgyl+h+j7Fkr7G1jcCWvRLJ0b79XWBtUwLp6vIufYuWxHrJiaSsYtnufNOtX4KwLeLbl7uX6xIGb jJEAbOoX97o8OdvM2gRyHfwQ221ss1Yo/CHy+IhIVyIJqMjxusyAysn5wkbOt+xcJhOWOd9BKY+0 D2sD/Hqt62XI27JLimPSmtruo+1JUQt4FQAmsZyAhLCtPWUP9lPNZkW3LqLZdndJpW42uTLYtscp 5dkYKY/c4twrFZzcZkXKwu4pj76VC2Ero8rLUnpO09+bO5HCBSo3bCcFiuC9SsKH+bfwSba+HxQh Y696dcjpygUqNWgdK201YV+UgqOgVKiOKaWPmBy7CahikQdQ6aXUtu8wDwelFOvBqNoITDgoNmEl PHNHqLBHnMJGnNqmgC07E1CR43XZAJUDUbb1hK86WvKH9Zyv2kj+wvKCmpb5VburAKznfD9HrQUw lYOKNwGVb8QGxWr4+CSUKhoTUMUiF1DpRVS1UUeFjToK68Go2ghMOEcdVcJTWI9KT+txKmyEqjAF bJmagIocr8sAqHSOgvVsr9ofpWAj+cN6ztds5H84RwmA86sCsDdKwe4SoJrKAZmbgMojYoNiNVJ8 hgxI41chF8IEVLHIAaqEH1D5FFSjjsKuMNTsjkrhqHVUD0lPR++Y0k4tctmYgIocr0sdqKKgFGyk fdtG8hfW075qI//DuUsAnEcVgAmlyMtzxQOVd7ga8QlHClE9IGEjFGHj9yAXzgRUsSgQqGIa42dE JVwkKEUxW94moCLH69IFKh2lYD3hq67EMX5q6iCTKxiovGPViE/h8PHpEZZGHMLUMltxE1DFIh+g igmlYCMw4fhRCtbjVNgIVWEK2MowARU5XpciUOkcBTup3nSsY/yM5C9cbChF5YBsmoAqV6yGj09C qeI2AVUs8gIqo4gKG3UU1sunaiUkbeeoo0p4CutR6elIFZQCtpJMQEWO1yUHVKuGUrCR/+EcJQDO rwrA3oUAdpcA1VQOyP4moPKP1UghGjIgjR+AvGImoIpFbqCiMX7ksjIBFTlelzBQ6fikueBj/HKX ADiPKgATSpEL4IoGqsKgFGyEImwcevIKm4AqFilANavXUWGjjsJ6+VSdRx2NFKHChFLkECagIsfr UgUqHZ9UFxyl4KhVANZzvp+j1gKYygE5hCsXqMLQlB6Hmj3C0ohDmEKxOExAFYtsoBo0gcqoo7Be PlUbRRSOH6VgPU6FjVAVpoCtYBNQkeN16QGVjk+qy/J2KdhdAlRTOSCHdiUDVVCU6nGoOSRKwcYR J6+WCahikTdQGXUU1sunaqOIwjnqqBKewnpUejp6x5R22pArygRU5HhdYkB1yA+oiuN2KTiPKgAT SpELbwKq6CGqByRshCJsHGvy6pqAKhZ5AJVRSmG9fNo2iiicu45GilDh6ChFMUsmoCLH67IAqhUb 42dkftV5VAFhvQoIu/O/aqoF5LxMQBUlRPWAhI1QhCkai9IEVLHIBVRGHYX18qnaKKIwoRS5eExA RY7XJQ5UdLsUmRzWlQ1U4ePTIyyNOIQpFIvYBFSxyAGqCR2o9PKp2iiicI46qoSnsB6VntbjVNgI VWEKWLLbBFTkeF2yQFUcY/zyqwIwjfEjr7grGKjCx2fIgDQOLrmoTEAVizyBSq+dqo0iCketo3pI ejp6x5R2hpDJpQJUVZd37Lm4kVz8vn7rcgkClUFQthWCsq3nfM1G/odzlwA4jyoAE0qRV8mVDlR6 KGrWAxI2QhE2Diu5CE1AFYtMoNLLp22jiMJFglIUs2RPlwBQZecHR/sfdz982Hn/+4575OJ15z38 Ro+fPpxIjZYUUBkQJeyGKNt62ldt5H/hqCgF6znfz1FrAWwkATI5P1cuUOlxqNkjLI04hKllVjom oIpFKlDp5VO1UURhQilykbsUeqgWUgtT46lnQ9M9z6a7B6e6yEXroemnY6mB6XRiIZtm6YqdYsUo Fah0joINiBLWc75qI/kLR72gBus53895oRSVA3KMJqAyTChVpiagikU2UD3zAyqjiMI56mh+RTRS BaWAJYdwkVfEFy8QHYvpxdmZ+YmJuWFg1fgsuXidmB2eSo/NLswAgwHD+PnkD1lkCgIqg6NgPedr NvI/vOIoBRtVwDaVA3IBTEDldsiANI4jufhNQBWLgoDKKKJw1Dqqh6Sno3dMaScDmezpYgeqH3Ce Ly0uZeazc3OZ5FxmBo11cnGa/UCLyfnF2Ux2HimwaGkK8gYqg6OE9bSv2sj/cO4SAOdRBWBCKXIx mYDKicxQMWkcQXKpmIAqFnkDlVFE4SJBKYpZcniXQkXECf9cxFZ2yQlBchGa57+l58+RtJjkD1h8 0oHKgChh/eupNvK/cNQqAOs5389RawHsDnYyOV4TUHmGpRGHMLXMStwEVLHIA6iMIgrHj1KwHqfC RqgKU8CSo7skKiJvm2s7Ti5S45cqZpQScgGVwVGwA06mjeQvXGwoReWAXGhXNlARSlWSCahikQuo jCIK56ij+RXR6B1T2q9PJodxRVVEEkkoAKh0fNJs5H94xVEKNkqAbWq/kVfKFQxUekDCRijCxiEj l6gJqGJRAFBFraN6sfR0dJSimCXnbQIqUgXKD6h0fFLtTv7CuUsAnEcVENargLBRAmxTLSCvrCsX qHLHpHGwyCVtAqpY5AdUhFLkMjABFakCZQKVjk+qlbSvOuoFNVjP+X6OWgtgKgfkFTcBlRGHMIVi OZqAKhaZQJWjjuZbQZXCadsIVWEKWHJMJqAiVaBUoNLxSbMbooRXHKVgowrYpnJAXiVXMlAZcShs HCNyeZiAKhapQBUJpWC9WHo6eseU9kOTyXmbgIpUgbKBam0AUBkcBedGKTiPKgATSpFLzQRUrmjU jg65nExAFYtsoBpiQGXUTtt5FFEa40debRNQkSpQOYDK4CjhQqEUrFcBYaME2KZaQC4CE1BRNFaK CahikQJUc3r5FM6jiBJKkYvDBFSkCpQvUBkQJZy7Y8pdBWA95/s5ai2AqRyQi8MVD1QUihVjAqpY FARU+RVRvXYKu0umbQpYciFNQEWqQHkDlcFR8IqjFGxUAdtUDsjF5MoGKuNwkMvYBFSxyBeo8iii 0TumtN+UTI7XBFSkCpQOVAZHwblRCs6jCsCEUuSycOUClXYgyGVvAqpY5AFUeRRRGuNHLkoTUJEq UC6gMlAKXvGOKaMEqDbClkwuBhNQkSvFBFSxyAVU+VbQCOWTUIq8giagIlWgAoCq2FCKygG5aE1A Ra4UE1DFIhuo3qv6bu2hf0Tz4cj+LzJ5Bf3q59fF6U1ARaoc2UD1/+y4CqZy20jjy7eR50Nai1Yy uahcUeXDBVRtfZPkivL19mHx0xNQLUc2UJHJZWwCKlLlyAYqMpm8fFccUJEr1gRUyxEBFbkSTEBF qhwRUJHJMZqAilwpJqBajh4/m0b1JZPL25OzGXnGk0jlrtmFrHb+k8nkvF0J5YMBlTbkkVyB3lr7 QJwQJBKJRCKRSCQSKax++OH/DxLht1CBCnnNAAAAAElFTkSuQmCC --94eb2c1907b49fe6b20555944f21 Content-Type: image/png; name="13.eil_sufficiant_eil.png" Content-Disposition: attachment; filename="13.eil_sufficiant_eil.png" Content-Transfer-Encoding: base64 Content-ID: <15d9676d955b580a1016> X-Attachment-Id: 15d9676d955b580a1016 iVBORw0KGgoAAAANSUhEUgAABJAAAAFKCAIAAADNLzKQAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAM7kSURBVHhe7f35fxTXuS2Mf/+1/HLyw5v4Xief b5zcnBznxHZuHN+AfRPHx47Je4xjMKPxAXIggLGZQYAkBosgRiEJyTIIhCVAAxqR1FJr6pZaarWE 37X3s2vaVdVd3apWD3rWZxmrq6urqqv3s5699lT/v+8ZDAaDwWAwGAwGg1GUYMPGYDAYDAaDwVjT eOED9TaDUVCwYWMwGAwGg8FglC3guxYWl+53Dt/vGv66ufPLK/fA9/ZfeWfvZY2vbj77g3cOanxr 1wV6d29VE3322v0eHArsG52CpytRXycN6YvYXJLuDL4UfbstJ+vMG5KRn1U00KfohgxH43RDAHUa Rhhgw8ZgMBgMBoPBKBMsLKbgQI5de/DxkRtwFD/+4AhM1w/fPUwGA26EDEbz48HWrmGN/ZEpdRQb 2vsi9G7FrUf0WToySAYP//55/xVsr2vr64sUo4WLzS3gnpyR1286VbKjuD/0El+Kvl1Nc6d5QzKy uqGDPkUH+cXHp+mw5HLNY+LODE8IL8fIDWzYGAwGg8FgMBilCrtDg3cib3bgUsv1+z1wFPFEUu2X N8Dmwf7Blmz4opYsHOwKnOGx2tb7XcMLi0ur7N9wOtyQqoYO3ATcip/+9Ti5MuohNJ2q2js/IJeL n4AMG+4MvBxdBvm3aCzBvXDBwYaNwWAwGAwGg1FKgEm7dr/H7dA8u8hWH7ArNc2d5JdweX/ef+XM zUeyiylfFgU3pEmaRpwRjhH/flbRcPzaA7imiVhC7VRowDzjesi/wUaC1DOJK2f/lh5s2BgMBoPB YDAYJQDTp/34gyP4t3gcWno0Px7cW9X0i49Pw17uqWq63/kc3mTl/gRHqGvrw5Hf2nUBtvA9aX7y 3XUWIuAkqWcSVw7zhvuzs6Lh2r3uWCLJ5k0DGzYGg8FgMBgMRvHC7dOSqSX1XkkB9rLi1qN35My6 jUdufN30dCGV9YDJ2NzC182duA8waRu+qMUB2/si6r1SxshEvLqhg35lWNBjtQ9oQiADYMPGYDAY DAaDwSg6UA9SGfg0N+KJJL7OlpN1v/j49OEr96IzcxmdyXA0dsYwe/hgOd0NN2BBD1xqeXXz2Te2 V1bVd/CASTZsDAaDwWAwGGUC1GuHo3FaqN1klbGUn52fVTSg9k80F6y38+vmTvtBQHPRdnWyvGFh MYWzw8xs+KK2vJ3JRCyBW41v+umJur7RSfetxd1uejwIv4p98DOV0IjHUNA1FEVBFbPd9l25dq8H t2dtOjc2bAwGg8FgMBilBNRZ6fFZtM4ESGu1/1guYY+avenEiObDsuysbuhA7Z9oLlhvp/t5XDgy jo+z4G+aMQXiGuDlojOJULwcvtex2lacCGcfmYirreUOONKa5s5X5eMBmjoGyZbgVlTVt+NW4FbD tapd1yqapWuFcwvYIVlmYMPGYDAYDAaDUbxA9ZSMGSqscEq0cLzmmmit9lVYwh6gtf5ouQiQvCJq 0qZX3PBFLbZn++ithcUlsmoHLrUUz8KGqwzcVdxP/MSfnqjDLYXTXjuuNQioQxJ3Bvenc3B87dg2 NmwMBoPBYDAYxYIXckwj3A55IdRNQTJm1+WDxYp5XUS4C1zhHXnx+qO3Hvb6+Td85ftdw29sr4RV Wx3PWeTAT1zT3FnGA0FXDtwfFJiNR27QMN2yBxs2BoPBYDAYjEKib3TqmnzEMLwNHA58DnVSNT8e LPW+Jvujtzz9WzSWQLUbG0tigX5GUeH6/R4Uqk9P1tGI3DIGGzYGg8FgMBiM1UZ0Zo4WZ4eHeXXz WfwBG7NqwxoLBbd/w3fnCVqMlaBGrk9ztLb1hYTaWl5gw8ZgMBgMBoOxGkBt8rtesV75G9srf/rX 47Q4+1oeBIjvvpa/PiMsJFNLCKvf77rwqHe0LB0bGzYGg8FgMBiMPMJ80vGP5ROBj1970DUUVe8x GIyQ0N4XQXz942LLC7FgqdpYHmDDxmAwGAwGo3jx4sWLhcWUeLCYnc7ngzlo7NM3OkX1NjlOqgDV N1zAsWsPUIOET+PONAZjdYCge3vP5fGZuXKybGzYGAwGg8FgFBLSki2RDaNHPB+41PKOfPDXT+Vi 8T989zC9zIq0/D3RfgR4J5zizK1HZPBCd3Q41LX7PXQB+CLtfRH1BoPBWBW0dg2/vr3yUW8k3NAu INiwMRgMBoPBWCXE5hZgzNJYMnrE8/FrD1DlAsNaIzGZWqIDgjXNnTjF3qomOiM5uje2V+JvXNWZ m21wcbG5ZA71vOFoHEfAN/r4yA2cSG1lMBirDkjH23su3+0YoBYZtbVkwYaNwWAwGAxGvgAPQw99 fm//Ffuq7qFbshWiayiKi8FVkZHDdZKHhIE8VttqdsSpvZ3AdnxH+oI4QqkvxM9glAeSqaUPD9U2 loVnY8PGYDAYDAYjHKBW5H6kGD30ufnx4MhEXO1XCqBOueqGDuoM/ME7B9/adQF27tq9bnqAGL5s dCYBO0ffEV9QfZLBYBQHhGf7orahveQ9Gxs2BoPBYDAYuWNhMVXX1kcdU3A1ZfxIsfa+SMWtR/h2 1FX4tvy+eFlaRpTBWFOAZ/vzvistT5+XtGdjw8ZgMBgMBiNrdA5Gj1178N7+Kz989/CGL2rhZODQ 1HtrAPCid9r6PqtogHmDR4Vf5R42BqM4MRFLvL6tMjI9V7qejQ0bg8FgMBiMQEBdp66tb8vJup/+ 9fgb2ysPXGphlwL0R6bgV03vWt3QwdPYGIyiQmvX8Po9l1JL0DA2bAwGg8FgMMoOqOLc7xz+rKLh xx8cgSGpae5kQ+KJZGrJ7HaDreWnYzMYxYNjtQ9+/vHpt/dc/oexGOxwVE1GVXsUMdiwMRgMBoPB 8Ebf6NTeqibYj3f2Xq5u6ODnPgcEnBts7RvbK9/adeH6/R61lcFgFBQjE3H7YrBQNlpMaMMXtV9e uXftfk/69WALCDZsDAaDwWAwHEB9BXUX1GNe3Xy24tYjXlQjZ7T3RT4+cuOnfz2OOiJcnNrKYDCK BgjSO219MGwIVXM92AOXWuoe9sYSuTyPMR9gw8ZgMBgMBkMhOpMwH/2MeozaylgZJmLirvL9ZDBK AgjV49cebPii9scfHKElhb7rHS2scWPDxmAwGAwG4/vOoajZF8RT1BgMBgOgJYXe2nUB2vjpybq6 h70wbqvf7caGjcFgMBiMNQ1YtQ1f1L6xvZJnWzEYDIYnJmKJmuZOSCWc256qpr7RydV0bWzYGAwG g8FYoxieiG85WQerdqetT21iMBgMhj/g3CpuPXp181ko59dNnavT4caGjcFgMBiMNYfYXJJWn69p 7lSbGAwGgxEYXUNReijlsdrW2NxCXm0bGzYGg8FgMNYQUKv4uukprFp1Q4faxGAwGIycQEsKQVEP X7m3sJjKk21jw8ZgMBgMxlpBX2Tqnb2Xt5ys4yeqMRgMRliAon555R5sW1V9Bzxb6LaNDRuDwWAw GOUP1B9Qn3hje2Vr17DaxGAwGIzwMBFLfFbR8Orms496R8N1bGzYGAwGg8Eoc8QSyXf2XoZh42c3 M/KDqRPbDv7gnYOb2tRrBmPNoj8y9fbey0drW1+8EC1loYANG4PBYDAYZYsXL150Do5zxxojRAzU 3th0tLV+VL2UYMPGYFhIppYOXGr5/a4L4zNzoVg2NmwMBoPBYJQn4Nau3et5a9eFkYm42sRgrBCj ra+/I7zZD472qi0CbNgYDB3tfZHXt1c+HYyufEobGzYGg8FgMMoQqCEcvnLv4yM3eBjk6qHthnAy 21oH1OviQwhX2LtJGrZNbVNqgwAbNgbDAxOxxO93XbjbMSDWIVmBbWPDxmAwGAxGuQH1Ari1L6/c U68Zq4M1Ydg8wYaNwfBGMrX04Re1jcKziVEPamuWYMPGYDAYDEZZATWCqvqOzyoa1GvGqoENGxs2 BsOFlXs2NmwMBqMcIMcavOgcjN7vGv66ufPLK/f2VjW9s/eyJw9casEOYNPjQewPLiwu5aahoYAu Htdwv1NcTF1bH12eH8/cekSXHZtLrqTFjlGWQHH4uunplpN16jUjM8hsnDsxKiZobZLGQ720MDXQ duN19ZZ493XnqhsDteeMtxx8vZbGDZrDCOUrG+qPyj095oN5Xo/9rd4TR82TnttU25veg2W6QsJU fS2+prUn/nYOfQQ8vZmvYRtow1dIf0AgyE9gR5D9M/xkxkFu1Mu/64+eU3PzxJ6+NzP7rxPkZ7Kf Hce84bxOION3YRQ74Nne3nO57dloblmbDRuDwShJQO++643Aunx85MZbuy5QGntjeyX8GKqqcDUV tx61dg178vi1B+R83tt/hSzcD989DJKXQ2X3u75I/owQDgtjWdUgOkDo7HTxdAHghi9q6fL8aHrR H39wBB/Ev/QS28/cbMvrxTOKHPjZ2a1lD6N6XSt7nwzavAftILntnM3PWA5B1qftdW6xm6zN0/s5 GTaP67HeMs9l0XEQHZmuEFAXKSjfUn9jZ6epo7vh/C7pNnpQ7+JL85U9kXF/26kd38Vu6mgfuCNj GRUHycjZkcvXCfAzWYcVv4jazX2dkr7fhVEC6I9Mvb6tci6ZYsPGYDDKGdGZua+bO2FLyKHhX/x9 /X5Pe19E7bECJFNL5OVQ2aXjw/7BUzWtbNw5gM/2jU5du99DRss8cnVDBxlItV+uiCeSdBx4VPvN wSlQd+8cirJ3WyPAD43i+t7+K+o1IyjsFXGjc2N0yqyCK0+1zd6nMWVudNTUfQcc5mDYiNr12N8y +3ZE/wxt9Hc4BtIMiRS+Re8CMvrlPPyDpzezb1RfTV6nccyperOjL+hX9kSG/YP9ZJ43UzhbtdHp rHL9Ohl+JnWH7b/IaO+mbdYND/ZdGKWBY7UP9l34Zmk567TMho3BYBQ74NOqGjpgdX761+NwU7Al oTi0jOgaisJTofr74w+ObDxyA+YnlkgGd26dg9Evr9zDZf/w3cOvbj778ZEb1Omn3s4zcItw8bhd MIe4AFz/tXvdC6lCjvxk5BX4ZRcWl1DSeAX/7GFWr726LFT3i/stLw8WsmFzn9R8y3ApCmq7syvM C1nPYXNfuTqX87u4NhrdVu6vnMYEev8EHki7f9CfzDyIdjPNK7R1suX4dTL/TFQAfH+4rIofoxTw +rbKjv5x4dmyycZs2BgMRpHC7tM+q2hYNavjRjyRvH6/B+YHzu3P+640dQz6ySwEGD5tb1XTLz4+ DacEw4bLLvii6rgAXD8cIznPa/d62LmVH/CD7jwjum3Va0YWUNVoz7qvqo47O1sIHlXtUA2b1/X4 vuV1HC9kbdjcZ/S8Bn2jR8eRCQ/zk+YreyLd/oF/Mv+DuK4wrK/j/pkMv6ebRkJ2xY9RCrjT1vfB wavZJmE2bAwGwwL0o290ipa+IKZfAAOGytxTsHMYAoSDZKdDLkRnEuR5CuvTPNH8ePC9/Vdgxr5u eoovaX7T2NzCmZtt5NMqbj0qzl4OzbnVPexl01YewO94r/P523svq9eM7JCu9q9q2KgZy+lDdtJ2 R2W6cIYtTc3egcyGbaq+tnXTUf1r2s7oeQ36Rq/vZULtbDMbab6yJ9LtH/gnS3MQ/fcK6+t4/Uy9 xqIpuGDYNocBy674MUoEP994ui8yk9XASDZsDMZaBGwGubJjcvkNWnsDlXio/6ubz+Jvk+kXwICh su8MUgqBacHfeBf7fN3ciRPBB5KXU1fgA9OqwfMUvGMqDbqGoltO1uE6YdLw1fBNf/rX47jyUhmN Rs4NPy5+KbJtK/TYjAICv938Yur17ZX9EW5rzw2Bav9+LJIetlAMm9Hb40HbGT2vQduoXq7c4fgg 3f6Bf7I0B9F+r9C+js/PZE1vE9x27oQxoS674scoEeypajp27WFWq1OzYWMw1gRicwtwTbBPqKPD ZkDlyV/RAvfNjwdbu4bjiaTae8WAn8EBqxs6cHAYG5wIPhAnpZUwqurb3SsZ4u9jta3Yrcitmh2w ZzBpuGZ801K5Zg34pahIaB2GjBICfrXTN9tQFNVrRtYIUPvPaIQIJW3Y6C14gKO9A67pWLYzel6D vjHtfVM759ewZf7J0hxkNXvYTDjW7qfPZlf8GCWCO219/3Hg6vzicvCZbGzYGIzyBDTgfqfl0H4s V37HS8hEAXuBaCUMeDb7Sobwb3UP+/A33GOIppERHCgS1GF47V4327bSAn6r5Rff/9vms/3cvZY7 0tX+VQ073RhCG0rZsPl4A/cZPa9B36iO5nnfVmcOW+afzP8grqU+wvo6AX4mYwVIuU92xY9RIkDO fWXjqfjCUirwqEg2bAxGWYEW6oBJo4d6FdyhpYfp33DBq7PwIyMNUE4+PnJj41c3ZuYW2LKVCuCu 256N/n7XBfWakQvSugXV7+S1GqEbamf/R3hpNXWjru/cnuZ6VuIEJHyvUHkS1xA7NcMqkxtxbVQn 8r9UxzWk+cqeSLt/0J9MHeQH2/S7oSyT/QpD+jqBfiY6F5m0oN+FUUqIJ5I/ev/ITCKVDOzY2LAx GCUP1Ng6B6MHLrW8sb2SFlSESSvREXqMguP6/Z7Xt1c+ejbKXW3FD/xAyPY7Ttfz4pArQ3q3YKvW OyvNA22tm7S6vtXZIm3P6JQ5ttCo1htvibU9bE9VXjXDlvkKbV9TPBBMXp7jjJ7X4N5o3DfbI86w 0Zys5XSGab6yJ9Lvb5w6w09mXiFoThuzHq3meYUr/Dqunwl7as++M06k9jFeBil+jNIBftPJucWF xeWAjo0NG4ORNVBJAuCR7ncNNz0e/NK1FEcaHrv2QKym2DVMjzOmQ6njZo/haBz2DCYNVu34tQdd Q1H1BoOxAoxMxN/adeFobSsVUbWVUXzAb5NIpqAAPJZ4ZfCtXhuwfAvq63KNPvOlVmM2qtcGbfV4 NSrSwW03TlCNf9UMW8ArxHdUf6sFCW1n9LwGr41m/6GLr+vXmeYreyLj/kF+MuMgR23O2aR7FGIY X8fLsBnH8S1XwYsfozQwEUu8vOH4xOzi/OKSnMaWOc+yYWMw0gFRdL9z+MytR/BatJQirBEJJS2E iI2mGQvCA5da8Cn7cX7x8WnaQrO54OUy1pLxLowiTo3PVjd0IPLVGwxGeEBZ/fO+K/OLKXZsRQvo RMvT52/v4dX8V4ggbkF2iFkVZbHMuugYcXZ6CIz2njCXXIcfs++At6zFAFW/ipfRSnM9wZ2AP4Je IXxIa/2oOrLtjJ7X4Hdh2n2D2dBXrpcI8hPYEWT/jD+Z7SCiL9G8J1qXlx0r/TqeP7d+zKPuswcu foxSQHtf5Lc7qqPxxUSSDRuDkRNMh7blZB15KlipvVVN8Fq0lGLovVgjE3EcltZUhGfD6XBSnBoX cOZmG/zbgm3l19hcEqYOPg1uDddDGxmMPAFlDJ4tq2fFMFYNkAX8NBcan356sk5tYjAYWSBbl8hg hAPU9/52rI4NG4ORHWihDs2h1TR3FnCEIU6NC8Bl4GJ++O7hVzef3Xjkxs6KBlg1mLqiXUSEUX74 urlz84nb7NmKEPhF8Lscv/6QF/RnMHICGzZGYfDuvpqL3/RMiCGRtLI/GzYGwx/D0fiZW4/giGih jsI6tPToj0xdv9+Di4Rhg3k7cKmF11RkrBr2VDWdutHGnq3YgJ8jtfziH5e+/fLKPbWJwWBkATZs jAJgZCL+s49ODU4uTM2lkimxcJR6Iy3YsDHWHMinvbG9EuZnb1VTa9eweqNEAPN2/NqDt3ZdgM+E c+PeNka+kUwtvb3n8r6L39x+2Ptd7yiSS5DmQEb+INpjBb5fXFr+5NjtmuZO9QaDwcgCbNgYBcDu yqZ9l+8NTy/E5pdsU14ygA0bY60gOpM4du2B6dPKYEHFiVgCzg1f5+MjN7jDjZFXjEzEv5QPYacn nqPUvbP38oFLLWduttF6p4xwgRz+XW+EFqGlqa0mf/zBEfwEJvGynx+ZzWDkAjZsjNUGKp+/3VHV FZmNzCRn+cHZDIYdqFBuOVlH/VFl4NPcuH6/B9VokJ+9xlgd0Eo5x6892FvV9Mb2SniGjUdufN30 NBpLBG0tZNiwsJhq6rC8GcQKlUhENC1CW93QQesSEXkFfwaDwShRrNt96XJL79DkwmQ2E9gANmyM sgVi4H7XMGo/qFCuhSFDPDaSUSjAQly/30PNIgi3A5da+iJTbNzSg0wa7hWM2Q/fPWz3ZvygDgaD wSg/7L/Ysru6pXc8EZlJxueXUmI8ZNBMyYaNUZ7oHIrS8CHUftQmBoORf3QNRY9fe/Dq5rNv7718 7V4PclHwhLQWcL9z2G7ScK94PDODwWCUPZAQ/+NAbffY3POphck5s3tNvZsRbNgY5YZoLLHhi9o3 tleyVWMwCggE4MdHbvzi49PHaltjieQat23D0Th82k//evydvZfZpDEYDMaaQvPjwR++e/jMnc6B ifnx+KKavZZNWmTDxigfoOhX1be/uvnsnbY+tYnBYBQUIxPKqByrfSCy0xqzbQuLqa+bO9/adQHG FT6NxzoyGAzGWkNNc+d7+68gG767r+bzc03jsYVkaln6NTZsjLWHvsgUakWfVTTwjHwGo9iQTC3B tr2+vfJR7+gacWzRmQRN6sO/3J/GYDAYaxDIfXurmpAF1Ovvvz9W++DNzy48G56EWWPDxlhbQIlv 6hiAW+NaEYNRzOgaiiJO/3GxZUE8ekZtLD/g23155d4vPj5d09zJ7UcMBoOxNtH8ePCN7ZUVtx6p 1waQCl/fXllZ356VZ2PDxihtoKifudn23v4rXDFiMEoCx649+P2uCzNzyfKzbEi9VfXtsGowbPyM DQaDwVibGJmIbzlZh6qp30MykSA+q2j4oubb4BPZ2LAxShgo5J+erNtb1aReMxiMUkDXUPTtPZfH Z8rqoW33u4bf2F6JHMwT1RgMBmNtor0vQqttBXma1JdX7inPpjakAxs2RqlCuLUTdWvhAWsMRvkB nu33uy4MjcfKwLPhGyDvvrP3Mr6U2sRgMBiMNYN4Ionq6Fu7LoDX7/eorQEgPdu95ReiTpsebNgY JQmU7MM191DQ1WsGg1FqGJmIv73ncql7tlgiCavGWsQoDkyd2HbwB+8c3NSmXpcK6o+Ky/7B0V71 msEoBSCLVTd0IAX8+IMjOa8vdTiYZ2PDxig9rFm3NtDWumnbudeR1RTPvX60tX7Ue4Q0ww8DteeM G+jmjXq1l28FgisWIeJOW99fDl0VDw9VG0oMcGtv89P5GUUENmwMxioB+esXH5/+rKJh5SnA8Gzp Wi/ZsDFKDCjNTR0D7+2/ol6vEYzCqsl85sltls1gZISqGXiTDdtq48/7rjR8NyA8W6mZtujMHNwa D4NkFBPYsDEYJYm391xuefo8jWdjw8YoJaAgLywuvb690m/hnfJE2w2jV+3cptregVG1Gbm5vtZ4 q/zyXNsN8b22tQ6o16EhYM2ADdvqAIbntW2Vi6XWyxabW3hr1wV2a4wiAxs2BqMkMTIR/7dNZ+cW UkiFnqaNDRujlIBC/MVaGww52qosma91gW079zobtsBgw1Zs+PO+K3ceyU42taHYgev88FDtnbY+ 9ZrBKBawYWMwShVVDR3bTtenlrx72diwMUoGKMBj03M///j0mnrAkUpjtqF6awVs2NYMKm49+uxs Y3JpWY4GKXbXhus7fbONnybCKEqwYWMwShhv77n8zZPnnnME2LAxSgYovkeuth641KJerwUY3Wuv 1+YwBHRqoO3G69bMN1qhRL1ngLL7uRPYPtp74qi5Gocce6n2sSPbY5pT7+RLBTmSc5u18gf+3tRm fUG/RUFcNyHIxXiADVuxobVr+A+7LyUWl4u/kw1ZdGZu4dXNZ/lha4yihN2wTdUfNRepEqMwPCU9 vRobsB8K+9zwUtrgguw8mrywrHSV1t8yTuR7zVlmNwaj8OiPTP3bprOLopNNHxjJho1RGkC5XX7x /b9tPovSrDatARjWJYfuNZW2Bbeds+Vju3ECjJRmzoWzU8+dWR/T2EHQaPHt3WRudBzE8mMy69sr B2I30NlmHPBiPMCGrdiAoP7XTyriC0t+Q0GKB7i8/Re/OX7tgXrNYBQXlDBuqjXG0tupL0+VWY0l LLEVUqz28ZR9yQyCbDupxRuqaS+zrtpOpFEfjkF7BsxuDEax4PefXbjfPeJuvmTDxigNoJ70bHgS hk29XhtQ3iD7YYHmB20NnFNeR7MnP7ORUjR/0ka7R8rpmEZD7OiU2kH0GeoNnIYvdab2tEMiA1+M B9RubNiKBl1D0d9sPT+dSCVls2LRAteGJPrzj0+PTMTVJgajuOAp6aIVTG20C1cwNVZb7Lo62rtp m0OuAwuyeXnnTpjpxm6oAsqy/GrGYcUsbq+PZ5HdGIziwbFrD/ZWNSMbapaNDRujBIBKHAruuTvt Oysa1Ka1AW9vYKZeGx0NomogpW/Tpi1RmSlNG+KitluHzeWY7p394D5IWsOWxcV4wEj5bjqan71v vv92Rs6oae78z69uTs4tLqTENDa1tfgAIWp5+vztPZfVawaj6OAn6cHHa+gqSornGpFuQ3BBVnu6 JNrYnkFX/T7u3eoXOLsxGMWEkYn4KxtPqzkCtnzIho1RAqCG7YOXv11rD8sObtjs+6jU5ZX5XKlX pS53/tNOHcox/eH1EX/Dls3FeEB9NQ+yYSsMPvrqesWdJ5NzqWI2bGu22YhRUvCXX3+344R+BMvp 6X5MIbggqz29VD2Irqb5uNe3C5rdGIxiw5ufXWjpHNbmCLBhY5QAUGQXl15sO11f3dChNq0NqLzi mZ8UVE6y5x71KaRJOZfATtpu29k3pWk5OJRj2jBVX9u66ah+EMdH/A1bNhfjgYDZ2m+3gB9nBEQy tfSj9488G5+bmksli9qwiWajA2uv2YhRUkgjv34DEDKqca+xdhQkF7ZNbw4LLshpxDOIrqbdR33x IE2HaRwmg1EM2Hyi7tydJwuLjpWT2bAxiggol9/1RpoeD6JKBG45WffO3svg2+Ceyz/ZcLy1a1jt ujag8kq6QSwqJ9lzj5k+/ZhDSgvlmATjS3nQ8ZEAhs2PgXrYMmVrv90CfpwREMdqW7dX3H0+tTCT SNHSWMUJXFdq+cXhK/fX1kK1jBJDGvn1MGxB1dg29UtwmzkDTSC4IKcRzwC66pHsbFDvsmFjlAFQ Af77hZa55JJ9VCQbNkYhsbCYauoY3FvVBFf2078eh4a+tevCe/uvkGGrae6EQzPZNRRVH1s7MEY/ emVfgkcOy8ZRBE1poRxTwPhGYiln12QDx0cyGrZc023Aj/vttsKzM+wYmYj/8pOKztF4JJacTS7B ERWrXxPNSamlF5eaOzd+dUNtYjCKDmnk12XYgquxgmPhfnOH4JKYZs8gB0m7j7psNmyMMsDxaw8+ P9ckVk625UQ2bIwCoHMweuzaA5i0H757GPas4tYj+DF+rpEXVMrx72QzdrDlHpWN0g2kNBE0pYVy TMAn43p9xN+wZXMxHghYvfDbLeDHGRmRTC39bmf1jbahwcn5ybnFedcc66ICrmxxaflBT+S1bZVq E4NRdPCXXzXLy1qWIws1dsBY/tH4YHBBTrNnEF1V+3ieKJs5bFp2YzCKDTXNnR8duTUzn7JPY2PD xlg9xOYWqho6Xt189o3tlQcutcCkqTcYaWA0gvqkQ5WTHLlHfSTIIo2BU1oYxwQo47qGLKo5Eo6P qDN6OdUsLsYDQWoGgN9uAT/OSA+4tff2X1m352vRvTaTjC8swQ4Vb/+a0cMWjS+8svEUty4xihVG RtAfuWYIl01Rs1BjDaTAZkoKLshqT9fB24yV/dPrqt/HzYTlyBds2BilCtSQ//vSt3KagNWKyYaN sRroHIxuOVn3078e/6yioX8tPfk6FBipCJTPzDGT4qjtCTaO3GPL2c4MOtDWusmRyIOntBCOCVhp 1foW1ox2x0esFlNZYEan3IN2AlyMB9iwFRzxRHLDF7XNjwer6tt/s/X8o/7xeTG7WswTK1rg2pA7 YSy3nWk8c/OR2spgFBcMbRS0P+tMJRG7PQumxjig9qw24xQryA42d2d7iprjmJ6wPm4+Yk4cwZhf 5zSfamc2bIySA62cPK3mdbNhY6wKojOJj4/ceGN7ZU1zZzK1pLYysoSYOUD5zJvIXmpPA1bexbty wS7zZc5tkCs9poSaRyGII6i/1Xpizo+YuVnRmYwDXowHjJZmT1qNxBkMmxddbdUMD8Cnvbr5LP6l l/2Rqde3VV5p6S7m8ZAALg1XOJdc6hyeeWXjKVYzRlGCZBMWyytl6MM0gqixTYfTyWxgQfbMZTB1 1HuW0UQZDXluvq5/NqvsxmAUEV7bdr7x8fDMPBs2xqpgYXHpWG3rLz4+ff1+j9rEWBGmZGulzDSK SIo3TrRNeQ2VBGT/m5U1xZrLjg46gWxT2oqOqTDae8K24NjrR1vrR9Xp9I9gT/P74ps6226DXYwH 1FfzZmbDlubjbNjSo2souuGL2vf2X9GGFML8bDxy49Ldp0hMRevZkDVh2OYXlyfnUp+da4K4qTcY jCKCMmxCx0R3mamfWi+ZgUBqrCntObFIiXrLjsCCbL8wGjaCjQENm4DrekTPnlt72bAxShLIjy9v OPZ8aiE2TzMF2LAx8onhifhbuy4cuNTC7dAMxhoHROD6/Z539l5+Y3vlnbY+tdWFT0/WXb77VGSn 4vVs3y8uvZiZTw1MJN76/GJ7X0S9wWAwGAxGGDhz89HmU/Uj5tRutZkNGyNsoLbVOTiOytlaXIWf wWDYUNPcueGL2h++e/jjIzeCLDL0531XGtsHitaz4aKQPROLy9HZxfs90f+9s5pXH2EwGAxGiHjz s+rrDwfHYkn1HDa1mQ0bI1SgntXUMfj23ssjE3G1icFgrEkkU0vHrz1I06XmBj7y+10XngyMS89W jKYNF7a49CI2vxSJJa/c6/vdzup4IqneYzAYDAZjBegaiv56y/mBifmJWfNRNyoVsmFjhAaUqs7B 6Fu7LnANhsFg5Aakqzc/uzCXTBWnYaNONuTRqbnF4emF2gcDv9l6nle+ZTAYDMbK8drW8ze/e47k MpNIJe2PzWbDxggLohHgxfevb6/kkZAMBmMl+Mellq/+2WofClJUgNIhjSbk6iPPpxa+6R7/7Y5q fqokg8FgMFaCqvqOjUdv90Xnx+OLc8kl8dRs9Y4AGzZGOECpOlrbeuBSi3rNYDAYOSGZWvr5xtOj k7PFOTCSLgqpFAk1Gl8cmlz4bnDm959f3HGmgQcXMBgMBiMHTMQS/771/P2+yeHphWnRvfZCy4Bs 2BghACUqkUz9+IMjvCYkg8FYOQ5cajl85b59ReOiAi4KV4bLm0suT8yKsZHPxhMHrzz4108qspqz x2AwGGsNEMnj1x60dg3zYgcmUHlet/vSldb+frN7Tdo19bYEGzZGCECpejIw/vr2SvWawWAwVgDk cmSvhdTysngyW/F6ttTSi0RSjI0cmU72RhPfPpv4474rf9pXwyv+MxgMhicg7wcutbyz9/IvPj79 g3cO4o+Pj9z48sq95seDa7bR/z+/vH78Vsez8cTITFLMXlvSu9cANmyMlQJFCpWqkzfa9lY1qU0M BoOxMvzkr8cHo3HnpOviAnm2xaXlRHJpai41OpMcmJjvGUucb+x+Y3sVDCfqH2pXBoPBYHgB/u36 /R4Ytvf2X/nhu4ff2nUBf6+pWcH7L7Z8dr4JueP51MLkXEotDqnetMCGjbFSoFShbG07XV/d0KE2 MRgMxsqwfs+l+u8Gk0W79ogEtYHiGhdSy7H5lBwemeyLzndH5i5+07t+z9evbT2PugiPFWcwGIwg aO+LwLC9s/cyzBssXE1zZ3nr56bjt3dXt3SPJYYmF5BB5pLyYdleaY8NG2OlQLFaXHrxxZX7vOII g8EIC385VFvzTc/8onxyaBGbNnFxL17gIiGDyLXTidRYbHFoakHatsS1h0P/caD25Q3HN5+oW1Nt xgwGg7ESwKc1Px7ccrLup389/llFQ/k9PQVf8IODV7+q/Q6ZYmByfiyWnF2AW/MYDElgw8ZYKVCw FpeWLzV1bvzqhtrEYDAYK8NHX92obHg6t0CGTW0sWuAKcZmpJdHVFl9YmpxbjMSSyraNJR70TR+u /e7NXRdf2XjqHxdbeIYbg8FgBEQ8kaxu6Hh189m3dl2oae5UW0scIxPx3+2sPnPnaXdkbmByAW4t Np8ypm2rfTSwYWOsFNKwvRiPL/xkw3Fe1ZrBYISC17adb3o6AvNTzNPY7KBGUepqm18Utm1qLoU0 /HxqoX9i/tl4oiuSaHw69nlVyxvbq/7l3cN/2ldz/NoDNm8MBoMRBFDLLSfr4NxKfXpw3cO+f996 vvbhYPdYYmBC9K3F5peSKe+paybYsDFWCuphi82ntp1pPHPzkdrKYDAYuSKZWvrR+0cGonPx+VSp GDYCrhWSSLZtIbU8K23beDw5Mr0wODnfF53vGU90Rua+ex4719i95XTj//P+Vz989/A7ey8fuNRy /X5P11BUHYjBYDAYLvRHpt7bfwUsxUGSSG27K5v+uO9Ka990j5y3Nh5fjC9kdmsAGzbGSoEShhoV CtyzSPzft54v6wdrTJ3YdvAH7xzc1KZelwrqj4rL/sHRXvW6xFC0t713E+5qCZaH4sedtr539/8z EkuWUA+bHWTbll8IbUQmnksuxeaXJmWH2/D0wsDEfMdQ7OA/H/zyk4rXtp2vbuho7Ro+fu3Bx0du vLG9kta53lvV9OWVe7BweAsMOHgBtQHav/nxYNmMHfIHByCDsWoorkQMiXt181mIpHpdCsA1/2br +b9fut85OvdsXKwJOTEr3dpSZrcGsGFjrBQoZShq84vL0fhic9coiiMqDeq9cgMbtjxgtPfE0XOv yxsree71o70Do+pNCY/bPlB7Y9PR1nrHbqsPqi+eO7Gyy/D8dQZqzxk3xOLr226caCu3idee+Oir 66frnozHFxNJmclKzrFJ4Lpx4bh82eG2DJGcXVjqej69s6LxJxuO7zzjO40ejqvi1iPURWDhYN7A H39whMoAvXST3qXOOvC9/VdwBHW4wsGzGBu8Ua/2EvCMgkzCFU4AMhieKI4sUzwoxvoPiWTx1zkn YokPDl5dt+fr2x0jXZG53mhiZDo5qdaEFE17QVIcGzZGCECtJJlanplPjUwvXPymZ93uS2U6mY0N W8jwr8+d22Q5E9dtH219nXYr8DfKo2FTGz25rXVA7VWe6BqK/nZHVc/47MTsonoiTYk6Ngm6evw3 NB7bfOL2Lz4+DSuVcw2DOtDcVG8XGdIVYzZsjGJGsWSZ4kGR1n+u3+95Z+/loq1z4sIO19z7108q TtU97YzM9chJa6Mzyam5VEK5taD5jQ0bIwSgsFEn2+Rc6vnUwtUHA3/Yfan81mBlwxYuTLf2ur0V c3Sq/ug5mSnN+pz7tptDofJfxtpuiIv09kj5N2z2jaNTJ44ad6y2nPvZ/nLwakV9J5RkOpEq8uew BUR0JrG3qglWbQ0MU3QguPIEjQIH2LD5IJ1qMQJiFbNMDijAT1y89Z/2vsgb2yuLbT4OWbWffXRq 57nm+31TXZG5vug88lo0vkgLQtLgkaB2jQ0bIyygyC3KxxBFZxcHJ+dvPnr+6y3nj9a2qrfLBGzY wgPlG7+rGu3dtC2NYVtFpMuLdGGOjoIckFVVVW1Pe1KayFSivdxfN3Vu+PJmbzRBD6UpxQlsdiAZ f9309NXNZ4thgOLqI7jyZBUFBsIJwDIEG7ayBxs2J7qGom/tulAkYyMnYgnTqrX2TXdG5p6Nz6Ni HIklp+YW58wlRiTUZwKADRsjHKDYofjBs83Cs8XFc2Ofjsa3nbn75s7qoh2ukz3YsIUFdSeD5ZuC 3vYiM2yG0U3Xq9AfmXpHznqiGU2fVTRUN3SUxGpAuPJfbzn/eCT+fGphas58KE2pWrZYIvnhF7Vb TtaV6RDxzAiuPNlFgUI4AegL0Wx0riR7s9mwFT1Qth1DS7IFGzYXjl97cOBSi3pRIDQ/Hvzoq+sv bzhGVq1LWLVE/8T8yExSrC8yv4SkllqWwyDVJ7IAGzZGaEABVJ5tQfSzocqFkvrP1v7f77oI23an rU/tV8KwC5Y5cg+U62TQLg5M1dfeeH2bNU0Lf3uNr7AfSiws4SXiUwNtOJTaR57RT+udR5MXFrza BAy0taKaYpzI95rlrZC2Qa4aYux/blOt561wwpgeEKwy5M4TaTJHkBsV6OL95tfZrpmOo9UXg/ya DmRXVQ1g2ExQVxvcGjzbLz4+/erms/ijaCMRlvL//Nelu51jAxPz4/HFuaRIbCXq1nDZnYPjuOFl oXu5I7jyZBcFCuEEoAekVVNH0DWKVF0d/wdwdPoiSQLBVNQcdKdem3B98UCSBWRSLftxcIX0rnip PuhpAJRcB9IcJ4JkQN9LsiFg+guYcAOCLkz7ddKXLnuBtO/pUUNQPzEOkqVty/QTBy9UQBYXbOzs PnLwykne8dauCwV5suVELHGs9sErG0+t23356I2Op6NzsldNTFcbmU7SGEg5Yy2XjjUTbNgYYcLw bGIZ68m51MhMsn9ivnssUXO//4/7rqA0f3nlXimv+28IVq0xHdlOawgfQemmfOucI4s4agDqmGI7 dlP76OnK3Md5KHcGtZ3U4g2VBTNXm2wn0qgnctrz3AkkSG1PMOOJsnEd1m238oR7CyHgjQp08TIJ 2XOzOCDoToQ2WBdg+2yGr5ldVTW7W+dAf2QK5m3DF7U//evx49ceIMeoN4oAuDbh1p6O9UXFhGzx FFE1G7v0DBuuualjEFWHorrDBYFvMXYhuyjwRS4B6IDNqkHSXYuy4l11fAcd8mhTIY26imZv2DLp bSbVso5jfZwuwGhEc19MOi+XDlllQK9LUrDdT8dxtJ814OmCQ53X80rEXVXHt18G7QAX51VD0FsW yNWrd4ObnEw/cfBCBWR1we4bAlj3JFPlZDXQNRR9Y3ulepF/xBPJmubOdbsvvbzh2NYzdxuejMGq Wb1q0qrNJFKoDxtjIEUlOWewYWOEDNOzzS8uo6SOxZLPpxZQCeuOJBqfju041/Szj06hfKO+WIKP iLVpk20ZQwio2miXQqGAfs2flpZ55EJZY7CLndLZbXZBnzI3elUUzhn1DNniKLZIZqr3qGPKr2Yc FkcwJNhD6K39aWO90fTrzhZ2GPdBT2A+cOcJ9xaB7G8UmOnisxl5EuTXdENdofPX8dxoXXmw6/ED jMSBSy2wbVtO1hWDqah72PfbHdV3O8eQ54anF6bmjMUh1fulBFz0102d7+2/UvwrTa8CfIqxB7KJ Al/kFoAK9p4r7+dnmLphCiw+JXXDdkZ1zYFUNFvDRgygt76qZT+O0Ts0StdpvKXfbbU9a9sTLAOm vSQBdSsyqnrQ0wWHujDz3gYoXfbvYv5MPjUEA7nZNv+fOAfDRsx4wfoNAYL+OquIX3x8Ot+9AuTT Pjh49UfvH/nw8I3q5meiS210rnssgbru0OTCyPRCdNawarJXTZq1lYINGyN8iFZx+XC2ZEo8d2hq LhWJJYfIto0luiKJi9/0bjnd+Ost51DcP/rqOsxba9dwKdRvTHXTBkKYiSGjA9HFlKQtXS5UTV/u lOPSZaORTFdqY7tntrDg93Hr23lmJu1WqO3ps3uWgu7OEx6ZI4sbldXFZ2PYMv+aXlB3w/nreGwU lQO50es3yg3IOkhvCMBCRR/Ou7uy6Y/7rjzom5ZuLTk5t5hILqWWpIiUGnDJdQ97N3xRq16veahi 7EFdKoNGQVrQ/tlbi4xWTULVYtPW/rNT0RwMWzC99VUt8zge38I7i/nqam5Io8Zep8hC1T0RcDdP qAszPxugdPn9TJlrCFnbtpANW5AL1m/Iin+dvGDLybo8Lcbb3hc5cKnlta3nyaedqnti+jQa/fh8 amEstjg5l6IBkNSrFopVI7BhY+QLKKMoqanlFwup5bi0bdTbhmKNwt3UNb7pZP3LG47vONOAGHhn 7+UfvnsYdUf88eWVeyBCDi7Ok/RIWXDV++hcgmXCP087oR/BkkUfgVY7eFVZtPyh9vSyFl5KrSPN x72+ne+tCHIutU8wF+R1Lo+zB79R2V18NoYt46/pCc87pjZ6Mev6aFrAMiEA39he2b/qz+FA/vvN 1vN/v3RfPEhU9q0h1SUWaeqaaPdR+5UIcMFNHQNwa9y3ZsK/GOfFsGUfgNajMn6Qab5TOoU0kKWK Bq9bZ6m3mQyb+zgSHtcT5Ftng0BibkKd3asA0BfPJIbpv2966J8NULr8TxeshuC0be5ZZDaEatiC XbDPDcn918kLUHWEZ1MvVoaJWAIVTlQ1qTPtje1Vuypbah8O2n1a/4ToUhuVa4pMJ1KzC0vzi8vG XLVAj8MODjZsjDwCBRZAwUXxhW1DUUaBvt028H//XvPzjafP3HykLZ42MhGn8AARcjBvntxb1UT7 rPraa2nU308lp+prWzcdVaPMzRHett2sbhM5g1kXOCWy4l3rIETabsqld+aWSPOWibT7qC8exPOk EXETxpfybW50wn0uj7MHv1HZXXw2hi3jr+kJzztvfh2L+C55m8wNt/bWrgur1gKCRLi7sgn573bH CA0jGTEeJFq6bi06k4Dv5XlrdqRVFQfSRUGAjxvINgCVbmeoHEsEuZi0+7hVNATD5q23ORo23/Ou oOadMQOmuyR1PeLXtI5ApO2uW53xdMHhvrCMpSvNd/H9rV2YOqG+ddr8mG/D5nEcfefsf53VAOqQ qCWqF1kCefBOWx/qlnJa2vGXNxx7c9fF7WebTtU9ud83RfPTuo0pakNTwqdFpU+LU5fakuiikFYt LxmMDRsj76DqFwrxZHx+84nbb++53Px4UL1XYshOjo0GOQ86j2BNRRDcZpsgYdNEP5qp1EuOFdK8 ZUB9NZ991LthGTbjzgQcZuM+l8fZg9+o7C4+O8MGpPs1PeH56wT4yUJGPJGEZ8t3bI5MxHecafjZ R6f2XrzXGZnrGRMjSSKxJHLe/GKpujUA1/znfVdKVtnyheDFOLwoyCoA7T1s/oMhBdwa6Ibax+eC 3UcoOsOmPmhaBdXNErBlTUewDJjuktR98Kf95wh2uuDwvLD0pSvNdwli2ORyi8bBC9zDlo1h82Pa YMkXIMLv7b+iXmRCe1+kprlzT2UTHNq/vHv4l3+r+OO+K3Bo1c3PvumegENTJm0sgVTVF51Hthqe lj4tLn3awlJicTmZWl4US2SJMWVIXfnLX2zYGKsBFOCmjsFXN5/N09ji1UI26qYyn5Rdy5akOYJj bVxdEwNUWdLsGeQgafdRl52j53HDuDle98EN97k8zh78RmV38b55MT28f01PeF55Nl8nNMCzIUjz 1EfUH5nafKIOVm1/TeujoRlkQeS/51MLyHxIews5PUi0SIArvv2w90OeuuZC8GIcdhRkEYAB57AF uZi0+7hVtPgMm3FJdJGBxNwPQTNgukvKogBknXAzIs1n/UpXmo/4/tYEp1Vb7TlswS5Y3zmLX2cV QcOv8AcNaARR7aSNH311HcYM/NH7R8SVv3Pwje1VHx6+sffiPTi0R0OxJyOznXJFfuHQxsWIRzJp yFMjM8nxuJifpnyanKIGn4a0tWqJiw0bI+9AOd5Z0fDe/iulP1jIX91US6TVZeSjZWn0kWCssGR8 UKXMAIYhzZ5BhFXt43miAMPZTQTL8SoZBPleXufyOHvwG5Xdxedo2Aj6r+kJz32CfDAfyKp5MiCQ Mj84ePWXf6v44uojZMSuiEiEg5PzETkMcm5hidJe6Rk1CSRqXPtfDl1d449c80TwYpyfKAgUgAqZ bJs6VFopSLePh4oGr1tnqbe5Gza7kGbeOQ187rz7mOnOElzVA58uODJ+1l26/D/iqiGYsHu/Qq0S GeyC9Z2zybmrhzc/uyCu6p2DNKARhCXbfrYJPHqjo7q5F97sft80MhFIs9GQkrojog+tV451RG4S Dm06iQwlTJoc9BibF6lqXvanpYRJk/1pAuq8qwA2bIz8AoX50xN11Q0d6nVpQwkW0rn3jHnb0BHa 4hoSoAbB++cAlxDTyyCjB9WeroObTXd6MnPC7+OmLjsGxvgKvXcFwgXjmD6jJhzLJbvP5XX24Dcq q4tXh81xUJD6eNqU5lnV8Ny4OoBhC2VoHwzMjjMNL284jpR5qu4pjS2RVk2sejwxKzrWkP9k8lvV tBcucOFD47Gff3xavWbYELwY5ysKAgSgA1J5xEfEp5zzlPwUBlVbXa6zU1H9CxrWzrY9S731VS3f 41gwa+pt9EeO0ke/XYAMmPaS/O65C4FPFxwB7pVeuowfNEANAchxQX9Cpp84QKECsrpg1w0J/Ous GrqGor/ecu6xMGNzdj/WGRH/0uDG7sgc9Z71Ruf7ovO0asjwtOhDg0OLGt1osfml2aQY8ShM2pLZ mSZ6IKD5BUlYbNgYeQS5tRIfBmmHoW4kUqoJ1nrGjj1bWOnZ1DKPZdlxQO3RMW61tUmqUxal3Hvo qU1Abc//cRzTE9bHbaulWUP2nblQ7exOZt4VCA+Yp9NyFa6ZHKb1LVzn8jy7ccDANyrQxRt5Tt2T 0SnbeBsNOGzGX9MDnrVSz42rg4pbj/ZWNdHf2SKZWrp+v2fzibofvX/kj/uu7K95QDMBuiOi8dJc TQu50LaUVinbNZm5L959+mlI65KVGYIX4zCiIMcA9IDNttl0zxgXYIm/MZLNXWUPpKJmmjDkxVI/ Seuy1WGD6q2vavkexwbzK0h63Tp8a/mu2y1YCJYBgfSXZFxMJlUPfDqBINfvujC8DJysBTPUEFTZ 1tNfYPgnpsCFCsjigs2d3b9dkJyrvm/wppOcsLuy6e+X1Oxo8mMDE4KDk4JIQM+n4M2SI9NJZCLq QEM+mppLzciBjnNJYc8WUrIbbekFKHvSpEmTaaqwqYoNGyNfKDu3BpA8QbVt8mdSVyIzu+Otc8b+ agElWw6w7WNJp5ZIrMRDR/Dd0zYO3iJ0k/KTV+p1wGyEc/F1/bNu7VbwrkB4w/b1deImm6nCfS6/ swe8UVldvH6RWpXLBtue6X5NHWFUVcNEf2Tq1c1n1YsAGJmImytrwae9d6D2i6uPjDW15FxtY0Gt SaNXjaZoy/ynDlKiwPXDc246fru8hC40mLVSLzoa5tNFgRe9wjDHAPSFtG2OE3krJLyZel8gCxUF bGnC5LYbanCmtX9WkgX4qZbvcewwa/zab2TC2CH9jQ2SAYGMlxRQ1QOeTiDY9WsXZrulvtdgfORo 5hoCynaOVk3Bdj2StoIasFABWVyw64YQsv110t/zFSGeSL6y8dSjgRlaGiQSE34sOit6zCbnxLBG EMZsZl6Mb5yV9kx1oMnZaNSAKLvRlDdDdqI/1AkKDTZsjLwABfx2GT5AlgRL5jBbEyzk29nwZsA+ KUJka6HOlCrs6Uq0ftklz3ttKG03sZCuOKlb7u0XJmyPPFpAwybguh7ReOZbN3JnWZ8KhC9kU5yZ X42b6fhe7nP5nj3Yjcry4vE7Wr/1Dc8ajIGAv6YD6aqqgW9jiMho2DSH9rOPTpkra333PCYHn4ih j31R0aI5Mi2y5tScaL9EakzRdLXSt2oEfInU8ov1ey61dg2rTQwbjJqxJzMbtjQf92k3ySUAs4NU dVOvfOrcAVVUwpEmlGK7hCh7vfVWrTTKaYdRvfbpD1EnzdhbEiwDBrikIKoe8HQCwa7ffWEZS5ft I0FqCCuE908sEahQAVldsN8vFeTXWY0ett2VTf996T7c2phcdng2CUsmko7oNBPDGmHJhCtDDhL/ Km8mWtzUOA+p5/L/RQo2bIzwgRKPAHh9W+WqP9iawWCsFDBjb+26AAfS/HgQrgzccaaBFtd6ecNx JF27Q6PZ2zBpYmUt5dPEgiIjM0lkzcm5xRk5V3vBWFBLQp2oDIDvgu+FO8OGjVFGUFVzP1ec9t3i R/6u38/SFC1K7oJ9IWevne+Nzo/OJGPzIuOQJSNXZnWaif9LY0Yspg60jGDDxggfCIDK+vbPKhrU awaDUTqAQ/tff6t4c9fFdbsv0+Ja+2se0OJa5qNprLWP5VQBWlmLHlBD/WliTa0k+TQxzkQ5tZLJ jEGB75VMLf/pv2v4CWyM8oEa1ek9HlKN18hnV0l+kcfrZ8NWGCRTS+t2X7raOjA4uTA5tzi/aM6O ViZN7VfiYMPGCBkIjeUX3/Mi1wxGKQKZ75WNp2DMRL+ZdGVycS25vlYk0T0m+tDE2sdRc+1jMVWA VtaakRMDEnL8CQ19NHvUyiZl2oEvhS+IL7u7svn4tQdqK4NR4kg7eo2q+D5ergSQ1+tnw1YY7Dhd f/DKw74J8agY5CBkn3JMOGzYGGEDYZJafvFvm872R0p0vASDsXZx5uajTSfraRKaXFxrARyaEotr 0aNpRuVYxwkxk1s9nUaYNNmZRg+oKXufZgcZtusPet/dV6M2MRilDTWBzXvEoOyeKtnBkPm+fjZs BUBlffvGo7eRsIanxdQ1ZCLZvabeLSewYWOEDMRJcmn5h+8eTqaW1CYGg1EKoO61+72TA3L9feo3 m5LGbEZ6M1CufSxmcotp3MbMNMOkqVkBawfCsKWWx2ILuG8TsYTaymCULmjEYD5X8ytfsGFbbTR1 DP5p/5UnI/GhyQUkLOQm2b1WnkmIDRsjTCBOll98P5NY/MmG4/FEUm1lMBilgP0XW3ZXt/RHxSpb sXk5uDGlHkpjLK71wjaT23Boa8yk2YFbgHsCN7v1TMOZm4/UVgaDwWDkGdKt/bNjOD4wMT8eF8+M QZ4SWYkNG4OREQgTxEsiufQfB3gOG4NRSrjc9HTDlzefjSdGZpJwIDSwRLkyY+q2ac/knww1AhwV hafPZ36z9Tx3sjEYDMYqgPrWOoZjNHVtZj6VTC3T4z3LFWzYGGECoYKASSwuf3n1wZ6qJrWVwWAU N1q7htfv+frxcGxocmFidjGRXJItlWzMMgC3BzdqfnE5Gl88UNO6p5JFj8FgMPKL0zfbkLA6huN9 0fkRY+qacGvq/fIEGzZGmED1jqovHYNTv9p0lqexMRjFj/7I1G93VD3on+6XjxydNQaWMIIANyqZ Wo7Np0Zmkm/v/bqpg9f3ZzAYjLwAtcr//PI6rYwl3NqMcGvmOv5qpzIFGzZGyEDUJFMvpuYW9136 9h8XW9RWBoNRlGjvi/z71vN3n44h+Y3KwZCIX5n81A6M9MB9wu1KJJcmZhefjc/+dkd111BUvcdg MBiMkNAfmfrdzupjNzuUW5tekG5NjgdZAxmLDRsjZCBsUksvRHvz9ALqLqgOqjcYDEaRobK+/fef X3zQN91rDCxRTZXqfUYg4H4tLi3H55ciseS33VH2bAwGgxEujta2/nrL+dqHgz1j4pEzkbXUt0Zg w8YIGWZ7c3R2sblz9Ddbz49MxNV7DAajOBBPJDcfv/3R0dvtz2PyCTYLU3NrK/mFCNww3LeF1DIq ECMzyfbBmd/uqOKxkQwGg7FytPdF3txZvfVM43cyWw1NLozFxCojtDLW2klYbNgYIUNEj2hvFp1s kZnk3aej/771fGvXsHqbwWAUGs2PB//1k4rDtd91ReZ6pVubnFtMLIrHXhPUfozAoIYqOF74XtzP zsjs+j1f7+cx4QwGg5Er4okkVPSN7VU19/o6ZbZ6PrUQnRUr+Cu3pnZcE2DDxggfZt1lOiHqLt8N zvz+84uV9e3qbQaDUSB0DUU/OHh13Z6vW3omuiOJ/gkxDWAKbi25JN2aaHBRuzKygfS54iF1uJNw v9C93uj8f1W1vLmzmocYMBgMRlZIppbO3Hz0s49OfV7V8nR0rntsbmBCzLKemkslkuK5oGW/JqQb bNgYeYGouyy9SCwuT84uPp9aeDae2Hi07k/7avojU2oPBqNkUd3QUXKTM8mq/XrLuVN1TztH5xCS g5NiTcgZOQ0A0cpubYUQju2FeCwbPBtqFSPTyb7o/JXW/l9+UrG7simeSKr9GAwGw4kDl1q4dmSi prnzlY2nPjlR39o3TcNAUI0cjy/G5mW2Mh4QutbAho2RF1DdZXFpeS65BM8m2pvHE5V3u3/5N667 MEoe7+y9XEKjfHGphlV7IpsqE73RxPB0UgwsEQ8bpTUhZcQyVga6i6hP0PiC0Zlkf3T+8Uj875fu /eyjU0drW/lJJwwGw403tlfySkWQR7JqHx6+2dIzAav2bFyuLxITHWtzyeXk0prOVmzYGPkCxRQ8 W0LO6xiZTvZPzHdHEn+/KOou/7jYwiOFGKUIJJUff3CkJGrezY8H1+2+9OauizarNj84uYD8Bzsx lxTPW1tr0wDyDal76nGUsfml8fjikBxi8KB/etuZu6iLVNV3qF0ZDAajpHJKnoDaIOqEL284DqvW 8CTSOTpHS0Gi3hiddXasqU+sRbBhY+QRsupC7c1LM/OpsVhyaBJ1l3nUXT6vaoFte3NndU1z51rW KUbJAS7ovf1X1IuiRGvX8I4zDUh+63ZfvtDca1o1RF9kJjk5uzgrZ2wbwyDVpxhhQeoe6hbf4ybP yiEGI9MLA0L6Et8+m/zoyG38NNxixWAwCMWfU/IHfPc/7atBbXBXVUtr3zRZtf6J+eHphfG4GLGf WFxeXNsdaybYsDHyC4oxBFsy9QLVxAnUXWZEVxvqLp2RuZr7/R8evvGj9498cPBqdUMH12AYRY5k aunVzWeLs6CaPu3NXRf31zz4pntCWLVIoldMV1NWLT6/RDPWOP/lG7izuMeoauCGz8ynonExMhzS 1zOeaOmZ+LzqG9RRUFPhFisGY41jwxe1d9r61Iu1gfa+iNmqeLax68nILCqEqBb2R2HVkuPxxWlY NWsMJDcsCrBhY6wGEGuIusWlZTlMSNRdRqaTA5PCtnWPJdqHY6frnv7nkduowfxqU8WBSy0wbyHO EZqIJbhKxAgFW07WoYatXhQBYB2R6d0+DcmvZyzRNzE/NCUGQE7OpeI0qsSyauoIjPxB1jNEV1sy JWbzogqCisjzKWnbxhJdkbnzjd0fHr6B3w6/YPNjfm4bg7Hm0DUUfWN7pXpR7uiPTP3jYssrG0+9 sb3KalUcS6AqaA6AFMP1F5agmUhV0qwxFNiwMVYJ1EaCCKS6S2x+CbZtdCaJCmVfVIQrqi+do3O3 O0Z2VbbAvKH2+YN3Dv5q09l1uy99eeUeiIoyXJyfkUPNld4F4few/5/21fxuZzUO8vKGYxCIwzX3 eLETxkpwuekpytK/vHsYZXJPZRMK5OpPE0cZRs2eijcq+j/76NQf911x+LTxRJ+cqCaHlCxOwaot aL1q6lCM1QHuN248bv6CzbZRbxu1WD3on/5HTeu6PV9DrPCzVtx6xOvFMRhrBGW/3EgytUStiqiG /fJvFbuqWhqejLlbFSfkXDUoJA3XJ6vG6coONmyMVYVZd4FtQyUyPp+amltE9WVEOrf+qKrBdEUS MG8Iafi3C8292882gR8evgkXR0bOTTEjTr4Lwu9h/7ON3V/f63syIo7zTXd057kmasnmgZeMHNDU MfinfVfahmYeDcVQJvdevIcC+est51D23txZjXJF3cLhpt72vgiOCWcIh/bBwatIeD96/8i63Zdl 8e5SJm10DvEiMp/h08ZiYvSjmfzUyiIC6rCMVQbde/wIqIiIFquFpZlEKjprtlhRh1sCv+a5xq5P TtSjWgOx2nyiLtyxBgwGo6iwt6qp4tYj9aK80B+ZgnwhbSFnUaui6dO6x+YoW43I0Y+iVVGO1ae5 amzV/MCGjVEAyGikQZJibpvscBPOLRpfjMwkh6eTiOSBiXmENPk3ZeEiomJKRs6Pah/5b5dsvwFx EHGcyFz789g/ah7A2n301fU1tYTuRCyh/mLkBBin339+8bvnMRQqKpAgihmVxpp7fftrWqlbmCwc KJ3VJRCFDXYrIFFHx0eoZxh8Y3sVjvnh4RtwaKfqnlDCA3EZonjLgt0/IVYTQeYzfNoSAsqR/ATU F2EUEPQ7OFusxBPb8MPh5xucnO+NCr2isQbfdEcPX/3OPtYAVR+UkObHg3lqckIFC+bw+LUHBy61 ULldUyLJYKwyKuvbf/TBEQQ14q4MZm1AQK7f7yH1+Jd3D//ybxWQL6StR0MzMmclkLB65dBH1PHG YouTc7JV0VgBS7YqUuWQ05U32LAxCgYRnGKChwhUanhOJJfiC2K0JCoxE7Oi521U+LeF51MLQ1ML qNAMTM6jegojh5oN/rWTtuDdgUmxJ4hPQRdGZpI4CP4VU0ekA0Q9+9jNDlSsIStrZN7Ie/uvcDt9 zkC19a3PLz7om0bhQblCoVJl0t6sIBoIHK0J9/umLzT3Vjc/O3qjg7qIg/CLq9/hI2bPMGi2QUiX OPdsXJwR5yWTFoklo7KFckb2p9l8mowvTn7FB/wi8neBc/seP9bCInRPrEoyOSeGStJYA/y+vdF5 /Nxk3lAMbneMnKp7ihKybs/XP/voFCwcDc0lZ0VuH7UlhHlGYjfaH6Ta1a82VeCAqGDBHG453bir sqW6uRfllkQSH1GXzmAwQkJTx+D6PV+fbehCUCPuEM6/2nS2tDrVkRlrmjv3VDZBJcihvXegVqrH s0dDMZG8jPlpyFkydS7Ap03MLs4kUrNyoD63KmYFNmyMAoMCFf8p5ybXJpHNz0uox8C/oSqD8J5O oEKziDoNqqeo1ozFRE+6nbQF70IOsBv2B/FZHEGawBQqtVG1vraoYaMSfPGb3nV7Lr+y8RQUp7zb kuOJ5Dt7L3N7eQ74uqnzje1VcGu94wnkG0o2okwaJYq6R+DfRLfwpJiQSRZOuLixuW7ZFSb7e2WP XFrSbtR9Rz3DZhsE7JlsgBBj/VHOEQso3rH5JaS9RHIJlX4a98g+rYRg1z38fGKGm1Qq/LIoV/ih 8XOjlkNNVLI4ic43YeEic09GZh8NzWgtAqgtoeaXkdiN9gepdnWrfQQHpIXaqBASUd+60PwMH0GF bK2tYsdg5A/IxUgr3z2PUcSZjTJfXH1kdqq/LFZQFJOlK249goUr7DAZVCGouQcXQw4NV/jrLec+ PHxj78V75NCEgKgRjyJ/UWeaNfpjTiUs+DRU8LhLLQewYWMUEczopUoM+TcEthg5iQrNohhEBCYW xdx9T6Lyih1Q9ZFTd8RnxRGMHjzsgPoQLXaCmpBsw040Ph2D4vx6y3ma4VauzckjE3F4tva+iHrN yIRkamnH6foPD99sfx5D7kHWgUND2UNBQvValMmUWLEdhUo0KySEf4OdIwsXmYGLE4kKLkv0xcn+ YaQu/Atf50XRAIkdsCcZs5EZcRAcitogcHCzAQJnFDlvSeQ8SnuqhZIzXwnC/OFgtoXiSaXC74ua jWwUEL8+LLocayA631BaYOFQINO0CJhVQI3iXTme1twNf1MDAY6GY4rWAVnHsk4kRfLiN71/3Hfl ta3na/ghBAzGymAO2YCroYiTgSZiUI6IVsHb0jNBk6U/OVEPC/fyhmPwSCDMEvHApZYvZT958+NB clMrjE06CK3ZRn3v4I/eP4KT4l9q7sHFkEODPROSIsc6dstJ1EJAZE8aUhjyFyUvpC3KWWaVjH1a zmDDxihSiHoMRbXxN8Kc6jT0bxrK+it9SkgCHYFMICQDpg62bXIuhQoxxKVP1khQcYE+/qPmASQJ 2rT5RF35tSiTZyvXKc7hAvfqdzurD1x5iHotSgjcFywTqtEw/8od2ZoVDP9mtCYsLM3Cxc2nUMxE X5zs7AVxBOol9iFcmUhv2D82L0wgDoJDURsEzCG1SuICZAlHkZYlXJRtdc2Mkobxa6pyhR/aPtYA /o2GCUzOinEEYzFh4ZwtAqIblloEBqTXQrl1DB2X9ULUDkFqHaB/qYEAR6MKFpVDnIi8IkQSB8fH USe79nDow8M3qWGL17HMH9r7IvyMh3IFflxya71RYWxouAQCDdGHGMQWEb+qU10MipaVE0G4I+oG p351cFdlC/WTr9vzNbmpf3n3MJk6JC/T19n5ykYxmtqPdBBas43GReMs9/um6byGPVMOjQaAUPsO tTDScEd8HVvDovJpMmdJSIlT94KRJdiwMUoJFPKId3/Kt30gxYKmjohqEKrUEBcIJVRyYFI0WkMf UUFv7Zs+fPW7P+67Avn76KvrcDhl0zEFH/LWrgvv7b+Sp3ULygDJ1NLR2tZ/33oe1VMkS9RxkUfh o8itaQWMXlESwpsoWtSaQM6KGhSp2p2UPXLU9+tN2XcHYn/6ODVGEuWZ5elkGZb/Z5QtjB9amTdR osi/yZGT8PDUr+vVIiAcHapNsF7mQHHzD+qtxQ7YDTvTp6iBAIYQxzRaBxTxN4lkJCZsG+wfIgJ1 zX/UPBAT3nZWc4dbPoBbyqMhyhJ1D/t+b7i1kekkIouGS4D4Q3SqGyM1EK2yU102x4gmGFg40YVF vXAgtTKL7jjxr7BS+AOeilhzrx++zs2GJ2NPRmD83BR+zLBkdExxfBgzVIpE97ts9JFtPaKhB1dF Ax2jcvQHLls6NPFF5Ph8IVa2zAVwzgoBbNgYaw5SO1StGrUfUklIpLlAJYSJRiZ89zx29EbHJyfq 39heJdqfdlbvqWy6fr+ntNxOq1z5Dc7zlY2nXt5wjBaF/+UnFfsvtvCD6TTcaev7108qtp5phGlH GUBhQE5C8UAeQmkhqF29QO8L4m+iBeoizkD5cXEO4+NE/MlYoxDlgUqU/AOFxG7hzBYBSJnZIkBV QPfQcenHRAVR7izsH1WtRMuC1TQgTmGeCMfH/qiNoVqGWEANsl8+Pg7yWHO/nzrcynI8QmHBs47L D1/U3PvjviuOAfbJJTPuRKzJNj7ZUCI61WWLDI2LNgfbU7+66NFSXk7aOeQpRKXRqS7Ck0xdD/4I QhoRLTvk++HKaHy+7LonY4aTonYkWnxkcw+18hh9aEJ2XA7NSn/qyzPCABs2xhqF0BRRRf4eNRJq SybnRn1uUENoVt+EcG7dY2pMec29vr0X7713oPZnH8H5HKdVtmGHis329Eemapo7d5xpoNXh35Qr v8F5movCd0bm4EU/r2qBOTlz8xG3kQPtfZF1uy8hoTY+HcP9ofEq0fhifH4JCQl5iKD2XhnUsWxQ bzAYmUDlRdCoEkmILSikkmrEuPmHRrJkql5FUIciWqWRXuIjqI1R2xbqauNxUWVEHVEMSYjMPeib PlwrxiPQUEnoofowY2WgEew8FKIMgBoCagufnWvucg2wt0GFM7ZRnOJd2RxjG2wv+9WVkTM61UGz Ux1Vl4gcWjliTKIOQDGaUViymOgxw3HM7nd4xZik7H4XZ8dlUJOQy6EJ1aDrV9+ZkQewYWOsaSih MTrcIEOQJAgTpAqyBf2Clg1NqQkhz0QFRc3sb+mZoFW2YYdoVu5rW8+jxr+nsgku7k5bHyou+TZC XUNRnKXi1iOc8aOvrpsj1H/5t4oPD9/YX/Pg63t95NDU8AY5toGmslAv4rfPJjadrMen1rJtwz1E Nn1je9WF5l44c9yWgQmRU2m8CooEygZnIUapQGiaglA2F+Ub2YA+Jdq25OPjDHkU4ySfS22kDjdI Is0BZucWFvojU69uPsvz2Uoa7X2R/72z+nTdE8Ot+Q6wN0GbRc1E/o0dZSOLrKXY+tXJy4HUqU4j pWGuyNRJX6ccV3rSztKVqfGZYso0dbzLShFOSt4MlFctr9BQBnXRjPyDDRuDIWAKEMkitSgnksuQ M8jrhGP1dmF4hHmTT0lCTYVMUe3DoermZ3sv3oOL++O+K6i40Axgc/qvuaaTSfJ1ftR2JtKh6Mi/ 3nIOZ/nkRD3OePRGB85u9aFJk2YMdUgMyBEOuH618KD8OsPTYnIz9kFNa9OJelSzDtfcWzuP2IZB rWnu/NWms7iH8N64abgVSKiiY008fho5VYxXofzEYKxxUBwgHEgeUatDJU91uM0khybFDDdEkN25 /ej9Ix99dR1Rxg/uzxnxRPK9/Vc+q2jgcRCliP0XW97YXnWrfZjaAZF/lVsLMMDeDtpXEH8TFVRv uWmoQKQt8nUBSfubH6ceeHk6CeuMaou6Jsaqgw0bg+EACRL+UQ1acp4b6u5ztHq77HmLxkXrMvwP XBBUWMwGlh1W3WoqsOjOolGUYM29frmmU6+5ppNJ8nV+1HYm0sJN9FRKw5jRCt20PLfsQzPWboL3 GJUObULODBZLC9BUFtGLuDwjH/c0PJ2E/+wZF2sJ7DzXJCe5XUIdq5int8HNrqT6MjIR/8fFFhjU Dw/fuNU+gtuIW4ebhjuGe4UbNbewlFxaRgEQhYHzE4NhA1XdqF5IHW4QFqjieHwRkqjmAI+LkQit fdNHb3TIeW7HXtt6/sClFl5IIzdUN3S8sb1yTd29O219X9oWlyf+aV8NNVwW/+w+XOGbO6s/r2pB ICApU3JB/QHVCcROuGlFpilABKYIz5zJKa+4wYaNwfAG6Rb+MZuvFo3J/Qk58ADVFDF8fG5xPC7G f6OyQvOAB2llbduTVcjLUXcckcZVEsnd4Q8yYKYHs9P4oDRmEdEX9GxcDGuE1yJvBuuIs+Ma4NBo OThcGyyZOc5BPbbLaELD30nxhIPl6YQY+UlDm3BYHP/iN71wMj96/8gHB68WiXNrfjy4p7LpV5sq fmCsPkx9jK9sPLXjTANSexD/hgx6/NqD3+2s/tlHp3ZVtaA2iVutrNqUeCA1fkrcrmRKuHSRUtXn GAyGDpJH0kYII1RxjtqzjN575dxkAxYU7NrDoV2V37yxvQqRi5o3KuIlt3pTQYBbBH3D7fr5xtNQ vN2VTWXcXYlcg4zz0VfXUUj+uO/Kdtvi8sSzjV3UcPnrLedo5C1ujvpw0QA/Gb7Cr7ecr7nfj8KP KBCjNuKL8QWxxr1wa2pHBiM7sGFjMDJD1E6o7UqNQBCGR3oeNRtYDByXCzqBsECiF854ssqIXHwS kg2SsxJLMBlPTCJrB8Iv9UXFIvLkwegtuY/yYyAdBByZFgaDjBlshpoibDy/CzZsfhHGY9kcfS47 i1QdS/4hvgu+iPgKso1cDm1apEGS8vEvYp2V03VPybkh/aB2VZAxOcjHcGXr9lzee/HezfbhJyPC 1pqPhWl4Mra/phWpHftU1Xeoz9iAa8YRkNeR3ZHjt5xurLnXj8+iBomqJG41biZ+JtxD3Df8lKh6 inslf3F1CAaD4Q8SFsO50RzgZdHnZgwjh44h0ISqyPam757HLohHSH1DqzdBXuDfvpQP/+WRkwBu Am4Fbsif9tXg5uAWQd/It7QNzUAG//WTisM198pvhOSZm4/w1ZBxjt7oeDQ0Y4wfEW2I9FxmlB/Z 7imbO0fnvumO/qPmAW7Oa1vPF8k0PxhOOOpfflKBr0ApZmBSZGoxakNMh1bJhcHIDWzYGIysQYZH +B855w1EZQXWCP5HzANWoyiFERJGTjY8w03Rsk5E6pqDr6NnIsHdgeNx8eDaCeNBSQbpIbbSktFx jFnCc9JjgDBd0p5ZDk2aNLpAVaNSl24DvWvaNtg8HBxnh8mEOZR1LJEskXiO3exA7cpsGocFWoWq FZIfTod8TBPzRNqWfZViVp4k9V5S12VLz8RHR27/alMFDZUZmYhX3HqEGg+11O6vefBN94R5kF45 ZBRVSdxw3Fj8Rvi9cOtw0wh0AQwGIyAobPAfiaHh3IT0IcQgblCV5/Jxl9TtJpqEpLa09k1faO7d Lh/++/KGYy8X8eq7eQKsF81Yxhd/xfbklbONXfTMYpgT3CjSLtgVOXa92a+JqhSBhPKrTWc/OVEP D0bfVIi8mHotWi2pjdJq9KRp5HL9enpu6rWHQ+v3fA21L+DD3PEjHq1thbuGo/7ueQy/lOpYE9Oh RZpGXkZ0cG5hrARs2BiMFUHUVMi/qb8B4YLINYmOOGXklKES5kr+C5NAJNOVkFPL6G/QfNf2PGV1 EDqazZiJ08lkINIBVZvkn4FAn6ILTi6Jy4AVnJLjPEemRXbskwM7kUSRGi9+07ur8htYILNqdfza A9Q21LHCA3zXb7aeR00OLqs7Mgd7hqoe8p/oWhSz8hZB/IGX2Ii3brcPn7j1+M//qP3R+0dQlUHi RPpHjUc008oBpagjIoPSQSJyUl9sXrR64sbiToqGT7oRDAZjBaAwwn+GcxMKRmMQps3Vm6R5o543 MftXLOAkFAbR2uJcfRf1+I++ug4zU9PcCZ0pgyGUcKH4IuTQ8NV+taniX949TDOWT9U9ocYpSBaI ewLVwv3BXaJxFuZNw/Zvn01+dOQ2tA53Rh26NLG7UszlvtU+DF9KKo2kgxIyLtsuqZkSnkc0VhrP iJ+cE29BxuHiBlCE5OrN5xu7f73l/LV7Peq4qwj8BPghtp6529o3jVyDdIkfa3RGdawhxSAQCOoD DEZOYMPGYOQFpM+i7kJ0QBgkG0XNRvou8Yfxt/muoDiUCeuYaqM65QpAR5HnogfTvUAdSzo3uZbA TBI1BnJu9GADs2q15XQjahtiXpl8qrhZtVpJYyc+/sb2qoYnEbOdkiwWUjWtQRyZStztGDp85f4n x27jvDj7a9sqP/rqBs7e/HhQtNDXfkc1HlwwLhvpc2RaLb6CrD8rHx9MXWri3sqvr87NYDDCAEkK /lGqIlcomV8UU90QwrLaba3eJJpdzEen2Fbfvd0xcvRGB8zMh4dvQmd+9pF4bMnLG46v232JjFzF rUeQiyJcjQOXhAujZ65sPlGHC6YpuHCh+CLk0PDVaNEjUH7lOXhXkizqWaKh7zTuHXcMJEEenl7o l0b37tMxenb5sdoHJdchSWMo/n7pvtTqORhRGDCoNL4jdF4O7BeNmxBq0e4pCf8vmy9F/+2sem5q ioaEwLZ1DMf+40AtHKA6QZ6B6z9z8xGsGn4CZEP8fPjtUIxxPbiquNGxRimGwVg52LAxGAWDqNNY wEttSwF0nq4BOQZmBglyQY5rQvqkigKNa0JlQpk3W9WKnipuVq1++TdVO0FKNpf2Qg0mI+G4UC07 drPj5O3H/1XZvPfCN/sutsCDrd9z+e09l1/fVonD/viDI2/vvXzgUgvMobuulkwt/em/a2q+7ZU+ bQGXjeoOfNoc1QBklxq+nfimbNUYjPzDiDXVIEXV7gXb6k3Cv4kx4aLbHG4E9W8xeFI9PUV173dK Y/NkZPab7uiF5l4ycp+cqIfavLG9CrJAY7ZBUhtPwVEXtAJoBwSv3+/BufZUNtHZcSUgLgkXRs9c +eLqd9XNz+DNaOYtaB/lSMtHoaJP7UrQ2PG4qPFT+xTuD+4S7hXumByg8YIGmuJeQYrxQRwBbmHr mbuQTXiVUumEpDEUF7/pxU2gVjlYNXxl+HkkHaQe2Zqm8pEAyo+Ua/yl0pMx8ha3CLcLJQeJCQXm vy/dh/7ndY4fkg5M+MsbjuH3bXgSob5BOczeGgOJQi6zjLxiBiMMsGFjMBgeoExpd240rgl1BVm1 Eo90M6pWot4gqlayCmKvWt3vm0LVylzai5qW0/B1YxG59XsuUY8Z8Y7xwDqaopYR8UTytW3nHw9O SZ9GU9RE+pQZlH0ag1EYiNqrYd4Qi9SfDyr/Jnv1EbNTcvouavBwL0Jk5PJL/fQAFdkHBZdiGrku o89fLmciVhQktfEUHHJTdpLL8uQrG0WHnkbtgOB7B2pxrr0X79F6hrQwErky4wqFMQNx5b1RZc9o lCO+XUQuH0VzlVHXFw5NDoknh0aqJWv+6qbhJd6FrFEjmrRtCXouy98v3YNt++ir6xBMdceLEhOx xP/eWd34dKx7bA7OHKkE32UuKVvTaIVe8XXTqbSxgzVhEiUnKvsecXurmnrg2dSu4QEmsKa587Wt 5+HGv7j6COWNBttT3yCs2kwihd8O12NYTfVBBiMUsGFjMBi+EHlRJB7DuclxTfaq1bScl4J6A3W+ wb+5qlZijS9UWaheRRT1GNnGTDUbk9vONB6rbVXnXhlQZXn/4FVjUIr8ImlrAAwGY5UhtMUQGeXf ZPNQ0lizxBQZVOilzoh2InJx1FoEz4MavxQc0WYkpsN5qI1Y81aTGhDOCoTHI5sniT/U39jY8GSM 9qGeMbN/jCj9mNH7J88CS4bqO4grwfXgqqjfDNdJF4wrJ3tmjnLEt8N3xDfF91VPXpHVfcOh6apF W/CulOIXcHc4CJwttFcMkpQm9tjNDjnNWKx6H7CFazVBIyAuftOLu4Q7g7thLsshvnWWKo19sb+0 baLA4G7gDuNW7Lnw7f6LLWqnFaM/MkVLDX94+EbtwyH8+rjPuH78vvhZ8RVw3gQMp+pVE6WawQgd bNgYDEYgUB7Cv2bVCjkS5g25FrkqLqeGI2/RjHBUrcZiwsXRBBWQWpTx76D9SQaypgXC3bX2Tb2y 8VSIQ1le31bZ3jcmMqjawGAwihSo5xoKI/6AwlALEfW/0bSlhHBxop8fUkPrT1BfHPwPdcfRKkS6 2kwKMyNEJip8lPwD7k4aPPgralQSq8YLx2X7Q8woE5QGDIRGGR83/JhcxpDOBe+B86L6PgJXZjwM k/rNcJ24WlwzRBIXL+2ZHOXofDam+Priq6s/1H3xAu1m2jYyKnKZqCSuCl8NdqKlZ+IfNQ9+veX8 rzZVVNx6VDxDJXdXNv33pfu4n7hdyBS4Ifh9pc+hr5UL5B0TvbUoJLjPuP+4D+/u/2fdwxX1NMKn Hb/24LWt53/5t4r9NQ8cj+6U41fxE4tBHMZXkGaNwcgX2LAxGIzsQIlVVizEH0hUVLWiqSm2qpVo II8ZRs6sXUmK2gyIag1qWvg3Ekt+fq7pWO0DdY4wcKet74ODV3FVnEUZjNICaYspMohhWSFWLm7R Wn+CGoyEC/JWm1nRfkSjAEhq8C8q9BAcVLhh8OS/osuOnB5R+C65Xewg+/SwP33cPA7kC4eVj2BR T16BK6Mes9kkPQxTTZoFcbW4ZvJmROlQ5LdTfiNrkRKflWMfYFRokCQugJ6gABsJVwm32RmZu9U+ /MmJ+p99dArO7cCllsIu0AJN/uO+K/DA8Le4e7hm3JlQfI5xN75HAsKvgJ+4e2wW3zqHJ9B0DUW/ vHIPtws+bcvpRqNLTZh2+EAUDxwcRUusjCL7RdWvKa9BHYLByAPYsDEYjBVBJsoMVSv8Kx9mICoW 1Ck3vygm0yNhE1HL+fnG0+E2AydTSz/64MhMQlo2zqQMRimD5EXoDFG+RGST1Bhqo6yR6L9yqI1q QhIUfVxiRHdcmivp8YTNw7/CccmlPuglUewJDyZ7xmDD6CA4Gh2WTiFcGVky6crwL10Srk1oj2nM 1JWLl+pbrRh0ZFJdXAZEFdcMDwlXCds5QA9OGBODQm93jOyqbHlje9WP3j+y+UTd9fs9q7ywJAT5 Xz+paOoah5+E3cUtxY2i+xMWcCTch4VF8UxRGNfTdU8++uq6ei8tcG3Njwf3VDa9svHUr7ec23Gu iRaJoZGuveNi3U65hJVYGQVXjp8eJU3+xPKXDfE7MBg+YMPGYDBChkjBolJir1oBVLsiqjoWEVWc vsgMDJv6fHjY+NWNS82d7NgYjHIFaUsatSGRcWuO3eAJo6WaltREMqOlScytsnswonk08yzyGoTK GJehrkRdZZ5BZ8J/uDBcKjwkXCVMy4R8Xtlz+dSEZ2pdqERr3/Thq9+9d0A8tfJXm87CvFXcerQK PW9nbj7adLK+LzqPS4IHxh2m+xYucDz8LjBUU3MpfPF/33LebyIfmbQDl1p+t7NaLnZ1ee/Fe/Qo vC65Tgy87oB8vgIuGB5YjH40Ht2JU0ioQzEYqwA2bAwGY1VBiU5CVmtkfr3Q+PTTk3Vqj/Bw/NqD 3ZXNSN6ox4jzMRiMtQQSGgmpNobmeNAO7S2i/QiCCupMxQG6MPKTsBbzi6J7cFoOlYzIxVoGJsWE 4Z7xBJxbZ0R0u8G8fXKinh6NQI/TrGnuXMmDND0xEUv8+9bz93sncQ2wUrCU0vOod8MFjgtPBXMF v/rP+33rd19Sb8hpaXfa+uwmbVdlS829flpIRvanzeH+wN+ST8MRuEuNUSRgw8ZgMAoJJD5kwS// eR9JVG0KD9fv92z44hoyt6gcqG0MBoNRzoCdkKZCSCusC626Sc4NDmQsJpa/H1KP0xRPchPmTToW epzmh4dv/vJvFfSElS/lU1VymAmmobqh46OjtwfkYEgIcmopj4KMbw+9h1+NzS/daR96ecOxnRUN +C74Rvhef9x3BSbt63t9ZNLgWuW6MvO4G4OTYtVH3B/cpRnDp9m61IRvZzAKBTZsDAajkEAKRDrc da6x4tYjtSk8tHYN/5//uhSbTy2ifsCWjcFgrCWQ6sFrKOcmZ/TNJZdn5Dy3ceNxLGItTePRCN30 RITRuUdDMxeae7efbZIPCTj28obj8DwHLrXAwgV/JKaJd/fVVDf3jMwkcWpchrA/oQoyjtY3OnW/ a/jYtQe4yHf2Xn5189kfvHPw959d+LfNZ/+w+/KF5mePhmJPRmbx1fAFu+W6/PjK+O64A7gPuBu4 J0gWnj4t3KtlMHIAGzYGg1FIIBEuLi3vOnc3f4ZtJsGGjcFgrF0YrkP2ucnpeQvG4zRj8+IZ3FG5 +uWIfArLoHy0Ha1WIvvfRE9US88E/Nuuym/oieS/3nIOdohc3OYTdXBx1BcHyQW1p7PEE0ns2TM2 G51dTOQ03kHIt8D39zuH4cqu3e+hM274otb0ZvgXf8OtHb/2ANdgjups74v8dkc1vkiPfDZDv1yU 3zJps2JyGu4D7gbuCU1oZJ/GKEKwYWMwGIUEMmIytXyoJl9DIv/yxbXpRCqZQx2BwWAwygvS9Yh/ IYjCvBmPY5lfVKv1Uucb/FtE+DdhbKzON/nAui56XLgcT0gu7ourj+DiqC8OXg78l3cPw0HRoErw tW3nf/T+kf/zX5f+38PXD31973CN8FppSDbM5I8/OIKjEWnLx0du0J5kETPOuPvJhuNt/VP4LjQt TawgkkjF5SIitMgndaYJm2bcH/VJBqNowIaNwWAUEsiMyJfn7zz59EReFh3ZebZpam4RWZkdG4PB YJiAItrNGwjztrgklsVPJMWTDGLz4ol2k/IpdhHxXHLV/wYL16+7OLFiR6fxL00Po0GV4J//UftZ RQOc1XWjZyw9zZ464sofP/Duvpor93on50RP2vziMr6g6EmzTJrqfmSfxihmsGFjMBiFBHIkDFvn 8+l8LOv/0Vc3Ku48kT1snIsZDAbDG8K2GL5Fdb7JZxtAnGnw5Kx4wpvofyMLR0MoR6WLE0uYyIlw Yi7c5IIcTinWxIed6xkT/OuXN2uaO9WZVoCRiXi2c+cIm0/UnbndAQuKr8MmjVGiYMPGYDAKCeTL xSXxnNNXNp7K6sHZyNz2Rll3IhcPzn7/SF90Thi2FHewMRgMRiBIRyP/VU+0E0tDkYWDfxMWTj5A XE6BE08bh8YKIzcnVqEkLxcx7NzzqYW3/utia9ewOnQ2iCeScHobv7rxQznG8pWPTv371vM0NvLd fTUVtx4FfPwAEsTeC9/AsIk8wJmAUZpgw8ZgMAoJJE8YNiT+z881Hat9oLamxddNnS9vOP7rLedo 4gQRL7ERb6mdvv/+Tlvfn/ZfQY0hNi9XkeY8zWAwGFlCSCf1R9ksHA2hhP+BhaNZcGTk5uVwSng5 uCNQzIibXfzXTyqyfbAbrNrhK/cg6Ru+vHni1uPHwzHqrOsWM+gEzzd2f3Ki/pd/q/jg4NWMLX3V DR2bTtyJIxFwwx2jZMGGjcFgFBJIn0j8SPCdwzOvbDylLS+mAVn8P7+8/uHhm990T9ACzWL6u5g4 ISbBt/RMbDh8EzvQnIfXtp6/3T4ciSVFw2o+H/vDYDAYawfStgF2FwdYRs60c8mlZcjvKxtPZzV6 oqljEB5v57mm757HaAl+WDVahR/sHafHxynZP1339JefVHxRc0992As1zZ0fHbkF98gtd4zSBRs2 BoNRSCB9IrXPLy5Pzi1+JjrZWtUbLnQNRZHFj93seDqKFC7mSPTLp+gMTop/+yfUQ4SO3+rAbl9e ufenfVcGJuYnZhdxcJyC8zSDwWDkFUJnBZSRI23/1aazwXvYTt9sW7/n65aeCVg1+LS+aGJocmF4 WgywjMSS5mDL4Wn1+AHIfsdw/LPzzR8cvOq3PEl1Q8cnx+/I57uITKC2MhglBTZsDAajwEACXVx6 MTOfGojO/XZHtee08mRqCTas8elYV2SuLzo/NLUQmUlGxaNOU1NzYu6EWId6JontePfmo+c/eOdg w5ORkekkkjRPYGMwGIxVBlSXDNu63ZcCzmHbXdm06WQ9WbWBiXkI+Hh8EQofm1+Ky0da2wdbisfH zS6OzCSxJ2zbmTtPf7ez2nOMxpdX7u2u+maaH8jJKGWwYWMwGAUG8ifyOjIxTNf9ZxP/e2f1RCyh 3jOw40zDP2pae8ZFFocxm5xbRM5OqKfoiHnw+BsZHc5tcCLxzt9rtpys++RYHZJ9Iim719RhGAwG g7EaMA3bx0dvBVklsrK+fePROri13vHE8PQCzNhMQj4qTazCrx6VRpRz58TEucTiMpwb9sT+fdH5 ivqnHxy8qg5nw+YTdSdudLBhY5Q02LAxGIwCAxkUlgrZF6l3dCZZ823v73ZW2+c8tHYN//7zi91j c0OTC+PxZGw+hUoAUu+yWsGM+H1q6UV0Zv79g1dp6ZH1ey7d+W4QXg5vcZJmMBiM1QRUVxq2pd2V zcevZVhQCiK/fs/XHcPxvmgCWWBqLjW3sJRcMlfhFwouaJs4h+14F4kAtg1mLBJL9k/Mb6+4e9Q1 rv7dfTVff/uMh0QyShps2BgMRuGBFApbBRuGPP18auHWd8//fet5cxTNut2XLrX0DkzOj8cX48az dCTofZG88Wfv6NTbey7faeujjfg4PigNm21XBoPBYOQfUF1oLxT4emsvLJPa6oVkaul3O6tvtA31 Refhu2Zkk1yKrJo8jtrPBfmu6MfDWWLzS2OxZM/43L9+UmFv78PBX95wvGskhsPyoiOM0gUbNgaD URRAHkWGnksuTcwuwrN9Nzjz+88vfnDwatdQFOm2czQ+OiMW6E8uUY+Z+hQhOpPYWdHw6uaz9vlv yNM/+evx8Zl54e7UNgaDwWCsEiC9ydTyWGzhR+8f8ZxdRjhz89Gmk/W90fmRmeR0IgX3ZTTJBVJu 7IT9cSIkCPi98w1dfzlkDYxs7Rp+6/OLOHJ8YUn0sKnNDEaJgQ0bg8EoClB2Ti3Bsy1H48KzPRuf P1P39GcfnUKyP/h166P+6Lyx3iNhOBqvaujY8EXtLz4+Xd3QoQ5kw2vbKh88G5PDYNQWBoPBYKwO oNJiQalE6s//+Kc59sGNlzccv9c7Ac2fnDMW9VXvBAV5Njg9+L2R6eS/2p78tqeyaf/lVhi52YUl TgWM0gUbNgaDUSxALkU+hb+aSy5NzqXEPPKJ+a9bev9t09k9VU3/tvnsD945CL699/IP3z2MP+DT PqtoQD3Ar+12/Z5Ldd8NogbA09gYDAZjlQHNTS2/gFM6fatj84k6tdWJrqHor7ec75+YH6NnZsom OfVeNiDPllgU7X1bTzdU3HpE21/ZeOp+TzTKz3dhlDjYsDEYjCICebaUMY98dCZZe78fvku9LdHa NZxmdI0d+OCttgHYP5mn1UYGg8FgrAKgumSihqcSME7u5X+BL6/c21XZ/HxqAYKfXNmUY3xucelF bH7pxsMByhp32vr+tP+fQ7aD054MRsmBDRuDwSguIKWC8GzzcsnmjsGpn288rd7LEq9sPP2of1K0 2i5xomYwGIxVBawXPNKCXE3qpE8n218OXT3f0GV1r6nNuQCfFf4wuTQQnaVZc7/Zer7hyejoTDI+ v8Rr+jNKGmzYGAxG0UHkVbUktOhne2XjKfuqXwGBj/zso1ORmJhrvsJ6AIPBYDByAJQ8tfQCfgmu 6d+3nLevC0V487PqG22DNHtt5WPXhT+UM9l++O7hY7UPNp+q75+Yj4oHciKfiKZABqNEwYaNwWAU KZC5F2Wm336m8cxNNSEhOPCRT0838FxzBoPBKBSgvHBKMGMTs4uXW5651/f/yYbj7UPTNGRx5TJN /jA2v/TKxlPgw/6pkenkDA7OOYBR4mDDxmAwihRIr0iyc8ml55MJ7dE6GYGd8ZHusdno7GJCNdyq txgMBoOxaoD2Li4tx+bFnOS/X/x2/8UW9YbEKxtPP+ybgMUSA9dXLNP4PHzf5Gzy5Q3HL7f0DE0u IAWoacxqFwajJMGGjcFgFCmQvGG0FlLLk3Opq66lR9Jj3e5Ll1t6h6YWpuZSC8KwcbJmMBiMAgDq C780vyiUHJr87v5/1j20lviHsF9/OBDWwHUcAef6/NzdH7xzcGQmORaTT+/k5UYYpQ82bAwGo3hB 41uQyyOx5JbT9bsrmzKuD4kdsNvmk/V90Xk51zwVSsMtg8FgMHIDFHhxSazvDwfVMzZrn8z20Vc3 ztU/EUIdzFQNR2P3O4ejMwlPVcfGyvr2D7+o/cmG4+PxxelEan6Ru9cY5QA2bAwGo3iBNGs1zU4u 7Klu+d3OavOJqCaO1ra+svEUPaXt5xtP/+XwzZ6xxHPZvYbPimzN6ZrBYDAKBEgwZHghpQZGftsd /e2Oqmv3evBWdUPHphN3MvawxeaSn1U0/PiDI7/4+PQ7ey//9K/HwZ0VDbG5BVPf8b89lU1bTtZd v9/z18PXkTVgERfZrjHKAmzYGAxGUQPJmJpmx+OLAxPzN9ue/3rL+R1nxPOy8W48kYSF23qmce+F e/955PZvtp5Hqn7zs+oTNzqw/1xyWVQCOF0zGAxGQQEVptVHphOpkelkZ2T2/QO1uyubRibir2w8 lWYOGzY2dQy8uvksrB0EX239/vuJWAJbsP1+5zD2gXN7e+9lel72pyfrKuoeT8mVJ7nBjlEeYMPG YDCKGki2SLhJOWd9LJaEZ3syGv9HzYM/7rtCXWrEvxy8iuRtDph887MLzU+HkykxC46zNYPBYBQc EHMaMTE1lxqeXugdT+y73PratvM//uCIlGuPrjB8pO5h3zt7L3s+dBvAdvi03ZV34dxau4axBVng JxuOP4vE4QxpAjNAOzMYpQs2bAwGo9iBZIs0j3QOzzYeTz6fEpm+eyxx8Zvedbu9VyJp74u8+Vl1 ckmYPc7WDAaDUXBIMX4BX5ZILsGzjUwv9E/M17UPv/P3mt9sPd/eN6b1huFFdCbxxvZKP7cG3Gnr +/nG07B85jLCx2pbPzvbNDqTRL6QD8umzQxGaYMNG4PBKAGYnm0uuTw5t4hkPCintB245Fgh2o4f vnt4JsHzFxgMBqNYIBzbC7HyPo2NjMREAxz4HweuQrFf314Ju9UXmcI+cs8Xn56oq2nuVB+2obVr eE9V0ysbT7+7/59tfZNf/vMBXmI7rN0rG0/1jM2OxZKzyXBWnmQwigFs2BgMRmkAeRfJFw4MmT4+ vzQxu7jp+J3qhg71tgs/33i6e3iaHRuDwWAUD8iJQZjlGiRL0fgizFXH4JQYx/548MClllc3nwU3 HrlxuObejz84cv1+D+wZ/v3yyj3wT/tqXt5w/M1dF/devHf36VjPWGJgYr65a/RXm87i4H/675rq 5p7ByflJnsDGKC+wYWMwGCUDM9PDhs0tLJ248WjnmQb1nhPxRPJH7x+ZnEuhTiCnsXHSZjAYjGIB KXkSSp5cmk6kJmYXv+0a/f1nF2gecn9kCg7ts4qGn2w4/n//XvPW5xf/40DtjrNN2882nW3s+qY7 +nR0riuSeDae6J+YH5paACH4m0/U7bt0vy86H5lJxnl9SEZ5gQ0bg8EoMSAHIw8nU8u9kdivNp21 rxtmoqq+42/H6lAJ4EZWBoPBKEJAlaHNNGiCutqu3ut987ML5my01q7hP/zXpcHJBRiz7kgCDg3E Hz1jCbiywcn5kemF8fhidHbx+WTiZx+d+q+q5t7o/PA0P9CFUYZgw8ZgMEoPyMOppRcz86lTtzr+ cuiq5tna+yL/+klFz9gsErmRtjlvMxgMRnFBSLOc0iaXIRGTk+s7hunpLHh3IpZ4ecNxGDbiEDi1 AD82MpOET5ucXUQKmF1Yutc18uZn1T945+Cz8bnnUwsTs4tzNHuNZZ9RRmDDxmAwSg/Iw8jHs8ml SCx57Pp3sGd7KptqmjuPX3vw0VfX39he1dQ5htQ+pYZEcuZmMBiMYgTJc2rpBVwWvBYcV8dQ7P2D ta9tO9/8ePAnG463D03DnuEt6Dk4k0jFF5bmFpbmF5e7hyc2fnXjrV0XIP6wefB70dnFuFwckmWf UWZgw8ZgMEoPSMRLcp2xybnU0OTC/d7Jv1+89+HhG1tONx690dEZmRPTGGJJZG6/h7EyGAwGoxgA hYa/gsuaXVgS4xunFnqj8zcfPV+/5+sfvHPw//695mjtw6bHQ82Pn7c8Ebx09+nuyru/+Pj0q5vP Ul/c4Sv3/vtiy3hcLOW/QKMq6NAMRrmADRuDwShJICHDjIkEH18cmqJJDnPdY4keOQ19dCYpnpqa 4mkMDAaDUewwPRs9uGVkOtkfne8dTzwZjr2y8dSGL2rf3nsZfEdyy8m6iluPzKluXUPR3+2sHppM TM4uJhaXRSMdvcFglBHYsDEYjJIEJfhkajm+IAbSwKE9nxKTHIblNPSZ+dT84hLPXmMwGIySAEk6 7FZCrhsJGYeYQ9VvPhz4/WcX+iNTaj8n2vsiYvBk1yg10iEjSNVn2WeUG9iwMRiMUgVy8vKL780n syFbg7H51FxyOZkSa0YT1N4MBoPBKGJArUFINwR8dkFIOj2lrb5j6Ddbzx+rfQB7pnaVa0j+42LL b3dUNzwZGZiYF0/KXuC1RhhlCzZsDAajhEEJXto20duWXFqGf0vRjHPxLmduBoPBKBmQ34Kkw3ot yAEUk3L1yN7o3Gdnm2DPfvDOwV9tOot/f//5xd3VLT1jid5oYmR6Ae6Ox8Azyhhs2BgMRskDGVqk eWne5P/Fv+o9BoPBYJQUhIzLJ2vLWW3wbKmRmeTAxDw9kK2uY6QrkuiUk5b7ovMj00mYukRyiZeY YpQx2LAxGAwGg8FgMIoLMF/LclYbPNvUXCoSSw5NLfRPzPdGBfEHXmLjdCIl1hqRfWts2BjlCjZs DEaR4nrb85N3epjM8uazSEyVeAaj3BGZTmjln5meJ+p6TtzpPl7Xc/R2z5FbPYdvdn1xo/uQ5Bc3 ur682f3Vre5jdd3Hb/ecxJ513drHmYWiKvGM8CAM26P+SSYzPZOpZSoxjFXDX058+z8+rWUyy5vX 256rEs9glDuQTLXyz8zMzVfpj//56bX/ueXa/9iCf68LbsW/1/7Hp6BjN2YxUJV4RngQhk27y0ym m5HpBJUYxqqBDRtzLZANG2PtgA1b7txMf5A9M0waUb3FLCKqEs8ID2zYmIHIhm31YRq2LZVth2qf HrrmyU7wi1x5+HqO/NKTNzzZZedXwXnTwSNh8Cjxlie7c+YxN2+Hw+NpWOfHnoAUY42C8E7W1MbG ePLtw01UvNmwMdYOTMP2m713DpWLqoO6evvRqeqgJtEZ+dWNTus44pideVJ1ME+qDupiblIXczt1 AfejLuCedIl2EGoa7kkq3qAq8Yzw4DBsfz7yTVh872g+2GLnfwThsXD4fp54fEX8IDt+mwP//9uv U9lgw7b6MA1bfcfo+PS8iwtgVOOM4kQmTsY0Ju2cIsY9OO3JWYszFhftjBHnfBk3mXBwVjHlwXnB uQBMEBc8ueTmPJgMxAWNi2m4nPRkyoOLaSgfXaAxpSgm6HtwWedSEL4QXNYpVtz25vfiyXgB+fnl direbNgYawemYUM1ySXpRJeqg4UWdpuqZyfslqpnKeyagPsxa1UPJuxZqXr+hd2l5yZXRdWzEnYq 3qAq8Yzw4DBsLuEAsxaONHrhJxa6RoBpK39pBCKtNOQiCj5ykIsQBJMAr+APHvNZRXuAOH/jv+up bLBhW334G7Z0Vi1NbBLTRCgxdKsG5mbVwMJYtUyxTAwW0cSQkrorwMEMVg20RXqaYHcwz0kdZMPG WINIa9iKsQ3Opuq6sKe3aqCfsKe3ankUdpeGezKwsK+CVfMX9hxUHdQlnejSc2L2qg5S8QZViWeE hzSGLRfhyKAXQZQibeUvRKuWURT85SBrIQgW/z7BHzDss4r2wHHOhq2A8DFsrsAEgyV1Z3gSXUG6 ukndClvvyPVN6lq0+rF8rBqYVYwTbZGeMdgV82/ViGzYGGsQPoYtj21wOau6U9izUHXQT9XBwli1 PAi7rudEl6SDupLb6VJ1sEiEXVPsgKTiDaoSzwgPnobNpR0BVCODXgRRiiAa4dIFoqc6eFf4Vteq gcHi3xX2YMCwzyras4rzF2zYCgmXYeP21zwndVfwuukIZ6Ieyya5/TUd2bAx1iBchi1cqwa6hN0l 6aCu50RD1Z3C7lB1MKiqBxf2UrNq4Qi7S9LBDKoO5iDsq9UGR6TiDaoSzwgPmmFbuVUDnWLhpRe6 TIBpZSIcqwa64t/NLKxaJiEIFv+umAdXEPMB63B6SGs0IpwNWwFhM2yRUJO6FaFpghTUg5QYIKmX nlXLFMtER0SDeizb6Qpqoiu0QT2o7XQFOJiVVQP16PbkarW/mmTDxliDcBo2l6qDwVQdzJOw21Q9 O2G3VD1/wq7rOVGXdDB3VQd1MTe5Cm1wLj03uSqqvnJhp+INqhLPCA8Ow5aDcPjphZ9Y6BoBpq38 pRGItNKQiyjky6qBetgTA42B1OPcZFbRnlWc22KbDVsBYRq2ho6IZ2Cmj03QGZ5EK0hVnLqCFNSD lGiEql+0EoNaNe/IzTF4iUVi1cJJ6q4ABzNYNdAW6YGCHSxEUgfZsDHWIOyGzaHqNmHXZNzNzKqe k7DbVF0X9vRWDcxa1cG8CrtLwz2ZlbDrek50STqoi7mdLlUHMwi7U9VBXcM9qUs60aXnxJBUHaTi DaoSzwgPPoYtgHBk0IsgSpGp8reqVs1bDrIWgmDxH8iqgXqoE7OK9qziXI9tNmyFhLdhK9mkboWt d+T6JnUtWv24SlYN1MPZJLe/ZkE2bIw1CG/DZqh6RmFPr+pgbqruFPYsVB30U3WwMFYtN2HXxdzO oBU2UFdyO12SDmawauCqCLsmzishFW9QlXhGeHAZtgCqkUYy8m3VQE918K3wueJfY4hWDQwW/66w BwOGfVbRnlWce0S4iGQ2bAWEbtiCZXQwTYSqIM0pqdui1Stgc0rq6a1aHpO6K3g96YhoUI9lk6tg 1XzCHHRGOqhHtyf1eCc6E7nJUK0akQ0bYw1CN2yGqmcUdpeqg6ELu0PVwaCqnqWwawLux+K1aqBL 1UFdzE26JB3MoOpgTqqerVULXdipeIOqxDPCg9OwZVKNNHrhJxa6RoBpZSJNzc9TGnx1wRX8bmZh 1TIJQbD4d8U8uIKYD1iH00Nao49VI7JhKyAsw/Y4kmtStyKUmFtG94vW9AFL9AxbYmGsWqZYJjoi GtRj2U5XUBNdoQ3qQW2nK8DBIknqWkoOhWzYGGsQDsMWTNXB9MIehlXLTtgtVXcJe3qrtmJh1yUd zF3VQV3MTZbacAlQl3SiS8+JebBqRCreoCrxjPCgGzZNJuzMoBdBlCJt5S+NQKSVhlxEIV9WDdTD nhi0S10PdWJW0Z5VnOuxDTqimg1bAaEZNi0eNTrDk+gK0uBJ3QhVv2glBrVq3pHrm9S1aPVkkVi1 cJK6K8DBIrFqeUrqIBs2xhqEZtg0GXczTFUHAwh7eqsG5qbqeRR2l4Z7Mith1/Wc6JJ0UBdzO12q DmYQdqeqg7qGezIrYc+nqoNUvEFV4hnhwWHYNKUwmUEvgihFEI1w6QKYVhpyEQV/OchFCALEfz6s mk+0ZxXnaTvWTLJhKyBMw9b4OKKFpEZnhIKuIM0pqdui1Stg/ZO6FbbekRtGUtfjl6hHMZi7VQP1 cDZZHu2verxbzHNSB9mwMdYg7IZNk3GN6VUdDN2qgblZNbAwVi03YdfF3M7yb4PTdDh0UvEGVYln hIcMhi2NZHjWAnWNADNpRKBqn64LXtLgin83V9eqga6YB3ON+VW2aoLfs2ErJIIYtjQR6hekRD1O iR7R6hWwOSX10KxatkndFbyedEQ0qMeyna6gJrpCG9SD2k5ngBMzJHVnpIN6dHuymNpfTbJhY6xB BDFsLlUHCyzslqpnKeyagPuxfKwamK2qg/lWdXC1hJ2KN6hKPCM8+Bq2NHrhJxa6RoAeMhFIIDyl wVcXXMHvZhZWLZMQBJMAV8yDwWPeO+BdQU7MKs718AZdgQ0asceGrYBIb9jSRCgxt4zuF63pA5bo GbbEwli1TLFMDBbRxCySuh7UdroCHCySpG7m3XyTDRtjDSKjYUsv7CVk1fIo7C4Nd1NXdVAXc5Pl MVwCdOk5cbWsGpGKN6hKPCM8eBu2DHoRRCnSVv7SCERaachFFPzlwKUCmYQgWPz7BH/AsPeOdp+A zyrO9dgGXYENOmObDVsB4WfYnOFJdAVpPpK6K1pNWmHrHbm+SV2LVj+WllUD9bg26QpwsEis2mom dbAkDNvMzMwgo0QwPDKsfrYiRhrDlidVdwq7S9UDCns2qp5Hq5YHYdf1nOiSdFAXcztdqg5mEHan qoO6hnuyiNvgiFS8QVXiGeFBN2wZ9CKIUgTRCJcuED3VId9WDQyiAsHi3xX2YMCwzyras4pzjwh3 RTXoVWNjw1ZAeBo2Z4SCriDNKanbotUrYIPErDNsjchd1aSee0YH9Vg2ye2veWHxG7YX379oamk8 cn3XwaubmcXP23dvTE9Po6Sr368o4WnY0qs6GLpVA4NaNW9hd0k6WGpWLRxhd0k6mMGqgTkIe9G3 wRGpeIOqxDPCg8Ow+UmGXy1QlwkwrUbkZNW8pMEV/26WklUDvQPeFeRgVnEe0KqBrqgjsmErIDTD 5gxP0IrQNEEK6kFKDJDU01s10DNs00UuyO2vBjMkdWekg3p0e7Lo219NFrlhg1tbfrEMw/aXqlfe PvdDZvGztvHixNQEgkCWryKF27DlSdhtqp6dsFuqnqWwawLux/KxaqBL1cE1a9WIVLxBVeIZ4cHT sGUWC10jwLSVvzQCkVYachGFLKxaJiEIJgFewR885rOK9qziXA9v0BXYYNrYZsNWQNgNmy2dOyKU GLpVA3OzamDZWLVwkrorwMEMVg20RXqgYAdLKqmDxW7YcD+XU2zYSohXGy+MTYwsLiXhtNWvWHyw GzanquvCvvpWDfQT9vRWLY/C7tJwTwYW9lWwav7CnoOqg7qkE116Tiy0qoNUvEFV4hnhQTNsLr0I ohRpK38hWrWMouAvB1kLQbD49wn+gGGfVbRnFed6bIOuwAYDxDYbtgLCx7C5gnR1k7oVtt6R65vU tWj1Y/lYNdAV4yBbNWKRGzZU+lH1v9vSwIatVAjDNjI+tLCYkDGBIlaMMA3be0fths2h6mBuqu4U 9ixUHfRTdbAwVi0Pwq7rOdEl6aCu5Ha6JB3MYNXAVRF2u8AWilS8QVXiGeHB27CFYtWURrh0geip Dr4VPlf8awzRqoHB4t8V9mDAsM8q2rOKc48Id0U10RVmnmTDVkC4DJuVzlWQ5pTUbdHqFbA5JfX0 Vi2PSd0VvG46wpmox7JJbn9dPRa/YUum5u9+w4atZHi1sfr5WD+0BEH2QhSxYoSXYQsk7LqeEw1V dwq7Q9XBoKqepbBrAu7JXFQ9N2HXxdxOHi6xeqTiDaoSzwgPumHLQizSysSqWTUwC6uWSQiCxb8r 5sEVxHzAOpwe0hrDtmpENmwFhM2wjQXJ6KAepMQAST1nqwYWxqplimWiI6JBPZbtdAU10RXaoB7U droCHCySpK5Fd2FZAoZtiQ1bKRGGbQiGbXEWoVYihs1S9ZUIu03VsxN2S9Vdwp7eqmUh7LqeE3VJ B3NXdVAXc5M8XGK1ScUbVCWeER4chi00q+YjEGmlIRdRyJdVA/WwJ+ZjDKQryIlZxbke3qArsMHs Y5sNWwHhadhCt2pgUKvmHbk5Bi+xSKxaOEndFeBgkVi1YkvqIBs2ZrgsXcO2+lYNzFrVwUIPlwCz EnZdz4kuSQd1MbfTpepgBmF3qjqoa7gndUknOsXcZFGqOkjFG1QlnhEenIYto1JkqvytqlXzloNc hCBA/OfDqvlEe1Zxrsc26ApsMNfYZsNWQGiGbfWTuhW23pHrm9S1aPXjKlk1UA9nk9z+WjCyYWOG yxI1bKG3weVs1cDCWLXchF0XczuzEHZdye10STqYwaqBqyLsdi0tKlLxBlWJZ4QHb8OmawQYRCNc ukD0VAffCp8r/jWuulUDXTEPBgz7rKI9qzj3iHBXVBNdERWcbNgKCNOw3X08xu2vWuT60RHRoB7L drqCmugKbVCPaztdMQ5mSOrOSAf16PakHu9EV7wTi9iqEdmwMcNlyRm2MNrgHKoOBlX1LIVdE3A/ lpZVA3UxN+mSdDCDqoM5qXq2Vq3IhZ2KN6hKPCM8eBg2XSPAtDKRpubnKQ2+uuAKfjezsGqZhCBY /LtiHlxBzAesw+kh7WbA8HbFUrZkw1ZAWIbtyZiZyE3qQUo0QtUvWtMHLNEzbImFsWqZYpnoiGhQ j2U7g3aYg3pQ2+kKcLBIkroWyEVINmzMcFl6hs2l6qAu6UQPVc9O2C1Vdwl7equ2YmHXJR3MXdVB XcxNltpwCVCXdKJTzE0WvVUjUvEGVYlnhAeHYdM1Akxb+UsjEGmlIRdR8JGDXIQgWPwHrdLpoU7M KtqzinM9tkFXYIMhxTYbtgIijWHT4xQ0QtUvWolBrZp35PomdS1aPemf0UE9kMHck7oey3Zy+2ux kA0bM1yWumHTJZ0YQNjTWzUwN1XPo7A7BdyPWQm7rudEl6SDupjb6VJ1MIOwO1Ud1DXck+XYBkek 4g2qEs8ID/6GLYhGuHSB6C8NuYiCvxzkIgQB4j8fVs0n2rOK84BjIEOtsbFhKyA8DZsjSE16RKtX wGaMWd/IzV9S16MYzN2qgXo4myyP9ldXvJssHatGZMPGDJela9h0PScaqu4Udoeqg7lZNbAwVi03 YdfF3E5ugysuUvEGVYlnhAcvw5ZJIwJV+3Rd8JIGV/y7ubpWDXTFPLiCmF9Vqwa6gmeFZMNWQGiG zUrkdgZI6umtGugZtukiF+T2V4MZkroz0kE9uj2ZVVIvtYxOZMPGDJclath0SSd6qHp2wm6pepbC rgm4H8vHqoHZqjqYb1UHS1PYqXiDqsQzwoPLsKWt/KURCE9p8NUFV/C7mYVVyyQEwSTAFfNg8Jj3 DnhXkBOzinM9vEFXYIOusAmFbNgKCNOwNT0Zc+RyohGqftGaPmCJnmFLLIxVyxTLxGARTcyY1GO9 HT2nqu6u+7R23Z2YHtcmRVDH+jp6TlfLPetjRoxTmMdPHxK/1Lr6uF+kBwp2MPukrsVsqZANGzNc lpxh0yWd6KHqoQl7equWR2F3CrgndVUHdTE3uQrDJUjYvZhZ1eP9T3rOVN9d/2nt+oa42qhLOhE6 Mzvw5FmF2nnWVPXchT0629TYtvNQ7UuftjVpb60KqXiDqsQzwoPTsPlX/tIIRFppyEUU/OXApQKZ hCBY/PsEf8CwzyraM8S5k3psg0Ytzc58NsOwYSsg0hm2FSd1K2y9I9c3qWvR6sdwrVpdldIoN1/6 9O66Qw9Ptc8EjWvQCurYqUPCgNGhvA2biuvYafue9TFnjLsMmy3SAwU7uDbaX02yYWOGy5I3bIaq O4U9C1UHs1L1rqHhE+cb/2DIGviHgw9P3h7ugoY/6jr53EvVwxL29ofmSU2uq5tBPe1OBrVvO9Ue 0yUdtFTdoi7mdtrqbCazsmqgruGC8TOHhPuiCxaGLZ2wz1Y4dpaGzSWVWTD6bP2hu3Q0NmzlB4dh S6cRLl0geqqDd4UvPKsGZrRqYACrBrrCHgwY9llFe+Y4t9Ejwo1amkZXtIRLNmwFhLdhK5xVC+jW cknqruB1E1H8rP0hWaaXqkaeqaCesTYeenjHCOoAVs3iYmpkuzyCh2HTY9zYU+tJszOrSDepxzvR Fe/EErdqRDZszHBZwoYtgFUDg1o1b2HXJH3mxEFxGX+o7Lr9fMZQ75muR11b5XZw66OVqXpmYZ+p q1LuYh1Juq2q5lB7tTH2rL3NUPu2+szC7kNd1QUzWDUwO2Ef3SGvE4YtgKpHdtLOjbOhCPtgo7ir bNjKD27DFlQgPKXBt8JnhH0aZmHVMgmB5dNs8e+iLdpNriDmAzbMuALbyaKxakQ2bAWEbtgCJPX0 Vg30DNt0kQsW0RjImVOyMoEU7ojlkW4ji3c/0yLapCu0QSOcY6p/zG7YXAEOppZGKA17GzZbmBP1 6PbkmhkDqZENGzNclqph81D17ITdUvWAwj40vFVewx9um1bNzpmTUmZNw5ZHVTf62ba3u2trM6ek LEu1t7XBjfQYat/Tm0HYvehSdTBUqyb5In5GXrzTsDmV3KJl2OwKmTufton7w4at7KAZtkACkVYa nLoAOoTAm/myaqAj/k0GGgOpx7nJrKI9qzi3AtukFtiSq9i+zoatgLAM29Mxr6RuRSsxN6sGloJV I9pTuCOozVE0MF16XIPO0Cbagtpp2FwBDhrtr6rd1MOw2SI9ULCDa2wMpEY2bMxwWXqGbcVWDfQT dm+rJqjc2kuVw5qM2yj2gWHLRdidAu5HJel2w+aUdLth0/S83q72vqruokvVQUPYnWJu0qnqoK7h nhQyHq/QDZtTzE0KVWfDxggED8MWolXLWNvzl4OshcBWq5PUg59YmOlqmeNchbSdrsAGV73Gxoat gNAMW85J3Qpb78j1TOpBrRq4KlaN4tfPsC0vtIsUJd6iZlf/0Ab1uLYbNleMg7YY9zJsWUU6cW1b NSIbNma4LFHDlpuqg36qDqZR9duVUic/fXjbpeR2dt9u/MPtGZekE3VVB3MU9pwMW7LDpva+qm6j S9LBDFYNXJGw2w2bU8ztVGLIho0RCLphC1Tt03XBSxpc8a8xRKsGOiRAD3uTzpgn2qpxRD3UiVlF e1ZxXmRjIDWyYSsgTMPW/HQs9KSe3qoFdGv+UQzqgQwGzOigI6JBFcJuw2Y0wbgNmyu0QT2uFQ3D Jtd+TBvmTsOWVaSb1OOd6Ip3YjlaNSIbNma4LDnD5qfqYFBVz1LY55530RIjabrXDFUfPlnnNmy6 pIM5WjUQAu5r2CDsMW/DBiV3GTaXpBt06jkxXeWNmIOw6xU507AZCz9qdAg7GzZGIDgMmyYKJj2l wVcXXPHvZhZWLZMQ6PHvTVu0m7RV44h6qJv0DnhXkBODx3lxWzUiG7YCwmXYXBk9J6sGFsaqZYpl oiOiQUcga4bNFs52w2YsIkKkYTMikI00DyKZNVgB7jBsfR3GvPZP7+7o0IY+2gybFeleizhbjDfK t+i86w+13Y0Gi3rQFY/lRDZszHBZsoYtC2G3VN0l7OmtGgl71+1GOrt9QRE7M6v6yMjJyrvmwpLr KrvrRnQNJ3a3P1xnrF8CLd1eZywrYhd2D8NmDoNyGTaztmYzbH2mjLtpr7ZFRuiJLPTBddU9DRFL 2Ps7RtXzWhqksI+P7pBrLYoU4CnpDW2mpGOf9dWjAw5JB2fthm3gidofO+986l5ZxN+wRSO04j+d a331s6aocwfJwadt6+le4fg4CBu2MkUGw5ZWGnxFIQ3zZdVAFe0a8zEG0opzB60KnBbeXtTDG3TW 1YiFbl9nw1ZAOA2bK6m7otWkFbbekeub1LVo9WSBrBrRbtgcEd17x1htzJzVMOq99mOf3FMZNhXX lmFrqFbHMbmuetQW5oZho7wu6FrE2R7m4z1466Xq0X7ZOoO0jX2QUyuUZ3PFu8ny7VgzyYaNGS5L 0LC5VD2gsGej6jZhV6uJvPRpY45L9o90/+HTu9vaZ6SwqzUeIWindM8mVod66dOH5OUWkjN31J4P 74w4JV03bHZVtxk2W1UNtKu9Xdst2upsgpGedaL1jZ7FEieRx2Wflp4NLy0jB2EfV4uamHSqulpN ZMcTuTGqMgJE3lmXswzbXVdOWV8dsSuhr2GLPlsvDZ58OdtkXHaFw7Nhu9xo241W9mfDVn7wNWxp pSG9KHjTXw6suh0xSPUuU8UO5OlqIZANWwHhadjy2v6akatk1UA9nIk+sxrMdcM+bau3Qlvlez2p y9ZZYdis6FaGDWlvXfVIvwzq/g4rbe/oMCPdYdhsca22O1O72PjSoR64NSPS1TiZl6ojerybXANW jciGjRkuS82wtQRUddBP1cFsVN1YbsQ5gS2QVRMc2fZp7bZ2u7Aby/Ye7O626XldldBSuDi7pNO6 UMKz2SXdMmzuCpuPYRu11N4aJWHSUnWTYmnfHR32ypt6bKYQZ03Yq9vWHWprHJcCPm6YMexmqjo1 uklVp7rcQINyR3cddTll2HAfYM8GpLAPPoUBExvBnU/tYuhp2MRG527GMQ89GzQ2DjbedVs449Rs 2MoN3obNUx18K3y2yPfj6lo1UIt8SXvMS+qhbtIZ8CFaNZdbM8PbSVcMFIps2AoIzbDlnNRDs2qB krpiQKsGOiIa1GPZTiuF946ouO5tN/P33e0d9ui2LSVij25/wyYfh22LbtEuK48sE7aMccuwOaPb w7D1y0SOLY6Ql2NjvCc2rBmrRmTDxgyXJWrYgqp6lsKuCbigOYHNZtgcqm7YJztfqhwhSe+ugzd4 WOcUdngzsY+9k00eBBZOHwBpPHxl3Z0ZS9Jths2qqina1H5UqXqv0Y5Gau8QdkvPLaLm1l+Py4ba 24Rd9Kqpg5weJ2E3LFz1qOXNDA3HxxuNLY30wUM91hhIa9yEXc9tQyLtwi46zegIlunyNGzSiemO q8m4bOXQ5NFe0vvr+DlsZQvdsHlKg68umELgzyysWqYanhX8RDPmHdRiXtKow5l0xLmdXgFvj3MH DZ8GmhHuSzO8Fe2xbaOr9BeWbNgKCLthW5X2V2/mYtUyxTIxWEQTqf3VSOGH7m4/ZI1jQQJbV9VT byR1I5y9DBuC2mXYUpZh0xfrN/J6W4OKdA9jJunaLp/DIzNrgKgHXaFX9mTDxgyXJWfY0rfBWaru Evb0Vs1f2M0eNjEk0k/Yu9tNX3f35Iip6qozzY+i502quupJqxpxCbsxPkI8LdNQdWPusW7YhJKn U/uGUVPnDWF3UVbelBPz444nJOzWY9Nsqm70p9kMG7bIFjdbM1x6w+aalmaYLrubchs29XE/Us8b Hcp9Cp7DVq5wGDZ/achKFBR95MCq2BFDtGorcmve0e6ovVk0fBpoxbYfzcC2aA9sg0XZvs6GrYCw DFvnmJbLTVoZ3TtyfZO6Fq1+LBqrRrQNkvEKbdAW1E7DZoa2zbDJGLeSusfT1YxkTA2xPkMfndtV R/oocrDNsLni3eQa61gzyYaNGS5Ly7D9BwybS89N5qbqmYTdadh0SSdCyY2pbge7u01hT4rxkKKH zankGsWjMuVn19XNuIX9mZo/LEdLkqS7DZsl5pba21TdRVPYbTSEHRoulFmqvU3VbfU3ojkzLZ1h c4+QisbvGiuCBDdshpsyeskE3YZNbMnkuNQpnMMmJdmwlSlchk2XhhxEwbflxqzYmQxSvQtQsSve 6Wp6hFvxbGMR19jYsBUQ6Q2bldGdYWtEbs5JXTF4FIO5WzVQD2eTgWc1eEe3zbDZA9xh2CiuvQwb xbhh2M7QrIYAhs2IdLthc4U8ca1aNSIbNma4LA/D5qfq4MpVnR7CBv4h3ZL9DsNmCHsGw2bouVrq SfSw6XpuN2yGpGuGzSHpmQwb6bkxcN1Om0NzGTZb/Q00BDyTYbOqcIID0dGdcgDFzoaIbSkpu7Cv gmFTn2LDtnbgNGwOXfCSBlf8u7m6Vg00It9OR9gL6qFu0qzGGVxVqwa6intRkQ1bAZHGsPkl9Txb NVAPZDCgVQMdEQ3qsWynK6gFvQ2bHtSK1sw0R4xbhs2Mbqdhs0e6vYVVMDvDJrfwdDVvsmFjhstS N2yWqmcp7JqA+1GoujFn7KWDXd2+qm4zbJZ6C8OGjebQR5NOVQ9i2NrqTUk3DZtt+rFBJeDehs3U 8wCGDVvEwlF2YXeoN5jBsMkFRYiiV03sSUuJgHbDZgl7RsNmd1Pehg1bPMyYRfenDLJhK1N4GLbV sGqZanhOCdDD3qBXx5oe8644N2kGvEFfqwb6xrkXrdg2aaurmXQV9CIkG7YCwtOw+WV0sDBWLVMs E4NFNNGnwxy0tbkGCHAPwyZiPL1hs0W6CHZKxtYqYV6GTbTOmPbMNGwqYb906JnK67bAH2hsszWv rlGyYWOGy5I2bH7Cnt6qZS/syoyB29r9hN1z7UdjY9WIh6q3P1RrQi76rAYpVZ2W44ec9pqS7mPY pIb7GDZbnc2k/6gope0vVY9aqm7ySZsxdMLLsEHGXYbtLs1Asy/zazNsNn3LZNgyLDpipA/XgiKC Tyl9WCnGdii1g9jOhq3s4DBsflYtoyj41/McQpBfqwbaAp7oiHOTWUS7VXVzxLkfjai20YhqO0un fZ0NWwGhGTYro2eZ1LVo9WNxWzWiw7DpcW2niGsj31eP2GPceAiPl2Gznq6mIprWBNvxxIxxp2Gz OtLthk2FOS33DO58ogU+Eq0rxa49smErAGvfPPK48WEM97/xiPZW6bNEDZufqoOhWjWDI8aaIsYU NZew+y7WT1dOnWw2Vcf+NntmLfxoCTvJeL08gmO6mmw+ExsNw2aTcZdhc1bbiOkqb+CyWjgKpPVF DCUHYdLMoRNOw2YKu8OwQROMji9T0sEsDRutFOLsOvPoK6PdXHuCOLJyYuY+2ll4lchyhWbYshaF gFYNDFK9s0mAGepuGtFup6rPWbSFvY1ZRbvNqjnj3IvlMgZSIxu2AsI0bN90jvkl9fRWLfekblEP ZDBHqwbqsWwyo1UjGobtUE+fFtombdFtrd0sHpn6IhUZPV3ddrpe5Vd6aqqMdIdhs4LaeOy1tcVu 2BzB7jUA0lzBWT781Aj82abGux7NrmuPa8ewbW0+9TA2aHzxwZFY49XmN8X2x41Xa/Wd88jaUyPW ZaQzbFsfm7tlYuzUVvpUc6P+1vffjzymr+l9NHo3RJacYbNUPbiwh6Lq7Q/dns3WBudt2OaNdfkh aNvrRoxV+8VDsdc5BkDaV4O0C7sYLWl1r5GkOw2bU8wNwwa1t6m6yQxWDaTKm/EgbFz2jgZz1f54 Y/Xd9Za2+wi7ZdhI1V2GDUKhurOEYRt82lah/JWPYfNeiN9rcKM9fTRGjAY++Vxs8+PGPvKzap/B xrad6sHZmodcJdL1gKrEM8KDv2Fzxb+bWVg1JQS+DFirMyLfRqsyp+iMeRu9A94V5MQ1b9WIbNgK CN2wBczoYF6tWqZYJjoiGtRj2U5XUBNdoW1/CM9pbVlnrwB3T28QMxmMKgIOsk49YC1O3W4gUjhl 9P4nwq2ZL4n9DcZn7c/hEc9ONbc7B0DKNaDpLZMeI1jWJNeIYTsyJOzKyNBWZWzOvbm1uXFE9HGB g6tq2CQN+xSghw0Gj34s05XZWbv1Kr6F46036cs6v68ivjW9hY8cyc+3LlXDlo2wawLux8yqPjKy jVzZp3e3tc+IxUWkbnePjJyqUmK4rs4a/UhcaH/oMWHskDb6ERzZbnitelpfBIc9hJdy9pol6bF6 81xVI1obXJ9d7SO6tgeyamYVzluHrcX6+6Uxo413rQexxMl0gWZLnBoSCQsnZqzNwh2tl+6IaHNi wlnRRvgrZaXkg7PNlyZxEPVxLTU89b5sR7+Zax9xEOkhxd+f3l2/6unGvBJV4hnhwcuwBexY04UA tCp2xKytGqhHPjHQGEh7tDvoDHUwHKsG2iptBm3VNZNqKFTpkQ1bAeEwbB5J3ZnLiaVm1QK6NRpL 46a+ZL+N1P7a39Gmsv6hNtWlJg3buuqe00/i0q0ZwT4+esZYoxlcj3Q+bp+ArsbM2LnzCeLdSuq2 7bbAj0aovRN86ZC9rXStcy0YNuWOhrZq2+FthNsphGEzusKCDImki/QxbIJbH2pvGa7sYbNto+LW h/Itr7sRDkvPsHmo+qoKu7BnlXfXSedGFM1YBx+egoVzqrol7DZHJ3auGjEeqqapeqz+Tts6QxvF s9TaY712VTcazuwkPW/wU3s5G5mE3VFns9Mm6UQl4FLe6TjCxlgtcR7CLka2GxbOpNEYN1thOjF4 J9GFBYWXL11O7EU0gp3tOaUpqo2tUB1xdjrGQMoj0HZ52V7pQ6QY9dn11dKeScOGvyuezq5+uqEr AVWJZ4QHp2ELaNW85UDXglW0amqglEYx9NlWgeurV+Xe2qF6NE2oGxU1H+o+DTRqaXaWrFUjsmEr IDwN2yq1v9pYWKtGtBpf3LTFuMl0GR3MKtKJHh3poCveTZZ44K8C14BhI4vi48pE/1WpGzbs4DxO AMMW+khIkyVm2I45DFuZt8G5JB3UldxOl6SDGawauCrCTiWc6Ucq3qAq8Yzw4DBsWvxrDNGqgcHi 3xX2oG/Yx8yGGdG97hPt1OIOq9afc5yX9RhIjWzY8oe55JL6yweaYVv99lcwYEYHHREN6rFschWs mn9SzyrSTerxTnTFO5GtWjCWv2EzhhR6uRfBI0OlbthcZMOWCW7DtvI2uFxUPZiwB1Z1MCRhd0k6 mEHVwRyEndvg8kMq3qAq8YzwENSwZWHVMglBsPh3xTyYMeZtE1i9Ap5iW8wuFVNZvEJdD2mNa8mq Edmw5Q9vfPXk3L2xNLbNbtjKpv1VD2qiK7RBPbrtdEY3sUiSuhZBTD+uHcPm545We9ERIhu2gsJu 2EJrg9P1nKhLOpi7qoO6mJssteESoC7poFPJ7WSrlg2peIOqxDPCQ2bDli+rBuphTwzapa6HOuhl 2FzRbjNsWcW5Ht6gK7DB8optNmz5wy8PtINpbJtp2FqEYXNldNAVrZ4sEqsWTlK3JXKTRWLVOKln xTUwJNIwPIKDtDJkZtZuvTo0aDi970eGHEt0bG1W7yrbU7vVWH9y8KGPEbKvcSL2CcmwbX18yuMI a9iwNfddPfHt9om5UfXaB07D5pJ0sJSGS4AuPSe6JB3UxdxOl6qDGYTdqeqgruGezErYWdWzJxVv UJV4RnhIZ9j85SAXIQgQ/yuwaiAi3GnYfKJdGjb5RI6gca7HNugKbLAcY5sNW/5Ahi2NbbMZtvEV JXU9fol6FIO5WzVQD2eTpdb+ylZtVbgWFh2xdbIJau7Lg3Ji20Nl7cxFF9XISby0jBxsj/PgaqP9 aOII2G56RXFAY2X/lRq2I0NeR1jbho0uI71tS2fYSm24RDjC7pJ0MINVA1dF2KkwM7MiFW9QlXhG ePA1bKtr1UBXzIPZxrxh2HZ0+Ee7fOCGadj0kNboEeGuqCa6Sm15kA1b/mA3bETNtnkbNm5/NZgh qTszOqhHtye5/XW1uCYMG1h7Sj6o2qJ7yXuDwtI4rY7bMhm2Z6hxJNao7F+t2qg5K7lGpTZNzuz0 W5FhE712nkdgw2bQz7b5GjaXgPuRrVp+VR1kYV8BqXiDqsQzwoOHYcvCqmUSgmAS4Ip5MLeYtwyb K8iJIsKVYdNDejlurvq6vrqncVw8c6nCeiKHDG9tkdbqZ/JZHFRMZwefPtsp3xWrskafGSu9Pivp VbxNw/b4eQxegvh8aoFKD2EstpjDW3iZp7cuPBjHedVWib7ofLhvdUUSK39Lc2smTdumG7bybX/V g9pOe4AbLJKkrgULMyuuFcMmaD2gzKDZjWZR+ivdBckuMrG/4bsME+V0fR5PV6P+N9ca+lk8h81y d55kw+aAZtiIbtvmYdgK3Qanqzqoi7nJUhsuAeqSTnSKuUm2aismFW9QlXhGeHAYNh858FKBTEIQ LP59gj9g2LujPY1hs+Lc07CJjWLpSHoZHYXdekk8J94W3uKh8nd3PqHnJ87ele5O7oMyGqk4ZBm5 nY3W4+dfOvTM8ZTDUqNp2P7X/od2U9HSG6MCBFdj3x7wrY7hWe0tbAn3LZyd3sJJw33r9tMp7S3T mGX1VnrCtr311cP/ueUabr4wbK7k7cfSsmqgHtcmXQEOcvtr2XAtGTZJOTnNcRMcPVfp3ZFpgdRu uu1xzUwjp+fhjlx7+jNdDxsbNg2eho1ot20Ow1ZqbXC6nhNdkg7qYm6nS9XBDMLuVHVQ13BPchtc IUjFG6QCzwgRTsOmCwHoJQSumNcYLP5dYQ8GDHu/aPc0bHqcexi2/oa7sF5nxu0RPrpTGTYK5shO 7Xm4xhMPrYfTC0cntygXVw70M2zXOiapALmNTZC3GruntbewJdy3Hg7G6a2aR9Fw37rwYFx7qyui xotm9VZGvvbFo5/suI2b39I1ruVvT2aV1HPP6KAeyya5/ZUZlDsu3Xntiz//7tjrH9es21P3brFx t+AfbzXWhmbYJLeKZUKsm2BzL+RnMvqogIZN7eZhnMIwbGARzmG7dOfMF7c3/dft/7v79p/w82k/ aL656err2vVoJNtmN2yagHuySKxaOMLuknQwg1UDcxB2boMrHKl4g1TzYYSINIbNSwhcMa8xWPy7 Yh5cQcxb0a4ZNu849zBsjdXyU08c4T0ghkSqeB4Qjq7trhHbVC6b5Kds9kyYOmxxPKi+xGkatout ozScD4TvWlzCmwq3n05l+xb+wMv8vYXz0nYg9Lfmkkuwcyt/S7Nndv7tUl/H8Kw5JPLbTIYtl6Tu Cl5POiIa1GPZTldQE12hDepBbacrwMEMSd0Z6aA9un3J7a8F5X9U/lar0RYdz//wesOVcA0b0RiX CJq2J1zDptxR/gxbEa4SeeH2qU2X/re2sdi49/amn+44B1UPYtjKx6qBLlUH2aqVH6nSAqqqDyM8 eBq2XIQgmAR4BX/wmM8Y7XbD5hvn3j1s+BSs186G0QGPCFedaX40HFo5GzZedCR0aCaNSFaNdghi 2Lj91R7prmD3ISf1IuD/Pfc/tbps0XGlhm3rQ9cUMpOmZzO8jb/FcjA7w+bhjkIybN5kwxaAvz3y f17eUpPesBVBG9wqWDV/Yc9B1UFd0okuPSeyqueHVGkBqRrDCBFuw5a1EASLf5/gDxj2AaPdNGzp FoGEYZOjH+klhXS0x5p1JmxbZMAR28KJvfRpW6bZaGzYGFkgjVUjZDRs3P5qpy3G/clWrWi4sfq/ tIps0XHlhi2N1VGL8nusJuLYjdhsPmI7oGHz91phGzbH479XZthW+CTx4jdsh+5+dOvxfVJ1P8OW i1XLg7Drek50STqoK7mdLkkHM1g1cFWEnQoqM3RS8QZVPYYRHjTD5hICV8xrDBb/rrAHA4Z9VtH+ xGHY9JBWNAybFuFyoRHzVkjbRuuLILbZsLFhCx9prBohjWHLJam7gtdNRzgT9Vg2ye2vzBXx88vt P91W9crnX5xputE19rDY+DTy4PFoS0Nz3YoMW5oeM2XYLONkLAjp/giMk+7EMhk262janrmsEpnO sDlN6YoMGw4V5Kp8eaWh8tvuO+3DzU9H73eOPdB+0Hzz4qND2vXYCas2NNUNVU8zh61IrFo4wu6S dDCDqoM5CDu3wRUZqXiDVI1hhAhvwxZECILFvyvmwRXEfIY6nM2w6VFtURo2x3r9VngPRCM7D6nF /cH1jbOyCAZ0YmzYGFkgjVUjeBq2IknqelATXaEN6kFtpyvAwaysGugKcC9y+2vxcQ2sEkkWxXha mpNknBzuxXoQ9uDDx+aq/fJp11a3m4/tcfeb2R6rPWIcbevjxofqwdna89k8mdmwCVto7xIMYNi8 uxDphviPIA3C4lwl0rRqBD/DtkqqDupibpKHSzBDIBVvUJV4RnjQDVsQIQgW//kYA+kKcqIZ5+Nq ZOP6hrge2yaftL10qMeYqOYd4QNPzPUeqVfNWBCyOqIVTcGnYm0S+TcbNkYWSGPVCJph4/ZXK9IF 42foUYdpgh1cu0ldPBmSnhtpNDwVF9eMYQOF49pqGqRa9Vg2mw0zKB5Ibd0iRVu/k1xP39hoOS7D WWlGzn00WC/zCLiqtGMdbZbPy3MaTymweTPrcXPuh4PDK9JbHvbPuCG+vZHBWGyGTbNqBLdhy0XY nQLux6yEXcp4rLe951TV3XWf1q67E8ta1UGXqoMZhH05floq+bqGOGm7ruGe1CWd6BRzk5aqq7pc cUpieZCKN6hKPCM8OAxbEVs1n2h3VOAQxqoOB0umnqhmpwzpu9XieWtaeNsXhFSxLdfoN4dB0oKQ oMuMIf7NoZJs2Bhhwm7YMmb025WqiHpy3cG766q660ZmMkQ0qIezyWJrf81k2PJg1Uwd8OT6Q3fX Vz9rihZDVQC6ZHvEPxu27BGOYSNLBm/zuHHE8FTgiLBbPiMDHY9rk05PvWW5MpPCnlkGzKDdEdme IjAyJLfL/fH31eY3deNk0LaIZUYaZtJ9GXR5WRwtSKdfOhaPYfO0agS7YcvCqo10/+HT2m3teW2D i506JKwaXZ4wbOGoekZhtwybruGeXNFwiQIbtsGnz8wxXC99enf9obaKp+JKBhvNdv+SJ307UJV4 RnhwGjZX2NsZLP5t1TiTAcM+q2j3qMBJeo6KNCJ84EmbXJ1fD2+xan91RPxtFTvhvjyfsbazMaI2 fj/bVI0qmtntpgxbOTXesGErIByGTU/nRGdSX1jqbn9IGfelqhEreEdGTlWpJLGuaqTbM6JBPZZN roJV8wlz0BnpoBXXaWglcjsdUW8xgFWzc/Bpm1IDe5d7NFIhH6YPQhMMiSgsi1qR1tyDs5l5ZjEY tjRWjWAatvdh2HQ9J+qqDnbXyYWs7aruw8CqDnoK+8h2eXluw6aLuUmXpIMZVB3MSdWztWpZCXu+ ieoibqwtO8yKVEJ9DGX08F58HaIq8YzwEMiwBYt/LewlnQEP6qFu0jvgXUFOTBvn/U9UdWp9w2i/ adWio6hOUVToUS0Nm9hftI5TmYMTc4WQUUuz8yWre020kaiNniMnS5Ns2AoIy7B1uw2bntFBOQZy ZBsVQldqr6sS2+ktR0SnC2rQFdREV2iDelDb6QpwsEiSulbmA1AZIXekm11wxSECbNhyBxu2kmNh DRt8WnqrRkhr2HRJBx2q/undUyMOVbdTV3VQF3OThlUb6VlXNeIU9tgp6u+yGTZdzO10qToYmqqP 96yvHlV/65JOdIq5ScRv9JmtMb3wHGyUltvjkkSnHxs2RhBkMGzB4t+nAd5WkyPqoU7MKtqDxvno meq71HRBfOkQPWPNFdjg998PNAqrZrZ2gOvhxNzxY2tER4DZW0rcD2orj342NmwFhI9h0zM6KJM6 xayvYbPe+vThnQwRTQypY80V4GCRWLVc2199DZv1VuZFZVeBbNhyBxu2kmNhDVtA+Bs2XdVBpert D+kj4Lo6fVg70aqkEXUxt9NS8voqkSmcqu4wbLqY2+lSdTCDsDtVHdQ13MlGOYElO2E3VF20uReR YRNS7OvKxAAuNmyMzEhn2ALEfz6smk+0ZxPnXhHuCmww9xrbWiEbtgLCZdj0dA7arBrR17AtJGdO HZRvyWbatEk9JKsGumIcDN+qgXq8g654N7nSwE9j2FTbTXG0mLJhyx1s2EqOJWvYdFUHbcIudBt6 rtT7YLc5pt0Qdid1MbfTKeztYkyQMmyWnluGTRdzky5JBzNYNTBbYZfTW2wrDgQSdiUvT+mzRWPY jDk1fgscNFWzYWNkhrdhCxb/tsg3aYW9oh7qJoNHe1ZxHtCqga5yxnSTDVsB4TRsekYHnVaN6G3Y ZCw7DZseziZdQU10hTaoB7WdzgAnZkjqzkgH9ej2ZE7trysjG7YQyIaNGS5L0LDpkg7qbXAj3eto JKTsZyP1tqm6jbqS26m3wfW2t5mznZ2qnsmwZavqYPaqbk5scRo2p5jbaRN27znGhaW1CIL3yAte dIQRBLphCyYBjshXdMS8oB7nJr0D3hXkxKzi3Apsk67ABl0ljOlHNmwFhM2wRTMkdYu6YbNiWSR+ +dah7md6REvKtUmsVcKqeupH3NEdq7fvc6itYZTiWk1VV9vrYyq6O9TEThC5qkHFdby/o2dHtTjO jo4XqUjPDqoiVIvFXY1gj5+x1vDoaRx/0d/QJp53r4I93v+kRwx7xrsN8eUXcW1M8s4nFOzWWGUk bz3w5QhnyqOgbQprRvobNjMxm+sV2RnojLO2xUvkUG2vXG4fv406nG0lJDvthk0ftm209TpukfPj GS9YPDlgp9xBHC36bKc8FHYLsuYKGzZmuCwDw+ZW9boqs1dNafu6uhlL1U0ai4UQ192ZUaouu9GI UOB6oecxcw0qO40xkDG1ZiMZttGR7fIlRGa7qeo2ovLW39G2ztSQT+/uqB/td9TfhFYrtX8ipqWR 2kPV5VLeDiUnbTeV3871DbNGFW72boO1oADO6Jic4vlZ1WLlftJJPlTRk7YDfnqXVobMzHQn8tPe NvrD5OrrPB0EVCWeER4chs0Z/54szBhIo5bmT92ngRTbTobTvr6GyIatgPA0bP5WjWgZNkc4J2eo 3RTc3q4FNbi8MNKzDim5XT57Z1G4MnGQT++eGrXF9Sj2EUfuk+HcJ80Y9jmtPNvyYsRYYcyW2kVG r6ejkWEbPW1bPHpHvTgm/f3SoZ4GFdGjO/CyelQ9nGN8FDkeJzIMW/yMfc16YdgQ7/EKueCHSIfO hYXuVos1YAe0si2nDexUiVMs92p+1rGbN/0Mm5UUjTRpY6AziiPjsCoRiuf4u/cRZxEttWqjeSj3 tFuthw21GesW2ffEEayTmsxwwRH7kwN2NiqnKvY59CzI/D02bMxwWdKGzUfYhZ6L1fzlS1o4Cv7t mV3b7Uo+Yq7xSIZN1dB67yiJkIaN9Fz1pJk9bErD7YZNCj7+NqkJe2pJ7CyEPULVtniDoUUN41R5 c6p9g3pSrtjnUE+jS8ltwyVUG5zsYbPrudLYnU+kf4NC0tEcUqz2cW20ncsadBCuKvrTaMtTF5DR 5qU7UXrtLbDO07ugKvGM8OBl2Ozx76AKfgfNypxBI+ydNILcZECrBipL5keerpZPsmErIDTDlsmq EV2GbWTmWftDagF96dBD12BIaoIRaX57uz20jXR+qKdXhbbYBy/JrUmq1I5zGTFuJHsjr6sYV9bO 7GETvWqUxZEYTqvUbgV1f4NY0NXWnwbCwhlbVJiPKjeiDJtcFkweEJnGHvh3q932SaR550Yjx3v2 jOl01RKitgWaD3kObgl0xsFGtZKtbTd80LHFYwFbuVEcSh9vo67Tqp3YbpFtN/HxHG+RUQtxHzMj 2bAxw2WJGrY0wt5dB0F4WGe8XDBWHxGNbt5VNdUwB7vlqLDRdDUybErPHYbNkHRL1ddVtYkBFBEp 7EZLnNB/pepC2BukFp1Wbk0RG+lcDWYVblz5NOzsVHWiaJ7Du4aSE03DJp+3ZJImth16NmDU6NTq iw7p8zRsRJckgqGroh+NvimT/g+ACXCiNNpbUJ3HbkRV4hnhwWnY9OA3aYt8kyrsLdpi3knDpJlc VasGuooUMyDZsBUQdsMWzK2BKrNqfOlQ950RY5CMK65776BaYDS+GqFdT625Ridbn2yj1Sc2dIiJ ELZmV8uwmUld0G3YjCS944lHsDfKlO94lKJwcW1novaQNw2bNVSGMo0xHpICP7LTlUqlL9LnEhie J4jxUFlfIzKc31OzA56Rtmg51TEkkibTuysHRkJ1VESM63Q0J9MtcpxiJbdIncJVD8hMNmzMcFly hi2TqotZx7QspGp9M+RdtMfpYk60DJsSc6Jp2KwKm2XYHJJua4aDNzPrbH3WKAmnqh/qsQZAghDz cdUYZ3sQtqX2pp5bfOFp2Azb4DRsd0mC7HpFkugQJeuzxhaTbkkEQ1fFNFRdWCbxQaN3y2KwE6XR 3kLqPHYjqhLPCA8ZDVugMZDOgLfRFvBEX6sGBrdqoBXYJq2otsgdaysjG7YCwjRs92DY9FzuQa+M brzUFxqxx7XK3H7c3oFYFlkcB7FGP3oHuN2w2UJbM2wixtOl8H75XEScbkeDMSrSo3XGbdjUAxVF jjcD/2mbMzeDKpn5MUBOUtnLqBAYL31zdtAzIn3iJY7jMyfNSKUeFRGjjuJIyR61E3UK+xFWdIuy SOQa2bAxw2XpGTangOtsf6h02zJsS3dUO9rDO5aYm4SqKzHXDZuhwHbDZhozh6SbPWzajDVXo5vq SaseVSJv1d/i6sjwckrS/dXeoeSmYUP0GYJmN2yISrmgiEOvQjBsoatiJso5Y/bPOnU74InSaW8B dd78uCrxjPCQxrDxdDUmG7ZCwjJsPRkMmy2ju5pgjVE0xloj7rgWH3HmcotGRNM+TsPminGbYYs7 AtxM9lakp21zNYbQyE8J2zbgEfJG6rUZNtpoT95NHssl0z56s2I2VKe20qGsNIgtriZMycBnNDrK xKE8bJvKr668K2iaPXezqHP/cG+ROkUWlRWDbNiY4bLMDJtYbkSbimzTc9dUZBJzl2EjJXcaNing PobNNawdFDU33bApV6ak3hJ2QbPFzRgA6aX2Vhuc3bCZSm6ZLrXFJSAvoqK3ymuonvVZa2dFT0lU 28NTxUAclFOUcTFE2yUFPFF67Q33G6U/l4PmN1IlnhEe/AwbBb+TRh3OpCPOTVq1N8WAVg20gtmT PAZy1cmGrYAIaNgcGd1rzMwzOZoR1JtdFb0NmzOunYbNFeOgjPGghi3DIBlQLjRCly0/e3eno/0V VCnEMmyyjYb6oIzk5zEIJJss5Ud1anuFgPyS7dR2ZnNGZxYXX9yZyMVGj4pIcMMW7i1Sp2DDxiw4 y8mwmYv6+tGm8B7DJZTUm3puM2yGpLsMm1Jyh2GzKm+6YVMCLnrYXFW4DIZNr8h5jJVwGDZX4ztZ HamNkcEwetjAVUkcHjQTh+3IAU+UQXsLpfP0dUBV4hnhwW3YzMi30Qx7g0bMu2irwBF9rRroinNf slUrENmwFRAZDZvTqlHy9jBs5sQG0LmyCIWz+sj2jjTRrfbRx8lYMU5h7mx2NUkzxQ3DJoM6k2GT IT8QHd15SOUz0N2ZZm00C619lpfHIBAwi9zjQ3UEZ4VA1RK8jpz1GWWNxPbFzaTrcV5Fw7DZs69x i7SbEOYtyvqrmWTDxgyX5WHYSMyf1d21VoO0lFzQNirSPVzCZthsFTbTsDVYku40bJaeW4bNUXnL ZNjs6m0YtrZGtcWm9npFDjRkysew2UUDMtskBxNay3WEZNjynDgiO71Em2h6NuPIAU+UabcC6Tx2 I6oSzwgPmmHTgl/SHvaSRsA7aQW8YjhWDdTDGzSj2kZXMwxz5WTDVkCkMWzKoZm00rnbsMmkLlbt l9s/1RcX8V8uTLKjTfaqGdldrhLmjPHl/vo2Y6Ewl2GjMDcMm5G/QX/D5mqdGXhiLjLWdtcKeZVC kIecgS+2U/72GgQCpknnIrF5fUSjOrV+BGspLa3NMsczDj7VD6jmsHm1iSrD5mhGtW6RuZu5PaRb pE4RJJFrZMPGDJdlYNgMSRcyLp63Zgm7jcaoSK8RE96GzZqBZmm7IenVI6aeS9oNm1FhA+2GTaq6 fTVITcOVYXPNYdv5xCHskjYltxs2HwlSAmjfGJZhC1MV3fTs4DKoL+oY8EQZtTfEb5TxXBaxG1GV eEZ4cBg2PfhtAU+0qnF2OqJdkKpxjmg3afg0oj3IPajHNmjEs51s1fJGNmwFhKdhs0yaSUc6txs2 Z/ur8QRVvGWs1K9IC0KCcn0RO5G8ZY43VglT+1hhjqCGSTMXCjOmmzvHyZgP58lg2AyrNtCAVOEM eZXSvA2bVmiNpN7mlyNpB9CVfpDAshgf4pHnZO2B3rKfOuAZPZ6RbXxxtY9xfHfipFM4t6/CLcoi kWtkw8YMlyVt2BySLpYb8VxWhGiI/KGeXrvCgz5PV2tQz9XMbNiCD2unZjjQ3eimL/NrrAPpNGwu JTcNm9AHTy/hpTahGbYQVdFNcV5fkdREPuiJMmtvQXSeDgiqEs8IDz6GzVmfA40gd9IW58QQrZrL rZnh7aSruDBDJBu2AsJt2BxJHdQTOWgZNiucDZrGTPNs5gNSkfa231HPxUZGR5pfZ6Zz25PTdnSY o2XiDfV37andaHa9e/pJXET6+Ojp6rYzDSqn2h7Co1L4enPpZ1uwDzTclc9LtUe9SBgvHXo2YET9 cprUa7gaz6wsaHWF2Rf2kFPYPdsadapTezZMminQ4dmCnXGwUTzY1Hwpqb64+RFVF9ETsLabtRE7 5/MW+Z8iE9mwMcNliRo2l6qLEeyyxc0u7ETVBkcPwgatIe6GmFuPY+mQj2AZHTld1Xb6jlJg+yRk pdU0aCIycrq6p1+oulLmAPOQ42eUFpk9aURxBLVRVeS0dSBNVScaGgLDZmt8V2aDNE0sq4g/1J4O 22AzbINP2yrkW16fpf3T6lUeE4c4r7BkHt1canCE46SBThRAewuh83RGUJV4RnhwGTZbNY6ovJmb VI2z0deqgUaQyzjPRKPeZlALb4OugsIMnWzYCgi7YXMldW8+M9eE/LTt1IiRy62Mruyc2OFQGzK6 9RRs+UQ1essk9mmwx7j3Ps7n8BgP4TEp2lmNtlhkhfUykfdLCye2VI8aSd0irc6/vvrZXfUI7Nm7 xtOizcAfbDSOoLsUULga2t+53canYnloOoJJfN+0raSKNM1d7P+p5zAYldvogBVPZ9XlBTijytzV z4y8jsTp/iJiwr38rLEbaiT4vq6LX4VbZJ0iQ33Fg2zYmOGy5Aybrurg4swd6g2rokV9TTpWFrGa 3oznZFo0Wt9MijER0m6B2H+dMazdHDRB3NEhBLzf2rOtwXwi9nL8tNEOZXu6GqiWhkIWaKTGuPFR uDiohBhMYem5qRKjVv3NoPWuU6bMmV1EMmnKiSnnMwv9WW+b62uqkOdn5XbvcxnMX+JQSQEHhxEa NI8vF7rEdg+/l+lEwbS3ADpvHkSVeEZ4cBo2e9hLWvbMTnsdTjJvVg3Uw1vQ1gzDzCvZsBUQpmG7 bzdsjixukWaiu6kvF+aZzimuRVusynMir1c7HpyqOs8jyNDGPofu7qgftdyaEeb9T5Svg+irLjVp 2NZX95x5Eu832mXtdD4yFSlcWLWBJ0jGxg6H2oR5U4EvkpD5WaI2VEN0VXmnZBttD8NReVTbwUWz 90yj3u5oNFuaVJeX6YyDjcKDwRDav7hXo+xsk6ipqH3wQ+w0baGxQ/5vkccpgrS/mmTDxgyXpW3Y hIxbDWrEdXdoGptp1azZyHaaAyBBKHmf0bIGBVZdatKGravuOd0Rs6l67LQarH53R0fcHNBuJ+yZ OfTRpLNLLd7Y4NCiHRB5qw0u7qES1ly19DI1S+KDy7M9WlptBA1tVA1Yujrpn80siWCeEoe4SLI6 +KxNukH5LXxk0/dEWWjv6uu8uZsq8Yzw4GvYVB1OoxXqiqoaZ1ba7LRZNdAIbx8GHAPJVm11yYat gPAwbDaH5qR7uTCDtqA2qce1na4YB9O1yIBZRbpJPd6JrpAncuCXHdmwMcNlqRo2XcztDEnYXZIO pqu8EXMQdo+KHOgUcztZ2MuOVLxBVeIZ4cHDsOmhbtI74F1BDmYV5wGtGugqGcx8kw1bAeEwbHoi t9OVy4nOXE7Ug9pOV4CDGZK6M9JBPbo9mVVS54xepmTDxgyXpWfYdCW3M49tcGzVmPkjFW9QlXhG eHAYNj3OTXoHvCvIiVnFuR7eoCuwQVeZYK4O2bAVEAEMW/m3v2oFklk2ZMPGDJclZtiO+xm2VRgu 4S/sOag6qEs60SnmJtmqlTWpeIOqxDPCQybDllW0ZxXnemyDrsAGObYLSjZsBURaw8btr8zSJhs2 ZrgsC8Pm0nOiS9JBXcntdKk6mEHYnaoO6hruSW6DYzpJxRtUJZ4RHvwNW1bRnlWce0S4K6qJrqLA XGWyYSsgfAzbKrS/ugLcZFaRblKPd6Ir3ols1dYG2bAxw2WJG7byHy7Bwr4WSMUbVCWeER58DJt3 wLuCnBg8ztmqlRrZsBUQXobNlcuJrnQOWuHspivAwQxJ3RbmRD26Pcntr0wfsmFjhsuSNWyl1gbH Vo3pTyreoCrxjPDgMmxZRXtWca6HN+gKbJBju5jIhq2AcBo2bn9llhXZsDHDZQkatlWwav7C7lR1 UNdwT+qSTnSKuUlW9bVHKt6gKvGM8OA0bMGjPas412MbdAU2yLFdfGTDVkDYDNuEns6JrowO6onc TmeAE9mqMQtCNmzMcFlyhk3Xc6JL0kFdye10STqYwaqBqyLs9nhnrhFS8QZViWeEB2/DFqJVc0W4 K6qJrl+dWQxkw1ZAmIat1W3YXBkd1BO5nbZcbjJDUs8q0k3q8U50xTuRrdoaJhs2ZrgsB8PmUnVQ F3OTLkkHM6g6mIOwcxscMzCpeIOqxDPCg4dhC1iH00NaI1u1siAbtgLC27C50jmoJ3I7nemcWCRJ XStszDVFNmzMcFnahs2l6qAu5na6VB0MX9VBXdJBp5LbyVZtzZOKN6hKPCM8OAxbOFYN1MMbdAU2 yLFd9GTDVkB4GDZXRgf1RG7Slc7BIrFqHPhMNmzMcFmqhs0l6aAu5na6VB3MIOxOVQd1DfdkVsLO qs6UpOINqhLPCA+aYXPFOZhVnOuxDboCG+TYLhGyYSsgHIbNldFBPZHb6croIFs1ZvGQDRszXJak YQtH1Qsv7PbQZq5lUvEGVYlnhIe0hi2rOPeIcFdUE10/MLNoyYatgLAM2zPdsOmJ3E5XRgfz1P7q jHeiK96JbNWYTrJhY4bL0jNsTlUHdTE36ZJ0sEisGgs7004q3qAq8Yzw4G/YsorzgOHt+mmZRU42 bAWEp2HTE7mdrowOFklS18oVk1kqhu3I9V0Hr25mFj9v371euoZNF3M7XaoOhq/qoC7pRKeYm2Sr xvQiFW9QlXhGePAybFnFuR7boCuwQY7t0iQbtgLCbdj0RG7Slc5Bbn9lFjNLwLCl5ociA0962tu7 Hn7X+YBZvOx6gN/oybP2iXik5AybLuZ2ulQdzCDsTlUHdQ33JLfBMUMiFW9QlXhGeHAatqziPOAY SK6xlTLZsBUQdsOmJ3I7XRkd5PZXZpGzFHrYFuILU+Px58PTvc+ne4amuplFy+HpZ2PxwelEdCGV EFolilgxQjNsupibdEk6yG1wzOInFW9QlXhGePA2bHpIawxo1UDXb8ksLbJhKyAyGzZXRgcL3/7K GZ0ZgEVu2F68QHQsJhZnZ+YnJuZGYNvGZ5nFy+jsyFRibHZhBjYbZhs/n/ohiwymYfvgeIuu5yZd qg6yVWOWBKl4g6rEM8KDbtj0kHZTD2/QFdig61dkliLZsBUQ6QybK52D3P7KLCEWu2H7HuV8aXEp OZ+am0vG5pIzMAPM4qT4gRZj84uzydQ8JLBo3RqQwbC5VB3Mqg1OF3A/6pJOdOk5kVWdGZhUvEFV 4hnhwWHY9JDWqMc26ApskGO7jMiGrYDwNWzZZnQwh6TOVo2ZTxa5YZNAgV+m2EotOUKQWWyU+re0 vAzRElA/YPHB17C5VB0sEmG3hy2TmZ5UvEFV4hnhIZhh84hwV1QTXT8es6TJhq2A8DBsrowOhp/R QT3eia54J7JVY2bPUjBsYmCknA3FLAHilypmq0bwMGwuSQeLxKqxsDOzJRVvUJV4RnjIZNjYqq1t smErIByGzZXRwQxJ3ZnRQT26Pcntr8xVYUkYNgYjXOiGzaXqIFs1ZumSijeoSjwjPKQ1bHp4g67A Bjm2y5ds2AoIy7D16oaN21+ZpU42bIw1CIdhc6o6mKc2OJeqgy49J7KqM1dGKt6gKvGM8OBj2PTY Bl2BDXJslzvZsBUQfoaNrRqzDMiGjbEG4WfYiqQNTgtSJjNbUvEGVYlnhAeXYfOIcFdUE12/E7P8 yIatgHAbNm5/ZZYN2bAx1iDchq1IrBoLOzMUUvEGVYlnhAenYQsY3q5fiFmuZMNWQNgNW5Ekda14 MJk5kw0bYw1CM2zhqzqoSzroEnOTbNWYoZKKN6hKPCM8OAxb5gjn2F5jZMNWQJiG7YEwbK5cbjKH pM7tr8xCkw0bYw3CbtjSuTWnqoO6hnsyK2FnVWfmgVS8QVXiGeHB07C5Ahvk2F6TZMNWQGQ2bPnO 6CAHPjM/ZMPGWIOwGbZvdT03uSrCrsUjkxkKqXiDqsQzwoNm2FxRTXT9JMw1QjZsBUQ6w+bM6KCe vz3J7a/MoiEbNsYaRAbDlm9VB1nYmfkkFW9QlXhGeMhk2Fw/BnNNkQ1bAeFr2FYlqWslgckMl2zY GGsQvoYtB1UHdUknuvScyFaNmX9S8QZViWeEB3/DxrHNZMNWUHgYthySOre/MouSbNgYaxAehs2p 6qCu4Z7kNjhmUZKKN6hKPCM8eBk2rrExDbJhKyAchi2HjA7q6ZzoTOQmOfCZq0g2bIw1CN2w5SDs 3AbHLGJS8QZViWeEB5dhc9195lomG7YCwjRs6w83IbtnxxNZE6djMleNv959m4o3GzbG2oFp2P7X rpu6aGekS7SDUIs7JjOvpOINqhLPCA8Ow9bWP8lk2mlWqtiwrT7s2sdklivZsDHWDkzDxmSWN1WJ Z4QHh2FjMv3Ihm31wYaNuRbIho2xdsCGjblGqEo8IzywYWMGIhu21cezSAzZncksb07OJlWJZzDK HbMLKa38M5llSVXiGeFBGDZz7CmT6UeuVDEYDAaDwWAwGKuN77///wBjo/TqWLV1dQAAAABJRU5E rkJggg== --94eb2c1907b49fe6b20555944f21-- From nobody Mon Jul 31 06:57:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCBB1322F5 for ; Mon, 31 Jul 2017 06:57: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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 SqBBkrkMiFUG for ; Mon, 31 Jul 2017 06:57:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 482641322F4 for ; Mon, 31 Jul 2017 06:57:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xLgxP5t8Pz3Bm; Mon, 31 Jul 2017 15:57:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1501509433; bh=7fH4FJE6zWA/vPJkEF3kMjwCeBL5bYI3Loz6xiLgXX4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=f/t/A/F/G6kqsNXcFneA4VWk3yufBXiyuZWUSJh90SnbQ5pG21Hu3dVPgKgAS+p/L ZCIrb3Yy7SoD8c8qu3MrrwnW6VQWrqirEny7PzlnRnGRM4S5mROMbESMX1KdEpFIHe f8erelzu/DzG8Hg7H33ux+y+r3hnqMtYygc8C2os= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pcAky0O94XkQ; Mon, 31 Jul 2017 15:57:12 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 31 Jul 2017 15:57:12 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8707730AF32; Mon, 31 Jul 2017 09:57:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8707730AF32 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8088E40D3592; Mon, 31 Jul 2017 09:57:11 -0400 (EDT) Date: Mon, 31 Jul 2017 09:57:11 -0400 (EDT) From: Paul Wouters To: Evan Hunt cc: Joe Abley , Shane Kerr , dnsop@ietf.org In-Reply-To: <20170730074253.GA33522@isc.org> Message-ID: References: <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> <20170730074253.GA33522@isc.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 13:57:18 -0000 On Sun, 30 Jul 2017, Evan Hunt wrote: > It's clearly helpful for human debugging. > > But, yes, you're correct -- diagnostic information included with a > SERVFAIL is about as trustworthy as the AD bit, and in the absence of an > authentication mechanism such as TSIG, clients should not rely on it or > base policy on it. But we know people are already building software and systems that DO trust the AD bit, even with non-localhost resolv.conf entries. This saves them the overhead of adding a dnssec library to their application, and saves them from running a system resolving understanding dnssec. So I'm pretty worried that people will treat new unprotected error codes exactly the same. They'll handwave and say that's the system administrator's issue to solve, not the application's responsibility. > Some of the error codes might be trustworthy enough if you're using COOKIE > or TCP; that would enusre at least that it wasn't an off-path forgery. That's a very small use case with pervasive monitoring and coffeeshop and hotel wifi. > This should be spelled out in more detail in the security considerations. I'm seriously afraid that's not going to matter at all when people implement this. Paul From nobody Mon Jul 31 10:11:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C421326D7 for ; Mon, 31 Jul 2017 10:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 y3iHGKS2VHdq for ; Mon, 31 Jul 2017 10:11:09 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 9BFC31326D6 for ; Mon, 31 Jul 2017 10:11:09 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 797403498BD; Mon, 31 Jul 2017 17:11:07 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 6CBD7216C1E; Mon, 31 Jul 2017 17:11:07 +0000 (UTC) Date: Mon, 31 Jul 2017 17:11:07 +0000 From: Evan Hunt To: Paul Wouters Cc: Joe Abley , Shane Kerr , dnsop@ietf.org Message-ID: <20170731171107.GA42492@isc.org> References: <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> <20170730074253.GA33522@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 17:11:11 -0000 On Mon, Jul 31, 2017 at 09:57:11AM -0400, Paul Wouters wrote: > But we know people are already building software and systems that DO > trust the AD bit, even with non-localhost resolv.conf entries. This > saves them the overhead of adding a dnssec library to their application, > and saves them from running a system resolving understanding dnssec. Are there applications specifically trusting AD=1 and behaving differently than with AD=0? Or are they just ignoring it and trusting every answer equally? I would have expected the latter, but I confess to being surprised if there are people going out of their way to implement "DNSSEC validation" by just buying whatever magic beans some dude in the forest has for sale. > > Some of the error codes might be trustworthy enough if you're using COOKIE > > or TCP; that would enusre at least that it wasn't an off-path forgery. > > That's a very small use case with pervasive monitoring and > coffeeshop and hotel wifi. In case I wasn't clear, I'm suggesting that TCP and COOKIE would be adequate protection for any error code where the worst case scenario is no worse than what any MITM can do. If you've already got control of the channel, then I can't see how sending the client "Prohibited" or "Lame" messages gives you any more of an advantage than you already had. However, any response that says anything about DNSSEC validity should be presumed guilty until proven innocent. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Jul 31 11:16:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743DC13274F for ; Mon, 31 Jul 2017 11:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 hJRONGM75_G7 for ; Mon, 31 Jul 2017 11:16:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 35983127869 for ; Mon, 31 Jul 2017 11:16:50 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xLnhv3TYzz3Tt; Mon, 31 Jul 2017 20:16:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1501525007; bh=ATOLruJppm1iA6IEBhNrgWciGVgT18fSyXVb2DNb9Ks=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=MQfljdZt4IsPGNDv0YpNTxphcVBmLscFxImkR3zNHRHo/Xtkk/mb6TswCoL0rSGRL yPByGt3+QJdpHtsi2pZfEjyYgt29ONwHIPCKFkwbAPm3XsKIm12ilxFSR9pWnNiypT 4q4Hn2ssDkB5mu5K4rN9uxyE/kqfi/DAJU70DR5g= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id auirbvHpToOm; Mon, 31 Jul 2017 20:16:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 31 Jul 2017 20:16:44 +0200 (CEST) Received: from [193.111.228.71] (unknown [193.111.228.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 234D830AF32; Mon, 31 Jul 2017 14:16:43 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 234D830AF32 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14F89) In-Reply-To: <20170731171107.GA42492@isc.org> Date: Mon, 31 Jul 2017 14:16:37 -0400 Cc: Shane Kerr , dnsop@ietf.org, Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: <306070B3-DD80-41F2-A0AA-2004131D0F23@nohats.ca> References: <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> <20170730074253.GA33522@isc.org> <20170731171107.GA42492@isc.org> To: Evan Hunt Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 18:16:52 -0000 Postfix is one but last I knew only when resolv contains localhost. I think systemd-resolved also does various tricks but haven't looked at that= in a long time. Software doesn't want to link against a dnssec library. Hopefully we can get= something smaller and better if we can use query-chains (via stubby, TLS, e= tc) that removes most of the DNS code from getting and processing a dnssec c= hain. Paul Sent from my iPhone > On Jul 31, 2017, at 13:11, Evan Hunt wrote: >=20 >> On Mon, Jul 31, 2017 at 09:57:11AM -0400, Paul Wouters wrote: >> But we know people are already building software and systems that DO >> trust the AD bit, even with non-localhost resolv.conf entries. This >> saves them the overhead of adding a dnssec library to their application, >> and saves them from running a system resolving understanding dnssec. >=20 > Are there applications specifically trusting AD=3D1 and behaving different= ly > than with AD=3D0? Or are they just ignoring it and trusting every answer > equally? I would have expected the latter, but I confess to being > surprised if there are people going out of their way to implement "DNSSEC > validation" by just buying whatever magic beans some dude in the forest > has for sale. >=20 >>> Some of the error codes might be trustworthy enough if you're using COOK= IE >>> or TCP; that would enusre at least that it wasn't an off-path forgery. >>=20 >> That's a very small use case with pervasive monitoring and >> coffeeshop and hotel wifi. >=20 > In case I wasn't clear, I'm suggesting that TCP and COOKIE would be > adequate protection for any error code where the worst case scenario is > no worse than what any MITM can do. If you've already got control of the > channel, then I can't see how sending the client "Prohibited" or "Lame" > messages gives you any more of an advantage than you already had. However= , > any response that says anything about DNSSEC validity should be presumed > guilty until proven innocent. >=20 > --=20 > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Jul 31 12:13:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6713278F for ; Mon, 31 Jul 2017 12:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 kWjq_n71zGK8 for ; Mon, 31 Jul 2017 12:13:22 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 CFDDE13278D for ; Mon, 31 Jul 2017 12:13:21 -0700 (PDT) Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6VJDKCq032275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 31 Jul 2017 14:13:20 -0500 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6VJDFWv024074; Mon, 31 Jul 2017 14:13:15 -0500 Received: from lxomp06u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6VJDFwt024065 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Mon, 31 Jul 2017 14:13:15 -0500 Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6VJDFxP038342; Mon, 31 Jul 2017 14:13:15 -0500 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6VJDFCC038336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Jul 2017 14:13:15 -0500 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.14]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Mon, 31 Jul 2017 14:13:15 -0500 From: "Woodworth, John R" To: "'Vernon Schryver'" , "dnsop@ietf.org" CC: "Woodworth, John R" Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" Thread-Index: AQHTAAPw+UbndOaHcUud70v4A7K1OaJbDfuAgAAPdwCAABuOAP//u9kwgABcYQCAAJGCYIADa7GAgAEYHOCAAII6AIANadOQ Date: Mon, 31 Jul 2017 19:13:14 +0000 Message-ID: References: <201707230027.v6N0Rc7E047050@calcite.rhyolite.com> In-Reply-To: <201707230027.v6N0Rc7E047050@calcite.rhyolite.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:13:24 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Vernon Schryver > > > From: "Woodworth, John R" > > > > One could make $GENERATE more efficient without actually > > > implementing the BULK RR, by taking your pattern matching logic and > > > implementing it > > ... > > > This would still be a vendor-hack (bind) and not a standard. > Hi Vernon, Thank you for your question. > > The examples I've noticed in this thread look similar to RPZ patterns, > although perhaps I've missed examples that do not fit the RPZ mold. > > RPZ is not exactly a standard and certainly not without controversy, > but it is documented and available for more than BIND. > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/ > I'm no expert on RPZ (and am certainly not a coauthor for it ;) ) but my understanding is it is a policy driven blackhole list. After scanning through the link you provided I am now a true RPZ fan. That said, I do not believe it will help solve our problem. Our goal is to expand on $GENERATE and make its *intent* survive AXFR's with the end result being indistinguishable from that of a $GENERATE. Thanks, John > > RPZ is officially only for recursive resolvers, but that is because > superficially it makes little sense for an authority to rewrite its > own response. However, RPZ works on authorities (masters) in at > least BIND. > > Could RPZ be a partial solution to the problem that the BULK RR > would solve? > > I agree that a statement of the problems solved by the BULK RR > would be good. > > > Vernon Schryver vjs@rhyolite.com > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Mon Jul 31 13:13:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98566131CA0 for ; Mon, 31 Jul 2017 13:13:14 -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, URIBL_BLOCKED=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 Rj9s62DJgSME for ; Mon, 31 Jul 2017 13:13:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EF2127735 for ; Mon, 31 Jul 2017 13:13:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 24AC17A3309; Mon, 31 Jul 2017 20:13:11 +0000 (UTC) Date: Mon, 31 Jul 2017 20:13:11 +0000 From: Viktor Dukhovni To: dnsop@ietf.org Message-ID: <20170731201310.GI8146@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <20170731171107.GA42492@isc.org> <306070B3-DD80-41F2-A0AA-2004131D0F23@nohats.ca> <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> <20170730074253.GA33522@isc.org> <20170731171107.GA42492@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <306070B3-DD80-41F2-A0AA-2004131D0F23@nohats.ca> <20170731171107.GA42492@isc.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 20:13:15 -0000 On Mon, Jul 31, 2017 at 05:11:07PM +0000, Evan Hunt wrote: > Are there applications specifically trusting AD=1 and behaving differently > than with AD=0? Or are they just ignoring it and trusting every answer > equally? I would have expected the latter, but I confess to being > surprised if there are people going out of their way to implement "DNSSEC > validation" by just buying whatever magic beans some dude in the forest > has for sale. On Mon, Jul 31, 2017 at 02:16:37PM -0400, Paul Wouters wrote: > Postfix is one but last I knew only when resolv contains localhost. Not only Postfix, also Exim, and perhaps also Sendmail some day if/when DANE support appears there, partial support is already in the snapshot code: ftp://ftp.sendmail.org/pub/sendmail/snapshots/sendmail.8.16.0.21.tar.gz That code also relies on the (presumably configured local) resolver's AD bit. In all three code bases making sure that the resolver is actually local is up to the MTA administrator. I expect this implementation strategy will be near universal. > Software doesn't want to link against a dnssec library. Correct. Software similarly also does not want to explicitly add code to handle Kerberos, ... which is why various indirect approaches are becoming popular for handling security "out of process". Having a local resolver with a trustworthy "AD" bit is a feature, not a bug. The AD bit is exactly the right DNSSEC interface. All that's missing from the traditional libresolv (and not missing from recent innovations in res_ninit(), res_nsearch(), ...) is the ability to specify the loopback address as the sole resolver in the application. No matter how much some here might want to discourage the "AD" bit interface, it is the main one that developers will use, if they use DNSSEC security signalling at all. So it is up to the platform vendors to improve security by delivering systems with a default-on local validating resolver (that forwards to any upstream servers that would otherwise have been used directly). This also improves latency by bringing the cache closer to the application. -- Viktor. From nobody Mon Jul 31 13:51:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF27131CBF for ; Mon, 31 Jul 2017 13:51:24 -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] 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 sn7SloB8sXLI for ; Mon, 31 Jul 2017 13:51:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2CC1327BE for ; Mon, 31 Jul 2017 13:51:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8F6E07A3309; Mon, 31 Jul 2017 20:51:21 +0000 (UTC) Date: Mon, 31 Jul 2017 20:51:21 +0000 From: Viktor Dukhovni To: dnsop Message-ID: <20170731205121.GJ8146@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 20:51:24 -0000 On Sat, Jul 29, 2017 at 08:53:48AM -0400, Paul Wouters wrote: > > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > I have reviewed the draft, and while I think it could be useful, I'm > seriously worried about sending unauthenticated errors back to the user, > and fear that software will start using these without first validating > the response using DNSSEC. > > I would like to see more discussion on this topic before adopting this > document with a focus on how we could secure these error codes. My DANE-related code always treats SERVFAIL as insecure, a more detailed SERVFAIL would still be insecure. I don't see any new exposure here. Providing additional diagnostic information can help with deployment. Eliding useful information because some fool might misuse it is IMHO the wrong trade-off. Where necessary, the final document can emphasize that the information provided, is typically useful, but is not trustworthy. The intended purpose is presumably to facilitate problem resolution by enabling clients to report more detailed diagnostics to the server operator. Logging something more useful than SERVFAIL (e.g. signature expiration, lame delegation, ...) would be quite useful. Sometimes, by the time a problem is noticed in the logs it is no longer observable in real-time. Having a better record of what happened at the time of the problem is valuable. -- Viktor. From nobody Mon Jul 31 16:17:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601991270B4 for ; Mon, 31 Jul 2017 16:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 ErjYszYh417z for ; Mon, 31 Jul 2017 16:17:40 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387A31243F6 for ; Mon, 31 Jul 2017 16:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=fkfBWcLYk+dGOJdTLgchIoDBP+5lLQCD9BLsreOsXwQ=; b=mbjKdy76B25aqYcNpo5JmJk6RXr1DEN2oJkho9fp5t0Ts+gfOuMsMi5vUfWbx6U7bNGjNo0Ru5ewU0qYKRmIHjqxjGEvtFxaeBL7SCoyQ4DcY9qk6/KhpmSnz1Hey0zHfspPXHy4ugrMRrtAf2ALhuAu0DIdTJ4O+PP0PcqPMNo=; Received: ; Mon, 31 Jul 2017 16:17:38 -0700 To: dnsop WG From: Jacob Hoffman-Andrews Message-ID: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> Date: Mon, 31 Jul 2017 16:17:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:17:42 -0000 Hi, I'm interested in seeing https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03 move from draft status to become a standard. In particular, it would allow browsers to start treating "localhost" as a secure context, which would reduce attempts by application developers to abuse the public Web PKI in order to issue certificates for localhost, which harms security. See: https://groups.google.com/d/msg/mozilla.dev.security.policy/T6emeoE-lCU/-k-A2dEdAQAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/wsj5zpbbAQAJ What further steps are needed to move this draft along, and how can I help? Thanks, Jacob
On W= ed, Jul 26, 2017 at 2:24 PM, Joe Abley <jabley@hopcount.ca>= wrote:

On 26 Jul 2017, at 13:28, Richard Gibson <rgibson@dyn.com> wrote:

> The need for such a signal also came up recently in https://tools.ietf.org/html/draft= -wkumari-dnsop-multiple-responses-05#section-10 . But in this case= particularly, middleboxes should be a complete non-issue... anyone expecti= ng QTYPE=3DANY passthrough is already asking for trouble.

We may be imagining different things by "middlebox" -- I t= hink you're thinking of a resolver, whereas I'm thinking more broad= ly about stateful inspection, firewalls, ALGs, proxies, forwarders, etc. I = think there's an entirely reasonable and observable expectation that QT= YPE=3DANY passthrough works in that broader sense. Mark's <https://www.ietf.org/proceedings/92/= slides/slides-92-dnsop-7.pdf> was an easy-to-find example of tr= ouble in the real world.

Yes, color me = corrected on vocabulary but unconvinced on interference... those slides see= m to mostly demonstrate noncompliance by name servers theirselves with resp= ect to EDNS data in queries, whereas the data I'm suggesting would only= appear in responses.

I = will plan to add text to acknowledge the lack of signalling but not to chan= ge the mechanism to introduce any. People should throw rocks if that seems = bad.

That works. And I'm all out, so yo= u're safe from me.

<= span class=3D"">> 2. Section 4.1 appears to have some errors in grammar = and use RFC 2119 terms, and should be reworded (removals in strikethrough, = additions in bold):

Strikethrough and bold, eh? OK. :-) Suggestions are good, many thank= s!

Ha! I'll use Markdown convention= s in the future.