News

From jmaroisx@alexmo.com Fri Oct 2 17:23:09 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44913A6980 for ; Fri, 2 Oct 2009 17:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.725 X-Spam-Level: X-Spam-Status: No, score=-27.725 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m42nEI8h5tiN for ; Fri, 2 Oct 2009 17:23:09 -0700 (PDT) Received: from allianz.es (unknown [187.42.196.11]) by core3.amsl.com (Postfix) with SMTP id 2D0243A67DD for ; Fri, 2 Oct 2009 17:23:06 -0700 (PDT) To: Subject: Email Handling Opinion Needed From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091003002307.2D0243A67DD@core3.amsl.com> Date: Fri, 2 Oct 2009 17:23:06 -0700 (PDT)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.suchpull.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://suchpull.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 5, B222. 386 Clements Road. London. SE96 7DG

From mazzinizn@93-42-212-148.ip88.fastwebnet.it Sat Oct 3 16:20:31 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09A43A63EB for ; Sat, 3 Oct 2009 16:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.27 X-Spam-Level: X-Spam-Status: No, score=-7.27 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGm8SpsOuqx7 for ; Sat, 3 Oct 2009 16:20:31 -0700 (PDT) Received: from 93-42-212-148.ip88.fastwebnet.it (93-42-212-148.ip88.fastwebnet.it [93.42.212.148]) by core3.amsl.com (Postfix) with ESMTP id 186233A6359 for ; Sat, 3 Oct 2009 16:20:29 -0700 (PDT) Received: from 93.42.212.148 by mail.ronixa.com; Sun, 4 Oct 2009 00:22:01 +0100 Message-ID: <01ca4488$b17ed200$94d42a5d@mazzinizn> From: "Provreg" To: Subject: $$$Amazing Gifts!! Date: Sun, 4 Oct 2009 00:22:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Best gifts for your loved ones http://drinkwatchs.com From provrgcdo@carabinieri.it Sun Oct 25 19:31:29 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37A13A6A27 for ; Sun, 25 Oct 2009 19:31:29 -0700 (PDT) X-Quarantine-ID: <4XsI3D8b5M2m> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 VIAGRA \256 Offic[...] X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XsI3D8b5M2m for ; Sun, 25 Oct 2009 19:31:21 -0700 (PDT) Received: from pool-98-116-158-216.nycmny.fios.verizon.net (pool-98-116-158-216.nycmny.fios.verizon.net [98.116.158.216]) by core3.amsl.com (Postfix) with SMTP id 530063A69C6 for ; Sun, 25 Oct 2009 19:31:20 -0700 (PDT) From: © VIAGRA ® Official To: provreg-archive@ietf.org Subject: Dear provreg-archive@ietf.org 79% 0FF on Pfizer ! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20091026023121.530063A69C6@core3.amsl.com> Date: Sun, 25 Oct 2009 19:31:20 -0700 (PDT) News

Click here to view as a web page.

Unsubscribe | Change e-mail address | Privacy Policy | About Us

Copyright © 2009 jkyf Inc. All rights reserved.

