From peter@denic.de Mon Jul 2 02:22:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C61B21F8BC1 for ; Mon, 2 Jul 2012 02:22:23 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1n4IAapT7Nu for ; Mon, 2 Jul 2012 02:22:22 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE5021F880B for ; Mon, 2 Jul 2012 02:22:20 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1Slcps-0007Jz-Dv; Mon, 02 Jul 2012 11:22:24 +0200 Received: from localhost by x27.adm.denic.de with local id 1Slcps-0008Eq-AZ; Mon, 02 Jul 2012 11:22:24 +0200 Date: Mon, 2 Jul 2012 11:22:24 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20120702092224.GN22304@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] Preliminary slot assignment for IETF 84 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 09:22:23 -0000 FYI, we have been assigned, as requested, a one hour slot for the DNSOP WG meeting in Vancouver. The agenda currently sees us on Thursday, 1730-1830: APP iri Internationalized Resource Identifiers INT lwig Light-Weight Implementation Guidance INT trill Transparent Interconnection of Lots OPS bmwg Benchmarking Methodology OPS dnsop Domain Name System Operations RAI atoca Authority-to-Citizen Alert RAI avtext Audio/Video Transport Extensions TSV behave Behavior Engineering for Hindrance Avoidance "behave" is on our list of conflicts to avoid, but unless we hear strong arguments we'd rather not ask for a rescheduling not to produce worse overlaps. That said, we would like to encourage discussion of new and emerging topics on this list in the spirit of ... > Topics should ideally have been the subject of promising discussion on > the WG list, so if you have any drafts you are thinking of submitting > and would like discussed at the meeting, can you please get them in > and announce them to the list as soon as possible. > Although the draft WG agendas are not due until 18 July, the final > IETF agenda will be published on 6 July. We would therefore like > suggestions for agenda items by end 4 July the latest: if there is no > interest in a meeting, we will cancel the meeting request. -Peter & Stephen From paul.hoffman@vpnc.org Mon Jul 2 08:26:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E741821F86DF for ; Mon, 2 Jul 2012 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnyW8+K+yy0b for ; Mon, 2 Jul 2012 08:26:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C91D21F85CD for ; Mon, 2 Jul 2012 08:26:15 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q62FQ7gY009039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jul 2012 08:26:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120702092224.GN22304@x28.adm.denic.de> Date: Mon, 2 Jul 2012 08:26:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120702092224.GN22304@x28.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1278) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Preliminary slot assignment for IETF 84 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 15:26:16 -0000 On Jul 2, 2012, at 2:22 AM, Peter Koch wrote: >> Topics should ideally have been the subject of promising discussion = on >> the WG list, so if you have any drafts you are thinking of submitting >> and would like discussed at the meeting, can you please get them in >> and announce them to the list as soon as possible. >=20 >> Although the draft WG agendas are not due until 18 July, the final >> IETF agenda will be published on 6 July. We would therefore like >> suggestions for agenda items by end 4 July the latest: if there is no >> interest in a meeting, we will cancel the meeting request. There are only three WG drafts: dnssec-dps-framwork, which has already been sent to the IESG repsize, which is in some weird state with the AD writing up ballot text rfc4641bis, which has WG consensus and is waiting for a writeup Unless someone is wanting the WG to consider a new, non-WG draft, what = is the purpose of meeting? --Paul Hoffman From iesg-secretary@ietf.org Tue Jul 3 14:16:00 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1311E8145; Tue, 3 Jul 2012 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4k6vGDl7YuK; Tue, 3 Jul 2012 14:15:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE2411E80C4; Tue, 3 Jul 2012 14:15:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30 Message-ID: <20120703211559.31773.84433.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 14:15:59 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] Last Call: (A Framework for DNSSEC Policies and DNSSEC Practice Statements) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 21:16:00 -0000 The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'A Framework for DNSSEC Policies and DNSSEC Practice Statements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document presents a framework to assist writers of DNSSEC Policies and DNSSEC Practice Statements, such as Domain Managers and Zone Operators on both the top-level and secondary level, who are managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From peter@denic.de Wed Jul 4 03:06:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0221F8800 for ; Wed, 4 Jul 2012 03:06:58 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM5OjoRKnuEI for ; Wed, 4 Jul 2012 03:06:58 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0632E21F8702 for ; Wed, 4 Jul 2012 03:06:58 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1SmMUE-0007UT-SR; Wed, 04 Jul 2012 12:07:06 +0200 Received: from localhost by x27.adm.denic.de with local id 1SmMUE-0008VF-OJ; Wed, 04 Jul 2012 12:07:06 +0200 Date: Wed, 4 Jul 2012 12:07:06 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20120704100706.GF12591@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] Update on Vancouver X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 10:06:58 -0000 Dear WG, for the meeting in Vancouver we have asked for discussion to happen on the list to prepare for and substantiate a high bandwidth interaction on site. So far, the only document we have seen addressed is that on "Omniscient AS112 Servers". We are currently considering devoting meeting time to the topic of AS112 servers (that is, this draft but also surrounding questions), which is clearly within our scope, albeit not formally adopted. On top of that we want to allow discussion of any in- or post-IETF last call issues for draft-ietf-dnsop-dnssec-dps-framework and draft-ietf-dnsop-rfc4641bis. There are other old wg drafts that are expected to be updated or revived by Vancouver but do not appear to need face time. In the expectation that discussion is going to intensify and issues will be identified we are keeping the meeting slot assignment for now. Please stay tuned for a draft agenda early next week. -Peter & Stephen From internet-drafts@ietf.org Mon Jul 9 09:29:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94011E8128; Mon, 9 Jul 2012 09:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYx3FvurDYJp; Mon, 9 Jul 2012 09:29:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC111E810E; Mon, 9 Jul 2012 09:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 09:29:39 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:29:40 -0000 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 Working Gro= up of the IETF. Title : DNSSEC Key Timing Considerations Author(s) : Stephen Morris Johan Ihren John Dickinson Filename : draft-ietf-dnsop-dnssec-key-timing-03.txt Pages : 33 Date : 2012-07-09 Abstract: This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-dnssec-key-timing-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sa.morris7@googlemail.com Mon Jul 9 10:12:50 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE111E8152 for ; Mon, 9 Jul 2012 10:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS1vnylPGeQU for ; Mon, 9 Jul 2012 10:12:49 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F08BB11E8137 for ; Mon, 9 Jul 2012 10:12:48 -0700 (PDT) Received: by eaaq13 with SMTP id q13so4621263eaa.31 for ; Mon, 09 Jul 2012 10:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=JKIlekFZE4750kfaAMdiG5Jx4cEw8enBRXrAUUjx6pQ=; b=XWYVK4vn9JYSPi7Z07cnbLy+vRIgrMT9sPn3VY3PPMa1GMd7V/GZfMTLcKx29tamZ6 mAZ9yxu5EedNxcK1Nwxk26FxOHzcjEpEn855SgdEFDe6RKhhfwaqu+/V0pSZF97FZMO5 jCYIJKUAzcLsvdUfAlORxWGKsAJacX5dImfaKyM89K6Uevbi7aNVQhjvhS2q7P3cpuVE CmxrMeiX+XmOGg9gcnG2hB0LP9RoHQJUa0mx35jHlL7nsk47++FlWkKYQyZmj//8O8jT p9xFTa1hjPwBrF4wgsdWNSLr0VJRa3vP4A9Wh2VCar5pfTH4FLychki7yep0SA5VajBk 4edQ== Received: by 10.14.127.6 with SMTP id c6mr10039196eei.164.1341853993380; Mon, 09 Jul 2012 10:13:13 -0700 (PDT) Received: from [192.168.1.100] ([217.155.47.50]) by mx.google.com with ESMTPS id m46sm95480242eeh.9.2012.07.09.10.13.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 10:13:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stephen Morris In-Reply-To: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> Date: Mon, 9 Jul 2012 18:13:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:12:50 -0000 After much delay, the -03 version of the key timing draft has been submitted. It incorporates a number of comments made on-list and privately: many thanks to Mark Lampo, Matthijs Mekking and Alfred Hoenes. Perhaps the most significant change concerns the timing considerations related to the introduction of a new KSK (section 3.3.4.1). Stephen On 9 Jul 2012, at 17:29, 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 Working = Group of the IETF. >=20 > Title : DNSSEC Key Timing Considerations > Author(s) : Stephen Morris > Johan Ihren > John Dickinson > Filename : draft-ietf-dnsop-dnssec-key-timing-03.txt > Pages : 33 > Date : 2012-07-09 >=20 > Abstract: > This document describes the issues surrounding the timing of events > in the rolling of a key in a DNSSEC-secured zone. It presents > timelines for the key rollover and explicitly identifies the > relationships between the various parameters affecting the process. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-03 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-dnssec-key-timing-03= >=20 >=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 wmaton@ryouko.imsb.nrc.ca Tue Jul 10 06:45:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D80E21F86F6 for ; Tue, 10 Jul 2012 06:45:15 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONOvOgV+kx-9 for ; Tue, 10 Jul 2012 06:45:14 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 612E621F864C for ; Tue, 10 Jul 2012 06:45:14 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.5/8.14.5) with ESMTP id q6ADjQBm029809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 09:45:31 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.5/8.14.4/Submit) with ESMTP id q6ADjQdY029806; Tue, 10 Jul 2012 09:45:26 -0400 Date: Tue, 10 Jul 2012 09:45:26 -0400 (EDT) From: "William F. Maton Sotomayor" To: Joe Abley In-Reply-To: Message-ID: References: <0E1171B9-7E91-4432-8EAF-1810090B85B7@kumari.net> <6FE949C2-18F3-432D-AB75-F66E71570CDF@hopcount.ca> <20120628000150.E0EF122080E9@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:45:15 -0000 On Fri, 29 Jun 2012, Joe Abley wrote: >>> - we do need some mechanism to delegate (e.g.) zones under IP6.ARPA correspo >>> nding to the various v6 analogues of 1918 >> >> Do we have data that says we need to? > > I don't think we get that data until we look for it, and I think we look for it by delegating some zones and counting queries. We just need somewhere to delegate the zones to. This document is a proposal which would facilitate such a query sink. AFAIK, data points to this effect were presented by George Michaelson at the DNSOP IETF meeting in Prague when he introducted his draft to the group for their consideration. Not sure if George is on this list to verify my memory as being correct. >> Remember RFC 6303 style >> support for ULA was permitted a long time ago. ISC added it to >> named in 9.4.0. Full RFC 6303 support, to cover the RFC 1918 >> reverses, was only added in 9.9.0 the first major release after RFC >> 6303 was published. > > I think I interpret your note as "ISC is taking steps to reduce traffic > on the AS112 servers through the knobs and switches available in BIND" > which I think is commendable and great, but not entirely an answer to > the question. +1, good for BIND to do this, provided people run the latest version of BIND. An interesting test would be to see how many and what versions of vendor implementations would self-sink AS112-bound queries. >>> Adopt this doc? +1 wfms From paul@nohats.ca Tue Jul 10 11:49:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2083621F86B2 for ; Tue, 10 Jul 2012 11:49:41 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8-mOVgV4iHj for ; Tue, 10 Jul 2012 11:49:40 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A621F86B1 for ; Tue, 10 Jul 2012 11:49:40 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 52E6C853CA; Tue, 10 Jul 2012 14:50:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4605A81999 for ; Tue, 10 Jul 2012 14:50:06 -0400 (EDT) Date: Tue, 10 Jul 2012 14:50:06 -0400 (EDT) From: Paul Wouters To: dnsop Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:49:41 -0000 Hi, At Quebec City I volunteered for a use cases document for automating parent-child DNS updates. I've submitted a draft for it, and hope to get feedback before and in Vancouver... Paul https://datatracker.ietf.org/doc/draft-wouters-dnsop-secure-update-use-cases/ DNSOP P. Wouters Internet-Draft Red Hat Intended status: Informational July 9, 2012 Expires: January 10, 2013 Secure parent-child DNS update use cases draft-wouters-dnsop-secure-update-use-cases-00.txt Abstract DNS zone administrators occasionally need to update data published by a parent zone, such as NS and DS records. Traditionally these updates have happened out-of-band: through DNS registrar interfaces, EPP, websites, or manually by operators. Some updates could also be done using DNS Dynamic Update [RFC2136]. The IETF's DNSOP working group is considering proposing additional mechanisms for such updates, possibly leveraging DNSSEC for authentication. This document presents some use cases to drive this design work. From cet1@hermes.cam.ac.uk Wed Jul 11 08:08:34 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFA221F85D4 for ; Wed, 11 Jul 2012 08:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UySkZUSJJ837 for ; Wed, 11 Jul 2012 08:08:33 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6F35321F85C2 for ; Wed, 11 Jul 2012 08:08:33 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39181) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:cet1) id 1SoyXG-0002od-Z0 (Exim 4.72) (return-path ); Wed, 11 Jul 2012 16:09:02 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1SoyXG-0007R3-PB (Exim 4.67) (return-path ); Wed, 11 Jul 2012 16:09:02 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 11 Jul 2012 16:09:02 +0100 Date: 11 Jul 2012 16:09:02 +0100 From: Chris Thompson To: Paul Wouters Message-ID: In-Reply-To: References: X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsop Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 15:08:34 -0000 On Jul 10 2012, Paul Wouters wrote: >At Quebec City I volunteered for a use cases document for automating >parent-child DNS updates. I've submitted a draft for it, and hope to >get feedback before and in Vancouver... > >Paul > > >https://datatracker.ietf.org/doc/draft-wouters-dnsop-secure-update-use-cases/ | 3.2. The NS RRset | | Both the child and the parent have a copy of the NS RRset. These | RRsets are supposed to be identical. If they differ, it is referred | as a "Lame Delegation". I have always thought that a "Lame Delegation" was something more specific: an NS record in the delegation that points to a server that is not in fact authoritative for the zone at all. Is the above actually common usage? [That's not to say that any differences between the two NS RRsets is ever desirable, except as may be necessary or expedient during a change.] -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From jim@rfc1035.com Wed Jul 11 08:37:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D921E21F86D4 for ; Wed, 11 Jul 2012 08:37:03 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBrdB++oOHt4 for ; Wed, 11 Jul 2012 08:37:03 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 425BC21F86C4 for ; Wed, 11 Jul 2012 08:37:03 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id B2929CBC41C; Wed, 11 Jul 2012 16:37:31 +0100 (BST) Message-Id: From: Jim Reid To: cet1@cam.ac.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Jul 2012 16:37:30 +0100 References: X-Mailer: Apple Mail (2.936) Cc: dnsop , Paul Wouters Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 15:37:04 -0000 On 11 Jul 2012, at 16:09, Chris Thompson wrote: > | 3.2. The NS RRset > | > | Both the child and the parent have a copy of the NS RRset. These > | RRsets are supposed to be identical. If they differ, it is > referred > | as a "Lame Delegation". > > I have always thought that a "Lame Delegation" was something more > specific: > an NS record in the delegation that points to a server that is not > in fact > authoritative for the zone at all. Is the above actually common usage? There's no formal definition of the term AFAICT. So it can mean whatever anyone wants it to mean. RFC4697 seems to be the closest thing to a (somewhat indirect) definition but is only a BCP and RFC1912 is just Informational. That said, "lame delegation" is commonly understood to be a delegation to a server which should be authoritative but isn't. This may or may not be the same thing as a parent and child disagreement about some zone's NS RRset. So it may be better if the draft uses a different term for the scenario where the parent and child do not have the same NS RRset. Perhaps that can be called a Broken Delegation? Because that's what it is.... From paul@nohats.ca Wed Jul 11 09:03:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1E821F85C2 for ; Wed, 11 Jul 2012 09:03:30 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lX25YXucZfD for ; Wed, 11 Jul 2012 09:03:30 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7721F8593 for ; Wed, 11 Jul 2012 09:03:29 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 9A91285EFE; Wed, 11 Jul 2012 12:03:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8E1CE85DDF; Wed, 11 Jul 2012 12:03:54 -0400 (EDT) Date: Wed, 11 Jul 2012 12:03:54 -0400 (EDT) From: Paul Wouters To: Jim Reid In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cet1@cam.ac.uk, dnsop Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:03:30 -0000 On Wed, 11 Jul 2012, Jim Reid wrote: > So it may be better if the draft uses a different term for the scenario where > the parent and child do not have the same NS RRset. Perhaps that can be > called a Broken Delegation? Because that's what it is.... I've changed it from lame delegation to broken delegation. Thanks, Paul From gson@araneus.fi Wed Jul 11 11:15:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FAF11E8100 for ; Wed, 11 Jul 2012 11:15: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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWAkvAn2g8zk for ; Wed, 11 Jul 2012 11:15:52 -0700 (PDT) Received: from gunk.araneus.fi (gunk.araneus.fi [166.84.6.82]) by ietfa.amsl.com (Postfix) with ESMTP id C220C11E8088 for ; Wed, 11 Jul 2012 11:15:52 -0700 (PDT) Received: from guava.gson.org (guava.gson.org [10.0.11.2]) by gunk.araneus.fi (Postfix) with ESMTP id 22D401D0866; Wed, 11 Jul 2012 18:14:25 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 0854E75E3F; Wed, 11 Jul 2012 21:16:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20477.49909.903443.742699@guava.gson.org> Date: Wed, 11 Jul 2012 21:16:21 +0300 To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: dnsop , cet1@cam.ac.uk Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:15:53 -0000 Paul Wouters wrote: > On Wed, 11 Jul 2012, Jim Reid wrote: > > > So it may be better if the draft uses a different term for the scenario where > > the parent and child do not have the same NS RRset. Perhaps that can be > > called a Broken Delegation? Because that's what it is.... > > I've changed it from lame delegation to broken delegation. I suggest simply dropping the sentence 'If they differ, it is referred as a "Lame Delegation"' instead. I don't think Jim's suggestion of "broken delegation" is common usage for the particular situation of "parent and child NS RRsets differ" any more than "lame delegation" is, and as far as I know, there is no established shorthand term that refers specifically to this situation. -- Andreas Gustafsson, gson@araneus.fi From davidb@verisign.com Thu Jul 12 07:25:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7107C21F86E2 for ; Thu, 12 Jul 2012 07:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA3CFjA0e9zJ for ; Thu, 12 Jul 2012 07:25:58 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4012521F86DF for ; Thu, 12 Jul 2012 07:25:54 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKT/7ekt1vEMwA02sh/HePrITkMQgyw109@postini.com; Thu, 12 Jul 2012 07:26:31 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q6CEQJem020583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 10:26:19 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Thu, 12 Jul 2012 10:26:13 -0400 From: "Blacka, David" To: Andreas Gustafsson Thread-Topic: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 Thread-Index: AQHNXszaAZYwjIbudkKRU9yU3Ay73pckc6oAgAAH9ACAAAdgAIAAJQKAgAFSDYA= Date: Thu, 12 Jul 2012 14:26:17 +0000 Message-ID: <4283801C-B6B3-4954-9432-DFE713F86832@verisign.com> References: <20477.49909.903443.742699@guava.gson.org> In-Reply-To: <20477.49909.903443.742699@guava.gson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C135DBF116AA3409DAC3C9E0228AD45@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop , Paul Wouters , "" Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 14:25:58 -0000 On Jul 11, 2012, at 2:16 PM, Andreas Gustafsson wrote: > Paul Wouters wrote: >> On Wed, 11 Jul 2012, Jim Reid wrote: >>=20 >>> So it may be better if the draft uses a different term for the scenario= where=20 >>> the parent and child do not have the same NS RRset. Perhaps that can be= =20 >>> called a Broken Delegation? Because that's what it is.... >>=20 >> I've changed it from lame delegation to broken delegation. >=20 > I suggest simply dropping the sentence 'If they differ, it is > referred as a "Lame Delegation"' instead. I don't think Jim's > suggestion of "broken delegation" is common usage for the > particular situation of "parent and child NS RRsets differ" > any more than "lame delegation" is, and as far as I know, > there is no established shorthand term that refers > specifically to this situation. "broken delegation" suggests to me (at least) that the delegation cannot be= successfully followed. That is possible, of course, but most of the time = when the parent and child disagree, the delegation works but is not optimal= . If we want a term for this (very common) case, I suggest "mismatched del= egation". -- David Blacka =20 Principal Verisign Infrastructure Engineering From jabley@hopcount.ca Thu Jul 12 13:07:04 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC35321F8703 for ; Thu, 12 Jul 2012 13:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVoTj43VgIMC for ; Thu, 12 Jul 2012 13:07:03 -0700 (PDT) Received: from mail.hopcount.ca (mail.hopcount.ca [216.235.14.37]) by ietfa.amsl.com (Postfix) with ESMTP id CBE4F21F861E for ; Thu, 12 Jul 2012 13:07:03 -0700 (PDT) Received: from [99.249.222.163] (helo=[192.168.0.167]) by mail.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpPfd-000FgN-Tf; Thu, 12 Jul 2012 20:07:30 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Thu, 12 Jul 2012 16:07:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <69DB802F-2846-4ABC-AFEC-D10D54618466@hopcount.ca> References: To: cet1@cam.ac.uk X-Mailer: Apple Mail (2.1278) Cc: dnsop , Paul Wouters Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:07:04 -0000 On 2012-07-11, at 11:09, Chris Thompson wrote: > [That's not to say that any differences between the two NS RRsets is = ever > desirable, except as may be necessary or expedient during a change.] That's a good rule of thumb, but so long as the union of the delegation = and apex NS sets contains no lame delegations, everything will still = work as far as the client is concerned. I have seen someone use a deliberately different apex and delegation NS = set (with all servers authoritative) in order to try and identify = differences in the traffic pattern (e.g. to see whether there are = clients who reliably cache and re-use the delegation NS set in spite of = the apex NS set). When submitting NS set changes to the root zone it is required to update = the apex NS set before submitting the change request, and until the = change request is completed the delegation set will be definitively = different. Other registries that perform configuration checks on child = zones might behave differently. I realise this was encapsulated in your = use of "necessary" but I thought perhaps it was worth spelling out. Joe= From peter@denic.de Fri Jul 13 04:57:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5CA21F8705 for ; Fri, 13 Jul 2012 04:57:18 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-zzy5Qj8NWE for ; Fri, 13 Jul 2012 04:57:18 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0E21F8702 for ; Fri, 13 Jul 2012 04:57:17 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1SpeVL-0005Ls-Qm; Fri, 13 Jul 2012 13:57:51 +0200 Received: from localhost by x27.adm.denic.de with local id 1SpeVL-0002XI-Na; Fri, 13 Jul 2012 13:57:51 +0200 Date: Fri, 13 Jul 2012 13:57:51 +0200 From: Peter Koch To: dnsop@ietf.org Message-ID: <20120713115751.GE24669@x28.adm.denic.de> References: <20477.49909.903443.742699@guava.gson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20477.49909.903443.742699@guava.gson.org> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 11:57:18 -0000 On Wed, Jul 11, 2012 at 09:16:21PM +0300, Andreas Gustafsson wrote: > > I've changed it from lame delegation to broken delegation. > > I suggest simply dropping the sentence 'If they differ, it is > referred as a "Lame Delegation"' instead. I don't think Jim's while this discussion is refreshing, the reason Paul (was) volunteered to write this document was less the (re-)definition of the lame delegation terminology but more to address (potential) requirements for an in-band child parent key exchange. Let's leave the bikeshed black for the moment and focus on the design of the bikes instead. -Peter From dougb@dougbarton.us Sat Jul 14 13:49:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2DB21F85F1 for ; Sat, 14 Jul 2012 13:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puufRh1vE0Ds for ; Sat, 14 Jul 2012 13:49:55 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id B49BC21F85E3 for ; Sat, 14 Jul 2012 13:49:54 -0700 (PDT) Received: (qmail 16164 invoked by uid 399); 14 Jul 2012 20:50:24 -0000 Received: from unknown (HELO opti.dougb.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 14 Jul 2012 20:50:24 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <5001DB93.4000708@dougbarton.us> Date: Sat, 14 Jul 2012 13:50:27 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andreas Gustafsson References: <20477.49909.903443.742699@guava.gson.org> In-Reply-To: <20477.49909.903443.742699@guava.gson.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop , Paul Wouters , cet1@cam.ac.uk Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 20:49:55 -0000 On 07/11/2012 11:16, Andreas Gustafsson wrote: > Paul Wouters wrote: >> On Wed, 11 Jul 2012, Jim Reid wrote: >> >>> So it may be better if the draft uses a different term for the scenario where >>> the parent and child do not have the same NS RRset. Perhaps that can be >>> called a Broken Delegation? Because that's what it is.... >> >> I've changed it from lame delegation to broken delegation. > > I suggest simply dropping the sentence 'If they differ, it is > referred as a "Lame Delegation"' instead. I agree with Chris that "Lame" has the common meaning that a server in the NS set is not authoritative for the zone. I would argue further that a child NS set which is a superset of the parent is not lame, or broken. There are valid reasons to do this, (outside the scope of this document, certainly) and I'd hate to see this instantiated as "an RFC violation" as a side effect. > I don't think Jim's > suggestion of "broken delegation" is common usage for the > particular situation of "parent and child NS RRsets differ" > any more than "lame delegation" is, and as far as I know, > there is no established shorthand term that refers > specifically to this situation. Agreed. I would express 3.2 like this: Both the child and the parent have a copy of the NS RRset. The child's zone should contain each of the NS records listed in the parent, and each of the servers in the NS RRset should be authoritative for the zone. Modifying the NS RRset ... -- If you're never wrong, you're not trying hard enough From joe.abley@icann.org Sat Jul 14 14:04:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207CD21F8610 for ; Sat, 14 Jul 2012 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+EelimEhv5B for ; Sat, 14 Jul 2012 14:04:25 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9821F860F for ; Sat, 14 Jul 2012 14:04:25 -0700 (PDT) Received: from [199.212.90.56] (199.212.90.56) by smtpx.exc.icann.org (64.78.22.244) with Microsoft SMTP Server (TLS) id 8.3.245.1; Sat, 14 Jul 2012 14:05:04 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_4349D928-F8D2-4520-AE25-CD46D678409A"; protocol="application/pkcs7-signature"; micalg=sha1 From: Joe Abley In-Reply-To: <5001DB93.4000708@dougbarton.us> Date: Sat, 14 Jul 2012 17:05:02 -0400 Message-ID: <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> References: <20477.49909.903443.742699@guava.gson.org> <5001DB93.4000708@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: Andreas Gustafsson , Paul Wouters , dnsop , "cet1@cam.ac.uk" Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 21:04:26 -0000 --Apple-Mail=_4349D928-F8D2-4520-AE25-CD46D678409A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-07-14, at 16:50, Doug Barton wrote: > I would argue further that a child NS set which is a superset of the > parent is not lame, or broken. There are valid reasons to do this, > (outside the scope of this document, certainly) and I'd hate to see = this > instantiated as "an RFC violation" as a side effect. Or a subset, or a completely different set. The relative sizes of the NS = sets and the size of the intersection is not really relevant; the = important thing for resolution is whether the union of both sets = contains lame servers. Any new work which needed to assert that both sets were the same would = meet with little objection though, I think. It's commonly-shared wisdom = that both sets should be the same, and "are consistent and remain so" = (RFC 1034 section 4.2.2) is fairly clear. Joe --Apple-Mail=_4349D928-F8D2-4520-AE25-CD46D678409A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNzE0MjEwNTAzWjAjBgkqhkiG9w0BCQQxFgQUYFjVdFdpWMpnb+GkU1eKJIYtLxswgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB AExCP5a+h5s65ftsdY/hT64NSnqHHRpHnA+gAlAu6oEsHQR07xphkbqhHdRLxiUEe1x9ctkEYovE J+uhOqHfsmMkgNLKAdrhshWrvd9eB1mroS9zh/goyT83rPlnsLECRj5jUatxkpkXSQkiAL9bKt5F n6Mmo3/1mG/b7QynX0AkN9V9quQZk8dg2CfsjMMHrl5nE1n6o1qTI/D9gM9DHg6TW+xpQ/9DW5fU tNVA342FSsOhf8JQJ3ekKD0Pxfb8ND33UnaLFA73lNzAOlhNJOHCayKlAsHWrERP8T3HPsXFZC37 GVqyxhSrR3gDvtz0prgpttqTUivsUwCByIIxIBsAAAAAAAA= --Apple-Mail=_4349D928-F8D2-4520-AE25-CD46D678409A-- From dougb@dougbarton.us Sat Jul 14 14:34:43 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF7C21F8629 for ; Sat, 14 Jul 2012 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iehto0r89Gs for ; Sat, 14 Jul 2012 14:34:43 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id C399421F84E2 for ; Sat, 14 Jul 2012 14:34:42 -0700 (PDT) Received: (qmail 24284 invoked by uid 399); 14 Jul 2012 21:35:16 -0000 Received: from unknown (HELO opti.dougb.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 14 Jul 2012 21:35:16 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <5001E617.5000304@dougbarton.us> Date: Sat, 14 Jul 2012 14:35:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Joe Abley References: <20477.49909.903443.742699@guava.gson.org> <5001DB93.4000708@dougbarton.us> <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> In-Reply-To: <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andreas Gustafsson , Paul Wouters , dnsop , "cet1@cam.ac.uk" Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 21:34:43 -0000 On 07/14/2012 14:05, Joe Abley wrote: > > On 2012-07-14, at 16:50, Doug Barton wrote: > >> I would argue further that a child NS set which is a superset of >> the parent is not lame, or broken. There are valid reasons to do >> this, (outside the scope of this document, certainly) and I'd hate >> to see this instantiated as "an RFC violation" as a side effect. > > Or a subset, or a completely different set. The subset you can usually get away with, (assuming, as you have, that the omitted server actually answers authoritatively for the zone) but in practice that's a meaningless exercise because so many resolver implementations will continue to query the server if it answers authoritatively. The "completely different set" case is a whole different can of worms, and is likely to cause damage. (Both of these observations are based on my experience.) > The relative sizes of the > NS sets and the size of the intersection is not really relevant; the > important thing for resolution is whether the union of both sets > contains lame servers. My experience tells me differently regarding the 2 cases you mention above. However, you'll note that the text I proposed does take what you wrote into account when the child set is identical or greater than the parent set. > Any new work which needed to assert that both sets were the same > would meet with little objection though, I think. It's already met with at least 2 objections, so I'm pretty sure you're wrong. :) > It's > commonly-shared wisdom that both sets should be the same, and "are > consistent and remain so" (RFC 1034 section 4.2.2) is fairly clear. Sure, that's the ideal, and I always advise people to "make it so." However 25 years after 1034 was written we know quite a bit more about how DNS works in the real world, and the case of the child zone having a superset of NS records is a real, valid configuration. Doug -- If you're never wrong, you're not trying hard enough From joe.abley@icann.org Sat Jul 14 14:53:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE321F85FF for ; Sat, 14 Jul 2012 14:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k0v-0sifz9H for ; Sat, 14 Jul 2012 14:53:53 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37F21F85F9 for ; Sat, 14 Jul 2012 14:53:53 -0700 (PDT) Received: from [199.212.90.56] (199.212.90.56) by smtpx.exc.icann.org (64.78.22.243) with Microsoft SMTP Server (TLS) id 8.3.245.1; Sat, 14 Jul 2012 14:54:32 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0BD61597-D756-45DF-9315-1C7B021225AC"; protocol="application/pkcs7-signature"; micalg=sha1 From: Joe Abley In-Reply-To: <5001E617.5000304@dougbarton.us> Date: Sat, 14 Jul 2012 17:54:29 -0400 Message-ID: <16A391ED-C508-4E7B-80C9-518130A2098E@icann.org> References: <20477.49909.903443.742699@guava.gson.org> <5001DB93.4000708@dougbarton.us> <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> <5001E617.5000304@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: Andreas Gustafsson , Paul Wouters , dnsop , "cet1@cam.ac.uk" Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 21:53:53 -0000 --Apple-Mail=_0BD61597-D756-45DF-9315-1C7B021225AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2012-07-14, at 17:35, Doug Barton wrote: >> Any new work which needed to assert that both sets were the same >> would meet with little objection though, I think. >=20 > It's already met with at least 2 objections, so I'm pretty sure you're > wrong. :) Well, my note wasn't an objection and yours just made assertions with no = explanation, so I didn't count them. Joe --Apple-Mail=_0BD61597-D756-45DF-9315-1C7B021225AC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNzE0MjE1NDMwWjAjBgkqhkiG9w0BCQQxFgQUe8tgKDuDf3NuF4N1czLmgmw+XSswgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB ABtonLsu66xqvxlFydT6KmBnxJ6wsndzjR0bJ8PZZvepJPqHVrI9JOyXQbZytJLOiE3Aq/+KA9GQ 0ZarR/lHy/RLPkil1SPToRZFo61btYHb9UQpbfV4OYah7yqvpAgkeApCOluBOKGwMq5XHuL4+4lO 18160+conYZ79bO8+GLnmbokDpXIxU7Q/HTmBUi+zKcUevyHzpq4xlQIRsWXaBkxwys5Mk/M8Dbq 7ICvcvS0l5HMEKizRmyy8OOsNZDquZKC+t70Tjv4zenQxUzF15HvBexrgAptzJCzExKtF8MWcpNe zdxinmS1H69gYxjRjNpXoeO6drcEuZsFirPC1OIAAAAAAAA= --Apple-Mail=_0BD61597-D756-45DF-9315-1C7B021225AC-- From paf@frobbit.se Mon Jul 16 00:40:00 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B8821F85F8 for ; Mon, 16 Jul 2012 00:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HukU4xfaJ0IK for ; Mon, 16 Jul 2012 00:40:00 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5F21F85F6 for ; Mon, 16 Jul 2012 00:39:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 03DF514338311; Mon, 16 Jul 2012 09:40:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLFr-w+Q2AJT; Mon, 16 Jul 2012 09:40:41 +0200 (CEST) Received: from [IPv6:2a01:3f0:1::8477:17a2:b83f:4035] (unknown [IPv6:2a01:3f0:1::8477:17a2:b83f:4035]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id A56291433830A; Mon, 16 Jul 2012 09:40:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120713115751.GE24669@x28.adm.denic.de> Date: Mon, 16 Jul 2012 09:40:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1278) Cc: dnsop@ietf.org Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 07:40:00 -0000 On 13 jul 2012, at 13:57, Peter Koch wrote: > while this discussion is refreshing, the reason Paul (was) volunteered > to write this document was less the (re-)definition of the lame = delegation > terminology but more to address (potential) requirements for an = in-band > child parent key exchange. Let's leave the bikeshed black for the = moment > and focus on the design of the bikes instead. Because I find the registrar/registry description be non-complete, and = in some cases wrong, let me suggest that portion of the draft is just = removed, and instead that the draft actually talk about what it is = supposed to talk about. For example: - I recommend strongly to not talk about sub-registrars - I recommend as strongly to not talk about registrant/registry = relationship - The protocol to use to communicate with registrar is normally private = API, not epp - It varies what and how the registrars are to send data to the = registry, even if epp is in use, so just skip trying to describe it as = registries have too much difference in policy and ideas on how that is = to be done Etc... Patrik From paul.hoffman@vpnc.org Mon Jul 16 07:09:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53BD21F8851 for ; Mon, 16 Jul 2012 07:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGYjJfF1V3x0 for ; Mon, 16 Jul 2012 07:09:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 025B021F883E for ; Mon, 16 Jul 2012 07:09:26 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GDO01S006213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 06:24:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> Date: Mon, 16 Jul 2012 07:10:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1278) Cc: Peter Koch , dnsop@ietf.org Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:09:27 -0000 On Jul 16, 2012, at 12:40 AM, Patrik F=E4ltstr=F6m wrote: > On 13 jul 2012, at 13:57, Peter Koch wrote: >=20 >> while this discussion is refreshing, the reason Paul (was) = volunteered >> to write this document was less the (re-)definition of the lame = delegation >> terminology but more to address (potential) requirements for an = in-band >> child parent key exchange. Let's leave the bikeshed black for the = moment >> and focus on the design of the bikes instead. >=20 > Because I find the registrar/registry description be non-complete, and = in some cases wrong, let me suggest that portion of the draft is just = removed, and instead that the draft actually talk about what it is = supposed to talk about. >=20 > For example: >=20 > - I recommend strongly to not talk about sub-registrars > - I recommend as strongly to not talk about registrant/registry = relationship > - The protocol to use to communicate with registrar is normally = private API, not epp > - It varies what and how the registrars are to send data to the = registry, even if epp is in use, so just skip trying to describe it as = registries have too much difference in policy and ideas on how that is = to be done >=20 > Etc... Patrik's partial list of problems with the document can be summarized = as: What is the intention of this document: is it describing current = operations, or operations that we want to see? If it is the former then, yes, there is a lot of completely incorrect = statements. If it is the latter, it will be interesting to imagine how = we can get consensus because current operators won't want to change to = this new design or to run two or more different operations in parallel. --Paul Hoffman= From paul@cypherpunks.ca Mon Jul 16 07:25:04 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011B521F8766 for ; Mon, 16 Jul 2012 07:25:04 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwxL1puMRJ7C for ; Mon, 16 Jul 2012 07:25:03 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id EF7A221F8720 for ; Mon, 16 Jul 2012 07:25:02 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 23C28868ED; Mon, 16 Jul 2012 10:25:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1824385DD9; Mon, 16 Jul 2012 10:25:45 -0400 (EDT) Date: Mon, 16 Jul 2012 10:25:45 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> Message-ID: References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Cc: dnsop Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:25:04 -0000 On Mon, 16 Jul 2012, Paul Hoffman wrote: > Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 > > On Jul 16, 2012, at 12:40 AM, Patrik Fältström wrote: > >> On 13 jul 2012, at 13:57, Peter Koch wrote: >> >>> while this discussion is refreshing, the reason Paul (was) volunteered >>> to write this document was less the (re-)definition of the lame delegation >>> terminology but more to address (potential) requirements for an in-band >>> child parent key exchange. Let's leave the bikeshed black for the moment >>> and focus on the design of the bikes instead. >> >> Because I find the registrar/registry description be non-complete, and in some cases wrong, let me suggest that portion of the draft is just removed, and instead that the draft actually talk about what it is supposed to talk about. The goal was to describe use cases, not requirements. We can change that if we want, but then we will have the use-cases discussion anyway on the list. If the WG wants that, it's fine with me. >> For example: >> >> - I recommend strongly to not talk about sub-registrars It's a very important use case unfortunately, with the second largest reseller not supporting DNSSEC, while powering dozens of smaller sub-registrars. >> - I recommend as strongly to not talk about registrant/registry relationship How else would you describe the relationships where parent and child do not communicate with each other directly, but use a third party? >> - The protocol to use to communicate with registrar is normally private API, not epp Unless in the case of the sub-registrar. >> - It varies what and how the registrars are to send data to the registry, even if epp is in use, so just skip trying to describe it as registries have too much difference in policy and ideas on how that is to be done >> >> Etc... Can these be folded into use cases? > Patrik's partial list of problems with the document can be summarized as: > > What is the intention of this document: is it describing current operations, or operations that we want to see? It is trying to describe the use-cases that any solution that tries to automate parent-child related records with DNSSEC-based authentication should attempt to support. > If it is the former then, yes, there is a lot of completely incorrect statements. If it is the latter, it will be interesting to imagine how we can get consensus because current operators won't want to change to this new design or to run two or more different operations in parallel. I think this statement confuses "operator" with "registrar". There are many other use cases too. It would be unfortunate if we leave the entire RRR ecosystem out of any possible solution, because part of the motivation for this document is to speed up adoption of DNSSEC in the many different RRR eco-systems. Paul From peter@denic.de Mon Jul 16 07:28:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA4C21F880F for ; Mon, 16 Jul 2012 07:28:29 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bx5sdMzoGkU for ; Mon, 16 Jul 2012 07:28:29 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 275B821F880C for ; Mon, 16 Jul 2012 07:28:28 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1SqmIR-0004RC-Dt; Mon, 16 Jul 2012 16:29:11 +0200 Received: from localhost by x27.adm.denic.de with local id 1SqmIR-0006io-8D; Mon, 16 Jul 2012 16:29:11 +0200 Date: Mon, 16 Jul 2012 16:29:11 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20120716142911.GW24669@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] Draft DNSOP WG Agenda for IETF 84 Vancouver X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:28:29 -0000 Dear WG, the draft agenda for Vancouver has been posted to the meetings/preceedings page and is attached below for convenience and archival purposes. -Peter & Stephen ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 84, Vancouver Location: Hyatt Regency Vancouver, Georgia B Date: Thursday, 02 August 2012 Time: 17:30 - 18:30 (UTC-7) // atoca, avtext, behave, bmwg, iri, lwig, trill Chairs: Peter Koch Stephen Morris > Jabber: xmpp:dnsop@jabber.ietf.org WG URL: http://tools.ietf.org/wg/dnsop/ WG URL: https://datatracker.ietf.org/wg/dnsop/ Agenda: http://tools.ietf.org/agenda/84/#dnsop Agenda: https://datatracker.ietf.org/meeting/84/agenda.html#dnsop Agenda: http://www.ietf.org/proceedings/84/agenda/agenda-84-dnsop Material: https://datatracker.ietf.org/meeting/84/materials.html#wg-dnsop Version: $Revision: 1.1 $ ----------------------------------------------------------------------------- 1) Administrivia [chairs][5 min][17:30] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][5 min][17:35] {drafts not mentioned down below} 3) Active Drafts [chairs][5 min][17:40] 3.1) [2 min] (to be) in IETF Last Call resolution of LC comments, if any 3.2) [3 min] in IETF Last Call resolution of LC comments, if any 4) Other (non WG) Internet-Drafts [chairs][35 min][17:45] 4.1) Consolidating AS112 [15 min] Omniscient AS112 Servers 4.2) Child-Parent DNSSEC Key Exchange [15 min] Secure parent-child DNS update use cases 4.3) Next steps in Key Timing [5 min] DNSSEC Key Timing Considerations 5) I/O with other WGs [chairs][5 min][18:20] TBD 6) A.O.B. [N.N.][0 min][18:25] {please identify additional issues in advance} ----------------------------------------------------------------------------- From paul.hoffman@vpnc.org Mon Jul 16 07:52:52 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE3521F86CE for ; Mon, 16 Jul 2012 07:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdanBo8BPog5 for ; Mon, 16 Jul 2012 07:52:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 979CC21F86B1 for ; Mon, 16 Jul 2012 07:52:51 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GE7STw011258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 07:07:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Mon, 16 Jul 2012 07:53:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <712E5521-427B-4B4C-A16C-401097339822@vpnc.org> References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1278) Cc: dnsop Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:52:52 -0000 On Jul 16, 2012, at 7:25 AM, Paul Wouters wrote: > On Mon, 16 Jul 2012, Paul Hoffman wrote: >=20 >> Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 >> On Jul 16, 2012, at 12:40 AM, Patrik F=E4ltstr=F6m wrote: >>=20 >>> On 13 jul 2012, at 13:57, Peter Koch wrote: >>>=20 >>>> while this discussion is refreshing, the reason Paul (was) = volunteered >>>> to write this document was less the (re-)definition of the lame = delegation >>>> terminology but more to address (potential) requirements for an = in-band >>>> child parent key exchange. Let's leave the bikeshed black for the = moment >>>> and focus on the design of the bikes instead. >>>=20 >>> Because I find the registrar/registry description be non-complete, = and in some cases wrong, let me suggest that portion of the draft is = just removed, and instead that the draft actually talk about what it is = supposed to talk about. >=20 > The goal was to describe use cases, not requirements. We can change = that > if we want, but then we will have the use-cases discussion anyway on = the > list. If the WG wants that, it's fine with me. The use cases in section 3 are fine because they are use cases for = standardized things. Patrik's objections were (all?) about the "use = cases" in section 4, which in fact are business models, some of which = exist today and others which do not. I disagree that this WG needs to have a discussion of the latter as long = your use case document describes the three parties: "zone operator", = "registry", and "organization that might have a business relationship = between those two". Any discussion about the business model of the third = party and the first or second doesn't feel like a use case to me at all. --Paul Hoffman= From joe.abley@icann.org Mon Jul 16 08:47:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2861011E80CC for ; Mon, 16 Jul 2012 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmbrUfPeAOw0 for ; Mon, 16 Jul 2012 08:47:50 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0E20E11E80C7 for ; Mon, 16 Jul 2012 08:47:50 -0700 (PDT) Received: from [199.212.90.56] (199.212.90.56) by smtpx.exc.icann.org (64.78.22.243) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 16 Jul 2012 08:48:34 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_44EC171C-1196-4024-A50A-4EFF890ABD82"; protocol="application/pkcs7-signature"; micalg=sha1 From: Joe Abley In-Reply-To: <712E5521-427B-4B4C-A16C-401097339822@vpnc.org> Date: Mon, 16 Jul 2012 11:48:31 -0400 Message-ID: References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <712E5521-427B-4B4C-A16C-401097339822@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1278) Cc: dnsop , Paul Wouters Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:47:51 -0000 --Apple-Mail=_44EC171C-1196-4024-A50A-4EFF890ABD82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2012-07-16, at 10:53, Paul Hoffman wrote: > The use cases in section 3 are fine because they are use cases for = standardized things. Patrik's objections were (all?) about the "use = cases" in section 4, which in fact are business models, some of which = exist today and others which do not. >=20 > I disagree that this WG needs to have a discussion of the latter as = long your use case document describes the three parties: "zone = operator", "registry", and "organization that might have a business = relationship between those two". Any discussion about the business model = of the third party and the first or second doesn't feel like a use case = to me at all. I agree. There are technical/protocol aspects involved in this idea which need to = be documented and standardised. There are also changes required to the = business ecosystem of the various types of actor involved in the = maintenance of records in DNS registries. This working group's role is surely to concentrate on the former. There = are other bodies whose mandate might allow them to address the latter. Joe= --Apple-Mail=_44EC171C-1196-4024-A50A-4EFF890ABD82 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNzE2MTU0ODMxWjAjBgkqhkiG9w0BCQQxFgQUcyKFeD/oV6aCudsNQXJztD9p9tMwgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB AGuotQFmfjC0XJBGEXSWK5RLZ1jE9e8s4Ekq9Zj75gnb3cuX1W+fClV11kedcJB7nnhmYh/JDrf7 9oD6ki8/nOocXM4MteY0GBcwB6RMh7cjrwJwdPcZr/x36ig9TRgHZ3fud6smCT1pFAIvrKA3/h2l gwHTc0HZKjdICeTA/O048h2quaSU5dsp0fRep2YiE0dYRcw820RobzKtKYdXVz9hFkLzCD1h5KhC nR5fBO4aFfpAb9vim/TFwO0dhPx06P2/pyNijnLO0ED3a+BC7FPxxkSGUDQQ+ePCTkp6x0YE0IaH jsH5egp89QkhjF9RWVTnZZfOs9cZCywoiT1jSbsAAAAAAAA= --Apple-Mail=_44EC171C-1196-4024-A50A-4EFF890ABD82-- From simon.perreault@viagenie.ca Mon Jul 16 08:50:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDA121F8713 for ; Mon, 16 Jul 2012 08:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jey9Tl1MVLhT for ; Mon, 16 Jul 2012 08:50:28 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E0F0A21F870E for ; Mon, 16 Jul 2012 08:50:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9D744415D1 for ; Mon, 16 Jul 2012 11:51:12 -0400 (EDT) Message-ID: <50043870.4000405@viagenie.ca> Date: Mon, 16 Jul 2012 11:51:12 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120716154655.20530.97681.idtracker@ietfa.amsl.com> In-Reply-To: <20120716154655.20530.97681.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120716154655.20530.97681.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [DNSOP] Fwd: New Version Notification for draft-perreault-dnsop-stats-mib-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:50:29 -0000 Dnsopers, As suggested by a few people, we added a section to our draft evaluating how we stand against RFC 3197. For your convenience, here it is verbatim. We would of course appreciate further feedback. Thanks, Simon 1.2. On RFC 3197 A previous attempt at defining a MIB for DNS servers failed. [RFC3197] analyses the causes of that failure and identifies a few lessons to be learned. This section compares those lessons against the proposal contained in this draft. o Define a clear set of goals before writing any MIB extensions. Know who the constituency is and make sure that what you write solves their problem. * There is a single goal: expose usage statistics (i.e., counters) over SNMP. * Constituency: The problem has been identified by TLD operators trying to obtain usage statistics from anycast nodes. One TLD operator having this problem is co-authoring this draft. o Keep the MIB extensions short, and don't add variables just because somebody in the WG thinks they'd be a cool thing to measure. * The proposed MIB is short (subjectively). * The stats exposed by the MIB are those already available in a popular DNS server used by many TLDs. o If some portion of the task seems to be very hard to do within the SMI, that's a strong hint that SNMP is not the right tool for whatever it is that you're trying to do. * Writing this MIB was easy and straightforward. o If the entire project is taking too long, perhaps that's a hint too. * From a technical point of view, this could be wrapped up quickly. -------- Original Message -------- Subject: New Version Notification for draft-perreault-dnsop-stats-mib-01.txt Date: Mon, 16 Jul 2012 08:46:55 -0700 From: internet-drafts@ietf.org To: simon.perreault@viagenie.ca CC: jake.zack@cira.ca, jacques.latour@cira.ca A new version of I-D, draft-perreault-dnsop-stats-mib-01.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Filename: draft-perreault-dnsop-stats-mib Revision: 01 Title: DNS Server Statistics Management Information Base (MIB) Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-perreault-dnsop-stats-mib-01.txt Status: http://datatracker.ietf.org/doc/draft-perreault-dnsop-stats-mib Htmlized: http://tools.ietf.org/html/draft-perreault-dnsop-stats-mib-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-perreault-dnsop-stats-mib-01 Abstract: This memo defines a portion of the Management Information Base (MIB) for monitoring statistics of DNS servers. The IETF Secretariat From paf@frobbit.se Mon Jul 16 12:49:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8A11E808A for ; Mon, 16 Jul 2012 12:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ6gHuzXY31F for ; Mon, 16 Jul 2012 12:49:25 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 46FDF11E8142 for ; Mon, 16 Jul 2012 12:49:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 572441434491C; Mon, 16 Jul 2012 21:50:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdNzpAJljEH4; Mon, 16 Jul 2012 21:50:09 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 062CE14344915; Mon, 16 Jul 2012 21:50:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 16 Jul 2012 21:50:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1278) Cc: dnsop , Paul Hoffman Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:49:27 -0000 On 16 jul 2012, at 16:25, Paul Wouters wrote: > On Mon, 16 Jul 2012, Paul Hoffman wrote: >=20 >> Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 >> On Jul 16, 2012, at 12:40 AM, Patrik F=E4ltstr=F6m wrote: >>=20 >>> On 13 jul 2012, at 13:57, Peter Koch wrote: >>>=20 >>>> while this discussion is refreshing, the reason Paul (was) = volunteered >>>> to write this document was less the (re-)definition of the lame = delegation >>>> terminology but more to address (potential) requirements for an = in-band >>>> child parent key exchange. Let's leave the bikeshed black for the = moment >>>> and focus on the design of the bikes instead. >>>=20 >>> Because I find the registrar/registry description be non-complete, = and in some cases wrong, let me suggest that portion of the draft is = just removed, and instead that the draft actually talk about what it is = supposed to talk about. >=20 > The goal was to describe use cases, not requirements. We can change = that > if we want, but then we will have the use-cases discussion anyway on = the > list. If the WG wants that, it's fine with me. >=20 >>> For example: >>>=20 >>> - I recommend strongly to not talk about sub-registrars >=20 > It's a very important use case unfortunately, with the second largest > reseller not supporting DNSSEC, while powering dozens of smaller > sub-registrars. The problem is that there are large disagreements in the TLD business = whether something like subregistrar really should be (let me use = computer terminology here) a first order object or not. Specifically = because there are disagreements whether special restrictions should be = put on resellers, or if "only" the requirements on registrars should be = automatically transferred to the reseller. Plus of course whether = resellers are allowed at all -- and that dives into the issues where = there are discussions on how you define whether two organisations have = "too close relationship", i.e. "are the same organisation". And people = against the term reseller very strongly is against it because any such = text might risk removing responsibilities on the registrar, and because = of that the ability for registries to blame resellers (because resellers = live under not only agreement with the registrar, but also separate = agreement with the registry or some accreditation agency). Etc. This is a can of worms. >>> - I recommend as strongly to not talk about registrant/registry = relationship >=20 > How else would you describe the relationships where parent and child = do > not communicate with each other directly, but use a third party? If you do, then you must describe the relationship given the different = kind of agreements that exists. In most cases there are agreements = between the registry and the registrant that the registrant must live up = to. But how that is implemented, when the registrant is agreeing to the = rules, and how the registry is to ensure the registrant is living up to = the rules is very very different between different registries. In some = cases the rules are technical, in others not. In some you also have a = relationship between the DNS hosting provider and the registry. >>> - The protocol to use to communicate with registrar is normally = private API, not epp >=20 > Unless in the case of the sub-registrar. My experience is that majority of communication with the registrar is = not epp. Regardless of whether we talk about registrants, sub-registrars = or dns hosting providers that communicate with the registrar. >>> - It varies what and how the registrars are to send data to the = registry, even if epp is in use, so just skip trying to describe it as = registries have too much difference in policy and ideas on how that is = to be done >>>=20 >>> Etc... >=20 > Can these be folded into use cases? If you write lots of lots of text that describe the different cases. :-P And remember that registries do change their policies and rules every = third to fourth year, that changes things. >> Patrik's partial list of problems with the document can be summarized = as: >>=20 >> What is the intention of this document: is it describing current = operations, or operations that we want to see? >=20 > It is trying to describe the use-cases that any solution that tries to > automate parent-child related records with DNSSEC-based authentication > should attempt to support. I still think you should just concentrate on discussing what you = actually want to do. If we concentrate on that part I am happy to help = commenting on how those ideas fit (or not) into the world I see (as a = registrar mainly in the ccTLD world). For example, do you think DS is to be passed to the registry or DNSKEY? Even *that* discussion have stalled in the epp discussions because = registries want to (for possibly correct reasons) have a freedom to = build their own business models.=20 But if you manage to write only that "simple" thing in a document that = we can give registries and registrars, getting that implemented will not = be easy. >> If it is the former then, yes, there is a lot of completely incorrect = statements. If it is the latter, it will be interesting to imagine how = we can get consensus because current operators won't want to change to = this new design or to run two or more different operations in parallel. >=20 > I think this statement confuses "operator" with "registrar". There are > many other use cases too. It would be unfortunate if we leave the = entire > RRR ecosystem out of any possible solution, because part of the > motivation for this document is to speed up adoption of DNSSEC in the > many different RRR eco-systems. Patrik From paul@cypherpunks.ca Mon Jul 16 13:07:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E111E8298 for ; Mon, 16 Jul 2012 13:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mJL0W5R3YrR for ; Mon, 16 Jul 2012 13:07:08 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id EFADD11E8279 for ; Mon, 16 Jul 2012 13:07:07 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3298084DD9; Mon, 16 Jul 2012 16:07:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 24E2D84D81; Mon, 16 Jul 2012 16:07:52 -0400 (EDT) Date: Mon, 16 Jul 2012 16:07:52 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> Message-ID: References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: dnsop , Paul Hoffman Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:07:08 -0000 On Mon, 16 Jul 2012, Patrik Fältström wrote: > This is a can of worms. I understand, though this document is trying to be a technical one, not a legal one. If the examples in the RRR model can be made more generic or "fixed", I think that would help us determine what has a use and what has no use, getting implemented. > My experience is that majority of communication with the registrar is not epp. Regardless of whether we talk about registrants, sub-registrars or dns hosting providers that communicate with the registrar. One of the possible outcomes of this document would be a way where the DNS hoster and the registry can talk via a DNSSEC-authenticated method. I imagine that could be useful to registrants, DNS hosters, registrars and registries. But also within the non-RRR model of parent-child relationship. The private/different API/EPP implementations is not helping making DNSSEC deployment easy. That's what we're trying to address. > And remember that registries do change their policies and rules every third to fourth year, that changes things. If we have technology in place that can accomodate most, then over time, hopefully that will change. Just like going from a non-EPP to an EPP solution has slowly but surely gained more traction, and eased deployment for registrars. > I still think you should just concentrate on discussing what you actually want to do. If we concentrate on that part I am happy to help commenting on how those ideas fit (or not) into the world I see (as a registrar mainly in the ccTLD world). > > For example, do you think DS is to be passed to the registry or DNSKEY? That is something that would come up when discussing the use cases document. If we know all the answers to these questions, we would not need a use cases document. What I think (though the idea is that this becomes a WG document and I'm just the editor) is that a likely solution would be for the child to store something in its zone, that the parent can read and validate. It seems reasonable to suggest people would want to be able to pre-publish DS records without yet revealing the public DNSKEY, so in my personal (no hats) opininion, I would say that the DS option should be there. I also think the DNSKEY option should be there to accomodate those parents that have to generate the DS themselves for whatever (technical or not) reason. Paul From paul.hoffman@vpnc.org Mon Jul 16 13:18:59 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB27821F85DD for ; Mon, 16 Jul 2012 13:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOMYi2iKCzGq for ; Mon, 16 Jul 2012 13:18:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2021F85D1 for ; Mon, 16 Jul 2012 13:18:59 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GJXaNY064777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 12:33:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Mon, 16 Jul 2012 13:19:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> To: Paul Wouters X-Mailer: Apple Mail (2.1278) Cc: dnsop WG Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:19:00 -0000 On Jul 16, 2012, at 1:07 PM, Paul Wouters wrote: > On Mon, 16 Jul 2012, Patrik F=E4ltstr=F6m wrote: >=20 >> This is a can of worms. >=20 > I understand, though this document is trying to be a technical one, = not > a legal one. It would be better if it was really a "use cases" one. > If the examples in the RRR model can be made more generic > or "fixed", I think that would help us determine what has a use and = what > has no use, getting implemented. Fully disagree. Trying to say which of the use cases for the R between = the zone operator and the registry "has use" and "has no use" belongs in = ICANN, not the IETF. It is not an operations issue. >> My experience is that majority of communication with the registrar is = not epp. Regardless of whether we talk about registrants, sub-registrars = or dns hosting providers that communicate with the registrar. >=20 > One of the possible outcomes of this document would be a way where the > DNS hoster and the registry can talk via a DNSSEC-authenticated = method. Err, how could that be the outcome of a use cases document? Or are you = envisioning this as also being a protocol document? (FWIW, I would love = to have such a protocol, but I think it's a bad idea to do it as a "use = case".) > I imagine that could be useful to registrants, DNS hosters, registrars > and registries. But also within the non-RRR model of parent-child > relationship. The private/different API/EPP implementations is not > helping making DNSSEC deployment easy. That's what we're trying to > address. So this is now a list of current practices that are not working? >> And remember that registries do change their policies and rules every = third to fourth year, that changes things. >=20 > If we have technology in place that can accomodate most, then over = time, > hopefully that will change. Just like going from a non-EPP to an EPP > solution has slowly but surely gained more traction, and eased > deployment for registrars. That's a business argument. >> I still think you should just concentrate on discussing what you = actually want to do. If we concentrate on that part I am happy to help = commenting on how those ideas fit (or not) into the world I see (as a = registrar mainly in the ccTLD world). >>=20 >> For example, do you think DS is to be passed to the registry or = DNSKEY? >=20 > That is something that would come up when discussing the use cases > document. If we know all the answers to these questions, we would not > need a use cases document. >=20 > What I think (though the idea is that this becomes a WG document and = I'm > just the editor) is that a likely solution would be for the child to > store something in its zone, that the parent can read and validate. It > seems reasonable to suggest people would want to be able to = pre-publish > DS records without yet revealing the public DNSKEY, so in my personal > (no hats) opininion, I would say that the DS option should be there. I > also think the DNSKEY option should be there to accomodate those = parents > that have to generate the DS themselves for whatever (technical or = not) > reason. That all seems fine. What does it have to do with describing the = practices today? --Paul Hoffman From paf@frobbit.se Mon Jul 16 13:30:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E0611E813F for ; Mon, 16 Jul 2012 13:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uALNUA2bkigI for ; Mon, 16 Jul 2012 13:30:07 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 4755711E8085 for ; Mon, 16 Jul 2012 13:30:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 2E34D14345386; Mon, 16 Jul 2012 22:30:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bGmsMYtmJOl; Mon, 16 Jul 2012 22:30:51 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id D54331434537F; Mon, 16 Jul 2012 22:30:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 16 Jul 2012 22:30:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07FA7DC5-0BE2-44F7-A51B-42B9B9FD74ED@frobbit.se> References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> To: Paul Wouters X-Mailer: Apple Mail (2.1278) Cc: dnsop , Paul Hoffman Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:30:11 -0000 On 16 jul 2012, at 22:07, Paul Wouters wrote: > On Mon, 16 Jul 2012, Patrik F=E4ltstr=F6m wrote: >=20 >> This is a can of worms. >=20 > I understand, though this document is trying to be a technical one, = not > a legal one. If the examples in the RRR model can be made more generic > or "fixed", I think that would help us determine what has a use and = what > has no use, getting implemented. Fair. A good goal. I hope you can manage to describe something. Because = I agree it would be useful. I am just myself a bit tired over all the = different "technical" explanations I have heard from registries and = registrars lately... :-P >> My experience is that majority of communication with the registrar is = not epp. Regardless of whether we talk about registrants, sub-registrars = or dns hosting providers that communicate with the registrar. >=20 > One of the possible outcomes of this document would be a way where the > DNS hoster and the registry can talk via a DNSSEC-authenticated = method. Please stay away from that discussion (i.e. whether the registry should = have direct communication with the dns provider). That is *directly* = impacting the business models of among other things registrars. And the = discussion will be everything BUT technical. So, if you want a technical discussion, have one. But, as you say yourself, you MUST stay away from business models and = legal stuff. > I imagine that could be useful to registrants, DNS hosters, registrars > and registries. Depends on what "that" is of course :-) > But also within the non-RRR model of parent-child > relationship. The private/different API/EPP implementations is not > helping making DNSSEC deployment easy. The private API is absolutely helping as epp is not suitable for the = transactions you want. How many epp implementations have you written, or rather, how many state = machines for epp have you worked on for what number of TLDs that = implement what you want to do? The transactions are dead simple if you have for example a JSON based = "thing", but a pain in the back if you try to do it in epp. Specifically = in cases where one or more of the registrant, dns hosting provider and = registrar changes while you still want to have the domain operational. > That's what we're trying to address. Understood. >> And remember that registries do change their policies and rules every = third to fourth year, that changes things. >=20 > If we have technology in place that can accomodate most, then over = time, > hopefully that will change. Just like going from a non-EPP to an EPP > solution has slowly but surely gained more traction, and eased > deployment for registrars. Well, one can question how easy it has become. Yes, it is easier for registrars to either be bound to one non-gTLD or = as an accredited ICANN registrar address most gTLD registries. But to = support more than one of these (more than one non-gTLD or a non-gTLD and = gTLDs), it is a royal pain. We can discuss over a beer whether it is = easier than what it would have been without epp. And, note, I *was* the responsible Area Director when epp was created! So I am blaming no one else than myself for rather wanting a solution = people could agree on than something that lead to interoperability. = Today, I claim people over-use the 'e' in epp. ANYTHING that can reverse that I am thankful to. And that is why I say "please just start agreeing on whether you want DS = or DNSKEY" passed to the registrar. That would clean up so many things = that you can not imagine. >> I still think you should just concentrate on discussing what you = actually want to do. If we concentrate on that part I am happy to help = commenting on how those ideas fit (or not) into the world I see (as a = registrar mainly in the ccTLD world). >>=20 >> For example, do you think DS is to be passed to the registry or = DNSKEY? >=20 > That is something that would come up when discussing the use cases > document. If we know all the answers to these questions, we would not > need a use cases document. Well, I think the problem is that people know the *possible* answers, = but they can not agree on what to pick. > What I think (though the idea is that this becomes a WG document and = I'm > just the editor) is that a likely solution would be for the child to > store something in its zone, that the parent can read and validate. This might very well create a race condition between the DNS = provisioning path and the epp path. But this is exactly what we could have a look at. And "ignore" (note the = quotes) the background information where I think most issues are tied to = the business models. > It > seems reasonable to suggest people would want to be able to = pre-publish > DS records without yet revealing the public DNSKEY, so in my personal > (no hats) opininion, I would say that the DS option should be there. I > also think the DNSKEY option should be there to accomodate those = parents > that have to generate the DS themselves for whatever (technical or = not) > reason. Personally, I think many issues I bring up is because different = registries have a mix of: - Extremely restrictive implementations of DNSSEC in their epp - Extreme interest in policing what is done in child zones If registries just had (as I see between the lines you suggest) a = combination, or multitude, of approaches, then a few different things = would be resolved: 1. There would be easier for registrars to find _one_ mechanism or = algorithm or state machine that works on more than one TLD 2. There would be easier to implement a multitude of use cases with the = same registry Patrik From paul@cypherpunks.ca Mon Jul 16 13:36:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69C11E8269 for ; Mon, 16 Jul 2012 13:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzN1-e6HTyYy for ; Mon, 16 Jul 2012 13:36:17 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A98E411E8262 for ; Mon, 16 Jul 2012 13:36:17 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4B97684DD9; Mon, 16 Jul 2012 16:37:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3231084D81; Mon, 16 Jul 2012 16:37:00 -0400 (EDT) Date: Mon, 16 Jul 2012 16:37:00 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: Message-ID: References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop WG Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:36:18 -0000 On Mon, 16 Jul 2012, Paul Hoffman wrote: >> I understand, though this document is trying to be a technical one, not >> a legal one. > > It would be better if it was really a "use cases" one. What I meant was, we are looking at use cases without looking at legal limitations. If some use cases will not be legally suitable for some TLD or non-TLD cases, that is not a reason to remove the use case from this document. >> If the examples in the RRR model can be made more generic >> or "fixed", I think that would help us determine what has a use and what >> has no use, getting implemented. > > Fully disagree. Trying to say which of the use cases for the R between the zone operator and the registry "has use" and "has no use" belongs in ICANN, not the IETF. It is not an operations issue. See above. I meant with "has use" in that someone can see deploying a use case on its technical merits. >> One of the possible outcomes of this document would be a way where the >> DNS hoster and the registry can talk via a DNSSEC-authenticated method. > > Err, how could that be the outcome of a use cases document? Or are you envisioning this as also being a protocol document? (FWIW, I would love to have such a protocol, but I think it's a bad idea to do it as a "use case".) Eventually. Not through this use-cases documen, but a protocol document that is written taking the use cases of this document into consideration. >> I imagine that could be useful to registrants, DNS hosters, registrars >> and registries. But also within the non-RRR model of parent-child >> relationship. The private/different API/EPP implementations is not >> helping making DNSSEC deployment easy. That's what we're trying to >> address. > > So this is now a list of current practices that are not working? That's part of it. Another part is new shiny awesome things we could never do before :P >>> And remember that registries do change their policies and rules every third to fourth year, that changes things. >> >> If we have technology in place that can accomodate most, then over time, >> hopefully that will change. Just like going from a non-EPP to an EPP >> solution has slowly but surely gained more traction, and eased >> deployment for registrars. > > That's a business argument. internet is business, yes? > That all seems fine. What does it have to do with describing the practices today? I attempted to describe how we could better facilicate automation using DNSSEC - clearly that involves showing where the lack of DNSSEC now is hampering automation currently. Paul From paf@frobbit.se Mon Jul 16 13:36:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E981C11E8262 for ; Mon, 16 Jul 2012 13:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNyjYlfBcccg for ; Mon, 16 Jul 2012 13:36:45 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3575411E8160 for ; Mon, 16 Jul 2012 13:36:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 5D2D514345508; Mon, 16 Jul 2012 22:37:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fusa73MRUmJL; Mon, 16 Jul 2012 22:37:30 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 261C114345501; Mon, 16 Jul 2012 22:37:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 16 Jul 2012 22:37:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FB9E36D-4368-4472-B3A0-4BD17B084F09@frobbit.se> References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> To: Paul Wouters X-Mailer: Apple Mail (2.1278) Cc: dnsop , Paul Hoffman Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:36:46 -0000 Suggestion: JUST talk about things like: 1. we have registry, registrar, registrant and DNS operator" 2. any of those might give the right to a third party to act on their = behalf 3. we only know there are direct connections and knowledge between = registry-registrar, registrar-registrant and registrant-dns operator What we MUST have is: - Enough data in the registry so that DS can be created that refer to = key material used to sign the zone published by the dns operator Today we know that we have cases like: A. The DS is passed to the registry B. The DNSKEY is passed to the registry that create the DS C. The DNSKEY is fetched from the zone of the DNS operator and the DS is = created We have the following plus and minuses: bla bla bla Patrik From internet-drafts@ietf.org Mon Jul 16 15:48:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1684611E80EB; Mon, 16 Jul 2012 15:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zVgtwdZUHrZ; Mon, 16 Jul 2012 15:48:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A7B11E8085; Mon, 16 Jul 2012 15:48:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716224829.12138.45087.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:48:29 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-12.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:48:30 -0000 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 Working Gro= up of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking SIDN Labs Filename : draft-ietf-dnsop-rfc4641bis-12.txt Pages : 81 Date : 2012-07-16 Abstract: This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-12 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-rfc4641bis-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From matthijs@nlnetlabs.nl Tue Jul 17 06:56:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BF921F86BB for ; Tue, 17 Jul 2012 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUZyj5y74qfE for ; Tue, 17 Jul 2012 06:56:46 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C20CC21F86B6 for ; Tue, 17 Jul 2012 06:56:45 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q6HDvTnl076516 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 15:57:30 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1342533451; bh=m9O2EJnQaZOjFwwgiOhMn3IlzUhXCNiPwDpt6Ypjuk8=; h=Date:From:To:Subject:References:In-Reply-To; b=X1rjLHV0DOmV0fOJt6qNAA5Nd2OD4NqtCwVZ7UCGyNCXf+EsT2MegWtR5ZewgGPjb y0c7A+ug8NS+fCazZ/bCUofVBEyyZShg7qflVdu+ttzySqzDlT3j06Pyu8mZN2aruB nDQcCSqtQ92xjBbCgkh2xemI6D+Oyoc6aVV0rGJs= Message-ID: <50056F4A.8040801@nlnetlabs.nl> Date: Tue, 17 Jul 2012 15:57:30 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120716224829.12138.45087.idtracker@ietfa.amsl.com> In-Reply-To: <20120716224829.12138.45087.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 17 Jul 2012 15:57:30 +0200 (CEST) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-12.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 13:56:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Apparently, there went something wrong with the authors. That's what you get when you submit it just before the cut off date. The authors section should be: Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking R. (Miek) Gieben Best regards, Matthijs On 07/17/2012 12:48 AM, 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 Working Group of the IETF. > > Title : DNSSEC Operational Practices, Version 2 Author(s) > : Olaf M. Kolkman W. (Matthijs) Mekking SIDN Labs Filename : > draft-ietf-dnsop-rfc4641bis-12.txt Pages : 81 Date > : 2012-07-16 > > Abstract: This document describes a set of practices for operating > the DNS with security extensions (DNSSEC). The target audience is > zone administrators deploying DNSSEC. > > The document discusses operational aspects of using keys and > signatures in the DNS. It discusses issues of key generation, key > storage, signature generation, key rollover, and related policies. > > This document obsoletes RFC 4641 as it covers more operational > ground and gives more up-to-date requirements with respect to key > sizes and the DNSSEC operations. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-12 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc4641bis-12 > > > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQBW9KAAoJEA8yVCPsQCW57tEH/RAydahPYEhtQs3MJdkzYeBO 9W+uDsL+f2NVj24SmMhCWsfv9XPv0LBlI/IrWknizXZ+WTHW/lMduxAPTZ0yHH7b 2U1BI/NbvQowwvPZxCTc4Y9a8U4QPSBqzL4WqGJpNff5xy4jbVYxd9EwwLC4tOQn kBH6bVfndh5AQjYEeom+GlDqPtH3OTFUrhngphhU7Mrncuj5csWCRATpKvpmCyw8 1+KICHB7q2rWdx2xN2bRsBOxgBTvIE5gGTQM3AZZUcyXHWKf5DkDARxQlOYpU3u9 HgKpzHJAnL4SpAubrkLoDOt1V2SRnOmcaIGHxGxj/bBEl6BJ0+zv0jO0VFgH4GU= =7RgS -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Thu Jul 19 00:03:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133AB21F8525 for ; Thu, 19 Jul 2012 00:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXxXpHCMIK9v for ; Thu, 19 Jul 2012 00:03:35 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8321F8604 for ; Thu, 19 Jul 2012 00:03:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host86-129-90-194.range86-129.btcentralplus.com ([86.129.90.194]:51420 helo=[192.168.1.66]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1Srkmg-00078P-Xq (Exim 4.72) for dnsop@ietf.org (return-path ); Thu, 19 Jul 2012 08:04:26 +0100 From: Tony Finch Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) Message-Id: <9EA59767-3C83-482C-A450-1294D5C064A0@dotat.at> Date: Thu, 19 Jul 2012 08:04:24 +0100 To: "dnsop@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Sender: Tony Finch Subject: [DNSOP] The RRR discussion is unnecessary - draft-wouters-dnsop-secure-update-use-cases X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 07:03:37 -0000 As far as I can tell the structure of the parent zone is irrelevant to this p= roblem. There are basically two parties that we care about: the child zone, a= nd some entity that is capable of updating the delegation in the parent. Wha= t that entity is does not matter: registry / registrar / some gateway betwee= n this protocol and some proprietary protocol / whatever. The questions we need to answer are: * How does the child signal what should be in the parent? This can't simply be "just use the apex NS and SEP DNSKEY records" because t= hat doesn't cope with some change-of-hosting-provider or key-rollover scenar= ios. So we need an analysis of the scenarios this has to accommodate. These a= re all about configuration changes at the child: as far as I can tell change= s at the parent (such as change of registrar) are irrelevant. * How does the child signal when a change should happen? Implicitly, by updating some published data? With a time field in the data? B= y some out-of-band do-it-now signal? * Is the protocol stateful or not? For instance, along the lines of RFC 5011. If it is, can the child query the= state? If so, how? * Is it entirely in-band? Should it include any non-DNS signalling mechanisms? A profile of EPP perhap= s? Tony. -- f.anthony.n.finch http://dotat.at/= From sm@resistor.net Thu Jul 19 18:13:04 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F2011E80CE; Thu, 19 Jul 2012 18:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXEIDa4gxVcB; Thu, 19 Jul 2012 18:13:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8611E80A6; Thu, 19 Jul 2012 18:13:01 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6K1Do9i027742; Thu, 19 Jul 2012 18:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342746835; bh=SQvZh6Kiq0SZTCEC7cFS0DiVVmKbqh6MRPhaHo5l2/E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2qtp/W+OGJSkpWvxWOa6qh6APeyFFI3Huv4e0nItciJt/Oj+iZixqbd6cYrMm24q7 w9pba+DvK2Km2ZIvfQbBctG/e8zE02QSsInzthst84qJX+hdHecekvAXgjDYVRmYWh MA+T1VnidJjKzfqyybSlUP8hlPxoyvQEu98efTLA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342746835; i=@resistor.net; bh=SQvZh6Kiq0SZTCEC7cFS0DiVVmKbqh6MRPhaHo5l2/E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MkA/3QzukdKRMGlEwpcr83vH1gXV4T3tNHnvJ+USu55t2AfIAi9DRjcX12FfcCIuz SiV2odvOfpC7TF0h5KCrpXRKj9wznMgYuJ5EUuKncJfpk1No2yOF0x7aZsaDuXh2ly oWRAiVl2pHy2u54nokrLc7yEs6P7UYUjC+HEpVPk= Message-Id: <6.2.5.6.2.20120719171949.0a4d0ad8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Jul 2012 18:10:52 -0700 To: ietf@ietf.org From: SM In-Reply-To: <20120703211559.31773.84433.idtracker@ietfa.amsl.com> References: <20120703211559.31773.84433.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Last Call: (A Framework for DNSSEC Policies and DNSSEC Practice Statements) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 01:13:04 -0000 At 14:15 03-07-2012, The IESG wrote: >The IESG has received a request from the Domain Name System Operations WG >(dnsop) to consider the following document: >- 'A Framework for DNSSEC Policies and DNSSEC Practice Statements' > as Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2012-07-17. Exceptionally, comments may be This comment is after the deadline. The draft is well-written. Thanks to the authors and DNSOP WG Chairs for moving forward. The question which Russ posted, e.g. Specification change procedures ( http://www.ietf.org/mail-archive/web/ietf/current/msg73975.html ) may be related to Section 4.1.4 of the draft. A sentence could be added about specification change procedures. Regards, -sm From peter@denic.de Fri Jul 20 07:22:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C4021F85D3 for ; Fri, 20 Jul 2012 07:22:31 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeBjsU8GOvfY for ; Fri, 20 Jul 2012 07:22:30 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4A21F85EA for ; Fri, 20 Jul 2012 07:22:30 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1SsE73-0003K2-Fg; Fri, 20 Jul 2012 16:23:25 +0200 Received: from localhost by x27.adm.denic.de with local id 1SsE73-0001QE-9Y; Fri, 20 Jul 2012 16:23:25 +0200 Date: Fri, 20 Jul 2012 16:23:25 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20120720142325.GL24669@x28.adm.denic.de> References: <20120716224829.12138.45087.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120716224829.12138.45087.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-12.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 14:22:31 -0000 Dear WG, > Title : DNSSEC Operational Practices, Version 2 > Author(s) : Olaf M. Kolkman > W. (Matthijs) Mekking > SIDN Labs > Filename : draft-ietf-dnsop-rfc4641bis-12.txt this version -12 is the result of a thorough NITS review and some late but helpful comments by Alfred and Marc. Also, per the request of the document editors we appointed Miek Gieben as the third document editor. Even though this happened late in the game, your chairs believe it is in line with IETF custom and reflects Miek's editorship of 4641 as well as his contribution to this -12 version. The next step is the PROTO writeup that accompanies the submission of the draft to the IESG, including a final pass on the draft. In the meantime I'd like to encourage the WG to review the editorial changes introduced in -12: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis We're not looking for additional topics or typos but would appreciate a quick confirmation that the changes between 11 and 12 are OK and, more importantly, did not introduce errors. Regards, Peter From bortzmeyer@nic.fr Mon Jul 23 03:48:59 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C217321F8683 for ; Mon, 23 Jul 2012 03:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.828 X-Spam-Level: X-Spam-Status: No, score=-101.828 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DagofKRQdWuT for ; Mon, 23 Jul 2012 03:48:59 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4F221F86B9 for ; Mon, 23 Jul 2012 03:48:59 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A14B0280153 for ; Mon, 23 Jul 2012 12:48:24 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 9D6CF280137 for ; Mon, 23 Jul 2012 12:48:24 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id 9BA82B3805C for ; Mon, 23 Jul 2012 12:47:54 +0200 (CEST) Date: Mon, 23 Jul 2012 12:47:54 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20120723104754.GA15804@nic.fr> References: <20120716154655.20530.97681.idtracker@ietfa.amsl.com> <50043870.4000405@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50043870.4000405@viagenie.ca> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] New Version Notification for draft-perreault-dnsop-stats-mib-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 10:48:59 -0000 On Mon, Jul 16, 2012 at 11:51:12AM -0400, Simon Perreault wrote a message of 92 lines which said: > As suggested by a few people, we added a section to our draft > evaluating how we stand against RFC 3197. I won't be in Vancouver, sorry, but I've read this draft (background: I work for a TLD operator and we have problems similar to the ones described in the draft). Main comment: I am not convinced by the whole idea of "Discontinuity Time". Isn't the whole idea of SNMP to have dumb agents, often without stable memory, and the manager is supposed to know that, to detect discontinuities and to deal with it? Why is DNS different from typical MIB-II counters, which can go back to zero when the router reboots? Second, the draft requires a mention of RFC 6168, which covers also statistics. Otherwise, the draft seems sensible, addresses a real problem for DNS operators who have subcontractors, and, IMHO, correctly answer the warnings of RFC 3197. From simon.perreault@viagenie.ca Mon Jul 23 06:12:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0275A21F86DC for ; Mon, 23 Jul 2012 06:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5scIfofyFN0 for ; Mon, 23 Jul 2012 06:12:40 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4321F86DB for ; Mon, 23 Jul 2012 06:12:40 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:fdd9:bf18:7680:9905]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 84EF0400B1 for ; Mon, 23 Jul 2012 09:12:39 -0400 (EDT) Message-ID: <500D4DC6.6010102@viagenie.ca> Date: Mon, 23 Jul 2012 09:12:38 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120716154655.20530.97681.idtracker@ietfa.amsl.com> <50043870.4000405@viagenie.ca> <20120723104754.GA15804@nic.fr> In-Reply-To: <20120723104754.GA15804@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DNSOP] New Version Notification for draft-perreault-dnsop-stats-mib-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 13:12:41 -0000 Le 2012-07-23 06:47, Stephane Bortzmeyer a écrit : > Main comment: I am not convinced by the whole idea of "Discontinuity > Time". Isn't the whole idea of SNMP to have dumb agents, often without > stable memory, and the manager is supposed to know that, to detect > discontinuities and to deal with it? Why is DNS different from typical > MIB-II counters, which can go back to zero when the router reboots? The main use case is when the DNS daemon restarts and loses state. This creates a discontinuity in the DNS MIB counters but not in the global MIB-II counters. That's why we introduced a separate discontinuity indicator that the manager can monitor to identify discontinuities, just like it does with MIB-II. Other MIBs use the same technique (e.g. the OSPFv2 MIB [RFC4750]). > Second, the draft requires a mention of RFC 6168, which covers also > statistics. Clearly we can add a reference to that RFC. But it looks like it doesn't go into much detail about what statistics are needed, just that some are. So, not much guidance for us. Or did I overlook something? > Otherwise, the draft seems sensible, addresses a real problem for DNS > operators who have subcontractors, and, IMHO, correctly answer the > warnings of RFC 3197. Thank you! That's very encouraging! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From peter@denic.de Mon Jul 23 09:37:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C448121F8569 for ; Mon, 23 Jul 2012 09:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BbIUh+aQfEG for ; Mon, 23 Jul 2012 09:37:17 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 63AC821F851C for ; Mon, 23 Jul 2012 09:37:17 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1StLdE-0002HK-IQ; Mon, 23 Jul 2012 18:37:16 +0200 Received: from localhost by x27.adm.denic.de with local id 1StLdE-000572-Eo; Mon, 23 Jul 2012 18:37:16 +0200 Date: Mon, 23 Jul 2012 18:37:16 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20120723163716.GT24669@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] Publication requested for draft-ietf-dnsop-rfc4641bis-12.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 16:37:18 -0000 Dear WG, following last week's email we have now requested publication of DNSSEC Operational Practices, Version 2 draft-ietf-dnsop-rfc4641bis-12 as an Informational RFC. You can watch progress on the datatracker . Thanks to the editors and all contributors so far. We expect an IETF wide Last Call and look forward to the feedback to be provided. Please find below a copy of the proto writeup that was sent to the IESG. -Peter, as co-chair and doc shepherd ============================================================================= (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This draft, , aims at "Informational" status and obsoletes RFC 4641, which has the same status. The WG discussed BCP status but it was felt that there is too little experience beyond root and TLD operations to justofy "best". For the same reason, the document tries to discuss practices and their tradeoffs rather than giving strong recommendations. This is also explained in the Introduction. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is DNS zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It elaborates on issues of key generation, key storage, signature generation, key rollover, and related tasks. Working Group Summary The draft started as an updated version of RFC 4641 in 2009 and and was updated through WG contributions up to version -06 that got WGLC'ed in April 2011. Multiple comments received during the WGLC as well as after this were taken into account with the consent of the WG, leading to version -12 as of today. No part of the document was particluarly contentious, as the draft primarily discusses tradeoffs in favor of making recommendations. That means reasonable dissenting views could be and are reflected in the document. Document Quality This draft is a definitive improvement over RFC 4641, which it strives to replace. Various TLD and other zones' DNSSEC practices are in line with, or within the boundaries of this draft, that therefore reflects the collective wisdom of those active operators who chose to contribute. The draft received significant review within the WG as well as attention outside the IETF. Personnel Peter Koch is the document shepherd, Ron Bonica is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed this latest -12 version as well as previous versions. NITS level review was applied and addressed in -12. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has received widespread attention within the DNSOP WG as well as outside the IETF. There are no concerns regarding the depth or breadth of the review. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. As the draft talks about cryptographic parameters, such as DNSSEC key sizes and algorithms, the input of experienced IETF attendees with security and cryptographic background is highly appreciated. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is no IPR field against this draft as per (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus behind the document is strong. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) N/A (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The draft passes the IETF ID nits checker with two relevant warnings: RFC 2119 language is used only where the draft quotes other RFCs, therefore the 2119 boilerplate was not used. This is already addressed in the introduction. The draft uses the boilerplate for pre-5378 work, because it is an extended update of RFC 4641. Not all contributors to that RFC (as per the extensive acknowledgement section) have been asked for permission. Both WG chairs, including the shepherd, did independent nits reviews for consistency, language and, well, nits. These have been addressed in -08 and subsequent versions of the draft. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? All core DNS and DNSSEC RFCs are considered Normative. Other RFCs, DNS or otherwise, as well as non-IETF documents are considered Informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This draft intends to obsolete RFC 4641 while maintaining Informational status. This is refelected in the header as well as in the abstract and introduction. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does neither request registrations nor define a IANA registry. This is rightfully addressed in section 7 of the draft. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is no such formal language. All DNS examples have been inspected as appropriate and to the extent possible (DNSSEC signatures are intentionally shortened) during the review process. State diagrams in figures 1 through 15 have been reviewed manually. ============================================================================= From matthijs@nlnetlabs.nl Tue Jul 24 04:53:22 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440A821F85DA for ; Tue, 24 Jul 2012 04:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afWOh61kJpW3 for ; Tue, 24 Jul 2012 04:53:21 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA99F21F85D7 for ; Tue, 24 Jul 2012 04:53:20 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:20ac:f815:d474:2321] ([IPv6:2001:7b8:206:1:20ac:f815:d474:2321]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q6OBrFV9004476 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2012 13:53:16 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.5.2 open.nlnetlabs.nl q6OBrFV9004476 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1343130797; bh=uMjCg5/CXbbDut1d7S52wFpfGmMeOoeXwGkpYzcZDZ4=; h=Date:From:To:Subject:References:In-Reply-To; b=Ewj3FvM2DulKrcAMRehJn+jGmMVwHDLAkef0+MirYlFd9V8hZaTJHJThg1RJZHPm2 fQuo1L6Mq14kPNyKqy+u2algpxBcp64wVVtRPcJWITayhdS3y8vG7dKNbYFxYXmnfn 6U8Dgl7exg5HmLq/XDXwQ8NpM2zCMUGPOjut8h7k= Message-ID: <500E8CAC.6080206@nlnetlabs.nl> Date: Tue, 24 Jul 2012 13:53:16 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 24 Jul 2012 13:53:16 +0200 (CEST) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 11:53:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Stephen asked me to send this suggestion we had (surfaced from discussions) to the list. We would like to have input before the upcoming IETF meeting. Modification to the key states ============================== As you might know, I had this idea of unraveling key states. Instead of having states that describe the overall state of the key, we would have states for components of the key. How to divide the key into components is based on the parts that can be published: - - DNSKEY - - DS - - RRSIG - - RRSIG DNSKEY We can call this the representation of the key (which components are visible in the zone and/or caches). The RRSIG for zone contents and for the DNSKEY RRset need specifically be split to support a Single Type Singing Key in a later stadium. Each component follows a certain publication path. Initially it is Hidden, it will be Introduced into the zone, it is long enough in the zone to be Propagated to all caches, it will be Withdrawn from the zone and it will become Hidden again (as it has expired from caches): Hidden --> Introduced --> Propagated --> Withdrawn --> Hidden. (Note: a component could be removed from the zone before it was propagated, so a transition between Introduced and Withdrawn. The other way around is also true: A record can be reintroduced before it had expired from all the caches. The idea is to consider full rollovers only, so these transitions will be out of scope.) The overall key states from draft-ietf-dnsop-dnssec-key-timing-03.txt map (but not one-to-one) to the unraveled key states: For example, for ZSK Rollovers: Generated -> (DNSKEY Hidden, RRSIG Hidden) Published -> (DNSKEY Published, RRSIG Hidden) [Pre-publish] -> (DNSKEY Hidden, RRSIG Published) [Double-RRSIG] Ready -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish] -> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG] Active -> (DNSKEY Propagated, RRSIG Introduced) [Pre-publish] -> (DNSKEY Introduced, RRSIG Propagated) [Double-RRSIG] -> (DNSKEY Introduced, RRSIG Introduced) [Double-Signature] Retired -> (DNSKEY Propagated, RRSIG Withdrawn) [Pre-publish] -> (DNSKEY Withdrawn, RRSIG Propagated) [Double-RRSIG] -> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature] Dead -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish] -> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG] -> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature] Removed -> (DNSKEY Withdrawn, RRSIG Hidden) [Pre-Publish] -> (DNSKEY Hidden, RRSIG Withdrawn) [Double-RRSIG] -> (DNSKEY Withdrawn, RRSIG Withdrawn) [Double-Signature] (I leave the KSK rollovers as an exercise to the reader ;-) ) So you see, the key states as they are now do not map uniquely to how the key is presented in the zone. I want to propose that either the document uses the unraveled key states, or otherwise defines a unique mapping between the overall key states and the representation of the key. Also, we should not limit to one key state at a time. For example, a key can be Published and Active at the same time in my opinion. - From -03: Published The DNSKEY record - or information associated with it - is published in the zone, but predecessors of the key (or associated information) may be held in caches. Active The key has started to be used to sign RRsets. Note that when this state is entered, it may not be possible for validating resolvers to use the key for validation in all cases: the zone signing may not have finished, or the data might not have reached the resolver because of propagation delays and/or caching issues. If this is the case, the resolver will have to rely on the key's predecessor instead. But both descriptions may be valid at the same point in time. So I would like to say the key can be Published and Active at the same time. Finally, I would like to drop "associated information". To keep a clear definition, a key state should only say something about one key component. So, the definition for Published would become: Published The DNSKEY record is published in the zone, but predecessors of the key (or associated information) may be held in caches. or even more simpler: Published The DNSKEY record is published in the zone. So, you would get more states, but with simpler descriptions. To summarize: 1. Use unraveled key states or define a unique mapping between the overall key states and the representation of the key. 2. A key can have more than one state at a time. 3. Drop "associated information", a key state only says something about one key component. Thoughts? Best regards, Matthijs On 07/09/2012 07:13 PM, Stephen Morris wrote: > After much delay, the -03 version of the key timing draft has been > submitted. It incorporates a number of comments made on-list and > privately: many thanks to Mark Lampo, Matthijs Mekking and Alfred > Hoenes. > > Perhaps the most significant change concerns the timing > considerations related to the introduction of a new KSK (section > 3.3.4.1). > > Stephen > > > On 9 Jul 2012, at 17:29, 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 Working Group of the IETF. >> >> Title : DNSSEC Key Timing Considerations Author(s) >> : Stephen Morris Johan Ihren John Dickinson Filename : >> draft-ietf-dnsop-dnssec-key-timing-03.txt Pages : 33 >> Date : 2012-07-09 >> >> Abstract: This document describes the issues surrounding the >> timing of events in the rolling of a key in a DNSSEC-secured >> zone. It presents timelines for the key rollover and explicitly >> identifies the relationships between the various parameters >> affecting the process. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-03 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-key-timing-03 >> >> >> >> 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 > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQDoysAAoJEA8yVCPsQCW5AaYH/iFlHzxxMaUUsds5kW5M2y6J UANul10z65dWe0Sng335KmalieBFEuaFBugSo0IONazf6Qj8OWQ8OGHCbGKTDqI2 KOIC5z38AAD/BI82ahYUwVMr5u2aQXKFpjQc1yhH6ujvxspa0MWC+Uzzce5vSoQG I+ubviuWI2Oen4qN8X/FPf3JmagAzlBy87hf+qX6a2E649eXuQPWocfyyQqGXGWZ jjtkJ8cOp0BPLwf6OQ3HLYIlx6a/ucEsYaGJrzpDQvMjUj8c+nDngg9yoLqp+bxZ Stp2PpE83gSqRNeDUJRRrP8CtZvtCl4AH48iHa2z5V5OwZ8bxjWGavHWUPSt0fw= =XiNc -----END PGP SIGNATURE----- From paul@cypherpunks.ca Tue Jul 24 06:59:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BBA21F84F2 for ; Tue, 24 Jul 2012 06:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJl2FaSurgZP for ; Tue, 24 Jul 2012 06:59:51 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id ED55721F84E1 for ; Tue, 24 Jul 2012 06:59:50 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 485B58052F; Tue, 24 Jul 2012 09:59:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3CA518052E; Tue, 24 Jul 2012 09:59:36 -0400 (EDT) Date: Tue, 24 Jul 2012 09:59:36 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Matthijs Mekking In-Reply-To: <500E8CAC.6080206@nlnetlabs.nl> Message-ID: References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <500E8CAC.6080206@nlnetlabs.nl> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 13:59:51 -0000 On Tue, 24 Jul 2012, Matthijs Mekking wrote: > But both descriptions may be valid at the same point in time. So I > would like to say the key can be Published and Active at the same time. > 2. A key can have more than one state at a time. I would not be in favour or using "states" where there is no clear distinction between the key states. Looking at implementors of key management software using state machines, we really should help them by using solid state definitions that do not overlap. So "Published" would need to include "not used for signing" so it can never overlap with "Active". Paul From Antoin.Verschuren@sidn.nl Tue Jul 24 07:07:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DE921F8656 for ; Tue, 24 Jul 2012 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtMC1xPUeIsl for ; Tue, 24 Jul 2012 07:07:52 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 34E7B21F8652 for ; Tue, 24 Jul 2012 07:07:51 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q6OE7oxb020002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 24 Jul 2012 16:07:50 +0200 Received: from [94.198.156.18] (94.198.156.18) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 24 Jul 2012 16:07:50 +0200 Message-ID: <500EAC32.9090609@sidn.nl> Date: Tue, 24 Jul 2012 16:07:46 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> <7FB9E36D-4368-4472-B3A0-4BD17B084F09@frobbit.se> In-Reply-To: <7FB9E36D-4368-4472-B3A0-4BD17B084F09@frobbit.se> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.156.18] Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:07:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16-07-12 22:37, Patrik Fältström wrote: Just back from holidays, some aditions: > JUST talk about things like: > > 1. we have registry, registrar, registrant and DNS operator" In the DNSSEC transfer issues we discussed, we did enter a reseller, so the administrative chain that is general enough for any current relationship is: Registry-Registrar-Reseller-Registrant-DNS_operator. Where there may be 0-1 Registrars and 0-multiple resellers in the administrative chain. The more general mistake is that one entity can play multiple roles. So one entity may act as both Registrar and DNS_operator for a certain delegation where in another delegation one entity may be both registrant and DNS_operator. So they are roles, not players. This is often not understood in discussions. (you may even have entities that combine registrar and multiple reseller roles). > 2. any of those might give the right to a third party to act on > their behalf > > 3. we only know there are direct connections and knowledge between > registry-registrar, registrar-registrant and registrant-dns > operator The issue for the administrative chain is the question as to who offers the authoritative data. For a Registry, the registry database IS the authoritative data, which is fed into the DNS parent zone. So from the point of view of the parent zone, it only accepts changes from the Registry database and not from another source. Or to put it in pictures: Registrant/Reseller/Registrar => Registry database => DNS Parent zone If we only look technically at the DNS, what we're trying to do here is: Parent zone <=> Child zone To keep them both in sync. But this leads to problems in the administrative chain: Registrant/Reseller/Registrar => Registry database <=> DNS parent zone Which data is authoritative for the Registry database, The registrar's input, or the DNS input ? Registrars claim they are always right, we DNS people claim DNS is always right. We need the registrar's input for bootstrapping the delegation at least. The question is who is authoritative for the delegation after that. DNS or the registrar's input. > What we MUST have is: > > - Enough data in the registry so that DS can be created that refer > to key material used to sign the zone published by the dns > operator > > Today we know that we have cases like: > > A. The DS is passed to the registry > > B. The DNSKEY is passed to the registry that create the DS > > C. The DNSKEY is fetched from the zone of the DNS operator and the > DS is created > > We have the following plus and minuses: > > bla bla bla > > Patrik > > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQDqwxAAoJEDqHrM883AgnMw4H/Rzwxyomgr5AjzvQ8iLAYCgW mDHCP99T6IX2N2qzTjxb3yCxuSenFYSjXEIjY+qCWj02ilVpDkaaj1OYoeA3QNax aVckUbkDGXkIvT3Y9BNrMeNTRLovBZ8Tkt6YlkUM2QHCirvkkCnZ0FCRFxQZlXWj V5jWkHtr7M+m5f965JutGSs+2P4JcqijAJAMXy+SNVpNJhwt2RxTARvzFLIeAZ0S jH9/PAzyAcIF6gV5sTaIwz404VfY23dEJZ8GL5arQ3JEfGOBIQsRv2eaCwX29kaD ziirytFdy/p4S0WQeF/K/4z4TFI9XQg3FiRJBBnIk34SD5cHu/JERQRpkOALgck= =fmXB -----END PGP SIGNATURE----- From patrik@frobbit.se Tue Jul 24 07:38:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C8021F8682 for ; Tue, 24 Jul 2012 07:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cGRf76ZMUKz for ; Tue, 24 Jul 2012 07:38:17 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB3721F8681 for ; Tue, 24 Jul 2012 07:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 64A1C143ECA54; Tue, 24 Jul 2012 16:38:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA+B-sf2czDU; Tue, 24 Jul 2012 16:38:08 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id F0885143ECA46; Tue, 24 Jul 2012 16:38:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <500EAC32.9090609@sidn.nl> Date: Tue, 24 Jul 2012 16:38:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09DD3329-1A0D-44D0-9A32-493CC0697839@frobbit.se> References: <20477.49909.903443.742699@guava.gson.org> <20120713115751.GE24669@x28.adm.denic.de> <2ECB7435-5439-4973-B223-876E9A0467CD@frobbit.se> <3CDA61C3-CFB8-4BFF-B0B3-EC48AF7B8B4E@vpnc.org> <0B4B3617-9BE9-483A-AB74-E8E8A44AE191@frobbit.se> <7FB9E36D-4368-4472-B3A0-4BD17B084F09@frobbit.se> <500EAC32.9090609@sidn.nl> To: Antoin Verschuren X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Tue, 24 Jul 2012 07:40:33 -0700 Cc: dnsop@ietf.org Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:38:18 -0000 On 24 jul 2012, at 16:07, Antoin Verschuren wrote: > On 16-07-12 22:37, Patrik F=D0=B4ltstr=D1=86m wrote: >=20 > Just back from holidays, some aditions: >=20 > > JUST talk about things like: > >=20 > > 1. we have registry, registrar, registrant and DNS operator" >=20 > In the DNSSEC transfer issues we discussed, we did enter a reseller, > so the administrative chain that is general enough for any current > relationship is: >=20 > Registry-Registrar-Reseller-Registrant-DNS_operator. >=20 > Where there may be 0-1 Registrars and 0-multiple resellers in the > administrative chain. My point is that you complicate things by including reseller. A reseller = can be viewed as the down-facing portion of the registrar. The problem is not there, The problem is the gap between the others (see = below). > The more general mistake is that one entity can play multiple roles. Yes. And too many do believe the registrar do run DNS, in the form of = saying "registrar" when they mean "DNS operator". > So one entity may act as both Registrar and DNS_operator for a certain > delegation where in another delegation one entity may be both > registrant and DNS_operator. So they are roles, not players. This is > often not understood in discussions. (you may even have entities that > combine registrar and multiple reseller roles). >=20 > > 2. any of those might give the right to a third party to act on > > their behalf > >=20 > > 3. we only know there are direct connections and knowledge between > > registry-registrar, registrar-registrant and registrant-dns > > operator >=20 > The issue for the administrative chain is the question as to who > offers the authoritative data. Agree, but that is a different issue from what I am talking about. I am talking about the problem that you have one path like this: dns operator - registrant registrant - registrar registrar - registry ...as the three connections we know we have to create a chain between = dns operator and registry. Then you have the potential difference between what the dns operator = have and what is in the zone that the registry produces from the content = of their database. Now, if you create a mechanism where the parent zone is produced by data = fetched from a merge between what is in the registry database and in the = child zone, then you still must recognize that the only data you have to = bridge that gap are the three connections I list above. And btw, this is not something new for DNSSEC, as we have same issue = with NS record or glue in the cases that is needed. > For a Registry, the registry database IS the authoritative data, which > is fed into the DNS parent zone. >=20 > So from the point of view of the parent zone, it only accepts changes > from the Registry database and not from another source. > Or to put it in pictures: >=20 > Registrant/Reseller/Registrar =3D> Registry database =3D> DNS Parent = zone >=20 > If we only look technically at the DNS, what we're trying to do here = is: >=20 > Parent zone <=3D> Child zone >=20 > To keep them both in sync. Correct as a goal. > But this leads to problems in the administrative chain: >=20 > Registrant/Reseller/Registrar =3D> Registry database <=3D> DNS parent = zone >=20 > Which data is authoritative for the Registry database, The registrar's > input, or the DNS input ? I do not see that as a problem, although I agree that is one. What is = the problem is for the registry (or mechanism that produces the parent = zone) to know what is the correct DNS child. > Registrars claim they are always right, we DNS people claim DNS is > always right. > We need the registrar's input for bootstrapping the delegation at = least. > The question is who is authoritative for the delegation after that. > DNS or the registrar's input. What I am talking about is how the registry knows that the child DNS is = really the child DNS. If you do, then of course you can as parent "just" = fetch the data from there. Patrik > > What we MUST have is: > >=20 > > - Enough data in the registry so that DS can be created that refer > > to key material used to sign the zone published by the dns > > operator > >=20 > > Today we know that we have cases like: > >=20 > > A. The DS is passed to the registry > >=20 > > B. The DNSKEY is passed to the registry that create the DS > >=20 > > C. The DNSKEY is fetched from the zone of the DNS operator and the > > DS is created > >=20 > > We have the following plus and minuses: > >=20 > > bla bla bla > >=20 > > Patrik > >=20 > >=20 > > _______________________________________________ DNSOP mailing list=20= > > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > >=20 >=20 >=20 > - --=20 > Antoin Verschuren >=20 > Technical Policy Advisor SIDN > Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands >=20 > P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 > mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl > http://www.sidn.nl/ From joe.abley@icann.org Tue Jul 24 08:11:50 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF221F8679 for ; Tue, 24 Jul 2012 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q22yo8O6uDT9 for ; Tue, 24 Jul 2012 08:11:49 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9B10821F8678 for ; Tue, 24 Jul 2012 08:11:49 -0700 (PDT) Received: from [199.212.90.56] (199.212.90.56) by smtpx.exc.icann.org (64.78.22.243) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 24 Jul 2012 08:11:48 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0C892DAC-9DCB-42E4-9EE9-325596858C15"; protocol="application/pkcs7-signature"; micalg=sha1 From: Joe Abley In-Reply-To: <500E8CAC.6080206@nlnetlabs.nl> Date: Tue, 24 Jul 2012 11:11:46 -0400 Message-ID: References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <500E8CAC.6080206@nlnetlabs.nl> To: Matthijs Mekking X-Mailer: Apple Mail (2.1278) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 15:11:50 -0000 --Apple-Mail=_0C892DAC-9DCB-42E4-9EE9-325596858C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-07-24, at 07:53, Matthijs Mekking wrote: > As you might know, I had this idea of unraveling key states. Instead > of having states that describe the overall state of the key, we would > have states for components of the key. How to divide the key into > components is based on the parts that can be published: I am a big fan of this line of thinking. I saw you (in Vienna, I think) reduce this logic to a small set of = equations which, if all are satisfied, indicates that a particular = change for one component is safe (from the perspective of validators), = and I think this would be a vast improvement for implementers and = operators over the sometimes complicated reasoning that is otherwise = involved in planning a rollover event. This model makes arbitrary key = rollovers trivial to plan with confidence. While dnsop-dnssec-key-timing provides a fairly thorough background = which promotes understanding of the underlying issues, it's still a = thorny document to apply to an actual operational event. I think it would be great if we could present your model (or something = similarly robust and simple) in such a way that it becomes the normal = way of thinking about rollover events, both for implementers of DNSSEC = signing platforms and for operators of DNSSEC-signed zones. The world = would be a better place. Joe --Apple-Mail=_0C892DAC-9DCB-42E4-9EE9-325596858C15 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNzI0MTUxMTQ2WjAjBgkqhkiG9w0BCQQxFgQU50TplKHO97fvcsk7AGCHnmrOjaEwgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB AGhuvp6OngqoaBgu0yyZpaNQcVoKhYjmXsvkgi2XCSCf1z56rLtTWa3vymu2AgCZlVGJLLFtIgRz kbuywPkeVnCNsn68Kw0B4vtUNV74XGqOD7Z1j+I63HJU4dQiw7z7TPvbUNO1FMscL6OADopKZnhQ 5iEpE/rO+mzxtDn1Wm6U3FX6whqmF/JXeZ61dH6ADqczF8XDTOplB8fzCIf9IRBdjWOKIS/Fr7fc Xabs/k+nW3gWdiFX8GBjA4VYc+pwLyjMna0Fc9HQU64ot3cgKctA2q9c0oybazv8yNt8PdlrQt2l Y7MEG2KdJaBrxPezFTCrNPQap8K8wFKKfaR+2tkAAAAAAAA= --Apple-Mail=_0C892DAC-9DCB-42E4-9EE9-325596858C15-- From Ed.Lewis@neustar.biz Tue Jul 24 09:25:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4177921F85F3 for ; Tue, 24 Jul 2012 09:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYm55q2Ti0fH for ; Tue, 24 Jul 2012 09:25:57 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6828621F85CD for ; Tue, 24 Jul 2012 09:25:57 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q6OGPsxQ075292; Tue, 24 Jul 2012 12:25:55 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.139] by Work-Laptop-2.local (PGP Universal service); Tue, 24 Jul 2012 12:25:55 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 24 Jul 2012 12:25:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> References: <20477.49909.903443.742699@guava.gson.org> <5001DB93.4000708@dougbarton.us> <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> Date: Tue, 24 Jul 2012 12:25:50 -0400 To: dnsop From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 16:25:58 -0000 At 17:05 -0400 7/14/12, Joe Abley wrote: >Any new work which needed to assert that both sets were the same would >meet with little objection though, I think. I disagree. I would object to any strengthening of what is said in STD 13. Yes, the two sets are designed to be the same. But if they had to always be the same, it would bi impossible to add or delete NS records. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From joe.abley@icann.org Tue Jul 24 09:30:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4011621F85F2 for ; Tue, 24 Jul 2012 09:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTAqaNqYG2dV for ; Tue, 24 Jul 2012 09:30:54 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id B2E2221F85C2 for ; Tue, 24 Jul 2012 09:30:54 -0700 (PDT) Received: from [199.212.90.56] (199.212.90.56) by smtpx.exc.icann.org (64.78.22.243) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 24 Jul 2012 09:30:54 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_388CC2A3-35E7-4C8F-A175-F61E9DDE7F42"; protocol="application/pkcs7-signature"; micalg=sha1 From: Joe Abley In-Reply-To: Date: Tue, 24 Jul 2012 12:30:51 -0400 Message-ID: <61B04943-A50F-4DF5-B117-B9CAC1766165@icann.org> References: <20477.49909.903443.742699@guava.gson.org> <5001DB93.4000708@dougbarton.us> <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> To: Edward Lewis X-Mailer: Apple Mail (2.1278) Cc: dnsop Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 16:30:55 -0000 --Apple-Mail=_388CC2A3-35E7-4C8F-A175-F61E9DDE7F42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-07-24, at 12:25, Edward Lewis wrote: > At 17:05 -0400 7/14/12, Joe Abley wrote: >=20 >> Any new work which needed to assert that both sets were the same = would >> meet with little objection though, I think. >=20 > I disagree. >=20 > I would object to any strengthening of what is said in STD 13. >=20 > Yes, the two sets are designed to be the same. But if they had to=20 > always be the same, it would bi impossible to add or delete NS=20 > records. In this context, "the same" refers to the steady state: i.e. a mechanism = which standardised the promotion of an updated, signed apex NS set to = form a replacement delegation set in the parent would be one that = enforced that steady-state similarity. This is in contrast to a = conscious operational decision to keep the delegation and apex NS sets = different in the steady state (which at least a couple of us have = observed). My point was that prevalent deployment of such mechanisms which = prevented (or made difficult to maintain) such conscious dissonance = would likely meet with little objection. Joe= --Apple-Mail=_388CC2A3-35E7-4C8F-A175-F61E9DDE7F42 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNzI0MTYzMDUxWjAjBgkqhkiG9w0BCQQxFgQU8Mw4lXNiEQIgnlEW4LkIiTbG2FUwgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB ALVGjArUsL5dX/Dhb7kS8JagrXK/YY9aXxyWYDF/t0iEEFP/0Bt5jChfGHvxG7uwxwGeXexxoIfr rpInrUOTaUBip2E3ggjBi/yoeemygJ+Vwm++bVN6HgYNpkrBPbZCwsieGPCpVFZnJapAzhiI3IMl ny5/h+MaLHSLdX6O1erYnaOmHmtQu1fAD1tYJgBMU+d08gCo4s/Jk5gNVhTtPHLUlxxPepnxWTEL xmRWv/12TDBs7cDy0ODb/h0ylUWEMvDSViDThMyEh/jRt2m01rQArH+POLe6hW+S5jRDGtLzfVF8 6o2qCAV6sNSC69z3uC0nG6JTZSSy2w+jD6xUnDsAAAAAAAA= --Apple-Mail=_388CC2A3-35E7-4C8F-A175-F61E9DDE7F42-- From cet1@hermes.cam.ac.uk Tue Jul 24 10:43:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E712311E8096 for ; Tue, 24 Jul 2012 10:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMEsyBVH+xVY for ; Tue, 24 Jul 2012 10:43:06 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id CAE0111E8086 for ; Tue, 24 Jul 2012 10:43:05 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:50990) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1Stj8Q-00074J-qm (Exim 4.72) (return-path ); Tue, 24 Jul 2012 18:43:02 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Stj8P-0002IB-Up (Exim 4.67) (return-path ); Tue, 24 Jul 2012 18:43:01 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 24 Jul 2012 18:43:01 +0100 Date: 24 Jul 2012 18:43:01 +0100 From: Chris Thompson To: Joe Abley Message-ID: In-Reply-To: <61B04943-A50F-4DF5-B117-B9CAC1766165@icann.org> References: <20477.49909.903443.742699@guava.gson.org> <5001DB93.4000708@dougbarton.us> <371937C2-D6F9-4951-A778-2F560DD5043D@icann.org> <61B04943-A50F-4DF5-B117-B9CAC1766165@icann.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsop , Edward Lewis Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:43:07 -0000 On Jul 24 2012, Joe Abley wrote: [...] >In this context, "the same" refers to the steady state: i.e. a mechanism >which standardised the promotion of an updated, signed apex NS set to form >a replacement delegation set in the parent would be one that enforced that >steady-state similarity. Even if the intent is for the sets to converge, it isn't obvious that upward propagation ("promotion") is always the best way to do things. In theory, at least, I try to make changes in this order: Adding an NS: 1. Set up the slaving arrangement. 2. Add to the in-zone NS RRset. 3. Add to the delegation NS RRset. Dropping an NS: 1. Delete from the delegation NS RRset. 2. Delete from in-zone NS RRset. 3. Tear down the slaving arrangement. It's true, though, that I wouldn't much care about the order of the first two actions in the latter case if I could be sure that the updating of the delegation could always be done in a timely fashion. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From matthijs@nlnetlabs.nl Wed Jul 25 00:45:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FDE21F84E7 for ; Wed, 25 Jul 2012 00:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WeIyWke0oJD for ; Wed, 25 Jul 2012 00:45:28 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3128321F84EB for ; Wed, 25 Jul 2012 00:45:27 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q6P7jMSS050282 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2012 09:45:23 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.5.2 open.nlnetlabs.nl q6P7jMSS050282 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1343202325; bh=t6QsD00UM7b/MZmIpcHO+P1X1Vb+2em7YaBwF3PMCkY=; h=Date:From:To:Subject:References:In-Reply-To; b=cNN2EEvcyoQLumlUUdLWd7oIGRSTzFNfv/wIHhvOPMVhNNBDm0E/1e/ceot/7eiDy xzMd1K1Khx5JwE8PYL3ZdFPQaQCz8LQwR95Qg+ynPBEPxfa9g2POZBau/yCxv1Ox+f 28oV1NPFg1iI3bXX24CHQdJUCNeVr1C+KHq2WtWY= Message-ID: <500FA413.8090709@nlnetlabs.nl> Date: Wed, 25 Jul 2012 09:45:23 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <500E8CAC.6080206@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 25 Jul 2012 09:45:23 +0200 (CEST) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:45:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2012 03:59 PM, Paul Wouters wrote: > On Tue, 24 Jul 2012, Matthijs Mekking wrote: > >> But both descriptions may be valid at the same point in time. So >> I would like to say the key can be Published and Active at the >> same time. > >> 2. A key can have more than one state at a time. > > I would not be in favour or using "states" where there is no clear > distinction between the key states. Looking at implementors of key > management software using state machines, we really should help > them by using solid state definitions that do not overlap. The whole idea of the proposed suggestion is to make the distinction in key states more clear. The reason for the overlap to occur is that key *components* have a state and these states use a solid definition. Published says something about the DNSKEY record. Active says something about the RRSIG records. > > So "Published" would need to include "not used for signing" so it > can never overlap with "Active". But there are (obvious) situations that a Published key is used for signing, e.g. the key is Active. That doesn't matter, as long as the states for one key component do not overlap. Matthijs > > Paul _______________________________________________ DNSOP mailing > list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQD6QTAAoJEA8yVCPsQCW5dzYIALclPELerCbk15DLwi3r4UjW Oq9t3EzLQL+OoxK1YAVT+lAJzyD1pFnixXdgC2AVZqbjigEHMXWZIQIfHCJGhvpD j1lALhSnIvpTjCKaYIlluF4anA+B12euz8ePe6h0U4/v1TW+HzDTvfboUDv0sLep TcfXzZW7OerPnrdMSZNSlt1EIAF49Cqkbob4sU8cl0sKQ6qHC5s3GJr0BQiTilyJ qCOvmGc27htaq1ScMp9geP7Kbah7Y5C7FOMFUmQ1OaQ7bPaukk+bZSXa7VbRDHR4 0mcEUocDbV7P4uuWqqmMvC4A+yrPUmphd/wPILQmkhFIbVv2Rolq7v7XeJ/I2oc= =iOTv -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Jul 25 00:53:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6621F84E1 for ; Wed, 25 Jul 2012 00:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPkrL036VYwk for ; Wed, 25 Jul 2012 00:53:29 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C80B821F84EB for ; Wed, 25 Jul 2012 00:53:28 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q6P7r0nK058561 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 09:53:01 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.5.2 open.nlnetlabs.nl q6P7r0nK058561 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1343202782; bh=NY6NQZIYeDOARD3BjDpwYFzYryYRW3MC9bAqp20wGl0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=PP+QLDjScQRT2gpL9mAH+rtcDWnf9GLFOJKgfm9Ifbryxpv+Q7UGALLRW61q9scOs 5uTxhmDwKpWdHtDeU54EXHE7zwSRYgXZea5telVpJNES2Cf4LhwIJ+NMxzJluCpaFj cNNs/wvk6Ne506dxZuWb6m3PVyWBaFZGyF1agVhQ= Message-ID: <500FA5DD.9050501@nlnetlabs.nl> Date: Wed, 25 Jul 2012 09:53:01 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Joe Abley References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <500E8CAC.6080206@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 25 Jul 2012 09:53:01 +0200 (CEST) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:53:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2012 05:11 PM, Joe Abley wrote: > > On 2012-07-24, at 07:53, Matthijs Mekking wrote: > >> As you might know, I had this idea of unraveling key states. >> Instead of having states that describe the overall state of the >> key, we would have states for components of the key. How to >> divide the key into components is based on the parts that can be >> published: > > I am a big fan of this line of thinking. > > I saw you (in Vienna, I think) reduce this logic to a small set of > equations which, if all are satisfied, indicates that a particular > change for one component is safe (from the perspective of > validators), and I think this would be a vast improvement for > implementers and operators over the sometimes complicated > reasoning that is otherwise involved in planning a rollover event. > This model makes arbitrary key rollovers trivial to plan with > confidence. You are confusing me for my colleague Yuri, but we think alike. Yuri build the logic on top of the idea of unraveled key states. The logic is based on the timings described in draft-ietf-dnsop-dnssec-key-timing and draft-mekking-dnsop-dnssec-key-timing-bis-02.txt. For more information on the logic, see our paper: http://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf > > While dnsop-dnssec-key-timing provides a fairly thorough > background which promotes understanding of the underlying issues, > it's still a thorny document to apply to an actual operational > event. > > I think it would be great if we could present your model (or > something similarly robust and simple) in such a way that it > becomes the normal way of thinking about rollover events, both for > implementers of DNSSEC signing platforms and for operators of > DNSSEC-signed zones. The world would be a better place. Thanks. Matthijs > > > Joe > > > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQD6XdAAoJEA8yVCPsQCW5K3AIAIT+iJzk9FA+SpFelg1xGAg2 JevKRs/kP+BfaTWGedbJnP4UaHsJdhK+eM6VNAMRB0pjR+ORQv3KwRkzfpop5QVP v/mRqZqv+pHBwsikrecvH4kER5j9TLjghPnK8gElEVi0tf4wTnkgB6RfstZNN0aw lxj7lLWTJVvUgMZhl7DNKMmRdO5DS4j5amcQMX7etqn73UHnzArGkswRMttYFh7q BoPzn02ysXDZlXsRbaS58l4VA93nU31M6MJ4RNXzXSNDP3yWwvPq7UAlJL4ngS6y 15MGejj/GQB4626ao5pXtWoT5IfTq7vQ94hS5A5mSkFa/kL2gOUOKQsWY/+eMsc= =AP9g -----END PGP SIGNATURE----- From miekg@atoom.net Wed Jul 25 00:55:13 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A514C21F84A5 for ; Wed, 25 Jul 2012 00:55:13 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOxlJ6F9hSyS for ; Wed, 25 Jul 2012 00:55:13 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [IPv6:2001:7b8:32a::2]) by ietfa.amsl.com (Postfix) with ESMTP id 173A121F8462 for ; Wed, 25 Jul 2012 00:55:12 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id B90CD40114; Wed, 25 Jul 2012 09:55:11 +0200 (CEST) Date: Wed, 25 Jul 2012 09:55:11 +0200 From: Miek Gieben To: dnsop@ietf.org Message-ID: <20120725075511.GA323@miek.nl> Mail-Followup-To: dnsop@ietf.org References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <500E8CAC.6080206@nlnetlabs.nl> <500FA5DD.9050501@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <500FA5DD.9050501@nlnetlabs.nl> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:55:13 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [DNSOP] I-D Action: draft-ietf-..= =2E" ] > > While dnsop-dnssec-key-timing provides a fairly thorough > > background which promotes understanding of the underlying issues, > > it's still a thorny document to apply to an actual operational > > event. > >=20 > > I think it would be great if we could present your model (or=20 > > something similarly robust and simple) in such a way that it > > becomes the normal way of thinking about rollover events, both for=20 > > implementers of DNSSEC signing platforms and for operators of=20 > > DNSSEC-signed zones. The world would be a better place. >=20 > Thanks. I like this idea too. But does this mean 4641bis is overly complex wrt to key rollovers? grtz Miek --5vNYLRcllDrimb99 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlAPpl8ACgkQJYuFzziA0Pas3gCg62Tul+HDax6gF/JK6oSWo3jw 9qUAmwXTImzpum7KLu2r7AJazWoHcTjd =hX34 -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From sa.morris7@googlemail.com Mon Jul 30 13:50:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9EB11E81AE for ; Mon, 30 Jul 2012 13:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0Z+6P7ySs9y for ; Mon, 30 Jul 2012 13:50:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F25F311E81A9 for ; Mon, 30 Jul 2012 13:50:30 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10355062pbc.31 for ; Mon, 30 Jul 2012 13:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:x-forwarded-message-id:content-type :content-transfer-encoding; bh=iQRzbL+meZbOzKX8qR/6Bz2MifxY98zU22WM5evXc+E=; b=QdkAIiNMKO/POridL+ubpu+XKpfysskOnbbDUD/X7Fqhu+ylqD274TMMRIqk671MWw CBNTbHChHXsvGNV9jHU5runaMLv/qTe7U3B8UK1a4T4yJcvo4ExHdbFMiC7cbFvHNU0q +GoJoTVvaXg8BXF154RTQ8DcNYVb4+IamiU65sC+FFuV497tfHBnIlK2lfwaAVuxBMBh YoxmhoMpsHKeCLSI5hIIQIUOGUdu0Iu2FWpJhTrqnfFd+cHpkDk7yxaFzKFx+dXycIzU FA0VOm5Ls+Dd6dF04wOXHLxUdfHwX50yRm327Dn8Y3ZhH8oCBHP4or2dNl+JSCXSnF50 y4Kw== Received: by 10.68.130.9 with SMTP id oa9mr37903963pbb.95.1343681430736; Mon, 30 Jul 2012 13:50:30 -0700 (PDT) Received: from dhcp-1745.meeting.ietf.org ([2001:df8:0:16:225:ff:fe4c:a932]) by mx.google.com with ESMTPS id ph1sm8566416pbb.45.2012.07.30.13.50.29 (version=SSLv3 cipher=OTHER); Mon, 30 Jul 2012 13:50:29 -0700 (PDT) Message-ID: <5016F393.9010805@googlemail.com> Date: Mon, 30 Jul 2012 13:50:27 -0700 From: Stephen Morris User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [DNSOP] Need volunteers for the NomCom X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:50:32 -0000 Subject: Need volunteers for the NomCom Date: Sun, 29 Jul 2012 20:22:33 -0700 From: NomCom Chair To: Working Group Chairs We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participants in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org