From owner-ietf-provreg@cafax.se Tue Oct 27 12:59:36 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B653A6809 for ; Tue, 27 Oct 2009 12:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.286 X-Spam-Level: X-Spam-Status: No, score=0.286 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AobLF5ZQrtmZ for ; Tue, 27 Oct 2009 12:59:36 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 6E3C13A69C0 for ; Tue, 27 Oct 2009 12:59:18 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RJlrW7022407 for ; Tue, 27 Oct 2009 20:47:53 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RJlrAJ015438 for ietf-provreg-outgoing; Tue, 27 Oct 2009 20:47:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RJlrHP002192 for ; Tue, 27 Oct 2009 20:47:53 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3D18F2FE8CDC; Tue, 27 Oct 2009 19:47:51 +0000 (UTC) Date: Tue, 27 Oct 2009 15:47:48 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Cc: heland@afilias.info Subject: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027194746.GE60934@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se, heland@afilias.info MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear colleagues, I have of late observed a couple possibly pointy corners in RFC 4310, and Howard Eland just pointed out to me a pretty big operational problem in it, so I am wondering whether anyone is working on updates to it. If not, Howard and I will prepare a -00 with some suggestions, and solicit feedback. If so, please let us know about it so that we can offer our contribution. Thanks and best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 13:32:10 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD423A69C1 for ; Tue, 27 Oct 2009 13:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX9Gz6cclJIL for ; Tue, 27 Oct 2009 13:32:09 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 893743A69BC for ; Tue, 27 Oct 2009 13:32:09 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKGptH000849 for ; Tue, 27 Oct 2009 21:16:51 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKGpkg022481 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:16:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKGooR014908 for ; Tue, 27 Oct 2009 21:16:50 +0100 (MET) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id n9RKGoFC010467; Tue, 27 Oct 2009 21:16:50 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id n9RKGnWk010466; Tue, 27 Oct 2009 21:16:49 +0100 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Tue, 27 Oct 2009 21:16:49 +0100 From: Patrick Mevzek To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027201649.GF5590@home.patoche.org> References: <20091027194746.GE60934@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091027194746.GE60934@shinkuro.com> Organization: Dot And Co User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Tue, 27 Oct 2009 21:16:50 +0100 (CET) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hello Andrew, Andrew Sullivan 2009-10-27 21:05 > I have of late observed a couple possibly pointy corners in RFC 4310, > and Howard Eland just pointed out to me a pretty big operational > problem in it, so I am wondering whether anyone is working on updates > to it. I'm not specifically working on it, but I would advise anyone dealing with DNSSEC and EPP to have a look at what .CZ did and what .EU will do soon, as they both created other extensions to handle DNSSEC with EPP. Maybe other registries too. Sorry if you did that already. I'm not judging pro or in favor of any other extension, but I believe that having a look at the currently deployed EPP dealings with DNSSEC would be a good idea in light of future work on 4310. Hope that helps. -- Patrick Mevzek Dot and Co -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 13:45:28 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8BF3A6998 for ; Tue, 27 Oct 2009 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[AWL=-3.508, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNIssgykVT4C for ; Tue, 27 Oct 2009 13:45:28 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id C88093A6873 for ; Tue, 27 Oct 2009 13:45:27 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKVFVs017739 for ; Tue, 27 Oct 2009 21:31:15 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKVFKw004321 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:31:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKVECM007080 for ; Tue, 27 Oct 2009 21:31:14 +0100 (MET) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ/15kqrR7Ht/2dsb2JhbADBWZhThD8E X-IronPort-AV: E=Sophos;i="4.44,634,1249257600"; d="scan'208";a="262332875" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 20:31:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RKVCPq000369; Tue, 27 Oct 2009 20:31:12 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 21:31:12 +0100 Received: from [192.165.72.14] ([10.61.106.66]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 21:31:11 +0100 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20091027201649.GF5590@home.patoche.org> Date: Tue, 27 Oct 2009 21:31:10 +0100 Cc: ietf-provreg@cafax.se Content-Transfer-Encoding: 7bit Message-Id: <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> To: Patrick Mevzek X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 27 Oct 2009 20:31:11.0697 (UTC) FILETIME=[6C20EC10:01CA5744] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16974.000 X-TM-AS-Result: No--8.386800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 27 okt 2009, at 21.16, Patrick Mevzek wrote: > Andrew Sullivan 2009-10-27 21:05 >> I have of late observed a couple possibly pointy corners in RFC 4310, >> and Howard Eland just pointed out to me a pretty big operational >> problem in it, so I am wondering whether anyone is working on updates >> to it. > > I'm not specifically working on it, but I would advise anyone dealing > with DNSSEC and EPP to have a look at what .CZ did and what .EU will > do soon, as they both created other extensions to handle DNSSEC with > EPP. Maybe other registries too. Sorry if you did that already. > > I'm not judging pro or in favor of any other extension, > but I believe that having a look at the currently deployed EPP > dealings with DNSSEC would be a good idea in light of future work on > 4310. We use epp and DNSSEC in .SE since a while back. What are the issues you think? Patrik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 14:05:19 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099033A68C3 for ; Tue, 27 Oct 2009 14:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=1.363, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydU75DoDbV6g for ; Tue, 27 Oct 2009 14:05:18 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 1714A3A680F for ; Tue, 27 Oct 2009 14:05:17 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuwho006767 for ; Tue, 27 Oct 2009 21:56:58 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKuwPk026597 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:56:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuvDX025370 for ; Tue, 27 Oct 2009 21:56:57 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F3E132FE8CDC for ; Tue, 27 Oct 2009 20:56:55 +0000 (UTC) Date: Tue, 27 Oct 2009 16:56:52 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027205651.GB61322@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091027201649.GF5590@home.patoche.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Oct 27, 2009 at 09:16:49PM +0100, Patrick Mevzek wrote: > I'm not specifically working on it, but I would advise anyone dealing > with DNSSEC and EPP to have a look at what .CZ did and what .EU will > do soon, as they both created other extensions to handle DNSSEC with > EPP. Maybe other registries too. Sorry if you did that already. I haven't done anything yet, happily :) I was figuring that the .CZ and .EU (and .SE) experiences would have to inform the work. See my other message in this thread for a big issue, though. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 14:11:14 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5C428C18D for ; Tue, 27 Oct 2009 14:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ehIY0muVRkC for ; Tue, 27 Oct 2009 14:11:14 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id AAEE428C18C for ; Tue, 27 Oct 2009 14:11:13 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuMsq014221 for ; Tue, 27 Oct 2009 21:56:22 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKuMDg020328 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:56:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuLrS023056 for ; Tue, 27 Oct 2009 21:56:21 +0100 (MET) Message-Id: <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> From: Howard Eland To: ietf-provreg@cafax.se In-Reply-To: <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Tue, 27 Oct 2009 15:56:18 -0500 References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> X-Mailer: Apple Mail (2.936) X-Authenticated: True Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RKuMrS016488 Sender: owner-ietf-provreg@cafax.se Precedence: bulk The issue I brought up to Andrew involves the transform commands. These only require the key tag to perform tasks such as remove, but, as mentioned in 4034, the key tag by itself may not be unique. We are seeing much interest in multiple DS records that have the same key tag with different digest types from registrants. If multiple DS records are added to the registry with the same key tag, and a subsequent transform command is sent with only the key tag, as specified in 4310, the result is left to interpretation. Possible solutions for this are: 1) Force the specification of for all transform commands (this requires the protocol change to 4310, and is where I'm headed). 2) Proceed to transform all DS records with this key tag in the same manner (but here too are dragons, as a change or update could result in either duplicate DS records, or would force the registry to remove the dups, causing a discrepancy between the registrar and the registry). 3) Do not allow multiple DS records with the same key tag (forcing key tags to be unique on the domain object - this seems like a non-starter to me). 4) Do not allow multiple DS records (also a non-starter). Thoughts? -Howard On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote: > > On 27 okt 2009, at 21.16, Patrick Mevzek wrote: > >> Andrew Sullivan 2009-10-27 21:05 >>> I have of late observed a couple possibly pointy corners in RFC >>> 4310, >>> and Howard Eland just pointed out to me a pretty big operational >>> problem in it, so I am wondering whether anyone is working on >>> updates >>> to it. >> >> I'm not specifically working on it, but I would advise anyone dealing >> with DNSSEC and EPP to have a look at what .CZ did and what .EU will >> do soon, as they both created other extensions to handle DNSSEC with >> EPP. Maybe other registries too. Sorry if you did that already. >> >> I'm not judging pro or in favor of any other extension, >> but I believe that having a look at the currently deployed EPP >> dealings with DNSSEC would be a good idea in light of future work on >> 4310. > > We use epp and DNSSEC in .SE since a while back. What are the issues > you think? > > Patrik > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > List run by majordomo software. For (Un-)subscription and similar > details > send "help" to ietf-provreg-request@cafax.se > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 14:16:42 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D806C3A67ED for ; Tue, 27 Oct 2009 14:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLAKfqfbnmXU for ; Tue, 27 Oct 2009 14:16:42 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id C6F4D3A6800 for ; Tue, 27 Oct 2009 14:16:41 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RL2XCZ006375 for ; Tue, 27 Oct 2009 22:02:33 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RL2WuQ006276 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:02:32 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RL2W9Z026320 for ; Tue, 27 Oct 2009 22:02:32 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DC97B2FE8CDC for ; Tue, 27 Oct 2009 21:02:30 +0000 (UTC) Date: Tue, 27 Oct 2009 17:02:27 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027210224.GC61322@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Oct 27, 2009 at 09:31:10PM +0100, Patrik FÃ¤ltstrÃ¶m wrote: > We use epp and DNSSEC in .SE since a while back. What are the issues you > think? Howard pointed out to me that the key tag is what is used to do operations on a DS. That's fine, until you're trying to roll algorithms, because of this happy bit in RFC 4034: The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). One operational model for moving from SHA-1 to SHA-256 is to add a new key using both SHA-1 and SHA-256, and then remove the SHA-1 version after some time. Now, one might want to say, "Don't do that," but I think the document either ought to say that or else specify a way to identify DS records that does not rely on the key tag. Also, of course, if there turned out to be a major problem with one or the other algorithms, one would want a way to yank one of the keys without yanking the other. I haven't completely thought through this, however. The only way I know how really to think through something is to write the text (I'm dim), so I thought I'd ask whether someone is working on text. If so, I could figure out how to add to it, or else I could just write something new. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 14:38:53 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF643A699C for ; Tue, 27 Oct 2009 14:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[AWL=-3.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCSsVskiD64U for ; Tue, 27 Oct 2009 14:38:52 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 7C72A3A680F for ; Tue, 27 Oct 2009 14:38:51 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLNF5G017402 for ; Tue, 27 Oct 2009 22:23:15 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RLNFHr020603 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:23:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLNFj2009954 for ; Tue, 27 Oct 2009 22:23:15 +0100 (MET) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgAAFcB50qQ/uCWe2dsb2JhbACbPwEBFiQGpXmYT4I5ggYE X-IronPort-AV: E=Sophos;i="4.44,635,1249257600"; d="scan'208";a="52922566" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2009 21:23:14 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RLNE1f021235; Tue, 27 Oct 2009 21:23:14 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:23:14 +0100 Received: from [192.165.72.14] ([10.61.106.66]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:23:13 +0100 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20091027210224.GC61322@shinkuro.com> Date: Tue, 27 Oct 2009 22:23:12 +0100 Cc: ietf-provreg@cafax.se Message-Id: References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 27 Oct 2009 21:23:13.0566 (UTC) FILETIME=[B0E853E0:01CA574B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16974.000 X-TM-AS-Result: No--16.625000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RLNFj2015097 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 27 okt 2009, at 22.02, Andrew Sullivan wrote: > On Tue, Oct 27, 2009 at 09:31:10PM +0100, Patrik Fältström wrote: >> We use epp and DNSSEC in .SE since a while back. What are the >> issues you >> think? > > Howard pointed out to me that the key tag is what is used to do > operations on a DS. That's fine, until you're trying to roll > algorithms, because of this happy bit in RFC 4034: > > The key tag is the same for all DNSKEY algorithm types except > algorithm 1 (please see Appendix B.1 for the definition of the key > tag for algorithm 1). Correct, the key tag is the (only) index when you want to do operations. Hmm...have not thought about having multiple keys with same key tag. Yeah, also just saw this in 4034: > The key tag is used to help select DNSKEY resource records > efficiently, but it does not uniquely identify a single DNSKEY > resource record. It is possible for two distinct DNSKEY RRs to have > the same owner name, the same algorithm type, and the same key tag. > An implementation that uses only the key tag to select a DNSKEY RR > might select the wrong public key in some circumstances. Please see > Appendix B for further details. Who the heck came up with this? ;-) Changing this in epp will not be simple. There are tons of deployed things out there (i.e. if we change to {keytag, algorithm} instead of just {keytag}). The text above from 4034 do though say: > It is possible for two distinct DNSKEY RRs to have > the same owner name, the same algorithm type, and the same key tag. That is _not_ fun. Only possible path forward is to always: 1. Remove all keys (in .SE we use keytag=0 to remove all keys) 2. Add the keys again But there is a risk you have the zone with no keys then. Aaaarrgghhhh! Patrik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 14:40:10 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898353A680F for ; Tue, 27 Oct 2009 14:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2PSyvdAfTz1 for ; Tue, 27 Oct 2009 14:40:09 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id E21103A6781 for ; Tue, 27 Oct 2009 14:40:08 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLVdaN016114 for ; Tue, 27 Oct 2009 22:31:39 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RLVdqu017330 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:31:39 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLVcTM027518 for ; Tue, 27 Oct 2009 22:31:38 +0100 (MET) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9RLT7PY006495; Tue, 27 Oct 2009 17:29:07 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 17:31:16 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Oct 2009 21:31:15 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 17:31:12 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Howard Eland , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpXTM4TxOJVIoGD1kO325HeY8AlsA== In-Reply-To: <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 27 Oct 2009 21:31:16.0591 (UTC) FILETIME=[D0D017F0:01CA574C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RLVdTM028128 Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'm glad that this thread has come up, since I too was going to propose something similar to option 1 but with making the specification change backward compatible. We are implementing to 4310 for .com, .net, and .edu with no additional extensions. We see the issue with use of just the keyTag, since it is derived and is not unique. There are use cases where for the same key, which means the same keyTag, there could be multiple digest types and algorithms. My proposal is to add optional attributes (alg, digestType, and digest) to the element of and to add verbiage for the registries to match the DS record for the delete based on all of the passed information. If there is more than one matching DS record for the input, than an error must be returned. The following is what I would propose for the XML schema change: Original XML schema: Updated XML schema: An example of the resulting secDNS:rem for deleting two DS records with the same keyTag value but with a different algorithm, digestType, and digest is below: 12345 12345 One additional proposed change is to clarify the use of the to state something like ³is used to replace all existing DS information with new DS information². The information associated with the specified keyTag¹s is not the only information changed, since the interpretation is that the elements provided with the is a wholesale replacement of the all of the existing dsData information. Have any of the registries interpreted the in a different way? -- JG ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. > From: Howard Eland > Date: Tue, 27 Oct 2009 15:56:18 -0500 > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > > The issue I brought up to Andrew involves the transform commands. > These only require the key tag to perform tasks such as remove, but, > as mentioned in 4034, the key tag by itself may not be unique. We are > seeing much interest in multiple DS records that have the same key tag > with different digest types from registrants. If multiple DS records > are added to the registry with the same key tag, and a subsequent > transform command is sent with only the key tag, as specified in 4310, > the result is left to interpretation. > > Possible solutions for this are: > 1) Force the specification of for all > transform commands (this requires the protocol change to 4310, and is > where I'm headed). > 2) Proceed to transform all DS records with this key tag in the same > manner (but here too are dragons, as a change or update could result > in either duplicate DS records, or would force the registry to remove > the dups, causing a discrepancy between the registrar and the registry). > 3) Do not allow multiple DS records with the same key tag (forcing key > tags to be unique on the domain object - this seems like a non-starter > to me). > 4) Do not allow multiple DS records (also a non-starter). > > Thoughts? > > -Howard > > > On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote: > >> >> On 27 okt 2009, at 21.16, Patrick Mevzek wrote: >> >>> Andrew Sullivan 2009-10-27 21:05 >>>> I have of late observed a couple possibly pointy corners in RFC >>>> 4310, >>>> and Howard Eland just pointed out to me a pretty big operational >>>> problem in it, so I am wondering whether anyone is working on >>>> updates >>>> to it. >>> >>> I'm not specifically working on it, but I would advise anyone dealing >>> with DNSSEC and EPP to have a look at what .CZ did and what .EU will >>> do soon, as they both created other extensions to handle DNSSEC with >>> EPP. Maybe other registries too. Sorry if you did that already. >>> >>> I'm not judging pro or in favor of any other extension, >>> but I believe that having a look at the currently deployed EPP >>> dealings with DNSSEC would be a good idea in light of future work on >>> 4310. >> >> We use epp and DNSSEC in .SE since a while back. What are the issues >> you think? >> >> Patrik >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-=- >> List run by majordomo software. For (Un-)subscription and similar >> details >> send "help" to ietf-provreg-request@cafax.se >> > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > List run by majordomo software. For (Un-)subscription and similar details > send "help" to ietf-provreg-request@cafax.se > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 14:40:22 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4495E3A68B1 for ; Tue, 27 Oct 2009 14:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7V+3HCOchnj for ; Tue, 27 Oct 2009 14:40:21 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 34E8D3A680F for ; Tue, 27 Oct 2009 14:40:21 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLPGjt011843 for ; Tue, 27 Oct 2009 22:25:16 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RLPFek028443 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:25:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLPFf4004091 for ; Tue, 27 Oct 2009 22:25:15 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CF2202FE8CDC for ; Tue, 27 Oct 2009 21:25:13 +0000 (UTC) Date: Tue, 27 Oct 2009 17:25:11 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027212508.GH61322@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Oct 27, 2009 at 10:23:12PM +0100, Patrik FÃ¤ltstrÃ¶m wrote: > Aaaarrgghhhh! Yes. Hence my interest in doing something about this. :-) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 15:46:51 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211C628C0E3 for ; Tue, 27 Oct 2009 15:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-7qduTBSrrr for ; Tue, 27 Oct 2009 15:46:50 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 19E9A28C0D6 for ; Tue, 27 Oct 2009 15:46:49 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RMcdRg008880 for ; Tue, 27 Oct 2009 23:38:39 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RMcdKp005456 for ietf-provreg-outgoing; Tue, 27 Oct 2009 23:38:39 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RMcbur004189 for ; Tue, 27 Oct 2009 23:38:38 +0100 (MET) Received: from [192.168.1.106] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9RMcWTr089936; Tue, 27 Oct 2009 18:38:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> Date: Tue, 27 Oct 2009 18:29:34 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Edward Lewis Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Cc: Andrew Sullivan , ietf-provreg@cafax.se Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RMccur017499 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 22:23 +0100 10/27/09, Patrik Fältström wrote: >Hmm...have not thought about having multiple keys with same key tag. That's probably because dnssec-keygen won't return a key that has the same keytag as another one in it's view. >Yeah, also just saw this in 4034: > >> The key tag is used to help select DNSKEY resource records >> efficiently, but it does not uniquely identify a single DNSKEY >> resource record. It is possible for two distinct DNSKEY RRs to have >> the same owner name, the same algorithm type, and the same key tag. >> An implementation that uses only the key tag to select a DNSKEY RR >> might select the wrong public key in some circumstances. Please see >> Appendix B for further details. > >Who the heck came up with this? ;-) I'll blame Olafur. >That is _not_ fun. Neither is a lot of other stuff in DNS - like round robin, case preservation, etc. It's not fun, but not an obstacle. >Only possible path forward is to always: > >1. Remove all keys (in .SE we use keytag=0 to remove all keys) >2. Add the keys again We could specify the DS record by the key hash in the DS. This is about provisioning the DS after all. If there's gonna be an update to 4310, it has to be out there soon. We haven't gone live, but, we have already implemented RFC 4310 as is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 16:39:51 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE9B3A6957 for ; Tue, 27 Oct 2009 16:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY10Ua0q9qXZ for ; Tue, 27 Oct 2009 16:39:50 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 44ED728C0F8 for ; Tue, 27 Oct 2009 16:39:49 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RNRGsZ023637 for ; Wed, 28 Oct 2009 00:27:16 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RNRGRC021139 for ietf-provreg-outgoing; Wed, 28 Oct 2009 00:27:16 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RNREIP011842 for ; Wed, 28 Oct 2009 00:27:15 +0100 (MET) Message-Id: <402D2C7D-326F-4436-BDD3-7FD7A75B1851@afilias.info> From: Howard Eland To: EPP Provreg In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Tue, 27 Oct 2009 18:27:10 -0500 References: X-Mailer: Apple Mail (2.936) X-Authenticated: True Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RNRFIP015421 Sender: owner-ietf-provreg@cafax.se Precedence: bulk There's a lot of ways to skin this cat. All of them that I can see involve an RFC update (even if it's just for clarification). So, I seem to be hearing "yes, fix this, but hurry up about it". If this is the case, then is there anything else that folks would like to see in 4310-bis? (who has the worm-can opener?) Other comments below. On Oct 27, 2009, at 4:31 PM, James Gould wrote: > I'm glad that this thread has come up, since I too was going to > propose > something similar to option 1 but with making the specification change > backward compatible. We are implementing to 4310 for .com, .net, > and .edu > with no additional extensions. We see the issue with use of just the > keyTag, since it is derived and is not unique. There are use cases > where > for the same key, which means the same keyTag, there could be multiple > digest types and algorithms. My proposal is to add optional > attributes > (alg, digestType, and digest) to the element of > > and to add verbiage for the registries to match the DS record for > the delete > based on all of the passed information. If there is more than one > matching > DS record for the input, than an error must be returned. I'd rather not include the digest itself here, since the tuple uniquely identify the DS record. I'm not sure we have to maintain backwards compatibility, but, assuming we do, an error could be returned anytime multiple DS records are matched, as you suggest, or we could also affect the remove against all records that match those attributes sent in (in other words, the default is to match all for any given attribute). > The following is > what I would propose for the XML schema change: [...] > > One additional proposed change is to clarify the use of the > to > state something like “is used to replace all existing DS information > with > new DS information”. The information associated with the specified > keyTag’s > is not the only information changed, since the interpretation is > that the > elements provided with the is a wholesale > replacement of the all of the existing dsData information. Have any > of the > registries interpreted the in a different way? > To make the most versatile, I'd still like to have the ability to specify the other attributes. That way, it can be used to change one or more DS records, as opposed to having to replicate all DS records to change one. This would make syntax similar to , and would still be backwards compatible: if you don't specify the keyTag or any other attributes, then they all change. -Howard > > -- > > > JG > > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > > > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > Notice to Recipient: This e-mail contains confidential, proprietary > and/or > Registry Sensitive information intended solely for the recipient > and, thus > may not be retransmitted, reproduced or disclosed without the prior > written > consent of VeriSign Naming and Directory Services. If you have > received > this e-mail message in error, please notify the sender immediately by > telephone or reply e-mail and destroy the original message without > making a > copy. Thank you. > > >> From: Howard Eland >> Date: Tue, 27 Oct 2009 15:56:18 -0500 >> To: EPP Provreg >> Subject: Re: [ietf-provreg] Anyone working on 4310-bis? >> >> The issue I brought up to Andrew involves the transform commands. >> These only require the key tag to perform tasks such as remove, but, >> as mentioned in 4034, the key tag by itself may not be unique. We >> are >> seeing much interest in multiple DS records that have the same key >> tag >> with different digest types from registrants. If multiple DS records >> are added to the registry with the same key tag, and a subsequent >> transform command is sent with only the key tag, as specified in >> 4310, >> the result is left to interpretation. >> >> Possible solutions for this are: >> 1) Force the specification of for all >> transform commands (this requires the protocol change to 4310, and is >> where I'm headed). >> 2) Proceed to transform all DS records with this key tag in the same >> manner (but here too are dragons, as a change or update could result >> in either duplicate DS records, or would force the registry to remove >> the dups, causing a discrepancy between the registrar and the >> registry). >> 3) Do not allow multiple DS records with the same key tag (forcing >> key >> tags to be unique on the domain object - this seems like a non- >> starter >> to me). >> 4) Do not allow multiple DS records (also a non-starter). >> >> Thoughts? >> >> -Howard >> >> >> On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote: >> >>> >>> On 27 okt 2009, at 21.16, Patrick Mevzek wrote: >>> >>>> Andrew Sullivan 2009-10-27 21:05 >>>>> I have of late observed a couple possibly pointy corners in RFC >>>>> 4310, >>>>> and Howard Eland just pointed out to me a pretty big operational >>>>> problem in it, so I am wondering whether anyone is working on >>>>> updates >>>>> to it. >>>> >>>> I'm not specifically working on it, but I would advise anyone >>>> dealing >>>> with DNSSEC and EPP to have a look at what .CZ did and what .EU >>>> will >>>> do soon, as they both created other extensions to handle DNSSEC >>>> with >>>> EPP. Maybe other registries too. Sorry if you did that already. >>>> >>>> I'm not judging pro or in favor of any other extension, >>>> but I believe that having a look at the currently deployed EPP >>>> dealings with DNSSEC would be a good idea in light of future work >>>> on >>>> 4310. >>> >>> We use epp and DNSSEC in .SE since a while back. What are the issues >>> you think? >>> >>> Patrik >>> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> =- >>> =-=-=- >>> List run by majordomo software. For (Un-)subscription and similar >>> details >>> send "help" to ietf-provreg-request@cafax.se >>> >> >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-=-=- >> List run by majordomo software. For (Un-)subscription and similar >> details >> send "help" to ietf-provreg-request@cafax.se >> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 17:49:54 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB06F28C17B for ; Tue, 27 Oct 2009 17:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-z1dENmN2Sv for ; Tue, 27 Oct 2009 17:49:54 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id DCF8628C168 for ; Tue, 27 Oct 2009 17:49:53 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S0aNwA015775 for ; Wed, 28 Oct 2009 01:36:23 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9S0aNdN008060 for ietf-provreg-outgoing; Wed, 28 Oct 2009 01:36:23 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S0aMBk012197 for ; Wed, 28 Oct 2009 01:36:22 +0100 (MET) Received: from 121-160-185-235.icannmeeting.org (121-160-185-235.icannmeeting.org [121.160.185.235] (may be forged)) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id n9S0EgN4090162; Tue, 27 Oct 2009 19:14:42 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4AE79202.1040104@nic-naa.net> Date: Wed, 28 Oct 2009 09:36:18 +0900 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Andrew Sullivan , ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk > But there is a risk you have the zone with no keys then. How surprising! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Tue Oct 27 19:26:03 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2F93A6A92 for ; Tue, 27 Oct 2009 19:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pVjAtPUNtL3 for ; Tue, 27 Oct 2009 19:26:02 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 0071F3A6827 for ; Tue, 27 Oct 2009 19:26:01 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S2CGpb009235 for ; Wed, 28 Oct 2009 03:12:16 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9S2CGvL002237 for ietf-provreg-outgoing; Wed, 28 Oct 2009 03:12:16 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S2CFHs015717 for ; Wed, 28 Oct 2009 03:12:15 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 3A2A84B0; Wed, 28 Oct 2009 03:12:15 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id ShxkAGBafe7y; Wed, 28 Oct 2009 03:12:09 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 68BCD1449; Wed, 28 Oct 2009 00:25:10 +0100 (MEZ) Received: from [127.0.0.1] (klaus@localhost [127.0.0.1]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id n9RNP8ST020920; Wed, 28 Oct 2009 00:25:09 +0100 (MEZ) Message-ID: <4AE78154.9060304@knipp.de> Date: Wed, 28 Oct 2009 00:25:08 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091019 Shredder/3.0pre MIME-Version: 1.0 To: Howard Eland CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> In-Reply-To: <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 2009-10-27 21:56, Howard Eland wrote: > The issue I brought up to Andrew involves the transform commands. These > only require the key tag to perform tasks such as remove, but, as > mentioned in 4034, the key tag by itself may not be unique. We are > seeing much interest in multiple DS records that have the same key tag > with different digest types from registrants. If multiple DS records are > added to the registry with the same key tag, and a subsequent transform > command is sent with only the key tag, as specified in 4310, the result > is left to interpretation. > > Possible solutions for this are: > 1) Force the specification of for all > transform commands (this requires the protocol change to 4310, and is > where I'm headed). > 2) Proceed to transform all DS records with this key tag in the same > manner (but here too are dragons, as a change or update could result in > either duplicate DS records, or would force the registry to remove the > dups, causing a discrepancy between the registrar and the registry). > 3) Do not allow multiple DS records with the same key tag (forcing key > tags to be unique on the domain object - this seems like a non-starter > to me). > 4) Do not allow multiple DS records (also a non-starter). > > Thoughts? > > -Howard > Hi all, interestingly, I pointed out the problem of RFC 4310 regarding multiple DNSKEY records having the same key tag about four years ago. This was not seen as a problem at that time, I was told that the user should just generate a new key pair to avoid the tag clash. Nobody (including myself) saw the problem of the need for multiple DS with different digest types for the very same DNSKEY record. Never mind. I think RFC 4310 is still usable despite the drawbacks, and its use is probably better than reinventing the wheel. If the registrar chooses the option in the , he can simply submit the desired DS records, even if there are multiple entries with the same key tag. For our implementation within the puntCAT registry, some basic testing is done, however: No two entries may exist with the same key tag and digest type. Also, algorithms must indicate the same key type (RSA vs. DSA). But if the registrars have problems with it, we might relax even this test. For the element, a similar test is done on the resulting set of DS records. The element simply deletes all entries having the specified key tag(s), whether there are multiple entries per key tag or not. This may make the element useless, but this is IMHO the only choice. Besides the problem above, I also dislike the following in RFC 4310: - the element is asymmetric to the element in the base protocol and other extensions in so far that a element exists and that the and elements are mutually exclusive. - the submission of the key data is somewhat questionable. The only use is to verify the given DS data, which we do in our implementation. Regards, Klaus -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Wed Oct 28 02:37:35 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E2E3A6956 for ; Wed, 28 Oct 2009 02:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=-3.687, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K52zft6+w70N for ; Wed, 28 Oct 2009 02:37:34 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 62DB33A693D for ; Wed, 28 Oct 2009 02:37:34 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S9RCiQ014732 for ; Wed, 28 Oct 2009 10:27:12 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9S9RCvt008620 for ietf-provreg-outgoing; Wed, 28 Oct 2009 10:27:12 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S9RBKm023181 for ; Wed, 28 Oct 2009 10:27:11 +0100 (MET) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcAAEOr50qQ/uCWe2dsb2JhbABCmmQcAQEWJAalPphIhD8E X-IronPort-AV: E=Sophos;i="4.44,638,1249257600"; d="scan'208";a="52958742" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 09:27:11 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9S9RAPD022821; Wed, 28 Oct 2009 09:27:11 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:27:10 +0100 Received: from 95.209.82.236.bredband.tre.se ([10.55.87.216]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:27:09 +0100 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 28 Oct 2009 06:11:56 +0100 Cc: Howard Eland , EPP Provreg Content-Transfer-Encoding: 7bit Message-Id: <907ABD87-2140-429A-80A8-56624A92D579@cisco.com> References: To: James Gould X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 28 Oct 2009 09:27:09.0903 (UTC) FILETIME=[D2FB5DF0:01CA57B0] Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 27 okt 2009, at 22.31, James Gould wrote: > My proposal is to add optional attributes > (alg, digestType, and digest) to the element of > > and to add verbiage for the registries to match the DS record for > the delete > based on all of the passed information. If there is more than one > matching > DS record for the input, than an error must be returned. I like this, specifically with the keyword "optional". That way, it would be backward compatible with deployed implementations (on the client side), and roll out of the new mechanism is as smooth as possible. Patrik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Wed Oct 28 05:02:21 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD8D3A6982 for ; Wed, 28 Oct 2009 05:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3YzdalDR1KF for ; Wed, 28 Oct 2009 05:02:20 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 031383A697D for ; Wed, 28 Oct 2009 05:02:19 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SBk0vS012278 for ; Wed, 28 Oct 2009 12:46:00 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9SBk058000628 for ietf-provreg-outgoing; Wed, 28 Oct 2009 12:46:00 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SBjxOP004015 for ; Wed, 28 Oct 2009 12:45:59 +0100 (MET) Received: (qmail 13762 invoked from network); 28 Oct 2009 11:45:58 +0000 Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Oct 2009 11:45:58 +0000 Message-ID: <4AE82EF2.1000802@publisher.de> Date: Wed, 28 Oct 2009 12:45:54 +0100 From: Ulrich Wisser User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <907ABD87-2140-429A-80A8-56624A92D579@cisco.com> In-Reply-To: <907ABD87-2140-429A-80A8-56624A92D579@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9SBjxOP011828 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Here at .SE we implemented 4310. As pointed out earlier there is potential for further development. ;) The first problem is the update tag as it doesn't allow add and rem in the same command. This definition could be changed (with backwards compatibility) from to . The bigger problem is the secDNS:rem tag. As pointed out additional information (alg, digestType) is needed. At .SE we use SHA-1 and SHA-256 by default for all keys. Try "dig @a.ns.se dnssec.se DS" for example. In the past months I have seen many registrars struggle with the rem tag because it works fundamentally different from the rest of EPP. I would propose several solutions: A. totally backward compatible Add optional attributes to the secDNS:keyTag tag. But this would mean that alg and digesttype are attributes to keytag which isn't really the case. Backward compatible but not a clean solution. B. Not backward compatible Revamp the whole rem tag and insert a new grouping like This would make the whole thing work more like the rest of EPP. And while we are at it I would like to propose another change: The add command (as well as update) uses the secDNS:dsDataType. Which makes keytag, alg, digestType and digest mandatory. I know that .SE and other registries considered to become a "fat" registry and take in the public keys instead of the ds records. The DS records would be computed from the public keys according to registry policies. This case is not covered by 4310. Kind Regards Ulrich -- Ulrich Wisser senior developer .SE (The Internet Infrastructure Foundation) PO Box 7399, SE-103 91 Stockholm, Sweden Visits: Ringvägen 100 A Switchboard: +46(0)8-452 35 00 Direct: +46(0)8-452 35 58 Mobile: +46(0)732-74 59 00 E-mail: ulrich.wisser@iis.se Website: http://www.iis.se -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Wed Oct 28 07:48:28 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A8D28C18F for ; Wed, 28 Oct 2009 07:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=-1.699, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OreKg-z7hi2M for ; Wed, 28 Oct 2009 07:48:21 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 9563328C143 for ; Wed, 28 Oct 2009 07:48:20 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SEWu4D028340 for ; Wed, 28 Oct 2009 15:32:56 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9SEWuac027070 for ietf-provreg-outgoing; Wed, 28 Oct 2009 15:32:56 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SEWslV029560 for ; Wed, 28 Oct 2009 15:32:55 +0100 (MET) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n9SEGlCo022252; Wed, 28 Oct 2009 10:16:47 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:32:33 +0000 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Oct 2009 14:32:32 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 10:32:19 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Klaus Malorny CC: Howard Eland , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpXdmo7oON9R0tNTQWVOMZiBb5l4QAZQnRD In-Reply-To: <4AE7845A.7010305@knipp.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339570744_3019602" X-OriginalArrivalTime: 28 Oct 2009 14:32:33.0023 (UTC) FILETIME=[7C6998F0:01CA57DB] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339570744_3019602 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Klaus, Your proposal will work with one small fix of replacing in remType to . This will be backward compatible, will address the issue of identifying the DS record to remove, and will support adding and removing more than one DS record in the same command. I like that the chg still behaves like a replace, which again is backward compatible. The only difference is that all four elements need to be provided (keyTag, alg, digestType, digest) with a rem, which I don=B9t believe should be a big issue= . Does anyone see an issue with having to specify either the keyTag or all four elements on a rem? The following is the schema elements with the smal= l fix that I tested through with various use cases successfully. The following tests worked and passed schema validation: * Passing a single add, chg, or rem with the rem containing just the keyTag= . This is the backward compatible tests. * Passing multiple dsData elements for both the add and rem elements * Passing multiple keyTag or dsData elements with the rem element --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Klaus Malorny Date: Tue, 27 Oct 2009 19:38:02 -0400 To: James Gould Cc: Howard Eland , EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? On 2009-10-27 22:31, James Gould wrote: > [...] > > Updated XML schema: > > > > > > > > > > > > > maxOccurs=3D"unbounded"/> > > > > [...] Hi James, instead of adding attributes, one could declare the content of the element to be a choice between the element and the element, with unbounded repetition, e.g. Also, I propose a change to allow both and to occur in the same request, i.e. something like this (may be formally incorrect, haven't checked the syntax): Regards, Klaus --B_3339570744_3019602 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? Klaus,

Your proposal will work with one small fix of replacing </sequence> i= n remType to </choice>. This will be backward compatible,= will address the issue of identifying the DS record to remove, and wi= ll support adding and removing more than one DS record in the same command. = I like that the chg still behaves like a replace, which again is backw= ard compatible. The only difference is that all four elements need to = be provided (keyTag, alg, digestType, digest) with a rem, which I don’= t believe should be a big issue. Does anyone see an issue with having = to specify either the keyTag or all four elements on a rem? The follow= ing is the schema elements with the small fix that I tested through with var= ious use cases successfully.

<complexType name=3D"updateType"> <choice> <element name=3D&qu= ot;chg" type=3D"secDNS:dsType"/> <sequence> <elem= ent name=3D"add" type=3D"secDNS:dsType" minOccurs=3D"0&qu= ot;/> <elem= ent name=3D"rem" type=3D"secDNS:remType" minOccurs=3D"0&q= uot;/> </sequence> </choice> <attribute name=3D"urgent&= quot; type=3D"boolean" default=3D"false"/> </complexType> <complexType name=3D"remType"> <choice maxOccurs=3D"unbou= nded"> <element name=3D&qu= ot;keyTag" type=3D"unsignedShort"/> <element name=3D&qu= ot;dsData" type=3D"secDNS:dsDataType"/> </choice> </complexType>

The following tests worked and passed schema validation:

Passing a single add, chg, or rem with the rem conta= ining just the keyTag. This is the backward compatible tests.
Passing multiple dsData elements for both the add = and rem elements
Passing multiple keyTag or dsData elements with the rem = element

From: Howard Eland <heland@afilias.info>
Date: Thu, 29 Oct 2009 13:05:57 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

One thing that does make using all four elements easier: it's
consistent with both the add and chg operators, which may make it
easier for implementors to code (well, a tiny bit, anyway). James, I'm not sure if this is to your point or not.

Codifying the edge cases is important, however, and it appears that
we'll have to lose some of this compatibility to do so (regardless if
we use just the hash on the rem, or the entire dsData). By requiring =
anything other than just the keyTag itself, it will not be backwards
compatible for implementors - today, the keytag submission is
sufficient, tomorrow, it will not be (going strictly by the RFC, not
by registry policy).

I am no longer particular to either method - they both would be fine.

-Howard

On Oct 29, 2009, at 10:57 AM, Howard Eland wrote:

> This is what I was saying. The digest is unique (specially when =
> we're talking across only the same keytag), so the rest of the
> information is superfluous.
>
> -Howard
>
> On Oct 29, 2009, at 10:32 AM, Andrew Sullivan wrote:
>
>> On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote:
>>
>>> still behaves like a replace, which again is backward compatib= le.
>>> The only
>>> difference is that all four elements need to be provided (keyT= ag,
>>> alg,
>>> digestType, digest) with a rem, which I don’t believe sh= ould be a
>>> big issue.
>>> Does anyone see an issue with having to specify either the key= Tag
>>> or all
>>> four elements on a rem?
>>
>> Can you say why you prefer to use all four elements instead of jus= t
>> the digest? The digest actually is unique, so adding the oth= er
>> elements doesn't make it easier, I don't think, does it?
>>
>> A
>>
>>
>> --
>> Andrew Sullivan
>> ajs@shinkuro.com
>> Shinkuro, Inc.
>> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -
>> =3D-=3D-=3D-=3D-
>> List run by majordomo software. For (Un-)subscription and si= milar
>> details
>> send "help" to i= etf-provreg-request@cafax.se
>>
>
>
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-<= BR> > =3D-=3D-=3D-
> List run by majordomo software. For (Un-)subscription and simila= r
> details
> send "help" to ietf-= provreg-request@cafax.se
>

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
List run by majordomo software. For (Un-)subscription and similar det= ails
send "help" to ietf-provr= eg-request@cafax.se

--B_3339676348_6418696-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 04:54:07 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FD93A68F7 for ; Fri, 30 Oct 2009 04:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQj0NCakVtI5 for ; Fri, 30 Oct 2009 04:54:04 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 6C2823A68A8 for ; Fri, 30 Oct 2009 04:54:04 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UBdFiM011347 for ; Fri, 30 Oct 2009 12:39:15 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UBdFIw024491 for ietf-provreg-outgoing; Fri, 30 Oct 2009 12:39:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UBdEmQ017017 for ; Fri, 30 Oct 2009 12:39:14 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id F311FFB; Fri, 30 Oct 2009 12:39:07 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id uJV8aT6EQW5O; Fri, 30 Oct 2009 12:39:02 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 75A8EFA; Fri, 30 Oct 2009 12:39:02 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id n9UBd2UJ020632; Fri, 30 Oct 2009 12:39:02 +0100 (MEZ) Message-ID: <4AEAD054.5030503@knipp.de> Date: Fri, 30 Oct 2009 12:39:00 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5pre) Gecko/20091029 Shredder/3.0pre MIME-Version: 1.0 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi all, trying to catch up on the e-mails of yesterday, I'd like to summarize the state of the discussion as far as I understand: 1) it is a little bit unclear to me whether we still want to create an update of RFC 4310 that is fully backward compatible, XML-wise and mostly semantically. 2) there is a consensus that and elements shall be allowed in a single request, which must be on the other hand mutually exclusive to the element. 3) there is a consensus that as of RFC 4310, the is a replace-all operation, i.e. all existing DS records are removed completely and independently from the data provided and the provided DS records are added. 4) there is a disagreement of how to interpret a 1234 in the case that multiple DS records with this key tag have been provisioned earlier. One choice is to reject the operation, the other is to remove all DS records matching the key tag. There is a third choice of removing the the element at all. 5) there is a disagreement of how to repair the element. One choice is to use the existing "dsDataType", with the semantics that it must match exactly an existing DS record, otherwise the request will fail (questionable though what an exact match is). The other choice is to create a separate "selectType" datatype which contains optional elements only. All existing DS records are tested against the respective element. If a key tag, algorithm, digest type or digest has been specified, the respective component must match, otherwise the DS record is retained. While easy to define, still unknown what happens if no DS records match or a DS record matches multiple "selectType" instances. 6) if we break backward compatibility, the element can be revisited. It is unclear to me whether registries exist that would prefer to have the key data *instead* of the DS data and not *in addition*. Please feel free to correct me if I misunderstood something. ------- Now my further comments: * If we break compatibility, then we should consider removing either / or for the sake of symmetry to the base EPP standards and extensions. As far as I understand the Scott Hollenbeck's design pattern, there is *either* a replace-all/change strategy *or* an add/remove strategy on a certain data element. For example, the registrant contact adheres the "change" strategy, while the other contacts adhere an add/remove strategy. RFC 4310 breaks it. * I am a little bit undetermined regarding the "selectType" approach. While it is a nice idea, it is also some kind of novelty in the EPP world. As far as I can remember, always the same datatype has been used for both the removal and addition. Of course, not in all cases all data fields have been used for comparison. For example, I assume no registry implementation will check the human readable text and the language for a removal of a status value, while it is possible to specify it. Also, I don't see that much the use cases. IMHO the most frequent use will be the KSK rollover, and for that purpose, this flexibility is not required. * regarding 4), the element, I think the least trouble is to allow the removal of multiple DS records, but still rejecting the request, if no DS record is found at all. Regards, Klaus -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 07:53:48 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC00D3A68E6 for ; Fri, 30 Oct 2009 07:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob8fsvUlee25 for ; Fri, 30 Oct 2009 07:53:48 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id ADEBA3A67AB for ; Fri, 30 Oct 2009 07:53:47 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UEdoRA020850 for ; Fri, 30 Oct 2009 15:39:50 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UEdo98006988 for ietf-provreg-outgoing; Fri, 30 Oct 2009 15:39:50 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UEdmXo016367 for ; Fri, 30 Oct 2009 15:39:49 +0100 (MET) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1022E2FE8CDC for ; Fri, 30 Oct 2009 14:39:48 +0000 (UTC) Date: Fri, 30 Oct 2009 10:39:46 -0400 From: Andrew Sullivan To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091030143945.GE76006@shinkuro.com> Mail-Followup-To: Andrew Sullivan , EPP Provreg References: <4AEAD054.5030503@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AEAD054.5030503@knipp.de> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > 1) it is a little bit unclear to me whether we still want to create an > update of RFC 4310 that is fully backward compatible, XML-wise and mostly > semantically. My impression was that we _do_ need at least an update that allows old clients to continue to work, and will allow new clients to work with old servers. I haven't figured out whether it's possible to make the necessary schema changes and still be technically backward compatible, though I'm leaning toward "no". That will mean a bump in the schema version. Such a bump would be an even stronger reason to make it operationally backward compatible. I attach a -00 version as a scratch proposal. The draft submission window is closed due to the upcoming Hiroshima meeting, so I'm posting it here. Anyway, this doubtlessly needs changes before really being submitted. > 2) there is a consensus that and elements shall be allowed in > a single request, which must be on the other hand mutually exclusive to > the element. Are we sure that the and elements have to be processed in the order in which they appear? I am not completely sure. I recall at least one operator who had an issue related to this processing-order question. If they do _not_ have to be so processed, then in fact they can't be allowed in a single request because the effect could be different from what is intended. (Note that this remark also means that there is by no means a consensus on this matter yet.) RFC5731 says, "Commands are processed by a server in the order they are received from a client." But in this case these aren't actually different commands, and I have so far been unable to convince myself that a server operator has to process the elements of one command in the order in which those elements appear. If someone knows otherwise (and I would be very much pleased to have such proof), I'd like to hear it. But as things stand, my reading is that a server operator could handle all the elements first, and all the elements second, and the effect of that could be quite different than what we're trying to achieve. > 4) there is a disagreement of how to interpret a > 1234 in the case that multiple DS records > with this key tag have been provisioned earlier. One choice is to reject > the operation, the other is to remove all DS records matching the key > tag. There is a third choice of removing the the element at all. I have candidate text for this now. In order to make this backward compatible, one has to accept it in the protocol. I have written the text so that by registry policy, sich an operation can nevertheless be rejected. > 5) there is a disagreement of how to repair the element. One choice > is to use the existing "dsDataType", with the semantics that it must > match exactly an existing DS record, otherwise the request will fail > (questionable though what an exact match is). The other choice is to > create a separate "selectType" datatype which contains optional elements > only. All existing DS records are tested against the respective element. Not elements, but attributes, is the way I've got it at the moment. I didn't include the attributes other than the hash in the text as it's written, but I think James has convinced me there'd be no harm in adding the other ones. Comments are welcome. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 08:25:48 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620563A6955 for ; Fri, 30 Oct 2009 08:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9WpdWf6raao for ; Fri, 30 Oct 2009 08:25:38 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 8B1293A67AB for ; Fri, 30 Oct 2009 08:25:37 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UF8MuZ001985 for ; Fri, 30 Oct 2009 16:08:22 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UF8Mhv008694 for ietf-provreg-outgoing; Fri, 30 Oct 2009 16:08:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UF8LPY027409 for ; Fri, 30 Oct 2009 16:08:21 +0100 (MET) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n9UEqUa3005213; Fri, 30 Oct 2009 10:52:30 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 11:08:20 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 Oct 2009 15:08:20 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 11:08:16 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Klaus Malorny , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpZWUVDgZeBOF6kT6uG51N1zOsZswAGYlIa In-Reply-To: <4AEAD054.5030503@knipp.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339745698_7158825" X-OriginalArrivalTime: 30 Oct 2009 15:08:20.0303 (UTC) FILETIME=[D11E05F0:01CA5972] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339745698_7158825 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Klaus, Thanks for the summary of the topic. I personally liked the schema updates that you had proposed with the added text around returning an error for use of the existing method when more than one DS record matches and clarity around the use of the , so my responses are pretty much in line with that proposal below. --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Klaus Malorny Date: Fri, 30 Oct 2009 07:39:00 -0400 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Hi all, trying to catch up on the e-mails of yesterday, I'd like to summarize the state of the discussion as far as I understand: 1) it is a little bit unclear to me whether we still want to create an update of RFC 4310 that is fully backward compatible, XML-wise and mostly semantically. 2) there is a consensus that and elements shall be allowed in a single request, which must be on the other hand mutually exclusive to the element. I agree the and should be allowed at the same time. This makes it consistent with the other EPP RFC=B9s. If and were supported at the same time, if we could uniquely identify each DS record, and if we weren=B9t worried about backward compatibility, then the option could b= e removed. =20 3) there is a consensus that as of RFC 4310, the is a replace-all operation, i.e. all existing DS records are removed completely and independently from the data provided and the provided DS records are added. In it=B9s current form, for the current specification to work, the need= s to be interpreted as a replace all. Having to split an update with multiple DS across multiple commands, is not a good practice and increases the risk of domains be published in an in-the-middle invalid state. 4) there is a disagreement of how to interpret a 1234 in the case that multiple DS records with this key tag have been provisioned earlier. One choice is to reject the operation, the other is to remove all DS records matching the key tag. There is a thir= d choice of removing the the element at all. I believe that it should be reject if there is a mechanism to uniquely identify a DS record. We are planning on deleting all of the matching DS records with the current specification, which is one of the areas of confusion that I would like to be fixed. EPP should be explicit to what th= e client really wants to do, so I=B9m in favor of rejecting if there is ambiguity and we=B9re supporting the existing form of for backward compatibility. This is at list backward compatibility from an XML schema perspective. =20 5) there is a disagreement of how to repair the element. One choice i= s to use the existing "dsDataType", with the semantics that it must match exactl= y an existing DS record, otherwise the request will fail (questionable though what an exact match is). The other choice is to create a separate "selectType" datatype which contains optional elements only. All existing DS records are tested against the respective element. If a key tag, algorithm, digest type or digest has been specified, the respective component must match, otherwise the DS record is retained. While easy to define, still unknown what happens if no DS records match or a DS record matches multiple "selectType" instances. I prefer just using the dsDataType since there should be no question relate= d to matching the DS. I don=B9t believe that there should be two DS records fo= r a domain with the same four elements (keyTag, alg, digestType, and digest) and the registry should ensure this. There is the very remotely possibilit= y of having more than one DS record with the combination of a subset of the elements. Although I agree the likelihood of duplicate digest values is statistically impossible. I don=B9t see any huge advantage to use a subset o= f the elements since it leaves no ambiguity. Supporting the existing scheme for backward compatibility should return an error when more than one DS records matches if the dsDataType scheme is supported. 6) if we break backward compatibility, the element can be revisited. It is unclear to me whether registries exist that would prefer to have the key data *instead* of the DS data and not *in addition*. We are not planning on supporting the optional element. Please feel free to correct me if I misunderstood something. ------- Now my further comments: * If we break compatibility, then we should consider removing either / or for the sake of symmetry to the base EPP standards and extensions. As far as I understand the Scott Hollenbeck's design pattern, there is *either= * a replace-all/change strategy *or* an add/remove strategy on a certain data element. For example, the registrant contact adheres the "change" strategy, while the other contacts adhere an add/remove strategy. RFC 4310 breaks it. * I am a little bit undetermined regarding the "selectType" approach. While it is a nice idea, it is also some kind of novelty in the EPP world. As far as I can remember, always the same datatype has been used for both the removal and addition. Of course, not in all cases all data fields have been used for comparison. For example, I assume no registry implementation will check the human readable text and the language for a removal of a status value, while it is possible to specify it. Also, I don't see that much the use cases. IMHO the most frequent use will be the KSK rollover, and for that purpose, this flexibility is not required. * regarding 4), the element, I think the least trouble is to allow the removal of multiple DS records, but still rejecting the request, if no DS record is found at all. Regards, Klaus -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se --B_3339745698_7158825 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? Klaus,

Thanks for the summary of the topic. I personally liked the schema up= dates that you had proposed with the added text around returning an error fo= r use of the existing <rem><keyTag> method when more than one DS= record matches and clarity around the use of the <chg>, so my respons= es are pretty much in line with that proposal below.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 07:39:00 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi all,

trying to catch up on the e-mails of yesterday, I'd like to summarize the s= tate
of the discussion as far as I understand:

1) it is a little bit unclear to me whether we still want to create an upda= te of
RFC 4310 that is fully backward compatible, XML-wise and mostly semanticall= y.

2) there is a consensus that <add> and <rem> elements shall be = allowed in a
single request, which must be on the other hand mutually exclusive to the &= lt;chg>
element.

I agree the <add> and <rem> should be allowed at the same time.= This makes it consistent with the other EPP RFC’s. If <= ;add> and <rem> were supported at the same time, if we could unique= ly identify each DS record, and if we weren’t worried about backward c= ompatibility, then the <chg> option could be removed.

3) there is a consensus that as of RFC 4310, the <chg> is a replace-a= ll
operation, i.e. all existing DS records are removed completely and independ= ently
from the data provided and the provided DS records are added.

In it’s current form, for the current specification to work, the <= chg> needs to be interpreted as a replace all. Having to spli= t an update with multiple DS across multiple commands, is not a good practic= e and increases the risk of domains be published in an in-the-middle invalid= state.

4) there is a disagreement of how to interpret a
<rem><keytag>1234</keytag></rem> in the case that m= ultiple DS records with this
key tag have been provisioned earlier. One choice is to reject the operatio= n,
the other is to remove all DS records matching the key tag. There is a thir= d
choice of removing the the <keytag> element at all.

I believe that it should be reject if there is a mechanism to uniquely iden= tify a DS record. We are planning on deleting all of the matching DS r= ecords with the current specification, which is one of the areas of confusio= n that I would like to be fixed. EPP should be explicit to what the cl= ient really wants to do, so I’m in favor of rejecting if there is ambi= guity and we’re supporting the existing form of <rem> for backwa= rd compatibility. This is at list backward compatibility from an XML s= chema perspective.

5) there is a disagreement of how to repair the <rem> element. One ch= oice is to
use the existing "dsDataType", with the semantics that it must ma= tch exactly an
existing DS record, otherwise the request will fail (questionable though wh= at an
exact match is). The other choice is to create a separate "selectType&= quot; datatype
which contains optional elements only. All existing DS records are tested against the respective element. If a key tag, algorithm, digest type or dig= est
has been specified, the respective component must match, otherwise the DS r= ecord
is retained. While easy to define, still unknown what happens if no DS reco= rds
match or a DS record matches multiple "selectType" instances.

I prefer just using the dsDataType since there should be no question relate= d to matching the DS. I don’t believe that there should be two D= S records for a domain with the same four elements (keyTag, alg, digestType,= and digest) and the registry should ensure this. There is the very re= motely possibility of having more than one DS record with the combination of= a subset of the elements. Although I agree the likelihood of duplicat= e digest values is statistically impossible. I don’t see any hug= e advantage to use a subset of the elements since it leaves no ambiguity. &n= bsp;Supporting the existing <rem><keyTag> scheme for backward co= mpatibility should return an error when more than one DS records matches if = the dsDataType scheme is supported. &nbs= p;

6) if we break backward compatibility, the <keyData> element can be r= evisited.
It is unclear to me whether registries exist that would prefer to have the = key
data *instead* of the DS data and not *in addition*.

We are not planning on supporting the optional <keyData> element.

Please feel free to correct me if I misunderstood something.

-------

Now my further comments:

* If we break compatibility, then we should consider removing either <ad= d>/<rem>
or <chg> for the sake of symmetry to the base EPP standards and exten= sions. As
far as I understand the Scott Hollenbeck's design pattern, there is *either= * a
replace-all/change strategy *or* an add/remove strategy on a certain data element. For example, the registrant contact adheres the "change"= strategy,
while the other contacts adhere an add/remove strategy. RFC 4310 breaks it.=

* I am a little bit undetermined regarding the "selectType" appro= ach. While it
is a nice idea, it is also some kind of novelty in the EPP world. As far as= I
can remember, always the same datatype has been used for both the removal a= nd
addition. Of course, not in all cases all data fields have been used for comparison. For example, I assume no registry implementation will check the=
human readable text and the language for a removal of a status value, while= it
is possible to specify it. Also, I don't see that much the use cases. IMHO = the
most frequent use will be the KSK rollover, and for that purpose, this
flexibility is not required.

* regarding 4), the <keytag> element, I think the least trouble is to= allow the
removal of multiple DS records, but still rejecting the request, if no DS r= ecord
is found at all.

Regards,

Klaus

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
List run by majordomo software. For (Un-)subscription and similar det= ails
send "help" to ietf-provr= eg-request@cafax.se

--B_3339745698_7158825-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 08:51:04 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA253A694E for ; Fri, 30 Oct 2009 08:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajNBI6FYEia3 for ; Fri, 30 Oct 2009 08:51:03 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 187103A6859 for ; Fri, 30 Oct 2009 08:51:02 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFbfau008772 for ; Fri, 30 Oct 2009 16:37:41 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UFbfSB010536 for ietf-provreg-outgoing; Fri, 30 Oct 2009 16:37:41 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFbeNC002876 for ; Fri, 30 Oct 2009 16:37:40 +0100 (MET) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9UFZPV7006335; Fri, 30 Oct 2009 11:35:25 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:37:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Anyone working on 4310-bis? Date: Fri, 30 Oct 2009 11:37:38 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702ECDE6B@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <20091030143945.GE76006@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? thread-index: AcpZcjF4KtG4eCV6TR+bl1D53mwSpAAAyVQg References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> From: "Hollenbeck, Scott" To: "Andrew Sullivan" , "EPP Provreg" X-OriginalArrivalTime: 30 Oct 2009 15:37:39.0389 (UTC) FILETIME=[E99D3ED0:01CA5976] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9UFbfNC007693 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Friday, October 30, 2009 10:40 AM > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? [snip] > Are we sure that the and elements have to be > processed in the order in which they appear? I am not > completely sure. I recall at least one operator who had an > issue related to this processing-order question. If they do > _not_ have to be so processed, then in fact they can't be > allowed in a single request because the effect could be > different from what is intended. (Note that this remark also > means that there is by no means a consensus on this matter > yet.) > > RFC5731 says, "Commands are processed by a server in the > order they are received from a client." But in this case > these aren't actually different commands, and I have so far > been unable to convince myself that a server operator has to > process the elements of one command in the order in which > those elements appear. If someone knows otherwise (and I > would be very much pleased to have such proof), I'd like to > hear it. But as things stand, my reading is that a server > operator could handle all the elements first, and all > the elements second, and the effect of that could be > quite different than what we're trying to achieve. The answer to this question is implicit in the understanding of how XML Schema works. As currently specified, the and elements are part of a . Only one can appear, so there's no ordering issue. If the is changed to a , the order will be specified in the schema. If you don't want the order to matter, use . I would like to suggest that a sequence makes more sense if you want to avoid issues related to processing order. Scott -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 09:07:58 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCB828C0E5 for ; Fri, 30 Oct 2009 09:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDyqDrM+YSPB for ; Fri, 30 Oct 2009 09:07:58 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id C76C128C0FC for ; Fri, 30 Oct 2009 09:07:57 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFvmct016039 for ; Fri, 30 Oct 2009 16:57:48 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UFvm4x000991 for ietf-provreg-outgoing; Fri, 30 Oct 2009 16:57:48 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFvlTb027663 for ; Fri, 30 Oct 2009 16:57:47 +0100 (MET) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7437A2FE8CDC; Fri, 30 Oct 2009 15:57:46 +0000 (UTC) Date: Fri, 30 Oct 2009 11:57:44 -0400 From: Andrew Sullivan To: "Hollenbeck, Scott" Cc: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091030155744.GH76006@shinkuro.com> Mail-Followup-To: Andrew Sullivan , "Hollenbeck, Scott" , EPP Provreg References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> <046F43A8D79C794FA4733814869CDF0702ECDE6B@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF0702ECDE6B@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Oct 30, 2009 at 11:37:38AM -0400, Hollenbeck, Scott wrote: > The answer to this question is implicit in the understanding of how XML > Schema works. Aha, well, this is obviously where I fell down. > If the is changed to a , the order will be specified > in the schema. If you don't want the order to matter, use . I > would like to suggest that a sequence makes more sense if you want to > avoid issues related to processing order. Ok, cool. This is terribly helpful. Expect the next iteration to include this strategy, then. Thanks! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 10:43:08 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A53D28C0F1 for ; Fri, 30 Oct 2009 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 643uh-v3PFHe for ; Fri, 30 Oct 2009 10:43:07 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id C629A28C0FE for ; Fri, 30 Oct 2009 10:43:06 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHV2cE021987 for ; Fri, 30 Oct 2009 18:31:02 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UHV2nS002239 for ietf-provreg-outgoing; Fri, 30 Oct 2009 18:31:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHV1u8010290 for ; Fri, 30 Oct 2009 18:31:01 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 5A94DFF; Fri, 30 Oct 2009 18:30:59 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id DWVTH61GMq0i; Fri, 30 Oct 2009 18:30:53 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id B9BBDFE; Fri, 30 Oct 2009 18:30:53 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id n9UHUrPv015930; Fri, 30 Oct 2009 18:30:53 +0100 (MEZ) Message-ID: <4AEB22CA.3050700@knipp.de> Date: Fri, 30 Oct 2009 18:30:50 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5pre) Gecko/20091029 Shredder/3.0pre MIME-Version: 1.0 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> In-Reply-To: <20091030143945.GE76006@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 30/10/09 15:39, Andrew Sullivan wrote: > Hi, Hi Andrew, > > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > >[...] >> 2) there is a consensus that and elements shall be allowed in >> a single request, which must be on the other hand mutually exclusive to >> the element. > > Are we sure that the and elements have to be processed in > the order in which they appear? I am not completely sure. I recall > at least one operator who had an issue related to this > processing-order question. If they do _not_ have to be so processed, > then in fact they can't be allowed in a single request because the > effect could be different from what is intended. (Note that this > remark also means that there is by no means a consensus on this matter > yet.) > > [...] This problem has always been the case with EPP. If I submit a domain update request with adding the status "clientHold" and removing the status "clientHold" at the same time, what is the outcome? This applies to contacts, name servers and other stuff as well. So the protocol should clearly say how such a situation shall be handled: - define a static execution order, e.g. first the removal, then the addition - declare this as ambiguous and reject the order - declare this as a non-change and ignore By the way, as there seems to be some confusion: IMHO the order in the XML document should *never* imply any order of execution. > > Not elements, but attributes, is the way I've got it at the moment. I > didn't include the attributes other than the hash in the text as it's > written, but I think James has convinced me there'd be no harm in > adding the other ones. If this "select" solution is taken, I don't mind whether it is implemented via elements or attributes. Regards, Klaus -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 11:08:59 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3785E28C0F1 for ; Fri, 30 Oct 2009 11:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi7h942gBT7K for ; Fri, 30 Oct 2009 11:08:58 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id A58D93A696D for ; Fri, 30 Oct 2009 11:08:57 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHwTHB028140 for ; Fri, 30 Oct 2009 18:58:29 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UHwTr2011612 for ietf-provreg-outgoing; Fri, 30 Oct 2009 18:58:29 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHwSun028770 for ; Fri, 30 Oct 2009 18:58:28 +0100 (MET) Message-Id: <457B0D73-FE83-4573-8A40-0EB6A9640414@afilias.info> From: Howard Eland To: EPP Provreg In-Reply-To: <4AEB22CA.3050700@knipp.de> Content-Type: multipart/alternative; boundary=Apple-Mail-9--554568343 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Fri, 30 Oct 2009 12:58:25 -0500 References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> <4AEB22CA.3050700@knipp.de> X-Mailer: Apple Mail (2.936) X-Authenticated: True Sender: owner-ietf-provreg@cafax.se Precedence: bulk --Apple-Mail-9--554568343 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 30, 2009, at 12:30 PM, Klaus Malorny wrote: > On 30/10/09 15:39, Andrew Sullivan wrote: >> Hi, > > Hi Andrew, > >> >> On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: >> >> [...] >>> 2) there is a consensus that and elements shall be >>> allowed in >>> a single request, which must be on the other hand mutually >>> exclusive to >>> the element. >> >> Are we sure that the and elements have to be processed in >> the order in which they appear? I am not completely sure. I recall >> at least one operator who had an issue related to this >> processing-order question. If they do _not_ have to be so processed, >> then in fact they can't be allowed in a single request because the >> effect could be different from what is intended. (Note that this >> remark also means that there is by no means a consensus on this >> matter >> yet.) >> >> [...] > > This problem has always been the case with EPP. If I submit a domain > update request with adding the status "clientHold" and removing the > status "clientHold" at the same time, what is the outcome? This > applies to contacts, name servers and other stuff as well. > > So the protocol should clearly say how such a situation shall be > handled: > - define a static execution order, e.g. first the removal, then the > addition > - declare this as ambiguous and reject the order > - declare this as a non-change and ignore > > By the way, as there seems to be some confusion: IMHO the order in > the XML document should *never* imply any order of execution. Yes and no - that's _exactly_ what is for - to prescribe a predetermined order via XML. If we follow RFC5731 (see below), using domain status as in Klaus' example, then the correct thing to do is declare update child elements as a , with add first, then rem. The RFC is silent beyond that, so I would assume that this means the server must execute all adds in any order, then execute all rems in any order, then execute all chgs in any order. > >> >> Not elements, but attributes, is the way I've got it at the >> moment. I >> didn't include the attributes other than the hash in the text as it's >> written, but I think James has convinced me there'd be no harm in >> adding the other ones. > > If this "select" solution is taken, I don't mind whether it is > implemented via elements or attributes. > > Regards, > > Klaus > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > List run by majordomo software. For (Un-)subscription and similar > details > send "help" to ietf-provreg-request@cafax.se > --Apple-Mail-9--554568343 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

On Oct 30, 2009, = at 12:30 PM, Klaus Malorny wrote:

On = 30/10/09 15:39, Andrew Sullivan wrote:
Hi,

Hi Andrew,

On Fri, Oct 30, = 2009 at 12:39:00PM +0100, Klaus Malorny = wrote:

[...]
2) there is a consensus that<add> = and<rem> elements shall be allowed = in
a single request, which must be on the other hand mutually = exclusive to
the<chg> = element.

Are we sure = that the<add> and<rem> elements have to be = processed in
the order in = which they appear? I am not completely sure. I = recall
at least one operator = who had an issue related to this
processing-order question. If they do _not_ have to = be so processed,
then in fact = they can't be allowed in a single request because = the
effect could be different = from what is intended. (Note that this
remark also means that there is by no means a consensus on = this matter
yet.)

[...]

This problem has always been the = case with EPP. If I submit a domain update request with adding the = status "clientHold" and removing the status "clientHold" at the same = time, what is the outcome? This applies to contacts, name servers and = other stuff as well.

So the protocol should clearly say how such = a situation shall be handled:
- define a static execution order, e.g. = first the removal, then the addition
- declare this as ambiguous and = reject the order
- declare this as a non-change and ignore

By = the way, as there seems to be some confusion: IMHO the order in the XML = document should *never* imply any order of = execution.

Yes and no - that's = _exactly_ what <sequence> is for - to prescribe a predetermined = order via XML.

If we follow RFC5731 (see = below), using domain status as in Klaus' example, then the correct thing = to do is declare update child elements as a <sequence>, with add = first, then rem. The RFC is silent beyond that, so I would assume = that this means the server must execute all adds in any order, then = execute all rems in any order, then execute all chgs in any = order.

<complexType name=3D"updateType"> <sequence> <element name=3D"name" type=3D"eppcom:labelType"/> <element name=3D"add" type=3D"domain:addRemType" minOccurs=3D"0"/> <element name=3D"rem" type=3D"domain:addRemType" minOccurs=3D"0"/> <element name=3D"chg" type=3D"domain:chgType" minOccurs=3D"0"/> </sequence> </complexType>

Not elements, = but attributes, is the way I've got it at the moment. = I
didn't include the = attributes other than the hash in the text as = it's
written, but I think = James has convinced me there'd be no harm in
adding the other ones.

If this = "select" solution is taken, I don't mind whether it is implemented via = elements or = attributes.

Regards,

Klaus
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo = software. For (Un-)subscription and similar details
send "help" = to ietf-provreg-request@cafax.s= e

= --Apple-Mail-9--554568343-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 11:40:27 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 290A73A67E2 for ; Fri, 30 Oct 2009 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.749 X-Spam-Level: X-Spam-Status: No, score=0.749 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je+u-GyHPdGO for ; Fri, 30 Oct 2009 11:40:21 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id BCDC63A6767 for ; Fri, 30 Oct 2009 11:40:20 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIRD1f000410 for ; Fri, 30 Oct 2009 19:27:13 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UIRDHh022520 for ietf-provreg-outgoing; Fri, 30 Oct 2009 19:27:13 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIRCS2012016 for ; Fri, 30 Oct 2009 19:27:12 +0100 (MET) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9UIOupt014695; Fri, 30 Oct 2009 14:24:56 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:27:01 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 Oct 2009 18:27:10 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 14:27:08 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Klaus Malorny , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpZiV8liR3+qGRdT1CdTh6VrAcShwABTdt5 In-Reply-To: <4AEB22CA.3050700@knipp.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339757629_7880254" X-OriginalArrivalTime: 30 Oct 2009 18:27:01.0542 (UTC) FILETIME=[92BABC60:01CA598E] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339757629_7880254 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable =B3This problem has always been the case with EPP. If I submit a domain updat= e request with adding the status "clientHold" and removing the status "clientHold" at the same time, what is the outcome? This applies to contacts, name servers and other stuff as well.=B2 We really haven=B9t run into any issues with adding and removing contacts, name servers, or host ip addresses at the same time. In our system, trying to add and remove the same element like the clientHold status will result i= n a 2306 =B3Parameter value policy error=B2. The adds and removes are applied to the object within a single transaction so there should really be no orderin= g issue and the registry can address corner cases like trying to add and remove the same element. =B3If this "select" solution is taken, I don't mind whether it is implemented via elements or attributes.=B2 Either the elements or attributes will work, but I still like your schema proposal the best. The key is whether the elements (keyTag, alg, digestType, and digest) are required or optional and if they=B9re optional what happens if the specified elements match multiple DS records. I don=B9t have an issue making them optional as long as the registry returns an error if they match more then one DS record. I see it as a big issue if the client accidently deletes more then what was desired because they didn=B9t specify enough unique information. It=B9s better to error out and require the client to explicitly specify what they want deleted. --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Klaus Malorny Date: Fri, 30 Oct 2009 13:30:50 -0400 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? On 30/10/09 15:39, Andrew Sullivan wrote: > Hi, Hi Andrew, > > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > >[...] >> 2) there is a consensus that and elements shall be allowed i= n >> a single request, which must be on the other hand mutually exclusive to >> the element. > > Are we sure that the and elements have to be processed in > the order in which they appear? I am not completely sure. I recall > at least one operator who had an issue related to this > processing-order question. If they do _not_ have to be so processed, > then in fact they can't be allowed in a single request because the > effect could be different from what is intended. (Note that this > remark also means that there is by no means a consensus on this matter > yet.) > > [...] This problem has always been the case with EPP. If I submit a domain update request with adding the status "clientHold" and removing the status "clientHold" at the same time, what is the outcome? This applies to contacts, name servers and other stuff as well. So the protocol should clearly say how such a situation shall be handled: - define a static execution order, e.g. first the removal, then the additio= n - declare this as ambiguous and reject the order - declare this as a non-change and ignore By the way, as there seems to be some confusion: IMHO the order in the XML document should *never* imply any order of execution. > > Not elements, but attributes, is the way I've got it at the moment. I > didn't include the attributes other than the hash in the text as it's > written, but I think James has convinced me there'd be no harm in > adding the other ones. If this "select" solution is taken, I don't mind whether it is implemented via elements or attributes. Regards, Klaus -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se --B_3339757629_7880254 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? “This problem has always been the case with EPP. If I submit a domai= n update
request with adding the status "clientHold" and removing the stat= us "clientHold"
at the same time, what is the outcome? This applies to contacts, name serve= rs
and other stuff as well.”

We really haven’t run into any issues with adding and removing contac= ts, name servers, or host ip addresses at the same time. In our system= , trying to add and remove the same element like the clientHold status will = result in a 2306 “Parameter value policy error”. The adds = and removes are applied to the object within a single transaction so there s= hould really be no ordering issue and the registry can address corner cases = like trying to add and remove the same element.

“If this "select" solution is taken, I don't mind whether i= t is implemented via
elements or attributes.”

Either the elements or attributes will work, but I still like your schema p= roposal the best. The key is whether the elements (keyTag, alg, digest= Type, and digest) are required or optional and if they’re optional wha= t happens if the specified elements match multiple DS records. I don&#= 8217;t have an issue making them optional as long as the registry returns an= error if they match more then one DS record. I see it as a big issue = if the client accidently deletes more then what was desired because they did= n’t specify enough unique information.   It’s better t= o error out and require the client to explicitly specify what they want dele= ted.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 30/10/09 15:39, Andrew Sullivan wrote:
> Hi,

Hi Andrew,

>
> On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote:
>
>[...]
>> 2) there is a consensus that<add> and<rem> = ;elements shall be allowed in
>> a single request, which must be on the other hand mutually exclusi= ve to
>> the<chg> element.
>
> Are we sure that the<add> and<rem> elements ha= ve to be processed in
> the order in which they appear? I am not completely sure. = I recall
> at least one operator who had an issue related to this
> processing-order question. If they do _not_ have to be so proces= sed,
> then in fact they can't be allowed in a single request because the
> effect could be different from what is intended. (Note that this=
> remark also means that there is by no means a consensus on this matter=
> yet.)
>
> [...]

This problem has always been the case with EPP. If I submit a domain update=
request with adding the status "clientHold" and removing the stat= us "clientHold"
at the same time, what is the outcome? This applies to contacts, name serve= rs
and other stuff as well.

So the protocol should clearly say how such a situation shall be handled: - define a static execution order, e.g. first the removal, then the additio= n
- declare this as ambiguous and reject the order
- declare this as a non-change and ignore

By the way, as there seems to be some confusion: IMHO the order in the XML<= BR> document should *never* imply any order of execution.

>
> Not elements, but attributes, is the way I've got it at the moment. &n= bsp;I
> didn't include the attributes other than the hash in the text as it's<= BR> > written, but I think James has convinced me there'd be no harm in
> adding the other ones.

If this "select" solution is taken, I don't mind whether it is im= plemented via
elements or attributes.

Regards,

Klaus
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
List run by majordomo software. For (Un-)subscription and similar det= ails
send "help" to ietf-provr= eg-request@cafax.se

--B_3339757629_7880254-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 11:44:44 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89DBC3A6842 for ; Fri, 30 Oct 2009 11:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[AWL=-1.715, BAYES_40=-0.185, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuha1eHom34D for ; Fri, 30 Oct 2009 11:44:43 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id B02E53A6767 for ; Fri, 30 Oct 2009 11:44:42 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIb73o021444 for ; Fri, 30 Oct 2009 19:37:07 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UIb7GD001122 for ietf-provreg-outgoing; Fri, 30 Oct 2009 19:37:07 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIb6uU003798 for ; Fri, 30 Oct 2009 19:37:06 +0100 (MET) Cc: Klaus Malorny , EPP Provreg Message-Id: <0A88AC3F-354F-4A9C-997E-F9C31F9EBB7E@afilias.info> From: Howard Eland To: James Gould In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-11--552252440 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Fri, 30 Oct 2009 13:37:01 -0500 References: X-Mailer: Apple Mail (2.936) X-Authenticated: True Sender: owner-ietf-provreg@cafax.se Precedence: bulk --Apple-Mail-11--552252440 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Oct 30, 2009, at 1:27 PM, James Gould wrote: > =93If this "select" solution is taken, I don't mind whether it is =20 > implemented via > elements or attributes.=94 I was under the impression that the selectType idea was pretty much =20 dead. > > Either the elements or attributes will work, but I still like your =20 > schema proposal the best. The key is whether the elements (keyTag, =20= > alg, digestType, and digest) are required or optional and if they=92re = =20 > optional what happens if the specified elements match multiple DS =20 > records. I don=92t have an issue making them optional as long as the =20= > registry returns an error if they match more then one DS record. I =20= > see it as a big issue if the client accidently deletes more then =20 > what was desired because they didn=92t specify enough unique =20 > information. It=92s better to error out and require the client to =20= > explicitly specify what they want deleted. If I once again go back to RFC 5731, I see that non-unique attributes =20= of an element that is to be selected for the rem command are =20 optional. If we want to keep the EPP flavor, then I'd suggest that we =20= only require the digest itself, and make the others optional. -Howard > > > --=20 > > > JG > > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > > > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > Notice to Recipient: This e-mail contains confidential, proprietary =20= > and/or Registry Sensitive information intended solely for the =20 > recipient and, thus may not be retransmitted, reproduced or =20 > disclosed without the prior written consent of VeriSign Naming and =20= > Directory Services. If you have received this e-mail message in =20 > error, please notify the sender immediately by telephone or reply e-=20= > mail and destroy the original message without making a copy. Thank =20= > you. > > > From: Klaus Malorny > Date: Fri, 30 Oct 2009 13:30:50 -0400 > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > > On 30/10/09 15:39, Andrew Sullivan wrote: > > Hi, > > Hi Andrew, > > > > > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > > > >[...] > >> 2) there is a consensus that and elements shall be =20 > allowed in > >> a single request, which must be on the other hand mutually =20 > exclusive to > >> the element. > > > > Are we sure that the and elements have to be processed =20= > in > > the order in which they appear? I am not completely sure. I recall > > at least one operator who had an issue related to this > > processing-order question. If they do _not_ have to be so =20 > processed, > > then in fact they can't be allowed in a single request because the > > effect could be different from what is intended. (Note that this > > remark also means that there is by no means a consensus on this =20 > matter > > yet.) > > > > [...] > > This problem has always been the case with EPP. If I submit a domain =20= > update > request with adding the status "clientHold" and removing the status =20= > "clientHold" > at the same time, what is the outcome? This applies to contacts, =20 > name servers > and other stuff as well. > > So the protocol should clearly say how such a situation shall be =20 > handled: > - define a static execution order, e.g. first the removal, then the =20= > addition > - declare this as ambiguous and reject the order > - declare this as a non-change and ignore > > By the way, as there seems to be some confusion: IMHO the order in =20 > the XML > document should *never* imply any order of execution. > > > > > Not elements, but attributes, is the way I've got it at the =20 > moment. I > > didn't include the attributes other than the hash in the text as =20 > it's > > written, but I think James has convinced me there'd be no harm in > > adding the other ones. > > If this "select" solution is taken, I don't mind whether it is =20 > implemented via > elements or attributes. > > Regards, > > Klaus > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=20 > =3D-=3D-=3D- > List run by majordomo software. For (Un-)subscription and similar =20 > details > send "help" to ietf-provreg-request@cafax.se > > --Apple-Mail-11--552252440 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Oct 30, 2009, = at 1:27 PM, James Gould wrote:

=93If this "select" solution is taken, I don't = mind whether it is implemented via
elements or = attributes.=94

I was = under the impression that the selectType idea was pretty much = dead.

Either = the elements or attributes will work, but I still like your schema = proposal the best. The key is whether the elements (keyTag, alg, = digestType, and digest) are required or optional and if they=92re = optional what happens if the specified elements match multiple DS = records. I don=92t have an issue making them optional as long as = the registry returns an error if they match more then one DS record. = I see it as a big issue if the client accidently deletes more then = what was desired because they didn=92t specify enough unique = information.   It=92s better to error out and require the = client to explicitly specify what they want = deleted.

If I once again = go back to RFC 5731, I see that non-unique attributes of an element that = is to be selected for the rem command are optional. If we want to = keep the EPP flavor, then I'd suggest that we only require the digest = itself, and make the others = optional.

-Howard


=
--

JG

= ------------------------------------------------= -------
James= F. Gould
Principal Software = Engineer
VeriSign Naming = Services
jgould@verisign.com
= Direct: 703.948.3271
Mobile: = 703.628.7063

=
21345 Ridgetop Circle
LS2-2-1
= Dulles, VA 20166

Notice to = Recipient: This e-mail contains confidential, proprietary = and/or Registry Sensitive information intended solely for the = recipient and, thus may not be retransmitted, reproduced or = disclosed without the prior written consent of VeriSign Naming and = Directory Services. If you have received this e-mail = message in error, please notify the sender immediately by = telephone or reply e-mail and destroy the original message without = making a copy. Thank you.
=

From: Klaus Malorny <Klaus.Malorny@knipp.de>
= Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg = <ietf-provreg@cafax.se>
= Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

= On 30/10/09 15:39, Andrew Sullivan wrote:
> Hi,

Hi = Andrew,

>
> On Fri, Oct 30, 2009 at 12:39:00PM +0100, = Klaus Malorny wrote:
>
>[...]
>> 2) there is a = consensus that<add> and<rem> elements shall be = allowed in
>> a single request, which must be on the other = hand mutually exclusive to
>> the<chg> = element.
>
> Are we sure that the<add> = and<rem> elements have to be processed in
> the = order in which they appear? I am not completely sure. I = recall
> at least one operator who had an issue related to = this
> processing-order question. If they do _not_ have to = be so processed,
> then in fact they can't be allowed in a single = request because the
> effect could be different from what is = intended. (Note that this
> remark also means that there is = by no means a consensus on this matter
> yet.)
>
> = [...]

This problem has always been the case with EPP. If I = submit a domain update
request with adding the status "clientHold" = and removing the status "clientHold"
at the same time, what is the = outcome? This applies to contacts, name servers
and other stuff as = well.

So the protocol should clearly say how such a situation = shall be handled:
- define a static execution order, e.g. first the = removal, then the addition
- declare this as ambiguous and reject = the order
- declare this as a non-change and ignore

By the = way, as there seems to be some confusion: IMHO the order in the XML
= document should *never* imply any order of execution.

>
= > Not elements, but attributes, is the way I've got it at the moment. = I
> didn't include the attributes other than the hash in = the text as it's
> written, but I think James has convinced me = there'd be no harm in
> adding the other ones.

If this = "select" solution is taken, I don't mind whether it is implemented = via
elements or attributes.

Regards,

Klaus
= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-<= br> List run by majordomo software. For (Un-)subscription and = similar details
send "help" to ietf-provreg-request@cafax.se

=

= --Apple-Mail-11--552252440-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se From owner-ietf-provreg@cafax.se Fri Oct 30 12:04:42 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2FB3A6767 for ; Fri, 30 Oct 2009 12:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.822 X-Spam-Level: X-Spam-Status: No, score=0.822 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_40=-0.185, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db0NZ-2ZpZH3 for ; Fri, 30 Oct 2009 12:04:33 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 197053A683C for ; Fri, 30 Oct 2009 12:04:32 -0700 (PDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIqO86001691 for ; Fri, 30 Oct 2009 19:52:24 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UIqODQ022798 for ietf-provreg-outgoing; Fri, 30 Oct 2009 19:52:24 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIqNbx002146 for ; Fri, 30 Oct 2009 19:52:23 +0100 (MET) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9UIo7t7015999; Fri, 30 Oct 2009 14:50:07 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:52:21 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 Oct 2009 18:52:21 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 14:52:15 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Howard Eland CC: Klaus Malorny , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpZkAF9BP4rk/anTwe0h0SNl1dQKQAAhdXV In-Reply-To: <0A88AC3F-354F-4A9C-997E-F9C31F9EBB7E@afilias.info> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339759137_7953258" X-OriginalArrivalTime: 30 Oct 2009 18:52:21.0816 (UTC) FILETIME=[1CE22380:01CA5992] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339759137_7953258 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Eland, =B3I was under the impression that the selectType idea was pretty much dead.=B2 The comment is associated with the use of elements versus attributes and less on whether all of the elements are required or optional. The optional scheme is like the selectType idea, where a set of attributes/elements coul= d match more then one DS record. Either attributes or elements work, but one of the earlier points was that digest is not really an attribute of a keyTa= g and similarly alg is not an attribute of a digest. The elements are cleaner. =20 =B3If I once again go back to RFC 5731, I see that non-unique attributes of a= n element that is to be selected for the rem command are optional. If we wan= t to keep the EPP flavor, then I'd suggest that we only require the digest itself, and make the others optional.=B2 I suggest that we just make all four required to be consistent with the add and chg. There is a statistical chance (yes, very remote chance) of producing the same digest for two different DS records, so it=B9s cleanest to remove any chance of matching duplicate DS records. I don=B9t believe that it=B9s overly burdensome to pass all four attributes on a rem to remove any ambiguity. =20 I=B9m still not sure what is wrong with Klaus=B9s proposal. Is it really too burdensome to pass all four attributes to a remove? I have to assume that everyone is fine with support for add and rem in the same command like is the case for contacts and name servers in domains and ip addresses for hosts. =20 --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Howard Eland Date: Fri, 30 Oct 2009 14:37:01 -0400 To: James Gould Cc: Klaus Malorny , EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? On Oct 30, 2009, at 1:27 PM, James Gould wrote: > =B3If this "select" solution is taken, I don't mind whether it is implement= ed > via > elements or attributes.=B2 I was under the impression that the selectType idea was pretty much dead. > =20 > Either the elements or attributes will work, but I still like your schem= a > proposal the best. The key is whether the elements (keyTag, alg, digestT= ype, > and digest) are required or optional and if they=B9re optional what happens= if > the specified elements match multiple DS records. I don=B9t have an issue > making them optional as long as the registry returns an error if they mat= ch > more then one DS record. I see it as a big issue if the client accidentl= y > deletes more then what was desired because they didn=B9t specify enough uni= que > information. It=B9s better to error out and require the client to explici= tly > specify what they want deleted. If I once again go back to RFC 5731, I see that non-unique attributes of an element that is to be selected for the rem command are optional. If we wan= t to keep the EPP flavor, then I'd suggest that we only require the digest itself, and make the others optional. -Howard > =20 > =20 > --=20 > =20 > =20 > JG=20 > =20 > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > =20 > =20 > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > =20 > Notice to Recipient: This e-mail contains confidential, proprietary and= /or > Registry Sensitive information intended solely for the recipient and, th= us > may not be retransmitted, reproduced or disclosed without the prior writ= ten > consent of VeriSign Naming and Directory Services. If you have received > this e-mail message in error, please notify the sender immediately by > telephone or reply e-mail and destroy the original message without making= a > copy. Thank you. > =20 > =20 > =20 >=20 > From: Klaus Malorny > Date: Fri, 30 Oct 2009 13:30:50 -0400 > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > =20 > On 30/10/09 15:39, Andrew Sullivan wrote: >> > Hi, > =20 > Hi Andrew, > =20 >> > >> > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: >> > >> >[...] >>> >> 2) there is a consensus that and elements shall be allo= wed in >>> >> a single request, which must be on the other hand mutually exclusiv= e to >>> >> the element. >> > >> > Are we sure that the and elements have to be processed in >> > the order in which they appear? I am not completely sure. I recall >> > at least one operator who had an issue related to this >> > processing-order question. If they do _not_ have to be so processed, >> > then in fact they can't be allowed in a single request because the >> > effect could be different from what is intended. (Note that this >> > remark also means that there is by no means a consensus on this matte= r >> > yet.) >> > >> > [...] > =20 > This problem has always been the case with EPP. If I submit a domain upd= ate > request with adding the status "clientHold" and removing the status > "clientHold" > at the same time, what is the outcome? This applies to contacts, name se= rvers > and other stuff as well. > =20 > So the protocol should clearly say how such a situation shall be handled= : > - define a static execution order, e.g. first the removal, then the addi= tion > - declare this as ambiguous and reject the order > - declare this as a non-change and ignore > =20 > By the way, as there seems to be some confusion: IMHO the order in the X= ML > document should *never* imply any order of execution. > =20 >> > >> > Not elements, but attributes, is the way I've got it at the moment. = I >> > didn't include the attributes other than the hash in the text as it's >> > written, but I think James has convinced me there'd be no harm in >> > adding the other ones. > =20 > If this "select" solution is taken, I don't mind whether it is implement= ed > via > elements or attributes. > =20 > Regards, > =20 > Klaus > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D- > List run by majordomo software. For (Un-)subscription and similar detai= ls > send "help" to ietf-provreg-request@cafax.se > =20 > =20 > =20 > =20 --B_3339759137_7953258 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? Eland,

“I was under the impression that the selectType idea was pretty much = dead.”

The comment is associated with the use of elements versus attributes and le= ss on whether all of the elements are required or optional. The option= al scheme is like the selectType idea, where a set of attributes/elements co= uld match more then one DS record. Either attributes or elements work,= but one of the earlier points was that digest is not really an attribute of= a keyTag and similarly alg is not an attribute of a digest. The eleme= nts are cleaner.

“If I once again go back to RFC 5731, I see that non-unique attribute= s of an element that is to be selected for the rem command are optional. &nb= sp;If we want to keep the EPP flavor, then I'd suggest that we only require = the digest itself, and make the others optional.”

I suggest that we just make all four required to be consistent with the add= and chg. There is a statistical chance (yes, very remote chance) &nbs= p;of producing the same digest for two different DS records, so it’s c= leanest to remove any chance of matching duplicate DS records. I don&#= 8217;t believe that it’s overly burdensome to pass all four attributes= on a rem to remove any ambiguity.

I’m still not sure what is wrong with Klaus’s proposal. I= s it really too burdensome to pass all four attributes to a remove? I = have to assume that everyone is fine with support for add and rem in the sam= e command like is the case for contacts and name servers in domains and ip a= ddresses for hosts.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Howard Eland <heland@afilias.info>
Date: Fri, 30 Oct 2009 14:37:01 -0400
To: James Gould <jgould@verisign.co= m>
Cc: Klaus Malorny <Klaus.Malorny= @knipp.de>, EPP Provreg <ietf-prov= reg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Oct 30, 2009, at 1:27 PM, James Gould wrote:

<= SPAN STYLE=3D'font-size:11pt'>“If this "select" solution is ta= ken, I don't mind whether it is implemented via
elements or attributes.”

=
I was under the impression that the selectType idea was pretty much dead.

<= SPAN STYLE=3D'font-size:11pt'>
Either the elements or attributes will work, but I still like your sc= hema proposal the best. The key is whether the elements (keyTag, alg, = digestType, and digest) are required or optional and if they’re option= al what happens if the specified elements match multiple DS records. I= don’t have an issue making them optional as long as the registry retu= rns an error if they match more then one DS record. I see it as a big = issue if the client accidently deletes more then what was desired because th= ey didn’t specify enough unique information.   It’s be= tter to error out and require the client to explicitly specify what they wan= t deleted.

=
If I once again go back to RFC 5731, I see that non-unique attributes of an= element that is to be selected for the rem command are optional. If w= e want to keep the EPP flavor, then I'd suggest that we only require the dig= est itself, and make the others optional.

-Howard

<= SPAN STYLE=3D'font-size:11pt'>

--

JG

-------------------------------------------------------
= James F. Gould
= Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, = proprietary and/or Registry Sensitive information intended solely for = the recipient and, thus may not be retransmitted, reproduced or disclo= sed without the prior written consent of VeriSign Naming and Directory= Services. If you have received this e-mail message in error,= please notify the sender immediately by telephone or reply e-mail and= destroy the original message without making a copy. Thank y= ou.

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg <ietf-provr= eg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 30/10/09 15:39, Andrew Sullivan wrote:
> Hi,

Hi Andrew,

>
> On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: >
>[...]
>> 2) there is a consensus that<add> and<rem>= elements shall be allowed in
>> a single request, which must be on the other hand mutually e= xclusive to
>> the<chg> element.
>
> Are we sure that the<add> and<rem> eleme= nts have to be processed in
> the order in which they appear? I am not completely sure. = I recall
> at least one operator who had an issue related to this
> processing-order question. If they do _not_ have to be so = processed,
> then in fact they can't be allowed in a single request because t= he
> effect could be different from what is intended. (Note tha= t this
> remark also means that there is by no means a consensus on this = matter
> yet.)
>
> [...]

This problem has always been the case with EPP. If I submit a domain = update
request with adding the status "clientHold" and removing th= e status "clientHold"
at the same time, what is the outcome? This applies to contacts, name= servers
and other stuff as well.

So the protocol should clearly say how such a situation shall be hand= led:
- define a static execution order, e.g. first the removal, then the a= ddition
- declare this as ambiguous and reject the order
- declare this as a non-change and ignore

By the way, as there seems to be some confusion: IMHO the order in th= e XML
document should *never* imply any order of execution.

>
> Not elements, but attributes, is the way I've got it at the mome= nt. I
> didn't include the attributes other than the hash in the text as= it's
> written, but I think James has convinced me there'd be no harm i= n
> adding the other ones.

If this "select" solution is taken, I don't mind whether it= is implemented via
elements or attributes.

Regards,

Klaus
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and simil= ar details
send "help" to ietf= -provreg-request@cafax.se




=

--B_3339759137_7953258-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIqO86001691 for ; Fri, 30 Oct 2009 19:52:24 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UIqODQ022798 for ietf-provreg-outgoing; Fri, 30 Oct 2009 19:52:24 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIqNbx002146 for ; Fri, 30 Oct 2009 19:52:23 +0100 (MET) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9UIo7t7015999; Fri, 30 Oct 2009 14:50:07 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:52:21 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 Oct 2009 18:52:21 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 14:52:15 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Howard Eland CC: Klaus Malorny , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpZkAF9BP4rk/anTwe0h0SNl1dQKQAAhdXV In-Reply-To: <0A88AC3F-354F-4A9C-997E-F9C31F9EBB7E@afilias.info> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339759137_7953258" X-OriginalArrivalTime: 30 Oct 2009 18:52:21.0816 (UTC) FILETIME=[1CE22380:01CA5992] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339759137_7953258 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Eland, =B3I was under the impression that the selectType idea was pretty much dead.=B2 The comment is associated with the use of elements versus attributes and less on whether all of the elements are required or optional. The optional scheme is like the selectType idea, where a set of attributes/elements coul= d match more then one DS record. Either attributes or elements work, but one of the earlier points was that digest is not really an attribute of a keyTa= g and similarly alg is not an attribute of a digest. The elements are cleaner. =20 =B3If I once again go back to RFC 5731, I see that non-unique attributes of a= n element that is to be selected for the rem command are optional. If we wan= t to keep the EPP flavor, then I'd suggest that we only require the digest itself, and make the others optional.=B2 I suggest that we just make all four required to be consistent with the add and chg. There is a statistical chance (yes, very remote chance) of producing the same digest for two different DS records, so it=B9s cleanest to remove any chance of matching duplicate DS records. I don=B9t believe that it=B9s overly burdensome to pass all four attributes on a rem to remove any ambiguity. =20 I=B9m still not sure what is wrong with Klaus=B9s proposal. Is it really too burdensome to pass all four attributes to a remove? I have to assume that everyone is fine with support for add and rem in the same command like is the case for contacts and name servers in domains and ip addresses for hosts. =20 --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Howard Eland Date: Fri, 30 Oct 2009 14:37:01 -0400 To: James Gould Cc: Klaus Malorny , EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? On Oct 30, 2009, at 1:27 PM, James Gould wrote: > =B3If this "select" solution is taken, I don't mind whether it is implement= ed > via > elements or attributes.=B2 I was under the impression that the selectType idea was pretty much dead. > =20 > Either the elements or attributes will work, but I still like your schem= a > proposal the best. The key is whether the elements (keyTag, alg, digestT= ype, > and digest) are required or optional and if they=B9re optional what happens= if > the specified elements match multiple DS records. I don=B9t have an issue > making them optional as long as the registry returns an error if they mat= ch > more then one DS record. I see it as a big issue if the client accidentl= y > deletes more then what was desired because they didn=B9t specify enough uni= que > information. It=B9s better to error out and require the client to explici= tly > specify what they want deleted. If I once again go back to RFC 5731, I see that non-unique attributes of an element that is to be selected for the rem command are optional. If we wan= t to keep the EPP flavor, then I'd suggest that we only require the digest itself, and make the others optional. -Howard > =20 > =20 > --=20 > =20 > =20 > JG=20 > =20 > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > =20 > =20 > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > =20 > Notice to Recipient: This e-mail contains confidential, proprietary and= /or > Registry Sensitive information intended solely for the recipient and, th= us > may not be retransmitted, reproduced or disclosed without the prior writ= ten > consent of VeriSign Naming and Directory Services. If you have received > this e-mail message in error, please notify the sender immediately by > telephone or reply e-mail and destroy the original message without making= a > copy. Thank you. > =20 > =20 > =20 >=20 > From: Klaus Malorny > Date: Fri, 30 Oct 2009 13:30:50 -0400 > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > =20 > On 30/10/09 15:39, Andrew Sullivan wrote: >> > Hi, > =20 > Hi Andrew, > =20 >> > >> > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: >> > >> >[...] >>> >> 2) there is a consensus that and elements shall be allo= wed in >>> >> a single request, which must be on the other hand mutually exclusiv= e to >>> >> the element. >> > >> > Are we sure that the and elements have to be processed in >> > the order in which they appear? I am not completely sure. I recall >> > at least one operator who had an issue related to this >> > processing-order question. If they do _not_ have to be so processed, >> > then in fact they can't be allowed in a single request because the >> > effect could be different from what is intended. (Note that this >> > remark also means that there is by no means a consensus on this matte= r >> > yet.) >> > >> > [...] > =20 > This problem has always been the case with EPP. If I submit a domain upd= ate > request with adding the status "clientHold" and removing the status > "clientHold" > at the same time, what is the outcome? This applies to contacts, name se= rvers > and other stuff as well. > =20 > So the protocol should clearly say how such a situation shall be handled= : > - define a static execution order, e.g. first the removal, then the addi= tion > - declare this as ambiguous and reject the order > - declare this as a non-change and ignore > =20 > By the way, as there seems to be some confusion: IMHO the order in the X= ML > document should *never* imply any order of execution. > =20 >> > >> > Not elements, but attributes, is the way I've got it at the moment. = I >> > didn't include the attributes other than the hash in the text as it's >> > written, but I think James has convinced me there'd be no harm in >> > adding the other ones. > =20 > If this "select" solution is taken, I don't mind whether it is implement= ed > via > elements or attributes. > =20 > Regards, > =20 > Klaus > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D- > List run by majordomo software. For (Un-)subscription and similar detai= ls > send "help" to ietf-provreg-request@cafax.se > =20 > =20 > =20 > =20 --B_3339759137_7953258 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? Eland,

“I was under the impression that the selectType idea was pretty much = dead.”

The comment is associated with the use of elements versus attributes and le= ss on whether all of the elements are required or optional. The option= al scheme is like the selectType idea, where a set of attributes/elements co= uld match more then one DS record. Either attributes or elements work,= but one of the earlier points was that digest is not really an attribute of= a keyTag and similarly alg is not an attribute of a digest. The eleme= nts are cleaner.

“If I once again go back to RFC 5731, I see that non-unique attribute= s of an element that is to be selected for the rem command are optional. &nb= sp;If we want to keep the EPP flavor, then I'd suggest that we only require = the digest itself, and make the others optional.”

I suggest that we just make all four required to be consistent with the add= and chg. There is a statistical chance (yes, very remote chance) &nbs= p;of producing the same digest for two different DS records, so it’s c= leanest to remove any chance of matching duplicate DS records. I don&#= 8217;t believe that it’s overly burdensome to pass all four attributes= on a rem to remove any ambiguity.

I’m still not sure what is wrong with Klaus’s proposal. I= s it really too burdensome to pass all four attributes to a remove? I = have to assume that everyone is fine with support for add and rem in the sam= e command like is the case for contacts and name servers in domains and ip a= ddresses for hosts.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Howard Eland <heland@afilias.info>
Date: Fri, 30 Oct 2009 14:37:01 -0400
To: James Gould <jgould@verisign.co= m>
Cc: Klaus Malorny <Klaus.Malorny= @knipp.de>, EPP Provreg <ietf-prov= reg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Oct 30, 2009, at 1:27 PM, James Gould wrote:

<= SPAN STYLE=3D'font-size:11pt'>“If this "select" solution is ta= ken, I don't mind whether it is implemented via
elements or attributes.”

=
I was under the impression that the selectType idea was pretty much dead.

<= SPAN STYLE=3D'font-size:11pt'>
Either the elements or attributes will work, but I still like your sc= hema proposal the best. The key is whether the elements (keyTag, alg, = digestType, and digest) are required or optional and if they’re option= al what happens if the specified elements match multiple DS records. I= don’t have an issue making them optional as long as the registry retu= rns an error if they match more then one DS record. I see it as a big = issue if the client accidently deletes more then what was desired because th= ey didn’t specify enough unique information.   It’s be= tter to error out and require the client to explicitly specify what they wan= t deleted.

=
If I once again go back to RFC 5731, I see that non-unique attributes of an= element that is to be selected for the rem command are optional. If w= e want to keep the EPP flavor, then I'd suggest that we only require the dig= est itself, and make the others optional.

-Howard

<= SPAN STYLE=3D'font-size:11pt'>

--

JG

-------------------------------------------------------
= James F. Gould
= Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, = proprietary and/or Registry Sensitive information intended solely for = the recipient and, thus may not be retransmitted, reproduced or disclo= sed without the prior written consent of VeriSign Naming and Directory= Services. If you have received this e-mail message in error,= please notify the sender immediately by telephone or reply e-mail and= destroy the original message without making a copy. Thank y= ou.

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg <ietf-provr= eg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 30/10/09 15:39, Andrew Sullivan wrote:
> Hi,

Hi Andrew,

>
> On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: >
>[...]
>> 2) there is a consensus that<add> and<rem>= elements shall be allowed in
>> a single request, which must be on the other hand mutually e= xclusive to
>> the<chg> element.
>
> Are we sure that the<add> and<rem> eleme= nts have to be processed in
> the order in which they appear? I am not completely sure. = I recall
> at least one operator who had an issue related to this
> processing-order question. If they do _not_ have to be so = processed,
> then in fact they can't be allowed in a single request because t= he
> effect could be different from what is intended. (Note tha= t this
> remark also means that there is by no means a consensus on this = matter
> yet.)
>
> [...]

This problem has always been the case with EPP. If I submit a domain = update
request with adding the status "clientHold" and removing th= e status "clientHold"
at the same time, what is the outcome? This applies to contacts, name= servers
and other stuff as well.

So the protocol should clearly say how such a situation shall be hand= led:
- define a static execution order, e.g. first the removal, then the a= ddition
- declare this as ambiguous and reject the order
- declare this as a non-change and ignore

By the way, as there seems to be some confusion: IMHO the order in th= e XML
document should *never* imply any order of execution.

>
> Not elements, but attributes, is the way I've got it at the mome= nt. I
> didn't include the attributes other than the hash in the text as= it's
> written, but I think James has convinced me there'd be no harm i= n
> adding the other ones.

If this "select" solution is taken, I don't mind whether it= is implemented via
elements or attributes.

Regards,

Klaus
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and simil= ar details
send "help" to ietf= -provreg-request@cafax.se




=

--B_3339759137_7953258-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIb73o021444 for ; Fri, 30 Oct 2009 19:37:07 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UIb7GD001122 for ietf-provreg-outgoing; Fri, 30 Oct 2009 19:37:07 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIb6uU003798 for ; Fri, 30 Oct 2009 19:37:06 +0100 (MET) Cc: Klaus Malorny , EPP Provreg Message-Id: <0A88AC3F-354F-4A9C-997E-F9C31F9EBB7E@afilias.info> From: Howard Eland To: James Gould In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-11--552252440 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Fri, 30 Oct 2009 13:37:01 -0500 References: X-Mailer: Apple Mail (2.936) X-Authenticated: True Sender: owner-ietf-provreg@cafax.se Precedence: bulk --Apple-Mail-11--552252440 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Oct 30, 2009, at 1:27 PM, James Gould wrote: > =93If this "select" solution is taken, I don't mind whether it is =20 > implemented via > elements or attributes.=94 I was under the impression that the selectType idea was pretty much =20 dead. > > Either the elements or attributes will work, but I still like your =20 > schema proposal the best. The key is whether the elements (keyTag, =20= > alg, digestType, and digest) are required or optional and if they=92re = =20 > optional what happens if the specified elements match multiple DS =20 > records. I don=92t have an issue making them optional as long as the =20= > registry returns an error if they match more then one DS record. I =20= > see it as a big issue if the client accidently deletes more then =20 > what was desired because they didn=92t specify enough unique =20 > information. It=92s better to error out and require the client to =20= > explicitly specify what they want deleted. If I once again go back to RFC 5731, I see that non-unique attributes =20= of an element that is to be selected for the rem command are =20 optional. If we want to keep the EPP flavor, then I'd suggest that we =20= only require the digest itself, and make the others optional. -Howard > > > --=20 > > > JG > > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > > > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > Notice to Recipient: This e-mail contains confidential, proprietary =20= > and/or Registry Sensitive information intended solely for the =20 > recipient and, thus may not be retransmitted, reproduced or =20 > disclosed without the prior written consent of VeriSign Naming and =20= > Directory Services. If you have received this e-mail message in =20 > error, please notify the sender immediately by telephone or reply e-=20= > mail and destroy the original message without making a copy. Thank =20= > you. > > > From: Klaus Malorny > Date: Fri, 30 Oct 2009 13:30:50 -0400 > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > > On 30/10/09 15:39, Andrew Sullivan wrote: > > Hi, > > Hi Andrew, > > > > > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > > > >[...] > >> 2) there is a consensus that and elements shall be =20 > allowed in > >> a single request, which must be on the other hand mutually =20 > exclusive to > >> the element. > > > > Are we sure that the and elements have to be processed =20= > in > > the order in which they appear? I am not completely sure. I recall > > at least one operator who had an issue related to this > > processing-order question. If they do _not_ have to be so =20 > processed, > > then in fact they can't be allowed in a single request because the > > effect could be different from what is intended. (Note that this > > remark also means that there is by no means a consensus on this =20 > matter > > yet.) > > > > [...] > > This problem has always been the case with EPP. If I submit a domain =20= > update > request with adding the status "clientHold" and removing the status =20= > "clientHold" > at the same time, what is the outcome? This applies to contacts, =20 > name servers > and other stuff as well. > > So the protocol should clearly say how such a situation shall be =20 > handled: > - define a static execution order, e.g. first the removal, then the =20= > addition > - declare this as ambiguous and reject the order > - declare this as a non-change and ignore > > By the way, as there seems to be some confusion: IMHO the order in =20 > the XML > document should *never* imply any order of execution. > > > > > Not elements, but attributes, is the way I've got it at the =20 > moment. I > > didn't include the attributes other than the hash in the text as =20 > it's > > written, but I think James has convinced me there'd be no harm in > > adding the other ones. > > If this "select" solution is taken, I don't mind whether it is =20 > implemented via > elements or attributes. > > Regards, > > Klaus > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=20 > =3D-=3D-=3D- > List run by majordomo software. For (Un-)subscription and similar =20 > details > send "help" to ietf-provreg-request@cafax.se > > --Apple-Mail-11--552252440 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Oct 30, 2009, = at 1:27 PM, James Gould wrote:

=93If this "select" solution is taken, I don't = mind whether it is implemented via
elements or = attributes.=94

I was = under the impression that the selectType idea was pretty much = dead.

Either = the elements or attributes will work, but I still like your schema = proposal the best. The key is whether the elements (keyTag, alg, = digestType, and digest) are required or optional and if they=92re = optional what happens if the specified elements match multiple DS = records. I don=92t have an issue making them optional as long as = the registry returns an error if they match more then one DS record. = I see it as a big issue if the client accidently deletes more then = what was desired because they didn=92t specify enough unique = information.   It=92s better to error out and require the = client to explicitly specify what they want = deleted.

If I once again = go back to RFC 5731, I see that non-unique attributes of an element that = is to be selected for the rem command are optional. If we want to = keep the EPP flavor, then I'd suggest that we only require the digest = itself, and make the others = optional.

-Howard


=
--

JG

= ------------------------------------------------= -------
James= F. Gould
Principal Software = Engineer
VeriSign Naming = Services
jgould@verisign.com
= Direct: 703.948.3271
Mobile: = 703.628.7063

=
21345 Ridgetop Circle
LS2-2-1
= Dulles, VA 20166

Notice to = Recipient: This e-mail contains confidential, proprietary = and/or Registry Sensitive information intended solely for the = recipient and, thus may not be retransmitted, reproduced or = disclosed without the prior written consent of VeriSign Naming and = Directory Services. If you have received this e-mail = message in error, please notify the sender immediately by = telephone or reply e-mail and destroy the original message without = making a copy. Thank you.
=

From: Klaus Malorny <Klaus.Malorny@knipp.de>
= Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg = <ietf-provreg@cafax.se>
= Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

= On 30/10/09 15:39, Andrew Sullivan wrote:
> Hi,

Hi = Andrew,

>
> On Fri, Oct 30, 2009 at 12:39:00PM +0100, = Klaus Malorny wrote:
>
>[...]
>> 2) there is a = consensus that<add> and<rem> elements shall be = allowed in
>> a single request, which must be on the other = hand mutually exclusive to
>> the<chg> = element.
>
> Are we sure that the<add> = and<rem> elements have to be processed in
> the = order in which they appear? I am not completely sure. I = recall
> at least one operator who had an issue related to = this
> processing-order question. If they do _not_ have to = be so processed,
> then in fact they can't be allowed in a single = request because the
> effect could be different from what is = intended. (Note that this
> remark also means that there is = by no means a consensus on this matter
> yet.)
>
> = [...]

This problem has always been the case with EPP. If I = submit a domain update
request with adding the status "clientHold" = and removing the status "clientHold"
at the same time, what is the = outcome? This applies to contacts, name servers
and other stuff as = well.

So the protocol should clearly say how such a situation = shall be handled:
- define a static execution order, e.g. first the = removal, then the addition
- declare this as ambiguous and reject = the order
- declare this as a non-change and ignore

By the = way, as there seems to be some confusion: IMHO the order in the XML
= document should *never* imply any order of execution.

>
= > Not elements, but attributes, is the way I've got it at the moment. = I
> didn't include the attributes other than the hash in = the text as it's
> written, but I think James has convinced me = there'd be no harm in
> adding the other ones.

If this = "select" solution is taken, I don't mind whether it is implemented = via
elements or attributes.

Regards,

Klaus
= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-<= br> List run by majordomo software. For (Un-)subscription and = similar details
send "help" to ietf-provreg-request@cafax.se

=

= --Apple-Mail-11--552252440-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIRD1f000410 for ; Fri, 30 Oct 2009 19:27:13 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UIRDHh022520 for ietf-provreg-outgoing; Fri, 30 Oct 2009 19:27:13 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UIRCS2012016 for ; Fri, 30 Oct 2009 19:27:12 +0100 (MET) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9UIOupt014695; Fri, 30 Oct 2009 14:24:56 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:27:01 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 Oct 2009 18:27:10 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 14:27:08 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Klaus Malorny , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpZiV8liR3+qGRdT1CdTh6VrAcShwABTdt5 In-Reply-To: <4AEB22CA.3050700@knipp.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339757629_7880254" X-OriginalArrivalTime: 30 Oct 2009 18:27:01.0542 (UTC) FILETIME=[92BABC60:01CA598E] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339757629_7880254 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable =B3This problem has always been the case with EPP. If I submit a domain updat= e request with adding the status "clientHold" and removing the status "clientHold" at the same time, what is the outcome? This applies to contacts, name servers and other stuff as well.=B2 We really haven=B9t run into any issues with adding and removing contacts, name servers, or host ip addresses at the same time. In our system, trying to add and remove the same element like the clientHold status will result i= n a 2306 =B3Parameter value policy error=B2. The adds and removes are applied to the object within a single transaction so there should really be no orderin= g issue and the registry can address corner cases like trying to add and remove the same element. =B3If this "select" solution is taken, I don't mind whether it is implemented via elements or attributes.=B2 Either the elements or attributes will work, but I still like your schema proposal the best. The key is whether the elements (keyTag, alg, digestType, and digest) are required or optional and if they=B9re optional what happens if the specified elements match multiple DS records. I don=B9t have an issue making them optional as long as the registry returns an error if they match more then one DS record. I see it as a big issue if the client accidently deletes more then what was desired because they didn=B9t specify enough unique information. It=B9s better to error out and require the client to explicitly specify what they want deleted. --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Klaus Malorny Date: Fri, 30 Oct 2009 13:30:50 -0400 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? On 30/10/09 15:39, Andrew Sullivan wrote: > Hi, Hi Andrew, > > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > >[...] >> 2) there is a consensus that and elements shall be allowed i= n >> a single request, which must be on the other hand mutually exclusive to >> the element. > > Are we sure that the and elements have to be processed in > the order in which they appear? I am not completely sure. I recall > at least one operator who had an issue related to this > processing-order question. If they do _not_ have to be so processed, > then in fact they can't be allowed in a single request because the > effect could be different from what is intended. (Note that this > remark also means that there is by no means a consensus on this matter > yet.) > > [...] This problem has always been the case with EPP. If I submit a domain update request with adding the status "clientHold" and removing the status "clientHold" at the same time, what is the outcome? This applies to contacts, name servers and other stuff as well. So the protocol should clearly say how such a situation shall be handled: - define a static execution order, e.g. first the removal, then the additio= n - declare this as ambiguous and reject the order - declare this as a non-change and ignore By the way, as there seems to be some confusion: IMHO the order in the XML document should *never* imply any order of execution. > > Not elements, but attributes, is the way I've got it at the moment. I > didn't include the attributes other than the hash in the text as it's > written, but I think James has convinced me there'd be no harm in > adding the other ones. If this "select" solution is taken, I don't mind whether it is implemented via elements or attributes. Regards, Klaus -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se --B_3339757629_7880254 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? “This problem has always been the case with EPP. If I submit a domai= n update
request with adding the status "clientHold" and removing the stat= us "clientHold"
at the same time, what is the outcome? This applies to contacts, name serve= rs
and other stuff as well.”

We really haven’t run into any issues with adding and removing contac= ts, name servers, or host ip addresses at the same time. In our system= , trying to add and remove the same element like the clientHold status will = result in a 2306 “Parameter value policy error”. The adds = and removes are applied to the object within a single transaction so there s= hould really be no ordering issue and the registry can address corner cases = like trying to add and remove the same element.

“If this "select" solution is taken, I don't mind whether i= t is implemented via
elements or attributes.”

Either the elements or attributes will work, but I still like your schema p= roposal the best. The key is whether the elements (keyTag, alg, digest= Type, and digest) are required or optional and if they’re optional wha= t happens if the specified elements match multiple DS records. I don&#= 8217;t have an issue making them optional as long as the registry returns an= error if they match more then one DS record. I see it as a big issue = if the client accidently deletes more then what was desired because they did= n’t specify enough unique information.   It’s better t= o error out and require the client to explicitly specify what they want dele= ted.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 13:30:50 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 30/10/09 15:39, Andrew Sullivan wrote:
> Hi,

Hi Andrew,

>
> On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote:
>
>[...]
>> 2) there is a consensus that<add> and<rem> = ;elements shall be allowed in
>> a single request, which must be on the other hand mutually exclusi= ve to
>> the<chg> element.
>
> Are we sure that the<add> and<rem> elements ha= ve to be processed in
> the order in which they appear? I am not completely sure. = I recall
> at least one operator who had an issue related to this
> processing-order question. If they do _not_ have to be so proces= sed,
> then in fact they can't be allowed in a single request because the
> effect could be different from what is intended. (Note that this=
> remark also means that there is by no means a consensus on this matter=
> yet.)
>
> [...]

This problem has always been the case with EPP. If I submit a domain update=
request with adding the status "clientHold" and removing the stat= us "clientHold"
at the same time, what is the outcome? This applies to contacts, name serve= rs
and other stuff as well.

So the protocol should clearly say how such a situation shall be handled: - define a static execution order, e.g. first the removal, then the additio= n
- declare this as ambiguous and reject the order
- declare this as a non-change and ignore

By the way, as there seems to be some confusion: IMHO the order in the XML<= BR> document should *never* imply any order of execution.

>
> Not elements, but attributes, is the way I've got it at the moment. &n= bsp;I
> didn't include the attributes other than the hash in the text as it's<= BR> > written, but I think James has convinced me there'd be no harm in
> adding the other ones.

If this "select" solution is taken, I don't mind whether it is im= plemented via
elements or attributes.

Regards,

Klaus
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
List run by majordomo software. For (Un-)subscription and similar det= ails
send "help" to ietf-provr= eg-request@cafax.se

--B_3339757629_7880254-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHwTHB028140 for ; Fri, 30 Oct 2009 18:58:29 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UHwTr2011612 for ietf-provreg-outgoing; Fri, 30 Oct 2009 18:58:29 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHwSun028770 for ; Fri, 30 Oct 2009 18:58:28 +0100 (MET) Message-Id: <457B0D73-FE83-4573-8A40-0EB6A9640414@afilias.info> From: Howard Eland To: EPP Provreg In-Reply-To: <4AEB22CA.3050700@knipp.de> Content-Type: multipart/alternative; boundary=Apple-Mail-9--554568343 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Fri, 30 Oct 2009 12:58:25 -0500 References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> <4AEB22CA.3050700@knipp.de> X-Mailer: Apple Mail (2.936) X-Authenticated: True Sender: owner-ietf-provreg@cafax.se Precedence: bulk --Apple-Mail-9--554568343 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 30, 2009, at 12:30 PM, Klaus Malorny wrote: > On 30/10/09 15:39, Andrew Sullivan wrote: >> Hi, > > Hi Andrew, > >> >> On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: >> >> [...] >>> 2) there is a consensus that and elements shall be >>> allowed in >>> a single request, which must be on the other hand mutually >>> exclusive to >>> the element. >> >> Are we sure that the and elements have to be processed in >> the order in which they appear? I am not completely sure. I recall >> at least one operator who had an issue related to this >> processing-order question. If they do _not_ have to be so processed, >> then in fact they can't be allowed in a single request because the >> effect could be different from what is intended. (Note that this >> remark also means that there is by no means a consensus on this >> matter >> yet.) >> >> [...] > > This problem has always been the case with EPP. If I submit a domain > update request with adding the status "clientHold" and removing the > status "clientHold" at the same time, what is the outcome? This > applies to contacts, name servers and other stuff as well. > > So the protocol should clearly say how such a situation shall be > handled: > - define a static execution order, e.g. first the removal, then the > addition > - declare this as ambiguous and reject the order > - declare this as a non-change and ignore > > By the way, as there seems to be some confusion: IMHO the order in > the XML document should *never* imply any order of execution. Yes and no - that's _exactly_ what is for - to prescribe a predetermined order via XML. If we follow RFC5731 (see below), using domain status as in Klaus' example, then the correct thing to do is declare update child elements as a , with add first, then rem. The RFC is silent beyond that, so I would assume that this means the server must execute all adds in any order, then execute all rems in any order, then execute all chgs in any order. > >> >> Not elements, but attributes, is the way I've got it at the >> moment. I >> didn't include the attributes other than the hash in the text as it's >> written, but I think James has convinced me there'd be no harm in >> adding the other ones. > > If this "select" solution is taken, I don't mind whether it is > implemented via elements or attributes. > > Regards, > > Klaus > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > List run by majordomo software. For (Un-)subscription and similar > details > send "help" to ietf-provreg-request@cafax.se > --Apple-Mail-9--554568343 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 30, 2009, = at 12:30 PM, Klaus Malorny wrote:

On = 30/10/09 15:39, Andrew Sullivan wrote:
Hi,

Hi Andrew,

On Fri, Oct 30, = 2009 at 12:39:00PM +0100, Klaus Malorny = wrote:

[...]
2) there is a consensus that<add> = and<rem> elements shall be allowed = in
a single request, which must be on the other hand mutually = exclusive to
the<chg> = element.

Are we sure = that the<add> and<rem> elements have to be = processed in
the order in = which they appear? I am not completely sure. I = recall
at least one operator = who had an issue related to this
processing-order question. If they do _not_ have to = be so processed,
then in fact = they can't be allowed in a single request because = the
effect could be different = from what is intended. (Note that this
remark also means that there is by no means a consensus on = this matter
yet.)

[...]

This problem has always been the = case with EPP. If I submit a domain update request with adding the = status "clientHold" and removing the status "clientHold" at the same = time, what is the outcome? This applies to contacts, name servers and = other stuff as well.

So the protocol should clearly say how such = a situation shall be handled:
- define a static execution order, e.g. = first the removal, then the addition
- declare this as ambiguous and = reject the order
- declare this as a non-change and ignore

By = the way, as there seems to be some confusion: IMHO the order in the XML = document should *never* imply any order of = execution.

Yes and no - that's = _exactly_ what <sequence> is for - to prescribe a predetermined = order via XML.

If we follow RFC5731 (see = below), using domain status as in Klaus' example, then the correct thing = to do is declare update child elements as a <sequence>, with add = first, then rem. The RFC is silent beyond that, so I would assume = that this means the server must execute all adds in any order, then = execute all rems in any order, then execute all chgs in any = order.

 <complexType name=3D"updateType"> <sequence> <element name=3D"name" type=3D"eppcom:labelType"/> <element name=3D"add" type=3D"domain:addRemType" minOccurs=3D"0"/> <element name=3D"rem" type=3D"domain:addRemType" minOccurs=3D"0"/> <element name=3D"chg" type=3D"domain:chgType" minOccurs=3D"0"/> </sequence> </complexType>

Not elements, = but attributes, is the way I've got it at the moment. = I
didn't include the = attributes other than the hash in the text as = it's
written, but I think = James has convinced me there'd be no harm in
adding the other ones.

If this = "select" solution is taken, I don't mind whether it is implemented via = elements or = attributes.

Regards,

Klaus
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo = software. For (Un-)subscription and similar details
send "help" = to ietf-provreg-request@cafax.s= e

= --Apple-Mail-9--554568343-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHV2cE021987 for ; Fri, 30 Oct 2009 18:31:02 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UHV2nS002239 for ietf-provreg-outgoing; Fri, 30 Oct 2009 18:31:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UHV1u8010290 for ; Fri, 30 Oct 2009 18:31:01 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 5A94DFF; Fri, 30 Oct 2009 18:30:59 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id DWVTH61GMq0i; Fri, 30 Oct 2009 18:30:53 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id B9BBDFE; Fri, 30 Oct 2009 18:30:53 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id n9UHUrPv015930; Fri, 30 Oct 2009 18:30:53 +0100 (MEZ) Message-ID: <4AEB22CA.3050700@knipp.de> Date: Fri, 30 Oct 2009 18:30:50 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5pre) Gecko/20091029 Shredder/3.0pre MIME-Version: 1.0 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> In-Reply-To: <20091030143945.GE76006@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 30/10/09 15:39, Andrew Sullivan wrote: > Hi, Hi Andrew, > > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > >[...] >> 2) there is a consensus that and elements shall be allowed in >> a single request, which must be on the other hand mutually exclusive to >> the element. > > Are we sure that the and elements have to be processed in > the order in which they appear? I am not completely sure. I recall > at least one operator who had an issue related to this > processing-order question. If they do _not_ have to be so processed, > then in fact they can't be allowed in a single request because the > effect could be different from what is intended. (Note that this > remark also means that there is by no means a consensus on this matter > yet.) > > [...] This problem has always been the case with EPP. If I submit a domain update request with adding the status "clientHold" and removing the status "clientHold" at the same time, what is the outcome? This applies to contacts, name servers and other stuff as well. So the protocol should clearly say how such a situation shall be handled: - define a static execution order, e.g. first the removal, then the addition - declare this as ambiguous and reject the order - declare this as a non-change and ignore By the way, as there seems to be some confusion: IMHO the order in the XML document should *never* imply any order of execution. > > Not elements, but attributes, is the way I've got it at the moment. I > didn't include the attributes other than the hash in the text as it's > written, but I think James has convinced me there'd be no harm in > adding the other ones. If this "select" solution is taken, I don't mind whether it is implemented via elements or attributes. Regards, Klaus -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFvmct016039 for ; Fri, 30 Oct 2009 16:57:48 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UFvm4x000991 for ietf-provreg-outgoing; Fri, 30 Oct 2009 16:57:48 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFvlTb027663 for ; Fri, 30 Oct 2009 16:57:47 +0100 (MET) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7437A2FE8CDC; Fri, 30 Oct 2009 15:57:46 +0000 (UTC) Date: Fri, 30 Oct 2009 11:57:44 -0400 From: Andrew Sullivan To: "Hollenbeck, Scott" Cc: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091030155744.GH76006@shinkuro.com> Mail-Followup-To: Andrew Sullivan , "Hollenbeck, Scott" , EPP Provreg References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> <046F43A8D79C794FA4733814869CDF0702ECDE6B@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF0702ECDE6B@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Oct 30, 2009 at 11:37:38AM -0400, Hollenbeck, Scott wrote: > The answer to this question is implicit in the understanding of how XML > Schema works. Aha, well, this is obviously where I fell down. > If the is changed to a , the order will be specified > in the schema. If you don't want the order to matter, use . I > would like to suggest that a sequence makes more sense if you want to > avoid issues related to processing order. Ok, cool. This is terribly helpful. Expect the next iteration to include this strategy, then. Thanks! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFbfau008772 for ; Fri, 30 Oct 2009 16:37:41 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UFbfSB010536 for ietf-provreg-outgoing; Fri, 30 Oct 2009 16:37:41 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UFbeNC002876 for ; Fri, 30 Oct 2009 16:37:40 +0100 (MET) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9UFZPV7006335; Fri, 30 Oct 2009 11:35:25 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:37:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Anyone working on 4310-bis? Date: Fri, 30 Oct 2009 11:37:38 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702ECDE6B@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <20091030143945.GE76006@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? thread-index: AcpZcjF4KtG4eCV6TR+bl1D53mwSpAAAyVQg References: <4AEAD054.5030503@knipp.de> <20091030143945.GE76006@shinkuro.com> From: "Hollenbeck, Scott" To: "Andrew Sullivan" , "EPP Provreg" X-OriginalArrivalTime: 30 Oct 2009 15:37:39.0389 (UTC) FILETIME=[E99D3ED0:01CA5976] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9UFbfNC007693 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Friday, October 30, 2009 10:40 AM > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? [snip] > Are we sure that the and elements have to be > processed in the order in which they appear? I am not > completely sure. I recall at least one operator who had an > issue related to this processing-order question. If they do > _not_ have to be so processed, then in fact they can't be > allowed in a single request because the effect could be > different from what is intended. (Note that this remark also > means that there is by no means a consensus on this matter > yet.) > > RFC5731 says, "Commands are processed by a server in the > order they are received from a client." But in this case > these aren't actually different commands, and I have so far > been unable to convince myself that a server operator has to > process the elements of one command in the order in which > those elements appear. If someone knows otherwise (and I > would be very much pleased to have such proof), I'd like to > hear it. But as things stand, my reading is that a server > operator could handle all the elements first, and all > the elements second, and the effect of that could be > quite different than what we're trying to achieve. The answer to this question is implicit in the understanding of how XML Schema works. As currently specified, the and elements are part of a . Only one can appear, so there's no ordering issue. If the is changed to a , the order will be specified in the schema. If you don't want the order to matter, use . I would like to suggest that a sequence makes more sense if you want to avoid issues related to processing order. Scott -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UF8MuZ001985 for ; Fri, 30 Oct 2009 16:08:22 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UF8Mhv008694 for ietf-provreg-outgoing; Fri, 30 Oct 2009 16:08:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UF8LPY027409 for ; Fri, 30 Oct 2009 16:08:21 +0100 (MET) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n9UEqUa3005213; Fri, 30 Oct 2009 10:52:30 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 11:08:20 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 Oct 2009 15:08:20 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 30 Oct 2009 11:08:16 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Klaus Malorny , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpZWUVDgZeBOF6kT6uG51N1zOsZswAGYlIa In-Reply-To: <4AEAD054.5030503@knipp.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339745698_7158825" X-OriginalArrivalTime: 30 Oct 2009 15:08:20.0303 (UTC) FILETIME=[D11E05F0:01CA5972] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339745698_7158825 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Klaus, Thanks for the summary of the topic. I personally liked the schema updates that you had proposed with the added text around returning an error for use of the existing method when more than one DS record matches and clarity around the use of the , so my responses are pretty much in line with that proposal below. --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Klaus Malorny Date: Fri, 30 Oct 2009 07:39:00 -0400 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Hi all, trying to catch up on the e-mails of yesterday, I'd like to summarize the state of the discussion as far as I understand: 1) it is a little bit unclear to me whether we still want to create an update of RFC 4310 that is fully backward compatible, XML-wise and mostly semantically. 2) there is a consensus that and elements shall be allowed in a single request, which must be on the other hand mutually exclusive to the element. I agree the and should be allowed at the same time. This makes it consistent with the other EPP RFC=B9s. If and were supported at the same time, if we could uniquely identify each DS record, and if we weren=B9t worried about backward compatibility, then the option could b= e removed. =20 3) there is a consensus that as of RFC 4310, the is a replace-all operation, i.e. all existing DS records are removed completely and independently from the data provided and the provided DS records are added. In it=B9s current form, for the current specification to work, the need= s to be interpreted as a replace all. Having to split an update with multiple DS across multiple commands, is not a good practice and increases the risk of domains be published in an in-the-middle invalid state. 4) there is a disagreement of how to interpret a 1234 in the case that multiple DS records with this key tag have been provisioned earlier. One choice is to reject the operation, the other is to remove all DS records matching the key tag. There is a thir= d choice of removing the the element at all. I believe that it should be reject if there is a mechanism to uniquely identify a DS record. We are planning on deleting all of the matching DS records with the current specification, which is one of the areas of confusion that I would like to be fixed. EPP should be explicit to what th= e client really wants to do, so I=B9m in favor of rejecting if there is ambiguity and we=B9re supporting the existing form of for backward compatibility. This is at list backward compatibility from an XML schema perspective. =20 5) there is a disagreement of how to repair the element. One choice i= s to use the existing "dsDataType", with the semantics that it must match exactl= y an existing DS record, otherwise the request will fail (questionable though what an exact match is). The other choice is to create a separate "selectType" datatype which contains optional elements only. All existing DS records are tested against the respective element. If a key tag, algorithm, digest type or digest has been specified, the respective component must match, otherwise the DS record is retained. While easy to define, still unknown what happens if no DS records match or a DS record matches multiple "selectType" instances. I prefer just using the dsDataType since there should be no question relate= d to matching the DS. I don=B9t believe that there should be two DS records fo= r a domain with the same four elements (keyTag, alg, digestType, and digest) and the registry should ensure this. There is the very remotely possibilit= y of having more than one DS record with the combination of a subset of the elements. Although I agree the likelihood of duplicate digest values is statistically impossible. I don=B9t see any huge advantage to use a subset o= f the elements since it leaves no ambiguity. Supporting the existing scheme for backward compatibility should return an error when more than one DS records matches if the dsDataType scheme is supported. 6) if we break backward compatibility, the element can be revisited. It is unclear to me whether registries exist that would prefer to have the key data *instead* of the DS data and not *in addition*. We are not planning on supporting the optional element. Please feel free to correct me if I misunderstood something. ------- Now my further comments: * If we break compatibility, then we should consider removing either / or for the sake of symmetry to the base EPP standards and extensions. As far as I understand the Scott Hollenbeck's design pattern, there is *either= * a replace-all/change strategy *or* an add/remove strategy on a certain data element. For example, the registrant contact adheres the "change" strategy, while the other contacts adhere an add/remove strategy. RFC 4310 breaks it. * I am a little bit undetermined regarding the "selectType" approach. While it is a nice idea, it is also some kind of novelty in the EPP world. As far as I can remember, always the same datatype has been used for both the removal and addition. Of course, not in all cases all data fields have been used for comparison. For example, I assume no registry implementation will check the human readable text and the language for a removal of a status value, while it is possible to specify it. Also, I don't see that much the use cases. IMHO the most frequent use will be the KSK rollover, and for that purpose, this flexibility is not required. * regarding 4), the element, I think the least trouble is to allow the removal of multiple DS records, but still rejecting the request, if no DS record is found at all. Regards, Klaus -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se --B_3339745698_7158825 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? Klaus,

Thanks for the summary of the topic. I personally liked the schema up= dates that you had proposed with the added text around returning an error fo= r use of the existing <rem><keyTag> method when more than one DS= record matches and clarity around the use of the <chg>, so my respons= es are pretty much in line with that proposal below.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 07:39:00 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi all,

trying to catch up on the e-mails of yesterday, I'd like to summarize the s= tate
of the discussion as far as I understand:

1) it is a little bit unclear to me whether we still want to create an upda= te of
RFC 4310 that is fully backward compatible, XML-wise and mostly semanticall= y.

2) there is a consensus that <add> and <rem> elements shall be = allowed in a
single request, which must be on the other hand mutually exclusive to the &= lt;chg>
element.

I agree the <add> and <rem> should be allowed at the same time.= This makes it consistent with the other EPP RFC’s. If <= ;add> and <rem> were supported at the same time, if we could unique= ly identify each DS record, and if we weren’t worried about backward c= ompatibility, then the <chg> option could be removed.

3) there is a consensus that as of RFC 4310, the <chg> is a replace-a= ll
operation, i.e. all existing DS records are removed completely and independ= ently
from the data provided and the provided DS records are added.

In it’s current form, for the current specification to work, the <= chg> needs to be interpreted as a replace all. Having to spli= t an update with multiple DS across multiple commands, is not a good practic= e and increases the risk of domains be published in an in-the-middle invalid= state.

4) there is a disagreement of how to interpret a
<rem><keytag>1234</keytag></rem> in the case that m= ultiple DS records with this
key tag have been provisioned earlier. One choice is to reject the operatio= n,
the other is to remove all DS records matching the key tag. There is a thir= d
choice of removing the the <keytag> element at all.

I believe that it should be reject if there is a mechanism to uniquely iden= tify a DS record. We are planning on deleting all of the matching DS r= ecords with the current specification, which is one of the areas of confusio= n that I would like to be fixed. EPP should be explicit to what the cl= ient really wants to do, so I’m in favor of rejecting if there is ambi= guity and we’re supporting the existing form of <rem> for backwa= rd compatibility. This is at list backward compatibility from an XML s= chema perspective.

5) there is a disagreement of how to repair the <rem> element. One ch= oice is to
use the existing "dsDataType", with the semantics that it must ma= tch exactly an
existing DS record, otherwise the request will fail (questionable though wh= at an
exact match is). The other choice is to create a separate "selectType&= quot; datatype
which contains optional elements only. All existing DS records are tested against the respective element. If a key tag, algorithm, digest type or dig= est
has been specified, the respective component must match, otherwise the DS r= ecord
is retained. While easy to define, still unknown what happens if no DS reco= rds
match or a DS record matches multiple "selectType" instances.

I prefer just using the dsDataType since there should be no question relate= d to matching the DS. I don’t believe that there should be two D= S records for a domain with the same four elements (keyTag, alg, digestType,= and digest) and the registry should ensure this. There is the very re= motely possibility of having more than one DS record with the combination of= a subset of the elements. Although I agree the likelihood of duplicat= e digest values is statistically impossible. I don’t see any hug= e advantage to use a subset of the elements since it leaves no ambiguity. &n= bsp;Supporting the existing <rem><keyTag> scheme for backward co= mpatibility should return an error when more than one DS records matches if = the dsDataType scheme is supported.       &nbs= p;

6) if we break backward compatibility, the <keyData> element can be r= evisited.
It is unclear to me whether registries exist that would prefer to have the = key
data *instead* of the DS data and not *in addition*.

We are not planning on supporting the optional <keyData> element.

Please feel free to correct me if I misunderstood something.

-------

Now my further comments:

* If we break compatibility, then we should consider removing either <ad= d>/<rem>
or <chg> for the sake of symmetry to the base EPP standards and exten= sions. As
far as I understand the Scott Hollenbeck's design pattern, there is *either= * a
replace-all/change strategy *or* an add/remove strategy on a certain data element. For example, the registrant contact adheres the "change"= strategy,
while the other contacts adhere an add/remove strategy. RFC 4310 breaks it.=

* I am a little bit undetermined regarding the "selectType" appro= ach. While it
is a nice idea, it is also some kind of novelty in the EPP world. As far as= I
can remember, always the same datatype has been used for both the removal a= nd
addition. Of course, not in all cases all data fields have been used for comparison. For example, I assume no registry implementation will check the=
human readable text and the language for a removal of a status value, while= it
is possible to specify it. Also, I don't see that much the use cases. IMHO = the
most frequent use will be the KSK rollover, and for that purpose, this
flexibility is not required.

* regarding 4), the <keytag> element, I think the least trouble is to= allow the
removal of multiple DS records, but still rejecting the request, if no DS r= ecord
is found at all.

Regards,

Klaus

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
List run by majordomo software. For (Un-)subscription and similar det= ails
send "help" to ietf-provr= eg-request@cafax.se

--B_3339745698_7158825-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UEdoRA020850 for ; Fri, 30 Oct 2009 15:39:50 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UEdo98006988 for ietf-provreg-outgoing; Fri, 30 Oct 2009 15:39:50 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UEdmXo016367 for ; Fri, 30 Oct 2009 15:39:49 +0100 (MET) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1022E2FE8CDC for ; Fri, 30 Oct 2009 14:39:48 +0000 (UTC) Date: Fri, 30 Oct 2009 10:39:46 -0400 From: Andrew Sullivan To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091030143945.GE76006@shinkuro.com> Mail-Followup-To: Andrew Sullivan , EPP Provreg References: <4AEAD054.5030503@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AEAD054.5030503@knipp.de> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote: > 1) it is a little bit unclear to me whether we still want to create an > update of RFC 4310 that is fully backward compatible, XML-wise and mostly > semantically. My impression was that we _do_ need at least an update that allows old clients to continue to work, and will allow new clients to work with old servers. I haven't figured out whether it's possible to make the necessary schema changes and still be technically backward compatible, though I'm leaning toward "no". That will mean a bump in the schema version. Such a bump would be an even stronger reason to make it operationally backward compatible. I attach a -00 version as a scratch proposal. The draft submission window is closed due to the upcoming Hiroshima meeting, so I'm posting it here. Anyway, this doubtlessly needs changes before really being submitted. > 2) there is a consensus that and elements shall be allowed in > a single request, which must be on the other hand mutually exclusive to > the element. Are we sure that the and elements have to be processed in the order in which they appear? I am not completely sure. I recall at least one operator who had an issue related to this processing-order question. If they do _not_ have to be so processed, then in fact they can't be allowed in a single request because the effect could be different from what is intended. (Note that this remark also means that there is by no means a consensus on this matter yet.) RFC5731 says, "Commands are processed by a server in the order they are received from a client." But in this case these aren't actually different commands, and I have so far been unable to convince myself that a server operator has to process the elements of one command in the order in which those elements appear. If someone knows otherwise (and I would be very much pleased to have such proof), I'd like to hear it. But as things stand, my reading is that a server operator could handle all the elements first, and all the elements second, and the effect of that could be quite different than what we're trying to achieve. > 4) there is a disagreement of how to interpret a > 1234 in the case that multiple DS records > with this key tag have been provisioned earlier. One choice is to reject > the operation, the other is to remove all DS records matching the key > tag. There is a third choice of removing the the element at all. I have candidate text for this now. In order to make this backward compatible, one has to accept it in the protocol. I have written the text so that by registry policy, sich an operation can nevertheless be rejected. > 5) there is a disagreement of how to repair the element. One choice > is to use the existing "dsDataType", with the semantics that it must > match exactly an existing DS record, otherwise the request will fail > (questionable though what an exact match is). The other choice is to > create a separate "selectType" datatype which contains optional elements > only. All existing DS records are tested against the respective element. Not elements, but attributes, is the way I've got it at the moment. I didn't include the attributes other than the hash in the text as it's written, but I think James has convinced me there'd be no harm in adding the other ones. Comments are welcome. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UBdFiM011347 for ; Fri, 30 Oct 2009 12:39:15 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9UBdFIw024491 for ietf-provreg-outgoing; Fri, 30 Oct 2009 12:39:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9UBdEmQ017017 for ; Fri, 30 Oct 2009 12:39:14 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id F311FFB; Fri, 30 Oct 2009 12:39:07 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id uJV8aT6EQW5O; Fri, 30 Oct 2009 12:39:02 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 75A8EFA; Fri, 30 Oct 2009 12:39:02 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id n9UBd2UJ020632; Fri, 30 Oct 2009 12:39:02 +0100 (MEZ) Message-ID: <4AEAD054.5030503@knipp.de> Date: Fri, 30 Oct 2009 12:39:00 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5pre) Gecko/20091029 Shredder/3.0pre MIME-Version: 1.0 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi all, trying to catch up on the e-mails of yesterday, I'd like to summarize the state of the discussion as far as I understand: 1) it is a little bit unclear to me whether we still want to create an update of RFC 4310 that is fully backward compatible, XML-wise and mostly semantically. 2) there is a consensus that and elements shall be allowed in a single request, which must be on the other hand mutually exclusive to the element. 3) there is a consensus that as of RFC 4310, the is a replace-all operation, i.e. all existing DS records are removed completely and independently from the data provided and the provided DS records are added. 4) there is a disagreement of how to interpret a 1234 in the case that multiple DS records with this key tag have been provisioned earlier. One choice is to reject the operation, the other is to remove all DS records matching the key tag. There is a third choice of removing the the element at all. 5) there is a disagreement of how to repair the element. One choice is to use the existing "dsDataType", with the semantics that it must match exactly an existing DS record, otherwise the request will fail (questionable though what an exact match is). The other choice is to create a separate "selectType" datatype which contains optional elements only. All existing DS records are tested against the respective element. If a key tag, algorithm, digest type or digest has been specified, the respective component must match, otherwise the DS record is retained. While easy to define, still unknown what happens if no DS records match or a DS record matches multiple "selectType" instances. 6) if we break backward compatibility, the element can be revisited. It is unclear to me whether registries exist that would prefer to have the key data *instead* of the DS data and not *in addition*. Please feel free to correct me if I misunderstood something. ------- Now my further comments: * If we break compatibility, then we should consider removing either / or for the sake of symmetry to the base EPP standards and extensions. As far as I understand the Scott Hollenbeck's design pattern, there is *either* a replace-all/change strategy *or* an add/remove strategy on a certain data element. For example, the registrant contact adheres the "change" strategy, while the other contacts adhere an add/remove strategy. RFC 4310 breaks it. * I am a little bit undetermined regarding the "selectType" approach. While it is a nice idea, it is also some kind of novelty in the EPP world. As far as I can remember, always the same datatype has been used for both the removal and addition. Of course, not in all cases all data fields have been used for comparison. For example, I assume no registry implementation will check the human readable text and the language for a removal of a status value, while it is possible to specify it. Also, I don't see that much the use cases. IMHO the most frequent use will be the KSK rollover, and for that purpose, this flexibility is not required. * regarding 4), the element, I think the least trouble is to allow the removal of multiple DS records, but still rejecting the request, if no DS record is found at all. Regards, Klaus -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TJqXxB026889 for ; Thu, 29 Oct 2009 20:52:33 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9TJqXEA004406 for ietf-provreg-outgoing; Thu, 29 Oct 2009 20:52:33 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TJqWKE000665 for ; Thu, 29 Oct 2009 20:52:33 +0100 (MET) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9TJoIAD016357; Thu, 29 Oct 2009 15:50:18 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 19:52:30 +0000 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Oct 2009 19:52:30 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 15:52:27 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Howard Eland , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpYvFjWOzzp1P4pR8ynFZ7dirnNPQAFP5/r In-Reply-To: <99363757-F0D1-47F8-ADA5-75FE9247FD27@afilias.info> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339676348_6418696" X-OriginalArrivalTime: 29 Oct 2009 19:52:30.0839 (UTC) FILETIME=[599D9870:01CA58D1] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339676348_6418696 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable =B3One thing that does make using all four elements easier: it's consistent with both the add and chg operators, which may make it easier for implementors to code (well, a tiny bit, anyway). James, I'm not sure if this is to your point or not=B2 Yes, using all four elements makes it consistent with the add and chg. The rem could make some if not all of the 4 elements optional, but I=B9m not sure if this make things simpler or more complex for the client. =B3Codifying the edge cases is important, however, and it appears that we'll have to lose some of this compatibility to do so (regardless if we use just the hash on the rem, or the entire dsData). By requiring anything other than just the keyTag itself, it will not be backwards compatible for implementors - today, the keytag submission is sufficient, tomorrow, it will not be (going strictly by the RFC, not by registry policy).=B2 Yes, the backwards compatibility would only be at the XML schema level. This should be a reasonable compromise. --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Howard Eland Date: Thu, 29 Oct 2009 13:05:57 -0400 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? One thing that does make using all four elements easier: it's consistent with both the add and chg operators, which may make it easier for implementors to code (well, a tiny bit, anyway). James, I'm not sure if this is to your point or not. Codifying the edge cases is important, however, and it appears that we'll have to lose some of this compatibility to do so (regardless if we use just the hash on the rem, or the entire dsData). By requiring anything other than just the keyTag itself, it will not be backwards compatible for implementors - today, the keytag submission is sufficient, tomorrow, it will not be (going strictly by the RFC, not by registry policy). I am no longer particular to either method - they both would be fine. -Howard On Oct 29, 2009, at 10:57 AM, Howard Eland wrote: > This is what I was saying. The digest is unique (specially when > we're talking across only the same keytag), so the rest of the > information is superfluous. > > -Howard > > On Oct 29, 2009, at 10:32 AM, Andrew Sullivan wrote: > >> On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote: >> >>> still behaves like a replace, which again is backward compatible. >>> The only >>> difference is that all four elements need to be provided (keyTag, >>> alg, >>> digestType, digest) with a rem, which I don=B9t believe should be a >>> big issue. >>> Does anyone see an issue with having to specify either the keyTag >>> or all >>> four elements on a rem? >> >> Can you say why you prefer to use all four elements instead of just >> the digest? The digest actually is unique, so adding the other >> elements doesn't make it easier, I don't think, does it? >> >> A >> >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >> =3D-=3D-=3D-=3D- >> List run by majordomo software. For (Un-)subscription and similar >> details >> send "help" to ietf-provreg-request@cafax.se >> > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > =3D-=3D-=3D- > List run by majordomo software. For (Un-)subscription and similar > details > send "help" to ietf-provreg-request@cafax.se > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se --B_3339676348_6418696 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? “One thing that does make using all four elements easier: it's
consistent with both the add and chg operators, which may make it
easier for implementors to code (well, a tiny bit, anyway). James, I'm not sure if this is to your point or not”

Yes, using all four elements makes it consistent with the add and chg. &nbs= p;The rem could make some if not all of the 4 elements optional, but I’= ;m not sure if this make things simpler or more complex for the client.

“Codifying the edge cases is important, however, and it appears that =
we'll have to lose some of this compatibility to do so (regardless if
we use just the hash on the rem, or the entire dsData). By requiring =
anything other than just the keyTag itself, it will not be backwards
compatible for implementors - today, the keytag submission is
sufficient, tomorrow, it will not be (going strictly by the RFC, not
by registry policy).”

Yes, the backwards compatibility would only be at the XML schema level. &nb= sp;This should be a reasonable compromise.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Howard Eland <heland@afilias.info>
Date: Thu, 29 Oct 2009 13:05:57 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

One thing that does make using all four elements easier: it's
consistent with both the add and chg operators, which may make it
easier for implementors to code (well, a tiny bit, anyway). James, I'm not sure if this is to your point or not.

Codifying the edge cases is important, however, and it appears that
we'll have to lose some of this compatibility to do so (regardless if
we use just the hash on the rem, or the entire dsData). By requiring =
anything other than just the keyTag itself, it will not be backwards
compatible for implementors - today, the keytag submission is
sufficient, tomorrow, it will not be (going strictly by the RFC, not
by registry policy).

I am no longer particular to either method - they both would be fine.

-Howard

On Oct 29, 2009, at 10:57 AM, Howard Eland wrote:

> This is what I was saying. The digest is unique (specially when =
> we're talking across only the same keytag), so the rest of the
> information is superfluous.
>
> -Howard
>
> On Oct 29, 2009, at 10:32 AM, Andrew Sullivan wrote:
>
>> On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote:
>>
>>> still behaves like a replace, which again is backward compatib= le.
>>> The only
>>> difference is that all four elements need to be provided (keyT= ag,
>>> alg,
>>> digestType, digest) with a rem, which I don’t believe sh= ould be a
>>> big issue.
>>> Does anyone see an issue with having to specify either the key= Tag
>>> or all
>>> four elements on a rem?
>>
>> Can you say why you prefer to use all four elements instead of jus= t
>> the digest? The digest actually is unique, so adding the oth= er
>> elements doesn't make it easier, I don't think, does it?
>>
>> A
>>
>>
>> --
>> Andrew Sullivan
>> ajs@shinkuro.com
>> Shinkuro, Inc.
>> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -
>> =3D-=3D-=3D-=3D-
>> List run by majordomo software. For (Un-)subscription and si= milar
>> details
>> send "help" to i= etf-provreg-request@cafax.se
>>
>
>
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-<= BR> > =3D-=3D-=3D-
> List run by majordomo software. For (Un-)subscription and simila= r
> details
> send "help" to ietf-= provreg-request@cafax.se
>

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
List run by majordomo software. For (Un-)subscription and similar det= ails
send "help" to ietf-provr= eg-request@cafax.se

--B_3339676348_6418696-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TH61pT026276 for ; Thu, 29 Oct 2009 18:06:01 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9TH61Ta009990 for ietf-provreg-outgoing; Thu, 29 Oct 2009 18:06:01 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TH609x026457 for ; Thu, 29 Oct 2009 18:06:01 +0100 (MET) Message-Id: <99363757-F0D1-47F8-ADA5-75FE9247FD27@afilias.info> From: Howard Eland To: EPP Provreg In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Thu, 29 Oct 2009 12:05:57 -0500 References: <4AE7845A.7010305@knipp.de> <20091029153249.GH65688@shinkuro.com> X-Mailer: Apple Mail (2.936) X-Authenticated: True Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9TH619x018450 Sender: owner-ietf-provreg@cafax.se Precedence: bulk One thing that does make using all four elements easier: it's consistent with both the add and chg operators, which may make it easier for implementors to code (well, a tiny bit, anyway). James, I'm not sure if this is to your point or not. Codifying the edge cases is important, however, and it appears that we'll have to lose some of this compatibility to do so (regardless if we use just the hash on the rem, or the entire dsData). By requiring anything other than just the keyTag itself, it will not be backwards compatible for implementors - today, the keytag submission is sufficient, tomorrow, it will not be (going strictly by the RFC, not by registry policy). I am no longer particular to either method - they both would be fine. -Howard On Oct 29, 2009, at 10:57 AM, Howard Eland wrote: > This is what I was saying. The digest is unique (specially when > we're talking across only the same keytag), so the rest of the > information is superfluous. > > -Howard > > On Oct 29, 2009, at 10:32 AM, Andrew Sullivan wrote: > >> On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote: >> >>> still behaves like a replace, which again is backward compatible. >>> The only >>> difference is that all four elements need to be provided (keyTag, >>> alg, >>> digestType, digest) with a rem, which I don¹t believe should be a >>> big issue. >>> Does anyone see an issue with having to specify either the keyTag >>> or all >>> four elements on a rem? >> >> Can you say why you prefer to use all four elements instead of just >> the digest? The digest actually is unique, so adding the other >> elements doesn't make it easier, I don't think, does it? >> >> A >> >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-=-=- >> List run by majordomo software. For (Un-)subscription and similar >> details >> send "help" to ietf-provreg-request@cafax.se >> > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > List run by majordomo software. For (Un-)subscription and similar > details > send "help" to ietf-provreg-request@cafax.se > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TFvi8I020174 for ; Thu, 29 Oct 2009 16:57:44 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9TFviSs000496 for ietf-provreg-outgoing; Thu, 29 Oct 2009 16:57:44 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TFvhoq028574 for ; Thu, 29 Oct 2009 16:57:44 +0100 (MET) Cc: EPP Provreg Message-Id: From: Howard Eland To: Andrew Sullivan In-Reply-To: <20091029153249.GH65688@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Thu, 29 Oct 2009 10:57:38 -0500 References: <4AE7845A.7010305@knipp.de> <20091029153249.GH65688@shinkuro.com> X-Mailer: Apple Mail (2.936) X-Authenticated: True Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9TFvioq015056 Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is what I was saying. The digest is unique (specially when we're talking across only the same keytag), so the rest of the information is superfluous. -Howard On Oct 29, 2009, at 10:32 AM, Andrew Sullivan wrote: > On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote: > >> still behaves like a replace, which again is backward compatible. >> The only >> difference is that all four elements need to be provided (keyTag, >> alg, >> digestType, digest) with a rem, which I don¹t believe should be a >> big issue. >> Does anyone see an issue with having to specify either the keyTag >> or all >> four elements on a rem? > > Can you say why you prefer to use all four elements instead of just > the digest? The digest actually is unique, so adding the other > elements doesn't make it easier, I don't think, does it? > > A > > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > List run by majordomo software. For (Un-)subscription and similar > details > send "help" to ietf-provreg-request@cafax.se > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TFWrKC019607 for ; Thu, 29 Oct 2009 16:32:53 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9TFWrEO010598 for ietf-provreg-outgoing; Thu, 29 Oct 2009 16:32:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TFWqbB025182 for ; Thu, 29 Oct 2009 16:32:52 +0100 (MET) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9A2062FE8CDC for ; Thu, 29 Oct 2009 15:32:51 +0000 (UTC) Date: Thu, 29 Oct 2009 11:32:49 -0400 From: Andrew Sullivan To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091029153249.GH65688@shinkuro.com> Mail-Followup-To: Andrew Sullivan , EPP Provreg References: <4AE7845A.7010305@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote: > still behaves like a replace, which again is backward compatible. The only > difference is that all four elements need to be provided (keyTag, alg, > digestType, digest) with a rem, which I donÂ¹t believe should be a big issue. > Does anyone see an issue with having to specify either the keyTag or all > four elements on a rem? Can you say why you prefer to use all four elements instead of just the digest? The digest actually is unique, so adding the other elements doesn't make it easier, I don't think, does it? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TEKhWd011347 for ; Thu, 29 Oct 2009 15:20:43 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9TEKhZc017694 for ietf-provreg-outgoing; Thu, 29 Oct 2009 15:20:43 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9TEKgGj021598 for ; Thu, 29 Oct 2009 15:20:42 +0100 (MET) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 34F6D2FE8CDC for ; Thu, 29 Oct 2009 14:20:41 +0000 (UTC) Date: Thu, 29 Oct 2009 10:20:39 -0400 From: Andrew Sullivan To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091029142039.GF65688@shinkuro.com> Mail-Followup-To: Andrew Sullivan , EPP Provreg References: <907ABD87-2140-429A-80A8-56624A92D579@cisco.com> <4AE82EF2.1000802@publisher.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE82EF2.1000802@publisher.de> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Oct 28, 2009 at 12:45:54PM +0100, Ulrich Wisser wrote: > The add command (as well as update) uses the secDNS:dsDataType. Which > makes keytag, alg, digestType and digest mandatory. I know that .SE and > other registries considered to become a "fat" registry and take in the > public keys instead of the ds records. The DS records would be computed > from the public keys according to registry policies. > This case is not covered by 4310. While this is true, 4310 does provide an OPTIONAL element. Registry policy could require this. Then you could get the DS and the DNSKEY at the same time, and you could even check to be sure the DS they're providing actually matches the DNSKEY they're providing (and use that as a first-line test to make sure their plan is sane. If they can't generate the right DS, they are as likely to have other problems as not, and it could well be that you want to stop doing anything until it's sorted). No? I'm loathe to make the element OPTIONAL because it would necessarily mean changing the XML schema, which would cause changes to be strictly backwards incompatible. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SMkeDn028191 for ; Wed, 28 Oct 2009 23:46:40 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9SMkeT9008076 for ietf-provreg-outgoing; Wed, 28 Oct 2009 23:46:40 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SMkcsF018505 for ; Wed, 28 Oct 2009 23:46:39 +0100 (MET) Cc: Klaus Malorny , EPP Provreg Message-Id: From: Howard Eland To: James Gould In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Wed, 28 Oct 2009 17:46:33 -0500 References: X-Mailer: Apple Mail (2.936) X-Authenticated: True Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9SMkdsF008190 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Oct 28, 2009, at 5:19 PM, James Gould wrote: > Howard, > > I don’t believe that there is a desire to allow wildcard deletion of > DS > records. That is the existing issue, where the client requests to > delete > keyTag 12345 and if there are multiple DS records with the same > keyTag 1234 > for the domain, all of the DS records will be deleted. Not quite. The current standard ensures _all_ DS records under a specific keytag are transformed. I'm suggesting a way to allow anywhere from 1 to all DS records that match the keytag. Also, I'm attempting to make the functionality between these two commands consistent, and the spirit of the chg element in the current RFC seems to suggest that the change can occur for multiple DS records. See below for more on chg. > I believe it is > preferable to make the deletions as explicit as possible, where the > option > of using the dsDataType will address it by requiring all four > elements to be > passed (keyTag, alg, digestType, and digest) for uniquely > identifying the DS > record to delete. None of the attributes alone uniquely identify a DS > record, so the natural primary key is the combination of all four of > them. If we're shying away from selecting multiple DS records for transformation, then I agree with Ed - just use the hash. I'm still thinking that it would be good to be able to delete all alg ID 5 records, or all digest type 1 records, but maybe I'm in the minority here. > If clients desire to be able to uniquely identify a DS record by > using a > subset of the four elements, than a change could be made to make one > or more > of the elements of dsData optional by defining a new complexType like > dsDataType with minOccurs=”0”. The selectType meets the need, but > it best > not to introduce a new element like “select” under the rem element. > > My recommendation is for the registry to return an error if the client > specifies a DS that does not result in a single DS record being > deleted. If > we want to make the input elements for the rem flexible to allow the > client > to decide what uniquely identifies the DS to remove than the schema > could > look like below (the remType dsData element could be renamed to > something > like "select" if needed). Specifying no elements for the dsData > should > result in an error since it won't match anything. This still does not address the issue of the chg element. Maybe an example is in order: If I have two DS records each with keytag 12345, alg ID 5. One has digest type 1, the other, digest type 2, and each with their own digest. Under the current (and this) mechanism, how would one change _one_ of these to a new digest? There is no way to specify under chg which DS to affect. Currently, the only way I can see to do this would be to rem then add. That may be OK, but then why have chg at all? Another example would be "how does one change the keytag of one of these DS records, but not the other?" A rem/add is probably not called for here, as we could potentially break validation, albeit temporarily. I don't want to add complexity that isn't needed. However, I'd like to make sure that if we're going to the well to fix problems, we fix as many as we can see. I can certainly live without the multiple DS operations, but I think the selection bit needs to be addressed. -Howard > > > > > > > > > > minOccurs="0"/> > > minOccurs="0"/> > > > > > > > > > > > > > > > minOccurs="0"/> > minOccurs="0"/> > minOccurs="0"/> > minOccurs="0"/> > > > > > > > > > > > > > > > > > > > -- > > > JG > > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > > > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > Notice to Recipient: This e-mail contains confidential, proprietary > and/or > Registry Sensitive information intended solely for the recipient > and, thus > may not be retransmitted, reproduced or disclosed without the prior > written > consent of VeriSign Naming and Directory Services. If you have > received > this e-mail message in error, please notify the sender immediately by > telephone or reply e-mail and destroy the original message without > making a > copy. Thank you. > > > > From: Howard Eland > Date: Wed, 28 Oct 2009 17:19:32 -0400 > To: James Gould > Cc: Klaus Malorny , EPP Provreg > > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > > So, thinking about this, plus Ed's comments about being able to use > the > digest itself led me to add a couple more things. > > First, I'd think it'd be good to be able to specify which DS records > to > operate on with as little information as possible, and make it > flexible > (without having to specify the entire DS record). > > Second, I could see people wanting to do things like "remove all > algorithm > ID 5 records". > > So, I came up with a selectType, that let's you pick from keyTag, > alg ID, > digest type, or digest itself. For a rem, that's all that is needed. > However, to make this consistent, I added it to chg as well (creating > "chgType" in the process, so you could specify changing only one of > many DS > records without repeating the entire set. I made these changes to > your last > post of "updateType" below, so the simultaneous add/rem is in there > as well. > > I believe we're _mostly_ backwards compatible here (see Caveat 3). > A couple of caveats: > 1) Both with this and the post below, it looks like the XML would > allow for > a no-op on updateType (since the second choice contains all elements > with > minOccurs=0). > 2) I did not validate this XML yet - I wanted to explain the > concepts before > going any further. > 3) As written, this allows for selecting _no_ attributes, which, in > theory, > would allow one to remove all DS records for a domain object. > Currently RFC > 4310 does not allow this, because the keyTag is required. This adds > functionality, but at the expense of a foot-shotgun. > > (non-validated) XML code below. > > -Howard > > > > > > > > > > > > > > > minOccurs="0" maxOccurs="1"/> > minOccurs="0" maxOccurs="1"/> > minOccurs="0" maxOccurs="1"/> > minOccurs="0" maxOccurs="1"/> > > > > > maxOccurs="unbounded"/> > > > > > > > > > > > On Oct 28, 2009, at 9:32 AM, James Gould wrote: > >> Klaus, >> >> Your proposal will work with one small fix of replacing >> in >> remType to . This will be backward compatible, will >> address the >> issue of identifying the DS record to remove, and will support >> adding and >> removing more than one DS record in the same command. I like that >> the chg >> still behaves like a replace, which again is backward compatible. >> The only >> difference is that all four elements need to be provided (keyTag, >> alg, >> digestType, digest) with a rem, which I don’t believe should be a >> big issue. >> Does anyone see an issue with having to specify either the keyTag >> or all four >> elements on a rem? The following is the schema elements with the >> small fix >> that I tested through with various use cases successfully. >> >> > name="chg" type="secDNS:dsType"/> >> > name="add" type="secDNS:dsType" minOccurs="0"/> > name="rem" >> type="secDNS:remType" minOccurs="0"/> > choice> >> > complexType> >> >> > name="dsData" >> type="secDNS:dsDataType"/> >> >> The following tests worked and passed schema validation: >> >> >> * Passing a single add, chg, or rem with the rem containing just >> the keyTag. >> This is the backward compatible tests. >> * Passing multiple dsData elements for both the add and rem elements >> * Passing multiple keyTag or dsData elements with the rem element >> * >> >> >> >> -- >> >> >> JG >> >> ------------------------------------------------------- >> James F. Gould >> Principal Software Engineer >> VeriSign Naming Services >> jgould@verisign.com >> Direct: 703.948.3271 >> Mobile: 703.628.7063 >> >> >> 21345 Ridgetop Circle >> LS2-2-1 >> Dulles, VA 20166 >> >> Notice to Recipient: This e-mail contains confidential, >> proprietary and/or >> Registry Sensitive information intended solely for the recipient >> and, thus >> may not be retransmitted, reproduced or disclosed without the >> prior written >> consent of VeriSign Naming and Directory Services. If you have >> received >> this e-mail message in error, please notify the sender immediately by >> telephone or reply e-mail and destroy the original message without >> making a >> copy. Thank you. >> >> >> >> From: Klaus Malorny >> Date: Tue, 27 Oct 2009 19:38:02 -0400 >> To: James Gould >> Cc: Howard Eland , EPP Provreg > > >> Subject: Re: [ietf-provreg] Anyone working on 4310-bis? >> >> On 2009-10-27 22:31, James Gould wrote: >>> [...] >>> >>> Updated XML schema: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> maxOccurs="unbounded"/> >>> >>> >>> >>> [...] >> >> Hi James, >> >> instead of adding attributes, one could declare the content of the >> >> element >> to be a choice between the element and the >> element, with >> unbounded repetition, e.g. >> >> >> >> >> >> >> >> >> Also, I propose a change to allow both and to occur in >> the same >> request, i.e. something like this (may be formally incorrect, >> haven't checked >> the syntax): >> >> >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> Klaus >> >> >> > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SMKLrS016270 for ; Wed, 28 Oct 2009 23:20:21 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9SMKLGW023588 for ietf-provreg-outgoing; Wed, 28 Oct 2009 23:20:21 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SMKKwJ016225 for ; Wed, 28 Oct 2009 23:20:20 +0100 (MET) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9SMHlLf012740; Wed, 28 Oct 2009 18:17:47 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 18:19:59 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Oct 2009 22:19:57 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 18:19:53 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Howard Eland CC: Klaus Malorny , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpYFGCC6AQXgSROQw2BFvdSd+6jSQACGUJF In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 28 Oct 2009 22:19:59.0246 (UTC) FILETIME=[C9439AE0:01CA581C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9SMKLwJ019871 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Howard, I don¹t believe that there is a desire to allow wildcard deletion of DS records. That is the existing issue, where the client requests to delete keyTag 12345 and if there are multiple DS records with the same keyTag 1234 for the domain, all of the DS records will be deleted. I believe it is preferable to make the deletions as explicit as possible, where the option of using the dsDataType will address it by requiring all four elements to be passed (keyTag, alg, digestType, and digest) for uniquely identifying the DS record to delete. None of the attributes alone uniquely identify a DS record, so the natural primary key is the combination of all four of them. If clients desire to be able to uniquely identify a DS record by using a subset of the four elements, than a change could be made to make one or more of the elements of dsData optional by defining a new complexType like dsDataType with minOccurs=²0². The selectType meets the need, but it best not to introduce a new element like ³select² under the rem element. My recommendation is for the registry to return an error if the client specifies a DS that does not result in a single DS record being deleted. If we want to make the input elements for the rem flexible to allow the client to decide what uniquely identifies the DS to remove than the schema could look like below (the remType dsData element could be renamed to something like "select" if needed). Specifying no elements for the dsData should result in an error since it won't match anything. -- JG ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Howard Eland Date: Wed, 28 Oct 2009 17:19:32 -0400 To: James Gould Cc: Klaus Malorny , EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? So, thinking about this, plus Ed's comments about being able to use the digest itself led me to add a couple more things. First, I'd think it'd be good to be able to specify which DS records to operate on with as little information as possible, and make it flexible (without having to specify the entire DS record). Second, I could see people wanting to do things like "remove all algorithm ID 5 records". So, I came up with a selectType, that let's you pick from keyTag, alg ID, digest type, or digest itself. For a rem, that's all that is needed. However, to make this consistent, I added it to chg as well (creating "chgType" in the process, so you could specify changing only one of many DS records without repeating the entire set. I made these changes to your last post of "updateType" below, so the simultaneous add/rem is in there as well. I believe we're _mostly_ backwards compatible here (see Caveat 3). A couple of caveats: 1) Both with this and the post below, it looks like the XML would allow for a no-op on updateType (since the second choice contains all elements with minOccurs=0). 2) I did not validate this XML yet - I wanted to explain the concepts before going any further. 3) As written, this allows for selecting _no_ attributes, which, in theory, would allow one to remove all DS records for a domain object. Currently RFC 4310 does not allow this, because the keyTag is required. This adds functionality, but at the expense of a foot-shotgun. (non-validated) XML code below. -Howard On Oct 28, 2009, at 9:32 AM, James Gould wrote: > Klaus, > > Your proposal will work with one small fix of replacing in > remType to . This will be backward compatible, will address the > issue of identifying the DS record to remove, and will support adding and > removing more than one DS record in the same command. I like that the chg > still behaves like a replace, which again is backward compatible. The only > difference is that all four elements need to be provided (keyTag, alg, > digestType, digest) with a rem, which I don¹t believe should be a big issue. > Does anyone see an issue with having to specify either the keyTag or all four > elements on a rem? The following is the schema elements with the small fix > that I tested through with various use cases successfully. > > name="chg" type="secDNS:dsType"/> name="add" type="secDNS:dsType" minOccurs="0"/> type="secDNS:remType" minOccurs="0"/> > > > type="secDNS:dsDataType"/> > > The following tests worked and passed schema validation: > > > * Passing a single add, chg, or rem with the rem containing just the keyTag. > This is the backward compatible tests. > * Passing multiple dsData elements for both the add and rem elements > * Passing multiple keyTag or dsData elements with the rem element > * > > > > -- > > > JG > > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > > > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > Notice to Recipient: This e-mail contains confidential, proprietary and/or > Registry Sensitive information intended solely for the recipient and, thus > may not be retransmitted, reproduced or disclosed without the prior written > consent of VeriSign Naming and Directory Services. If you have received > this e-mail message in error, please notify the sender immediately by > telephone or reply e-mail and destroy the original message without making a > copy. Thank you. > > > > From: Klaus Malorny > Date: Tue, 27 Oct 2009 19:38:02 -0400 > To: James Gould > Cc: Howard Eland , EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > > On 2009-10-27 22:31, James Gould wrote: >> [...] >> >> Updated XML schema: >> >> >> >> >> >> >> >> >> >> >> >> >> > maxOccurs="unbounded"/> >> >> >> >> [...] > > Hi James, > > instead of adding attributes, one could declare the content of the > element > to be a choice between the element and the element, with > unbounded repetition, e.g. > > > > > > > > > Also, I propose a change to allow both and to occur in the same > request, i.e. something like this (may be formally incorrect, haven't checked > the syntax): > > > > > > > > > > > > > > Regards, > > Klaus > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SIk5mM013976 for ; Wed, 28 Oct 2009 19:46:05 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9SIk5Lg009348 for ietf-provreg-outgoing; Wed, 28 Oct 2009 19:46:05 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SIk4Ye014915 for ; Wed, 28 Oct 2009 19:46:05 +0100 (MET) Received: from [10.31.200.226] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9SIjxaT004547; Wed, 28 Oct 2009 14:46:00 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> Date: Wed, 28 Oct 2009 14:45:23 -0400 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9SIk5Ye001071 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 22:23 +0100 10/27/09, Patrik Fältström wrote: >Yeah, also just saw this in 4034: > >> The key tag is used to help select DNSKEY resource records >> efficiently, but it does not uniquely identify a single DNSKEY >> resource record. It is possible for two distinct DNSKEY RRs to have >> the same owner name, the same algorithm type, and the same key tag. >> An implementation that uses only the key tag to select a DNSKEY RR >> might select the wrong public key in some circumstances. Please see >> Appendix B for further details. > >Who the heck came up with this? ;-) So Olafur and I are throwing rocks at each other over that question.... The idea of the keytag predates memory, the desire was to have someway to select one of the keys in an RRset. (In DNS, there is no other selector "inside" an RRset.) The reason that the keytag is non-unique is, well, the things it is trying to describe/compress in 16 bits are practically random. You can't compress random data (think about it) without loss. In this case, we lose uniqueness. Perhaps you could hash the key instead ... hey, that's what the DS record does! The mistake here is using the keytag and not the DS hash as the selector. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SEWu4D028340 for ; Wed, 28 Oct 2009 15:32:56 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9SEWuac027070 for ietf-provreg-outgoing; Wed, 28 Oct 2009 15:32:56 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SEWslV029560 for ; Wed, 28 Oct 2009 15:32:55 +0100 (MET) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n9SEGlCo022252; Wed, 28 Oct 2009 10:16:47 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:32:33 +0000 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Oct 2009 14:32:32 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 10:32:19 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Klaus Malorny CC: Howard Eland , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpXdmo7oON9R0tNTQWVOMZiBb5l4QAZQnRD In-Reply-To: <4AE7845A.7010305@knipp.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339570744_3019602" X-OriginalArrivalTime: 28 Oct 2009 14:32:33.0023 (UTC) FILETIME=[7C6998F0:01CA57DB] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339570744_3019602 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Klaus, Your proposal will work with one small fix of replacing in remType to . This will be backward compatible, will address the issue of identifying the DS record to remove, and will support adding and removing more than one DS record in the same command. I like that the chg still behaves like a replace, which again is backward compatible. The only difference is that all four elements need to be provided (keyTag, alg, digestType, digest) with a rem, which I don=B9t believe should be a big issue= . Does anyone see an issue with having to specify either the keyTag or all four elements on a rem? The following is the schema elements with the smal= l fix that I tested through with various use cases successfully. The following tests worked and passed schema validation: * Passing a single add, chg, or rem with the rem containing just the keyTag= . This is the backward compatible tests. * Passing multiple dsData elements for both the add and rem elements * Passing multiple keyTag or dsData elements with the rem element --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Klaus Malorny Date: Tue, 27 Oct 2009 19:38:02 -0400 To: James Gould Cc: Howard Eland , EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? On 2009-10-27 22:31, James Gould wrote: > [...] > > Updated XML schema: > > > > > > > > > > > > > maxOccurs=3D"unbounded"/> > > > > [...] Hi James, instead of adding attributes, one could declare the content of the element to be a choice between the element and the element, with unbounded repetition, e.g. Also, I propose a change to allow both and to occur in the same request, i.e. something like this (may be formally incorrect, haven't checked the syntax): Regards, Klaus --B_3339570744_3019602 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ietf-provreg] Anyone working on 4310-bis? Klaus,

Your proposal will work with one small fix of replacing </sequence> i= n remType to </choice>. This will be backward compatible,= will address the issue of identifying the DS record to remove, and wi= ll support adding and removing more than one DS record in the same command. = I like that the chg still behaves like a replace, which again is backw= ard compatible. The only difference is that all four elements need to = be provided (keyTag, alg, digestType, digest) with a rem, which I don’= t believe should be a big issue. Does anyone see an issue with having = to specify either the keyTag or all four elements on a rem? The follow= ing is the schema elements with the small fix that I tested through with var= ious use cases successfully.

    <complexType name=3D"updateType">        <choice>          <element name=3D&qu= ot;chg" type=3D"secDNS:dsType"/>          <sequence>            <elem= ent name=3D"add" type=3D"secDNS:dsType" minOccurs=3D"0&qu= ot;/>            <elem= ent name=3D"rem" type=3D"secDNS:remType" minOccurs=3D"0&q= uot;/>          </sequence>        </choice>        <attribute name=3D"urgent&= quot; type=3D"boolean" default=3D"false"/>    </complexType>            <complexType name=3D"remType">        <choice maxOccurs=3D"unbou= nded">          <element name=3D&qu= ot;keyTag" type=3D"unsignedShort"/>          <element name=3D&qu= ot;dsData" type=3D"secDNS:dsDataType"/>        </choice>    </complexType>

The following tests worked and passed schema validation:

Passing a single add, chg, or rem with the rem conta= ining just the keyTag. This is the backward compatible tests.
Passing multiple dsData elements for both the add = and rem elements
Passing multiple keyTag or dsData elements with the rem = element

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, propriet= ary and/or Registry Sensitive information intended solely for the reci= pient and, thus may not be retransmitted, reproduced or disclosed with= out the prior written consent of VeriSign Naming and Directory Service= s. If you have received this e-mail message in error, please = notify the sender immediately by telephone or reply e-mail and destroy= the original message without making a copy. Thank you.

From: Klaus Malorny <Klaus.Malorny@knip= p.de>
Date: Tue, 27 Oct 2009 19:38:02 -0400
To: James Gould <jgould@verisign.com&g= t;
Cc: Howard Eland <heland@afilias.info&= gt;, EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 2009-10-27 22:31, James Gould wrote:
> [...]
>
> Updated XML schema:
>      <complexType name=3D"remKeyType&qu= ot;>
>          <simpleConten= t>
>            &nbs= p; <extension base=3D"unsignedShort">
>            &nbs= p;     <attribute name=3D"alg" type=3D&quo= t;unsignedByte"/>
>            &nbs= p;     <attribute name=3D"digestType" ty= pe=3D"unsignedByte"/>
>            &nbs= p;     <attribute name=3D"digest" type=3D&= quot;hexBinary"/>
>            &nbs= p; </extension>
>          </simpleConte= nt>
>      </complexType>
>
>      <complexType name=3D"remType"= >
>          <sequence>=
>            &nbs= p; <element name=3D"keyTag" type=3D"secDNS:remKeyType&quo= t;
> maxOccurs=3D"unbounded"/>
>          </sequence>= ;
>      </complexType>
>
> [...]

Hi James,

instead of adding attributes, one could declare the content of the <rem&= gt; element
to be a choice between the <keyTag> element and the <dsData> el= ement, with
unbounded repetition, e.g.

      <complexType name=3D"remType"= ;>
        <choice maxOccurs=3D"= unbounded">
          <element nam= e=3D"keyTag" type=3D"unsignedShort"/>
          <element nam= e=3D"dsData" type=3D"secDNS:dsDataType"/>
        </sequence>
      </complexType>

Also, I propose a change to allow both <add> and <rem> to occur= in the same
request, i.e. something like this (may be formally incorrect, haven't check= ed
the syntax):

      <complexType name=3D"updateType&q= uot;>
        <choice>
          <element nam= e=3D"chg" type=3D"secDNS:dsType"/>
          <sequence>= ;
            <= ;element name=3D"add" type=3D"secDNS:dsType" minOccurs=3D"= ;0"/>
            <= ;element name=3D"rem" type=3D"secDNS:remType" minOccurs=3D&quo= t;0"/>
          </sequence&g= t;
        </choice>
        <attribute name=3D"ur= gent" type=3D"boolean" default=3D"false"/>
      </complexType>

Regards,

Klaus

--B_3339570744_3019602-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SBk0vS012278 for ; Wed, 28 Oct 2009 12:46:00 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9SBk058000628 for ietf-provreg-outgoing; Wed, 28 Oct 2009 12:46:00 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9SBjxOP004015 for ; Wed, 28 Oct 2009 12:45:59 +0100 (MET) Received: (qmail 13762 invoked from network); 28 Oct 2009 11:45:58 +0000 Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Oct 2009 11:45:58 +0000 Message-ID: <4AE82EF2.1000802@publisher.de> Date: Wed, 28 Oct 2009 12:45:54 +0100 From: Ulrich Wisser User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: EPP Provreg Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <907ABD87-2140-429A-80A8-56624A92D579@cisco.com> In-Reply-To: <907ABD87-2140-429A-80A8-56624A92D579@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9SBjxOP011828 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Here at .SE we implemented 4310. As pointed out earlier there is potential for further development. ;) The first problem is the update tag as it doesn't allow add and rem in the same command. This definition could be changed (with backwards compatibility) from to . The bigger problem is the secDNS:rem tag. As pointed out additional information (alg, digestType) is needed. At .SE we use SHA-1 and SHA-256 by default for all keys. Try "dig @a.ns.se dnssec.se DS" for example. In the past months I have seen many registrars struggle with the rem tag because it works fundamentally different from the rest of EPP. I would propose several solutions: A. totally backward compatible Add optional attributes to the secDNS:keyTag tag. But this would mean that alg and digesttype are attributes to keytag which isn't really the case. Backward compatible but not a clean solution. B. Not backward compatible Revamp the whole rem tag and insert a new grouping like This would make the whole thing work more like the rest of EPP. And while we are at it I would like to propose another change: The add command (as well as update) uses the secDNS:dsDataType. Which makes keytag, alg, digestType and digest mandatory. I know that .SE and other registries considered to become a "fat" registry and take in the public keys instead of the ds records. The DS records would be computed from the public keys according to registry policies. This case is not covered by 4310. Kind Regards Ulrich -- Ulrich Wisser senior developer .SE (The Internet Infrastructure Foundation) PO Box 7399, SE-103 91 Stockholm, Sweden Visits: Ringvägen 100 A Switchboard: +46(0)8-452 35 00 Direct: +46(0)8-452 35 58 Mobile: +46(0)732-74 59 00 E-mail: ulrich.wisser@iis.se Website: http://www.iis.se -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S9RCiQ014732 for ; Wed, 28 Oct 2009 10:27:12 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9S9RCvt008620 for ietf-provreg-outgoing; Wed, 28 Oct 2009 10:27:12 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S9RBKm023181 for ; Wed, 28 Oct 2009 10:27:11 +0100 (MET) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcAAEOr50qQ/uCWe2dsb2JhbABCmmQcAQEWJAalPphIhD8E X-IronPort-AV: E=Sophos;i="4.44,638,1249257600"; d="scan'208";a="52958742" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 09:27:11 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9S9RAPD022821; Wed, 28 Oct 2009 09:27:11 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:27:10 +0100 Received: from 95.209.82.236.bredband.tre.se ([10.55.87.216]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:27:09 +0100 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 28 Oct 2009 06:11:56 +0100 Cc: Howard Eland , EPP Provreg Content-Transfer-Encoding: 7bit Message-Id: <907ABD87-2140-429A-80A8-56624A92D579@cisco.com> References: To: James Gould X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 28 Oct 2009 09:27:09.0903 (UTC) FILETIME=[D2FB5DF0:01CA57B0] Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 27 okt 2009, at 22.31, James Gould wrote: > My proposal is to add optional attributes > (alg, digestType, and digest) to the element of > > and to add verbiage for the registries to match the DS record for > the delete > based on all of the passed information. If there is more than one > matching > DS record for the input, than an error must be returned. I like this, specifically with the keyword "optional". That way, it would be backward compatible with deployed implementations (on the client side), and roll out of the new mechanism is as smooth as possible. Patrik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S2CGpb009235 for ; Wed, 28 Oct 2009 03:12:16 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9S2CGvL002237 for ietf-provreg-outgoing; Wed, 28 Oct 2009 03:12:16 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S2CFHs015717 for ; Wed, 28 Oct 2009 03:12:15 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 3A2A84B0; Wed, 28 Oct 2009 03:12:15 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id ShxkAGBafe7y; Wed, 28 Oct 2009 03:12:09 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 68BCD1449; Wed, 28 Oct 2009 00:25:10 +0100 (MEZ) Received: from [127.0.0.1] (klaus@localhost [127.0.0.1]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id n9RNP8ST020920; Wed, 28 Oct 2009 00:25:09 +0100 (MEZ) Message-ID: <4AE78154.9060304@knipp.de> Date: Wed, 28 Oct 2009 00:25:08 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091019 Shredder/3.0pre MIME-Version: 1.0 To: Howard Eland CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> In-Reply-To: <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 2009-10-27 21:56, Howard Eland wrote: > The issue I brought up to Andrew involves the transform commands. These > only require the key tag to perform tasks such as remove, but, as > mentioned in 4034, the key tag by itself may not be unique. We are > seeing much interest in multiple DS records that have the same key tag > with different digest types from registrants. If multiple DS records are > added to the registry with the same key tag, and a subsequent transform > command is sent with only the key tag, as specified in 4310, the result > is left to interpretation. > > Possible solutions for this are: > 1) Force the specification of for all > transform commands (this requires the protocol change to 4310, and is > where I'm headed). > 2) Proceed to transform all DS records with this key tag in the same > manner (but here too are dragons, as a change or update could result in > either duplicate DS records, or would force the registry to remove the > dups, causing a discrepancy between the registrar and the registry). > 3) Do not allow multiple DS records with the same key tag (forcing key > tags to be unique on the domain object - this seems like a non-starter > to me). > 4) Do not allow multiple DS records (also a non-starter). > > Thoughts? > > -Howard > Hi all, interestingly, I pointed out the problem of RFC 4310 regarding multiple DNSKEY records having the same key tag about four years ago. This was not seen as a problem at that time, I was told that the user should just generate a new key pair to avoid the tag clash. Nobody (including myself) saw the problem of the need for multiple DS with different digest types for the very same DNSKEY record. Never mind. I think RFC 4310 is still usable despite the drawbacks, and its use is probably better than reinventing the wheel. If the registrar chooses the option in the , he can simply submit the desired DS records, even if there are multiple entries with the same key tag. For our implementation within the puntCAT registry, some basic testing is done, however: No two entries may exist with the same key tag and digest type. Also, algorithms must indicate the same key type (RSA vs. DSA). But if the registrars have problems with it, we might relax even this test. For the element, a similar test is done on the resulting set of DS records. The element simply deletes all entries having the specified key tag(s), whether there are multiple entries per key tag or not. This may make the element useless, but this is IMHO the only choice. Besides the problem above, I also dislike the following in RFC 4310: - the element is asymmetric to the element in the base protocol and other extensions in so far that a element exists and that the and elements are mutually exclusive. - the submission of the key data is somewhat questionable. The only use is to verify the given DS data, which we do in our implementation. Regards, Klaus -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S0aNwA015775 for ; Wed, 28 Oct 2009 01:36:23 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9S0aNdN008060 for ietf-provreg-outgoing; Wed, 28 Oct 2009 01:36:23 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9S0aMBk012197 for ; Wed, 28 Oct 2009 01:36:22 +0100 (MET) Received: from 121-160-185-235.icannmeeting.org (121-160-185-235.icannmeeting.org [121.160.185.235] (may be forged)) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id n9S0EgN4090162; Tue, 27 Oct 2009 19:14:42 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4AE79202.1040104@nic-naa.net> Date: Wed, 28 Oct 2009 09:36:18 +0900 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Andrew Sullivan , ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk > But there is a risk you have the zone with no keys then. How surprising! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RNRGsZ023637 for ; Wed, 28 Oct 2009 00:27:16 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RNRGRC021139 for ietf-provreg-outgoing; Wed, 28 Oct 2009 00:27:16 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RNREIP011842 for ; Wed, 28 Oct 2009 00:27:15 +0100 (MET) Message-Id: <402D2C7D-326F-4436-BDD3-7FD7A75B1851@afilias.info> From: Howard Eland To: EPP Provreg In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Tue, 27 Oct 2009 18:27:10 -0500 References: X-Mailer: Apple Mail (2.936) X-Authenticated: True Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RNRFIP015421 Sender: owner-ietf-provreg@cafax.se Precedence: bulk There's a lot of ways to skin this cat. All of them that I can see involve an RFC update (even if it's just for clarification). So, I seem to be hearing "yes, fix this, but hurry up about it". If this is the case, then is there anything else that folks would like to see in 4310-bis? (who has the worm-can opener?) Other comments below. On Oct 27, 2009, at 4:31 PM, James Gould wrote: > I'm glad that this thread has come up, since I too was going to > propose > something similar to option 1 but with making the specification change > backward compatible. We are implementing to 4310 for .com, .net, > and .edu > with no additional extensions. We see the issue with use of just the > keyTag, since it is derived and is not unique. There are use cases > where > for the same key, which means the same keyTag, there could be multiple > digest types and algorithms. My proposal is to add optional > attributes > (alg, digestType, and digest) to the element of > > and to add verbiage for the registries to match the DS record for > the delete > based on all of the passed information. If there is more than one > matching > DS record for the input, than an error must be returned. I'd rather not include the digest itself here, since the tuple uniquely identify the DS record. I'm not sure we have to maintain backwards compatibility, but, assuming we do, an error could be returned anytime multiple DS records are matched, as you suggest, or we could also affect the remove against all records that match those attributes sent in (in other words, the default is to match all for any given attribute). > The following is > what I would propose for the XML schema change: [...] > > One additional proposed change is to clarify the use of the > to > state something like “is used to replace all existing DS information > with > new DS information”. The information associated with the specified > keyTag’s > is not the only information changed, since the interpretation is > that the > elements provided with the is a wholesale > replacement of the all of the existing dsData information. Have any > of the > registries interpreted the in a different way? > To make the most versatile, I'd still like to have the ability to specify the other attributes. That way, it can be used to change one or more DS records, as opposed to having to replicate all DS records to change one. This would make syntax similar to , and would still be backwards compatible: if you don't specify the keyTag or any other attributes, then they all change. -Howard > > -- > > > JG > > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > jgould@verisign.com > Direct: 703.948.3271 > Mobile: 703.628.7063 > > > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > Notice to Recipient: This e-mail contains confidential, proprietary > and/or > Registry Sensitive information intended solely for the recipient > and, thus > may not be retransmitted, reproduced or disclosed without the prior > written > consent of VeriSign Naming and Directory Services. If you have > received > this e-mail message in error, please notify the sender immediately by > telephone or reply e-mail and destroy the original message without > making a > copy. Thank you. > > >> From: Howard Eland >> Date: Tue, 27 Oct 2009 15:56:18 -0500 >> To: EPP Provreg >> Subject: Re: [ietf-provreg] Anyone working on 4310-bis? >> >> The issue I brought up to Andrew involves the transform commands. >> These only require the key tag to perform tasks such as remove, but, >> as mentioned in 4034, the key tag by itself may not be unique. We >> are >> seeing much interest in multiple DS records that have the same key >> tag >> with different digest types from registrants. If multiple DS records >> are added to the registry with the same key tag, and a subsequent >> transform command is sent with only the key tag, as specified in >> 4310, >> the result is left to interpretation. >> >> Possible solutions for this are: >> 1) Force the specification of for all >> transform commands (this requires the protocol change to 4310, and is >> where I'm headed). >> 2) Proceed to transform all DS records with this key tag in the same >> manner (but here too are dragons, as a change or update could result >> in either duplicate DS records, or would force the registry to remove >> the dups, causing a discrepancy between the registrar and the >> registry). >> 3) Do not allow multiple DS records with the same key tag (forcing >> key >> tags to be unique on the domain object - this seems like a non- >> starter >> to me). >> 4) Do not allow multiple DS records (also a non-starter). >> >> Thoughts? >> >> -Howard >> >> >> On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote: >> >>> >>> On 27 okt 2009, at 21.16, Patrick Mevzek wrote: >>> >>>> Andrew Sullivan 2009-10-27 21:05 >>>>> I have of late observed a couple possibly pointy corners in RFC >>>>> 4310, >>>>> and Howard Eland just pointed out to me a pretty big operational >>>>> problem in it, so I am wondering whether anyone is working on >>>>> updates >>>>> to it. >>>> >>>> I'm not specifically working on it, but I would advise anyone >>>> dealing >>>> with DNSSEC and EPP to have a look at what .CZ did and what .EU >>>> will >>>> do soon, as they both created other extensions to handle DNSSEC >>>> with >>>> EPP. Maybe other registries too. Sorry if you did that already. >>>> >>>> I'm not judging pro or in favor of any other extension, >>>> but I believe that having a look at the currently deployed EPP >>>> dealings with DNSSEC would be a good idea in light of future work >>>> on >>>> 4310. >>> >>> We use epp and DNSSEC in .SE since a while back. What are the issues >>> you think? >>> >>> Patrik >>> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> =- >>> =-=-=- >>> List run by majordomo software. For (Un-)subscription and similar >>> details >>> send "help" to ietf-provreg-request@cafax.se >>> >> >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-=-=- >> List run by majordomo software. For (Un-)subscription and similar >> details >> send "help" to ietf-provreg-request@cafax.se >> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RMcdRg008880 for ; Tue, 27 Oct 2009 23:38:39 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RMcdKp005456 for ietf-provreg-outgoing; Tue, 27 Oct 2009 23:38:39 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RMcbur004189 for ; Tue, 27 Oct 2009 23:38:38 +0100 (MET) Received: from [192.168.1.106] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9RMcWTr089936; Tue, 27 Oct 2009 18:38:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> Date: Tue, 27 Oct 2009 18:29:34 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Edward Lewis Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Cc: Andrew Sullivan , ietf-provreg@cafax.se Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RMccur017499 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 22:23 +0100 10/27/09, Patrik Fältström wrote: >Hmm...have not thought about having multiple keys with same key tag. That's probably because dnssec-keygen won't return a key that has the same keytag as another one in it's view. >Yeah, also just saw this in 4034: > >> The key tag is used to help select DNSKEY resource records >> efficiently, but it does not uniquely identify a single DNSKEY >> resource record. It is possible for two distinct DNSKEY RRs to have >> the same owner name, the same algorithm type, and the same key tag. >> An implementation that uses only the key tag to select a DNSKEY RR >> might select the wrong public key in some circumstances. Please see >> Appendix B for further details. > >Who the heck came up with this? ;-) I'll blame Olafur. >That is _not_ fun. Neither is a lot of other stuff in DNS - like round robin, case preservation, etc. It's not fun, but not an obstacle. >Only possible path forward is to always: > >1. Remove all keys (in .SE we use keytag=0 to remove all keys) >2. Add the keys again We could specify the DS record by the key hash in the DS. This is about provisioning the DS after all. If there's gonna be an update to 4310, it has to be out there soon. We haven't gone live, but, we have already implemented RFC 4310 as is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLVdaN016114 for ; Tue, 27 Oct 2009 22:31:39 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RLVdqu017330 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:31:39 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLVcTM027518 for ; Tue, 27 Oct 2009 22:31:38 +0100 (MET) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n9RLT7PY006495; Tue, 27 Oct 2009 17:29:07 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 17:31:16 -0400 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Oct 2009 21:31:15 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 17:31:12 -0400 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? From: James Gould To: Howard Eland , EPP Provreg Message-ID: Thread-Topic: [ietf-provreg] Anyone working on 4310-bis? Thread-Index: AcpXTM4TxOJVIoGD1kO325HeY8AlsA== In-Reply-To: <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 27 Oct 2009 21:31:16.0591 (UTC) FILETIME=[D0D017F0:01CA574C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RLVdTM028128 Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'm glad that this thread has come up, since I too was going to propose something similar to option 1 but with making the specification change backward compatible. We are implementing to 4310 for .com, .net, and .edu with no additional extensions. We see the issue with use of just the keyTag, since it is derived and is not unique. There are use cases where for the same key, which means the same keyTag, there could be multiple digest types and algorithms. My proposal is to add optional attributes (alg, digestType, and digest) to the element of and to add verbiage for the registries to match the DS record for the delete based on all of the passed information. If there is more than one matching DS record for the input, than an error must be returned. The following is what I would propose for the XML schema change: Original XML schema: Updated XML schema: An example of the resulting secDNS:rem for deleting two DS records with the same keyTag value but with a different algorithm, digestType, and digest is below: 12345 12345 One additional proposed change is to clarify the use of the to state something like ³is used to replace all existing DS information with new DS information². The information associated with the specified keyTag¹s is not the only information changed, since the interpretation is that the elements provided with the is a wholesale replacement of the all of the existing dsData information. Have any of the registries interpreted the in a different way? -- JG ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. > From: Howard Eland > Date: Tue, 27 Oct 2009 15:56:18 -0500 > To: EPP Provreg > Subject: Re: [ietf-provreg] Anyone working on 4310-bis? > > The issue I brought up to Andrew involves the transform commands. > These only require the key tag to perform tasks such as remove, but, > as mentioned in 4034, the key tag by itself may not be unique. We are > seeing much interest in multiple DS records that have the same key tag > with different digest types from registrants. If multiple DS records > are added to the registry with the same key tag, and a subsequent > transform command is sent with only the key tag, as specified in 4310, > the result is left to interpretation. > > Possible solutions for this are: > 1) Force the specification of for all > transform commands (this requires the protocol change to 4310, and is > where I'm headed). > 2) Proceed to transform all DS records with this key tag in the same > manner (but here too are dragons, as a change or update could result > in either duplicate DS records, or would force the registry to remove > the dups, causing a discrepancy between the registrar and the registry). > 3) Do not allow multiple DS records with the same key tag (forcing key > tags to be unique on the domain object - this seems like a non-starter > to me). > 4) Do not allow multiple DS records (also a non-starter). > > Thoughts? > > -Howard > > > On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote: > >> >> On 27 okt 2009, at 21.16, Patrick Mevzek wrote: >> >>> Andrew Sullivan 2009-10-27 21:05 >>>> I have of late observed a couple possibly pointy corners in RFC >>>> 4310, >>>> and Howard Eland just pointed out to me a pretty big operational >>>> problem in it, so I am wondering whether anyone is working on >>>> updates >>>> to it. >>> >>> I'm not specifically working on it, but I would advise anyone dealing >>> with DNSSEC and EPP to have a look at what .CZ did and what .EU will >>> do soon, as they both created other extensions to handle DNSSEC with >>> EPP. Maybe other registries too. Sorry if you did that already. >>> >>> I'm not judging pro or in favor of any other extension, >>> but I believe that having a look at the currently deployed EPP >>> dealings with DNSSEC would be a good idea in light of future work on >>> 4310. >> >> We use epp and DNSSEC in .SE since a while back. What are the issues >> you think? >> >> Patrik >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-=- >> List run by majordomo software. For (Un-)subscription and similar >> details >> send "help" to ietf-provreg-request@cafax.se >> > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > List run by majordomo software. For (Un-)subscription and similar details > send "help" to ietf-provreg-request@cafax.se > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLPGjt011843 for ; Tue, 27 Oct 2009 22:25:16 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RLPFek028443 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:25:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLPFf4004091 for ; Tue, 27 Oct 2009 22:25:15 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CF2202FE8CDC for ; Tue, 27 Oct 2009 21:25:13 +0000 (UTC) Date: Tue, 27 Oct 2009 17:25:11 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027212508.GH61322@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Oct 27, 2009 at 10:23:12PM +0100, Patrik FÃ¤ltstrÃ¶m wrote: > Aaaarrgghhhh! Yes. Hence my interest in doing something about this. :-) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLNF5G017402 for ; Tue, 27 Oct 2009 22:23:15 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RLNFHr020603 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:23:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RLNFj2009954 for ; Tue, 27 Oct 2009 22:23:15 +0100 (MET) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgAAFcB50qQ/uCWe2dsb2JhbACbPwEBFiQGpXmYT4I5ggYE X-IronPort-AV: E=Sophos;i="4.44,635,1249257600"; d="scan'208";a="52922566" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2009 21:23:14 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RLNE1f021235; Tue, 27 Oct 2009 21:23:14 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:23:14 +0100 Received: from [192.165.72.14] ([10.61.106.66]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:23:13 +0100 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20091027210224.GC61322@shinkuro.com> Date: Tue, 27 Oct 2009 22:23:12 +0100 Cc: ietf-provreg@cafax.se Message-Id: References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> <20091027210224.GC61322@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 27 Oct 2009 21:23:13.0566 (UTC) FILETIME=[B0E853E0:01CA574B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16974.000 X-TM-AS-Result: No--16.625000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RLNFj2015097 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 27 okt 2009, at 22.02, Andrew Sullivan wrote: > On Tue, Oct 27, 2009 at 09:31:10PM +0100, Patrik Fältström wrote: >> We use epp and DNSSEC in .SE since a while back. What are the >> issues you >> think? > > Howard pointed out to me that the key tag is what is used to do > operations on a DS. That's fine, until you're trying to roll > algorithms, because of this happy bit in RFC 4034: > > The key tag is the same for all DNSKEY algorithm types except > algorithm 1 (please see Appendix B.1 for the definition of the key > tag for algorithm 1). Correct, the key tag is the (only) index when you want to do operations. Hmm...have not thought about having multiple keys with same key tag. Yeah, also just saw this in 4034: > The key tag is used to help select DNSKEY resource records > efficiently, but it does not uniquely identify a single DNSKEY > resource record. It is possible for two distinct DNSKEY RRs to have > the same owner name, the same algorithm type, and the same key tag. > An implementation that uses only the key tag to select a DNSKEY RR > might select the wrong public key in some circumstances. Please see > Appendix B for further details. Who the heck came up with this? ;-) Changing this in epp will not be simple. There are tons of deployed things out there (i.e. if we change to {keytag, algorithm} instead of just {keytag}). The text above from 4034 do though say: > It is possible for two distinct DNSKEY RRs to have > the same owner name, the same algorithm type, and the same key tag. That is _not_ fun. Only possible path forward is to always: 1. Remove all keys (in .SE we use keytag=0 to remove all keys) 2. Add the keys again But there is a risk you have the zone with no keys then. Aaaarrgghhhh! Patrik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RL2XCZ006375 for ; Tue, 27 Oct 2009 22:02:33 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RL2WuQ006276 for ietf-provreg-outgoing; Tue, 27 Oct 2009 22:02:32 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RL2W9Z026320 for ; Tue, 27 Oct 2009 22:02:32 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DC97B2FE8CDC for ; Tue, 27 Oct 2009 21:02:30 +0000 (UTC) Date: Tue, 27 Oct 2009 17:02:27 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027210224.GC61322@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Oct 27, 2009 at 09:31:10PM +0100, Patrik FÃ¤ltstrÃ¶m wrote: > We use epp and DNSSEC in .SE since a while back. What are the issues you > think? Howard pointed out to me that the key tag is what is used to do operations on a DS. That's fine, until you're trying to roll algorithms, because of this happy bit in RFC 4034: The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). One operational model for moving from SHA-1 to SHA-256 is to add a new key using both SHA-1 and SHA-256, and then remove the SHA-1 version after some time. Now, one might want to say, "Don't do that," but I think the document either ought to say that or else specify a way to identify DS records that does not rely on the key tag. Also, of course, if there turned out to be a major problem with one or the other algorithms, one would want a way to yank one of the keys without yanking the other. I haven't completely thought through this, however. The only way I know how really to think through something is to write the text (I'm dim), so I thought I'd ask whether someone is working on text. If so, I could figure out how to add to it, or else I could just write something new. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuwho006767 for ; Tue, 27 Oct 2009 21:56:58 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKuwPk026597 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:56:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuvDX025370 for ; Tue, 27 Oct 2009 21:56:57 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F3E132FE8CDC for ; Tue, 27 Oct 2009 20:56:55 +0000 (UTC) Date: Tue, 27 Oct 2009 16:56:52 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027205651.GB61322@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091027201649.GF5590@home.patoche.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Oct 27, 2009 at 09:16:49PM +0100, Patrick Mevzek wrote: > I'm not specifically working on it, but I would advise anyone dealing > with DNSSEC and EPP to have a look at what .CZ did and what .EU will > do soon, as they both created other extensions to handle DNSSEC with > EPP. Maybe other registries too. Sorry if you did that already. I haven't done anything yet, happily :) I was figuring that the .CZ and .EU (and .SE) experiences would have to inform the work. See my other message in this thread for a big issue, though. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuMsq014221 for ; Tue, 27 Oct 2009 21:56:22 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKuMDg020328 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:56:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKuLrS023056 for ; Tue, 27 Oct 2009 21:56:21 +0100 (MET) Message-Id: <7B913B80-A6CC-4A14-9498-A1D5F7A4257C@afilias.info> From: Howard Eland To: ietf-provreg@cafax.se In-Reply-To: <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Date: Tue, 27 Oct 2009 15:56:18 -0500 References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> X-Mailer: Apple Mail (2.936) X-Authenticated: True Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n9RKuMrS016488 Sender: owner-ietf-provreg@cafax.se Precedence: bulk The issue I brought up to Andrew involves the transform commands. These only require the key tag to perform tasks such as remove, but, as mentioned in 4034, the key tag by itself may not be unique. We are seeing much interest in multiple DS records that have the same key tag with different digest types from registrants. If multiple DS records are added to the registry with the same key tag, and a subsequent transform command is sent with only the key tag, as specified in 4310, the result is left to interpretation. Possible solutions for this are: 1) Force the specification of for all transform commands (this requires the protocol change to 4310, and is where I'm headed). 2) Proceed to transform all DS records with this key tag in the same manner (but here too are dragons, as a change or update could result in either duplicate DS records, or would force the registry to remove the dups, causing a discrepancy between the registrar and the registry). 3) Do not allow multiple DS records with the same key tag (forcing key tags to be unique on the domain object - this seems like a non-starter to me). 4) Do not allow multiple DS records (also a non-starter). Thoughts? -Howard On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote: > > On 27 okt 2009, at 21.16, Patrick Mevzek wrote: > >> Andrew Sullivan 2009-10-27 21:05 >>> I have of late observed a couple possibly pointy corners in RFC >>> 4310, >>> and Howard Eland just pointed out to me a pretty big operational >>> problem in it, so I am wondering whether anyone is working on >>> updates >>> to it. >> >> I'm not specifically working on it, but I would advise anyone dealing >> with DNSSEC and EPP to have a look at what .CZ did and what .EU will >> do soon, as they both created other extensions to handle DNSSEC with >> EPP. Maybe other registries too. Sorry if you did that already. >> >> I'm not judging pro or in favor of any other extension, >> but I believe that having a look at the currently deployed EPP >> dealings with DNSSEC would be a good idea in light of future work on >> 4310. > > We use epp and DNSSEC in .SE since a while back. What are the issues > you think? > > Patrik > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > List run by majordomo software. For (Un-)subscription and similar > details > send "help" to ietf-provreg-request@cafax.se > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKVFVs017739 for ; Tue, 27 Oct 2009 21:31:15 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKVFKw004321 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:31:15 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKVECM007080 for ; Tue, 27 Oct 2009 21:31:14 +0100 (MET) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ/15kqrR7Ht/2dsb2JhbADBWZhThD8E X-IronPort-AV: E=Sophos;i="4.44,634,1249257600"; d="scan'208";a="262332875" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 20:31:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RKVCPq000369; Tue, 27 Oct 2009 20:31:12 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 21:31:12 +0100 Received: from [192.165.72.14] ([10.61.106.66]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 21:31:11 +0100 Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20091027201649.GF5590@home.patoche.org> Date: Tue, 27 Oct 2009 21:31:10 +0100 Cc: ietf-provreg@cafax.se Content-Transfer-Encoding: 7bit Message-Id: <23CBC376-9C3C-4D37-A67E-FF4214982D06@cisco.com> References: <20091027194746.GE60934@shinkuro.com> <20091027201649.GF5590@home.patoche.org> To: Patrick Mevzek X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 27 Oct 2009 20:31:11.0697 (UTC) FILETIME=[6C20EC10:01CA5744] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16974.000 X-TM-AS-Result: No--8.386800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 27 okt 2009, at 21.16, Patrick Mevzek wrote: > Andrew Sullivan 2009-10-27 21:05 >> I have of late observed a couple possibly pointy corners in RFC 4310, >> and Howard Eland just pointed out to me a pretty big operational >> problem in it, so I am wondering whether anyone is working on updates >> to it. > > I'm not specifically working on it, but I would advise anyone dealing > with DNSSEC and EPP to have a look at what .CZ did and what .EU will > do soon, as they both created other extensions to handle DNSSEC with > EPP. Maybe other registries too. Sorry if you did that already. > > I'm not judging pro or in favor of any other extension, > but I believe that having a look at the currently deployed EPP > dealings with DNSSEC would be a good idea in light of future work on > 4310. We use epp and DNSSEC in .SE since a while back. What are the issues you think? Patrik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKGptH000849 for ; Tue, 27 Oct 2009 21:16:51 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RKGpkg022481 for ietf-provreg-outgoing; Tue, 27 Oct 2009 21:16:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RKGooR014908 for ; Tue, 27 Oct 2009 21:16:50 +0100 (MET) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id n9RKGoFC010467; Tue, 27 Oct 2009 21:16:50 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id n9RKGnWk010466; Tue, 27 Oct 2009 21:16:49 +0100 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Tue, 27 Oct 2009 21:16:49 +0100 From: Patrick Mevzek To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027201649.GF5590@home.patoche.org> References: <20091027194746.GE60934@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091027194746.GE60934@shinkuro.com> Organization: Dot And Co User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Tue, 27 Oct 2009 21:16:50 +0100 (CET) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hello Andrew, Andrew Sullivan 2009-10-27 21:05 > I have of late observed a couple possibly pointy corners in RFC 4310, > and Howard Eland just pointed out to me a pretty big operational > problem in it, so I am wondering whether anyone is working on updates > to it. I'm not specifically working on it, but I would advise anyone dealing with DNSSEC and EPP to have a look at what .CZ did and what .EU will do soon, as they both created other extensions to handle DNSSEC with EPP. Maybe other registries too. Sorry if you did that already. I'm not judging pro or in favor of any other extension, but I believe that having a look at the currently deployed EPP dealings with DNSSEC would be a good idea in light of future work on 4310. Hope that helps. -- Patrick Mevzek Dot and Co -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RJlrW7022407 for ; Tue, 27 Oct 2009 20:47:53 +0100 (MET) Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n9RJlrAJ015438 for ietf-provreg-outgoing; Tue, 27 Oct 2009 20:47:53 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9RJlrHP002192 for ; Tue, 27 Oct 2009 20:47:53 +0100 (MET) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3D18F2FE8CDC; Tue, 27 Oct 2009 19:47:51 +0000 (UTC) Date: Tue, 27 Oct 2009 15:47:48 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Cc: heland@afilias.info Subject: [ietf-provreg] Anyone working on 4310-bis? Message-ID: <20091027194746.GE60934@shinkuro.com> Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se, heland@afilias.info MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear colleagues, I have of late observed a couple possibly pointy corners in RFC 4310, and Howard Eland just pointed out to me a pretty big operational problem in it, so I am wondering whether anyone is working on updates to it. If not, Howard and I will prepare a -00 with some suggestions, and solicit feedback. If so, please let us know about it so that we can offer our contribution. Thanks and best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se