From aroberts@domicilium.com Wed Feb 29 23:19:22 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED5D21F851D for ; Wed, 29 Feb 2012 23:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nH6brgPpLql for ; Wed, 29 Feb 2012 23:19:21 -0800 (PST) Received: from mail.domicilium.com (wormhole.domicilium.com [217.23.163.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1266F21F84A6 for ; Wed, 29 Feb 2012 23:19:21 -0800 (PST) Received: from LISA.internal.domicilium.com ([fe80::e8e2:5e30:5ac3:660c]) by LISA.internal.domicilium.com ([fe80::e8e2:5e30:5ac3:660c%10]) with mapi; Wed, 29 Feb 2012 15:24:06 +0000 From: Aaron Roberts To: "provreg@ietf.org" Date: Wed, 29 Feb 2012 15:24:04 +0000 Thread-Topic: clTRID element clarification Thread-Index: Acz28d6Bhd1aCdUQSZ+GUDDOKLppHA== Message-ID: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 09:04:57 -0000 Hi all, I'm looking to gauge domain registries' interpretation and use of the clTR= ID EPP command element in their EPP server implementations. It seems that some registry EPP servers (namely .za and .im) use a kind of = "cache/lookup" mechanism, based on the clTRID and (hopefully) scoped to ind= ividual registrars. Where a command is received from a registrar with a cl= TRID which has been previously used by the same registrar, the cached serve= r response is returned to the client, instead of the command being executed= a second time. The intention is to provide idempotency at the server leve= l, when commands are issued multiple times. My interpretation of the RFCs is that the clTRID is just a handy identifier= for debugging etc.. managed by the client end and that EPP commands are de= signed to be idempotent by nature so can be safely executed multiple times = without any considerations given to previous executions. I'd be very interested to know what everybody is doing in this regard? Regards, Aaron Domicilium (IOM) Limited=A0| The Isle of Man Datacentre=20 Ronaldsway Industrial Estate | Ballasalla | Isle of Man |IM9 2RS Tel +44 (0)=A01624 825278 www.domicilium.com=20 www.ipv6.domicilium.com=20 This e-mail is confidential and may be privileged. It may be read, copied a= nd used only by the intended recipient. If you have received it in error, p= lease contact the sender immediately by return e-mail. Please then delete t= he e-mail and do not disclose its contents to any person. From shollenbeck@verisign.com Thu Mar 1 03:57:11 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E392121F8726 for ; Thu, 1 Mar 2012 03:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cqh+6wbN-6O for ; Thu, 1 Mar 2012 03:57:11 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id D673E21F858D for ; Thu, 1 Mar 2012 03:57:10 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT09kFCgKSlspcb2ilhH1aLwYS/X2r54x@postini.com; Thu, 01 Mar 2012 03:57:10 PST 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 q21Bv4VB020625; Thu, 1 Mar 2012 06:57:07 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 06:57:04 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 06:57:03 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Thu, 1 Mar 2012 06:57:03 -0500 From: "Hollenbeck, Scott" To: Aaron Roberts , "provreg@ietf.org" Thread-Topic: clTRID element clarification Thread-Index: Acz28d6Bhd1aCdUQSZ+GUDDOKLppHAAsEpZg Date: Thu, 1 Mar 2012 11:57:02 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5B7647@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> In-Reply-To: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2012 11:57:03.0447 (UTC) FILETIME=[6ABD8670:01CCF7A2] Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:57:12 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Aaron Roberts > Sent: Wednesday, February 29, 2012 10:24 AM > To: provreg@ietf.org > Subject: [provreg] clTRID element clarification >=20 > Hi all, > I'm looking to gauge domain registries' interpretation and use of > the clTRID EPP command element in their EPP server implementations. >=20 > It seems that some registry EPP servers (namely .za and .im) use a kind > of "cache/lookup" mechanism, based on the clTRID and (hopefully) scoped > to individual registrars. Where a command is received from a registrar > with a clTRID which has been previously used by the same registrar, the > cached server response is returned to the client, instead of the > command being executed a second time. The intention is to provide > idempotency at the server level, when commands are issued multiple > times. >=20 > My interpretation of the RFCs is that the clTRID is just a handy > identifier for debugging etc.. managed by the client end and that EPP > commands are designed to be idempotent by nature so can be safely > executed multiple times without any considerations given to previous > executions. Your interpretation is correct. Servers should not make *any* assumptions a= bout clTRIDs. Scott From ulrich@wisser.se Thu Mar 1 14:11:55 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B8121E8353 for ; Thu, 1 Mar 2012 14:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64rtaC6+CwJE for ; Thu, 1 Mar 2012 14:11:54 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4C5021E8352 for ; Thu, 1 Mar 2012 14:11:53 -0800 (PST) Received: by lagj5 with SMTP id j5so1549520lag.31 for ; Thu, 01 Mar 2012 14:11:52 -0800 (PST) Received-SPF: pass (google.com: domain of ulrich@wisser.se designates 10.152.147.1 as permitted sender) client-ip=10.152.147.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ulrich@wisser.se designates 10.152.147.1 as permitted sender) smtp.mail=ulrich@wisser.se Received: from mr.google.com ([10.152.147.1]) by 10.152.147.1 with SMTP id tg1mr6499401lab.22.1330639912570 (num_hops = 1); Thu, 01 Mar 2012 14:11:52 -0800 (PST) Received: by 10.152.147.1 with SMTP id tg1mr5293568lab.22.1330639912358; Thu, 01 Mar 2012 14:11:52 -0800 (PST) Received: from ulrich-wissers-macbook-pro.local (h211n3-rny-a12.ias.bredband.telia.com. [213.65.82.211]) by mx.google.com with ESMTPS id jh4sm1983955lab.17.2012.03.01.14.11.50 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 14:11:51 -0800 (PST) Message-ID: <4F4FF425.7080604@wisser.se> Date: Thu, 01 Mar 2012 23:11:49 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: provreg@ietf.org References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> In-Reply-To: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlfInAyxAFkNlMYjtJOe+iE0/+t5rL4JdXVFTjEFgbUG4WJQ6Nbzh3Y3WgX39Nr/lyMusvp Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:11:55 -0000 Hi Aaron, at .SE the clTRID is ignored as long as it fits the standard definition (3-63 characters). It is returned to the client in the answer, but that's it. We actually do have registrars not sending clTRID at all, sending the same clTRID with every command, sending the clTRID from our example code with every command, setting clTRID to a hash of the command, ... Regards from Stockholm Ulrich > Hi all, > I'm looking to gauge domain registries' interpretation and use of the clTRID EPP command element in their EPP server implementations. > > It seems that some registry EPP servers (namely .za and .im) use a kind of "cache/lookup" mechanism, based on the clTRID and (hopefully) scoped to individual registrars. Where a command is received from a registrar with a clTRID which has been previously used by the same registrar, the cached server response is returned to the client, instead of the command being executed a second time. The intention is to provide idempotency at the server level, when commands are issued multiple times. > > My interpretation of the RFCs is that the clTRID is just a handy identifier for debugging etc.. managed by the client end and that EPP commands are designed to be idempotent by nature so can be safely executed multiple times without any considerations given to previous executions. > > I'd be very interested to know what everybody is doing in this regard? > > Regards, > Aaron > > > Domicilium (IOM) Limited | The Isle of Man Datacentre > Ronaldsway Industrial Estate | Ballasalla | Isle of Man |IM9 2RS > Tel +44 (0) 1624 825278 > > www.domicilium.com > www.ipv6.domicilium.com > This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail. Please then delete the e-mail and do not disclose its contents to any person. > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From theo@flame.co.za Fri Mar 2 00:06:50 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0A21E8056 for ; Fri, 2 Mar 2012 00:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DBf+rJJ+z5l for ; Fri, 2 Mar 2012 00:06:47 -0800 (PST) Received: from flame.co.za (letamo.com [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCE221E800C for ; Fri, 2 Mar 2012 00:06:46 -0800 (PST) Received: from theo-kramers-macbook-pro.int.coza.net.za (41-135-201-244.dsl.mweb.co.za [41.135.201.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id AAB3180127 for ; Fri, 2 Mar 2012 10:06:41 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5B7647@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Fri, 2 Mar 2012 10:06:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E414F3F-2C63-4EC0-9623-E47C4CE7FB8B@flame.co.za> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5B7647@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 08:06:50 -0000 On 01 Mar 2012, at 1:57 PM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On >> Behalf Of Aaron Roberts >> Sent: Wednesday, February 29, 2012 10:24 AM >> To: provreg@ietf.org >> Subject: [provreg] clTRID element clarification >>=20 >> Hi all, >> I'm looking to gauge domain registries' interpretation and use = of >> the clTRID EPP command element in their EPP server implementations. >>=20 >> It seems that some registry EPP servers (namely .za and .im) use a = kind >> of "cache/lookup" mechanism, based on the clTRID and (hopefully) = scoped >> to individual registrars. Where a command is received from a = registrar >> with a clTRID which has been previously used by the same registrar, = the >> cached server response is returned to the client, instead of the >> command being executed a second time. The intention is to provide >> idempotency at the server level, when commands are issued multiple >> times. >>=20 >> My interpretation of the RFCs is that the clTRID is just a handy >> identifier for debugging etc.. managed by the client end and that EPP >> commands are designed to be idempotent by nature so can be safely >> executed multiple times without any considerations given to previous >> executions. >=20 > Your interpretation is correct. Servers should not make *any* = assumptions about clTRIDs. >=20 The .za implementation for co.za operates as follows If no clTRID is provided the server generates a unique clTRID on behalf = of the client. If a clTRID matches a previous clTRID the server compares the message = and if it matches returns the original result. If a clTRID matches a previous clTRID the server compares the message = and if it does not match returns 2308 with an appropriate message. The server validates clTRID based on the standard EPP schema. Perhaps idempotency may simply not be practical, eg. in cases where = registrant tokens are used in updates/deletes/transfers ... --=20 Regards Theo From cbbrowne@afilias.info Thu Mar 1 15:43:44 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1E521E83E9 for ; Thu, 1 Mar 2012 15:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOiuJ3g4uE49 for ; Thu, 1 Mar 2012 15:43:43 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9352921E83E6 for ; Thu, 1 Mar 2012 15:43:42 -0800 (PST) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S3Fev-00009q-6A for provreg@ietf.org; Thu, 01 Mar 2012 23:43:41 +0000 Received: from mail-lpp01m010-f50.google.com ([209.85.215.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S3Fev-0006vh-8W for provreg@ietf.org; Thu, 01 Mar 2012 23:43:41 +0000 Received: by lahm13 with SMTP id m13so1446415lah.9 for ; Thu, 01 Mar 2012 15:43:40 -0800 (PST) Received-SPF: pass (google.com: domain of cbbrowne@afilias.info designates 10.112.86.229 as permitted sender) client-ip=10.112.86.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cbbrowne@afilias.info designates 10.112.86.229 as permitted sender) smtp.mail=cbbrowne@afilias.info Received: from mr.google.com ([10.112.86.229]) by 10.112.86.229 with SMTP id s5mr260326lbz.0.1330645420235 (num_hops = 1); Thu, 01 Mar 2012 15:43:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.86.229 with SMTP id s5mr215709lbz.0.1330645420157; Thu, 01 Mar 2012 15:43:40 -0800 (PST) Received: by 10.112.21.232 with HTTP; Thu, 1 Mar 2012 15:43:40 -0800 (PST) In-Reply-To: <4F4FF425.7080604@wisser.se> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> <4F4FF425.7080604@wisser.se> Date: Thu, 1 Mar 2012 18:43:40 -0500 Message-ID: From: Christopher Browne To: Ulrich Wisser Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnn09fYPF3dwrMknzVa5VjXb7NlDf+vUhclgCr/vkwCzlSrEAxAEVyFMKhbQGwWEHena2tE X-Mailman-Approved-At: Fri, 02 Mar 2012 01:50:29 -0800 Cc: provreg@ietf.org Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:43:44 -0000 On Thu, Mar 1, 2012 at 5:11 PM, Ulrich Wisser wrote: > We actually do have registrars not sending clTRID at all, sending the same > clTRID with every command, sending the clTRID from our example code with > every command, setting clTRID to a hash of the command, ... I periodically bring up the idea that we ought to consider putting a unique constraint on clTRID on a per-registrar basis; in principle, that ought to be someone a registry could consider imposing as a policy. Nobody gets terribly enthused about that idea. They expect, and I think they're right, that this would irritate registrars that are using particularly lazily-constructed client trids. Furthermore, it does not seem likely that there would be huge value to be gained from doing a lot of work interpreting clTRID values. It's an interesting idea to put an object cache that uses client trid as the basis for identifying that two requests ought to be interpreted the same way. But that seems likely to be counterproductive, looking at a couple of cases: 1. To repeat a write operation seems likely to cause trouble. Re-requesting a domain renew shouldn't be able to work, for instance, as two separate renew requests will need to be different as they need to include different expiry dates. 2. Caching read operations means that registrars are getting increasingly stale data, and if they were doing a domain check to see if a domain has become available, there's a risk that they are getting *wrong* information. So, the idea is interesting, in some theoretical ways, but in the absence of something *really* valuable to gain, I don't think it's worth irritating registrars by imposing a bunch of logic onto the interpretation of clTRIDs. Making some operations a little faster doesn't seem to be worth the potential for irritation. From shollenbeck@verisign.com Fri Mar 2 04:22:04 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D775821F8B88 for ; Fri, 2 Mar 2012 04:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYqnZkwlrk3m for ; Fri, 2 Mar 2012 04:22:03 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 38FC321F8B85 for ; Fri, 2 Mar 2012 04:22:03 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKT1C7U8dHGAPsvOVuiV9z7OzrLEBbeBfm@postini.com; Fri, 02 Mar 2012 04:22:03 PST 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 q22CLYs4003433; Fri, 2 Mar 2012 07:21:38 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 07:21:34 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 2 Mar 2012 07:21:34 -0500 From: "Hollenbeck, Scott" To: Theo Kramer , "provreg@ietf.org" Thread-Topic: [provreg] clTRID element clarification Thread-Index: AQHM+EtkSETIAkJHyUaCgGMOIXz5tJZW7QHw Date: Fri, 2 Mar 2012 12:21:34 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5B8552@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5B7647@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5E414F3F-2C63-4EC0-9623-E47C4CE7FB8B@flame.co.za> In-Reply-To: <5E414F3F-2C63-4EC0-9623-E47C4CE7FB8B@flame.co.za> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2012 12:21:34.0555 (UTC) FILETIME=[02008AB0:01CCF86F] Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:22:05 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Theo Kramer > Sent: Friday, March 02, 2012 3:07 AM > To: provreg@ietf.org > Subject: Re: [provreg] clTRID element clarification >=20 >=20 > On 01 Mar 2012, at 1:57 PM, Hollenbeck, Scott wrote: >=20 > >> -----Original Message----- > >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > >> Behalf Of Aaron Roberts > >> Sent: Wednesday, February 29, 2012 10:24 AM > >> To: provreg@ietf.org > >> Subject: [provreg] clTRID element clarification > >> > >> Hi all, > >> I'm looking to gauge domain registries' interpretation and use of > >> the clTRID EPP command element in their EPP server implementations. > >> > >> It seems that some registry EPP servers (namely .za and .im) use a > kind > >> of "cache/lookup" mechanism, based on the clTRID and (hopefully) > scoped > >> to individual registrars. Where a command is received from a > registrar > >> with a clTRID which has been previously used by the same registrar, > the > >> cached server response is returned to the client, instead of the > >> command being executed a second time. The intention is to provide > >> idempotency at the server level, when commands are issued multiple > >> times. > >> > >> My interpretation of the RFCs is that the clTRID is just a handy > >> identifier for debugging etc.. managed by the client end and that > EPP > >> commands are designed to be idempotent by nature so can be safely > >> executed multiple times without any considerations given to previous > >> executions. > > > > Your interpretation is correct. Servers should not make *any* > assumptions about clTRIDs. > > >=20 > The .za implementation for co.za operates as follows >=20 > If no clTRID is provided the server generates a unique clTRID on behalf > of the client. > If a clTRID matches a previous clTRID the server compares the message > and if it matches returns the original result. > If a clTRID matches a previous clTRID the server compares the message > and if it does not match returns 2308 with an appropriate message. > The server validates clTRID based on the standard EPP schema. >=20 > Perhaps idempotency may simply not be practical, eg. in cases where > registrant tokens are used in updates/deletes/transfers ... The server shouldn't be generating what's supposed to be a client-provided = transaction identifier. Scott From fobispo@isc.org Fri Mar 2 04:41:28 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32EA21F8A70 for ; Fri, 2 Mar 2012 04:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSq1iTxh-4E1 for ; Fri, 2 Mar 2012 04:41:14 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 3326D21F8B89 for ; Fri, 2 Mar 2012 04:41:03 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 3708E5F98A2; Fri, 2 Mar 2012 12:40:42 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.10.158] (unknown [12.8.36.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3BB75216C33; Fri, 2 Mar 2012 12:40:38 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_83C914D5-EE7C-45F1-B48D-B8F6123ABAEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Francisco Obispo In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5B8552@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Fri, 2 Mar 2012 07:40:33 -0500 Message-Id: <6CF1868B-CFB5-41AD-875A-B2A67FFADCAB@isc.org> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E33B@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5B7647@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5E414F3F-2C63-4EC0-9623-E47C4CE7FB8B@flame.co.za> <831693C2CDA2E849A7D7A712B24E257F0D5B8552@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1257) Cc: "provreg@ietf.org" Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:41:29 -0000 --Apple-Mail=_83C914D5-EE7C-45F1-B48D-B8F6123ABAEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 The clTRID is to be used by the client to identify the transaction = against the server.. this is very useful if the EPP protocol is used on = asynchronous protocols such as SMTP, or if pipelining is used. On Mar 2, 2012, at 7:21 AM, Hollenbeck, Scott wrote: > The server shouldn't be generating what's supposed to be a = client-provided transaction identifier. >=20 > Scott Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE --Apple-Mail=_83C914D5-EE7C-45F1-B48D-B8F6123ABAEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPUL/BAAoJEEY+YU6zjbG+jZ0P+wdxbvxs7QHSywMRO3P4A+IO 27P5b2Lh8qjr/P2rBRU1jAiEy27du4kyyU3rdY3h38MqIV4Q5dHNcCu4Ey8h6Khf BMYVG4wIBh/sk3GawE3plnFPc7AW2BC/oQeVCAOJnuG984s+AyQ8MwrK1LFg4zob SRLeX/5aQ+sWmQ7DT7PosSdvOvgRMNDv1baGlH9wSi7WE7T29x719TGghVutipwx DtkTo+WETgZFMF5+7fj66nexdDqZR/kqbtQBAa6/6PBLS7H7oRheoSbbZXvp28HJ dCbIhlyRcbpMrRPNTu5odQ5LoDrtuo2JrIUAtKE4BcsCVmz79M+cyeRJlfrWJr9f Zrhfndqzf06vKfusKutj8VcZmjsPXFW4ZrQ1WAvGN8dO7k9RSbZ0gdZwDJfjAbYG DNNDqwvCDu+kwwz6TNUc37z0Cu3//CFe4IIB1pQdG/A8iYHCSqrsv0Toxax9yvEe 0zeTmanS8fud9fullIZbCHRL+eLU2wuDNch0xhh3b8rvXMWIl6JVR9JC768R2Zdd GdsENf5Kjm1+AtU1Uhg+mE/3QB6cdTMgmgrdMTcIISQs8G077KJIrl2sNJXMuFo8 zvG/SzqkS7A6XHRQWceqMJadMgp5oFRyhhDiTw0IyqSkI2XDm+Mtv9Z1DTVMgIHD 9fswaNHRGh6j2/WGfidD =kffm -----END PGP SIGNATURE----- --Apple-Mail=_83C914D5-EE7C-45F1-B48D-B8F6123ABAEC-- From JGould@verisign.com Fri Mar 2 04:52:58 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E255521F8ADE for ; Fri, 2 Mar 2012 04:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0FSRTj8hlJz for ; Fri, 2 Mar 2012 04:52:58 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id C45F621F8ABD for ; Fri, 2 Mar 2012 04:52:56 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKT1DCqB/vR6QTnLck0hqKv1gPaaqt1AJn@postini.com; Fri, 02 Mar 2012 04:52:57 PST 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 q22Cqnsf005736; Fri, 2 Mar 2012 07:52:52 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 07:52:49 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 07:52:49 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 2 Mar 2012 07:52:48 -0500 From: "Gould, James" To: Francisco Obispo , "Hollenbeck, Scott" Thread-Topic: [provreg] clTRID element clarification Thread-Index: Acz28d6Bhd1aCdUQSZ+GUDDOKLppHAAsEpZgADTJIgAACOdIAAAAqbmA//+vloA= Date: Fri, 2 Mar 2012 12:52:48 +0000 Message-ID: In-Reply-To: <6CF1868B-CFB5-41AD-875A-B2A67FFADCAB@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8A7F66035A705F4A86B0E677F94AA711@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2012 12:52:49.0316 (UTC) FILETIME=[5F725E40:01CCF873] Cc: "provreg@ietf.org" Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:52:59 -0000 ++1 For .com, .net, .tv, .cc, .jobs, and .name the clTRID is generated by the client and is mirrored back in the response. I agree that it's a necessary feature for pipelining as an Asynchronous Completion Token (ACT). =20 -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/2/12 7:40 AM, "Francisco Obispo" wrote: >+1 > >The clTRID is to be used by the client to identify the transaction >against the server.. this is very useful if the EPP protocol is used on >asynchronous protocols such as SMTP, or if pipelining is used. > > > >On Mar 2, 2012, at 7:21 AM, Hollenbeck, Scott wrote: > >> The server shouldn't be generating what's supposed to be a >>client-provided transaction identifier. >>=20 >> Scott > >Francisco Obispo=20 >email: fobispo@isc.org >Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >PGP KeyID =3D B38DB1BE > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From theo@flame.co.za Fri Mar 2 05:42:59 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE421F879F for ; Fri, 2 Mar 2012 05:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8haxzh0qcSjm for ; Fri, 2 Mar 2012 05:42:58 -0800 (PST) Received: from flame.co.za (fmtrns.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033D621F87A1 for ; Fri, 2 Mar 2012 05:42:58 -0800 (PST) Received: from theo-kramers-macbook-pro.int.coza.net.za (41-135-201-244.dsl.mweb.co.za [41.135.201.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id A3FCC80127 for ; Fri, 2 Mar 2012 15:42:54 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: Date: Fri, 2 Mar 2012 15:42:52 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6A973352-4808-402F-9A35-E952E7F7B631@flame.co.za> References: To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 13:42:59 -0000 On 02 Mar 2012, at 2:52 PM, Gould, James wrote: > ++1 > > For .com, .net, .tv, .cc, .jobs, and .name the clTRID is generated by the > client and is mirrored back in the response. Yes - as for co.za when supplied by the client. > I agree that it's a > necessary feature for pipelining as an Asynchronous Completion Token > (ACT). A null clTRID can not be used as an ACT. and, for a next release the server will not include a server generated clTRID in a response. -- Regards Theo From patrik@frobbit.se Fri Mar 2 05:46:44 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F129221F87F9 for ; Fri, 2 Mar 2012 05:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th8FMUvoJQcx for ; Fri, 2 Mar 2012 05:46:44 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 268B821F87F8 for ; Fri, 2 Mar 2012 05:46:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B9DFA133679E3; Fri, 2 Mar 2012 14:46:42 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6jqXNMgZA80; Fri, 2 Mar 2012 14:46:42 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 73117133679DC; Fri, 2 Mar 2012 14:46:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6A973352-4808-402F-9A35-E952E7F7B631@flame.co.za> Date: Fri, 2 Mar 2012 14:46:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A973352-4808-402F-9A35-E952E7F7B631@flame.co.za> To: Theo Kramer X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Fri, 02 Mar 2012 11:50:55 -0800 Cc: provreg@ietf.org Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 13:46:45 -0000 On 2 mar 2012, at 14:42, Theo Kramer wrote: > On 02 Mar 2012, at 2:52 PM, Gould, James wrote: >=20 >> ++1 >>=20 >> For .com, .net, .tv, .cc, .jobs, and .name the clTRID is generated by = the >> client and is mirrored back in the response. >=20 > Yes - as for co.za when supplied by the client. That is how I think it should be used. I.e. clTRID is something that = could be of benefit for the client. Not policed by the registry. = Specifically if we start getting more and more async operations (or = rather, overloading of commands) from the client. Patrik From nkong@cnnic.cn Mon Mar 5 01:29:42 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6689421F8548 for ; Mon, 5 Mar 2012 01:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE5+w2EGUvnq for ; Mon, 5 Mar 2012 01:29:41 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id ED00821F854E for ; Mon, 5 Mar 2012 01:29:40 -0800 (PST) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 05 Mar 2012 17:29:36 +0800 From: "Ning Kong" To: Date: Mon, 5 Mar 2012 17:29:33 +0800 Message-ID: <008001ccfab2$79c61890$6d5249b0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz6sl3KPaRN1XXNQC2l/CSc85D68g== Content-Language: zh-cn Subject: [provreg] draft-kong-epp-idn-variants-mapping-00 Submitted for Review X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:29:42 -0000 Hi folks, Any comments on this draft are welcomed! A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kong-epp-idn-variants-mapping-00.t xt Cheers, Ning -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, March 05, 2012 5:20 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-kong-epp-idn-variants-mapping-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Internationalized Domain Name (IDN) Variants Author(s) : Ning Kong Jiagui Xie Hongtao Li Wil Tan Xiaodong Li Filename : draft-kong-epp-idn-variants-mapping-00.txt Pages : 27 Date : 2012-03-05 This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of Internationalized Domain Name (IDN) Variants. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of IDN variants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kong-epp-idn-variants-mapping-00.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-kong-epp-idn-variants-mapping-00.tx t _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From patrik@frobbit.se Mon Mar 5 02:45:59 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AB121F8707 for ; Mon, 5 Mar 2012 02:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuir9QOF8dO8 for ; Mon, 5 Mar 2012 02:45:58 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8F21F86F9 for ; Mon, 5 Mar 2012 02:45:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 1F71E133B016C; Mon, 5 Mar 2012 11:45:57 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB9wd5RaxbIZ; Mon, 5 Mar 2012 11:45:56 +0100 (CET) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 9454D133B015C; Mon, 5 Mar 2012 11:45:56 +0100 (CET) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 11:43:30 +0100 To: provreg@ietf.org Message-Id: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 10:45:59 -0000 According to RFC 5910, section 4, there are two alternative interfaces = for managing DNSSEC key data when interfacing with a registry. The RFC = does not explicitly say whether a registry must implement one or the = other. I have successfully implemented in a web interface, an API for = registrants etc, the DS interface as the client do believe passing DS = data is the easiest. After all that is what is to be signed by the = parent. I just encountered a registry that "want to set a limit on what digest = algorithms to use" and to do that, they have decided to not implement = the DS interface and only support the KEY interface. I can accept limitations on what digest algorithms they accept, but not = limitations by not supporting DS. Reactions? Patrik From michele@blacknight.ie Mon Mar 5 02:59:47 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD9621F855F for ; Mon, 5 Mar 2012 02:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_05=-1.11, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e-cfvQQSRrV for ; Mon, 5 Mar 2012 02:59:46 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id C4C6321F8550 for ; Mon, 5 Mar 2012 02:59:45 -0800 (PST) Received: from bkexchmbx02.blacknight.local ([fe80::d4d7:819a:4fb5:c923]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 10:59:44 +0000 From: "Michele Neylon :: Blacknight" To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: AQHM+r00tHy4v05x7kyzT+4+6EfUaZZbiKmA Date: Mon, 5 Mar 2012 10:59:43 +0000 Message-ID: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> In-Reply-To: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <6351C0AF95EFE047A0B605CF24055950@blacknight.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 10:59:48 -0000 UGF0cmlrDQoNCldlbGNvbWUgdG8gb3VyIHdvcmxkIDopDQoNCldlIHNlZSBpbmNvbnNpc3RlbmNp ZXMgYmV0d2VlbiByZWdpc3RyaWVzIGFsbCB0aGUgdGltZSAtIGl0IG1ha2VzIGludGVncmF0aW9u IHdpdGggbmV3IHJlZ2lzdHJ5IHByb3ZpZGVycyBwYWluZnVsIGFuZCBhcyBhIHJlc3VsdCB3ZSB0 ZW5kIHRvIGZvY3VzIG9uIHRoZSBvbmVzIHdob3NlIHF1aXJrcyB3ZSd2ZSBhbHJlYWR5IGRlYWx0 IHdpdGggDQoNClJlZ2FyZHMNCg0KTWljaGVsZQ0KDQoNCk9uIDUgTWFyIDIwMTIsIGF0IDEwOjQz LCBQYXRyaWsgRsOkbHRzdHLDtm0gd3JvdGU6DQoNCj4gQWNjb3JkaW5nIHRvIFJGQyA1OTEwLCBz ZWN0aW9uIDQsIHRoZXJlIGFyZSB0d28gYWx0ZXJuYXRpdmUgaW50ZXJmYWNlcyBmb3IgbWFuYWdp bmcgRE5TU0VDIGtleSBkYXRhIHdoZW4gaW50ZXJmYWNpbmcgd2l0aCBhIHJlZ2lzdHJ5LiBUaGUg UkZDIGRvZXMgbm90IGV4cGxpY2l0bHkgc2F5IHdoZXRoZXIgYSByZWdpc3RyeSBtdXN0IGltcGxl bWVudCBvbmUgb3IgdGhlIG90aGVyLg0KPiANCj4gSSBoYXZlIHN1Y2Nlc3NmdWxseSBpbXBsZW1l bnRlZCBpbiBhIHdlYiBpbnRlcmZhY2UsIGFuIEFQSSBmb3IgcmVnaXN0cmFudHMgZXRjLCB0aGUg RFMgaW50ZXJmYWNlIGFzIHRoZSBjbGllbnQgZG8gYmVsaWV2ZSBwYXNzaW5nIERTIGRhdGEgaXMg dGhlIGVhc2llc3QuIEFmdGVyIGFsbCB0aGF0IGlzIHdoYXQgaXMgdG8gYmUgc2lnbmVkIGJ5IHRo ZSBwYXJlbnQuDQo+IA0KPiBJIGp1c3QgZW5jb3VudGVyZWQgYSByZWdpc3RyeSB0aGF0ICJ3YW50 IHRvIHNldCBhIGxpbWl0IG9uIHdoYXQgZGlnZXN0IGFsZ29yaXRobXMgdG8gdXNlIiBhbmQgdG8g ZG8gdGhhdCwgdGhleSBoYXZlIGRlY2lkZWQgdG8gbm90IGltcGxlbWVudCB0aGUgRFMgaW50ZXJm YWNlIGFuZCBvbmx5IHN1cHBvcnQgdGhlIEtFWSBpbnRlcmZhY2UuDQo+IA0KPiBJIGNhbiBhY2Nl cHQgbGltaXRhdGlvbnMgb24gd2hhdCBkaWdlc3QgYWxnb3JpdGhtcyB0aGV5IGFjY2VwdCwgYnV0 IG5vdCBsaW1pdGF0aW9ucyBieSBub3Qgc3VwcG9ydGluZyBEUy4NCj4gDQo+IFJlYWN0aW9ucz8N Cj4gDQo+ICBQYXRyaWsNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+IHByb3ZyZWdAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcm92cmVnDQoNCk1yIE1p Y2hlbGUgTmV5bG9uDQpCbGFja25pZ2h0IFNvbHV0aW9ucyDimZ4NCkhvc3RpbmcgJiBDb2xvY2F0 aW9uLCBCcmFuZCBQcm90ZWN0aW9uDQpJQ0FOTiBBY2NyZWRpdGVkIFJlZ2lzdHJhcg0KaHR0cDov L3d3dy5ibGFja25pZ2h0LmNvbS8NCmh0dHA6Ly9ibG9nLmJsYWNrbmlnaHQuY29tLw0KaHR0cDov L2JsYWNrbmlnaHQuYml6DQpodHRwOi8vbW5leWxvbi50ZWwNCkludGwuICszNTMgKDApIDU5ICA5 MTgzMDcyDQpVUzogMjEzLTIzMy0xNjEyIA0KTG9jYWxsOiAxODUwIDkyOSA5MjkNCkRpcmVjdCBE aWFsOiArMzUzICgwKTU5IDkxODMwOTANCkZhY2Vib29rOiBodHRwOi8vZmIubWUvYmxhY2tuaWdo dA0KVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL21uZXlsb24NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkJsYWNrbmlnaHQgSW50ZXJuZXQgU29sdXRpb25zIEx0ZCwgVW5pdCAx MkEsQmFycm93c2lkZSBCdXNpbmVzcyBQYXJrLFNsZWF0eQ0KUm9hZCxHcmFpZ3VlY3VsbGVuLENh cmxvdyxJcmVsYW5kICBDb21wYW55IE5vLjogMzcwODQ1DQoNCg== From patrik@frobbit.se Mon Mar 5 03:04:43 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5F21F84EB for ; Mon, 5 Mar 2012 03:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ6+JD7Df2bO for ; Mon, 5 Mar 2012 03:04:43 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 54C7721F8585 for ; Mon, 5 Mar 2012 03:04:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B5BDC133B0CD4; Mon, 5 Mar 2012 12:04:41 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VzTrRsK6Sn8; Mon, 5 Mar 2012 12:04:41 +0100 (CET) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 641FA133B0CC9; Mon, 5 Mar 2012 12:04:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_EDCA1313-A0BB-43DE-B345-CEDD3E9F9D7C"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 5 Mar 2012 12:04:40 +0100 Message-Id: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> To: "Michele Neylon :: Blacknight" X-Mailer: Apple Mail (2.1257) Cc: "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:04:44 -0000 --Apple-Mail=_EDCA1313-A0BB-43DE-B345-CEDD3E9F9D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This one is specifically irritating as it requires in worst case massive = explanations, education and web/REST interface implementations that are = dependent on the TLD. I.e. something a registrar can not "hide" from the = registrant. I am not happy about differences that cost registrars hard work of = various kinds. But I am definitely not happy of things that cost = registrant things. So, for this specific case, I would like to see a MUST in at least the = DS interface. Patrik On 5 mar 2012, at 11:59, Michele Neylon :: Blacknight wrote: > Patrik >=20 > Welcome to our world :) >=20 > We see inconsistencies between registries all the time - it makes = integration with new registry providers painful and as a result we tend = to focus on the ones whose quirks we've already dealt with=20 >=20 > Regards >=20 > Michele >=20 >=20 > On 5 Mar 2012, at 10:43, Patrik F=C3=A4ltstr=C3=B6m wrote: >=20 >> According to RFC 5910, section 4, there are two alternative = interfaces for managing DNSSEC key data when interfacing with a = registry. The RFC does not explicitly say whether a registry must = implement one or the other. >>=20 >> I have successfully implemented in a web interface, an API for = registrants etc, the DS interface as the client do believe passing DS = data is the easiest. After all that is what is to be signed by the = parent. >>=20 >> I just encountered a registry that "want to set a limit on what = digest algorithms to use" and to do that, they have decided to not = implement the DS interface and only support the KEY interface. >>=20 >> I can accept limitations on what digest algorithms they accept, but = not limitations by not supporting DS. >>=20 >> Reactions? >>=20 >> Patrik >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > Mr Michele Neylon > Blacknight Solutions =E2=99=9E > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://blacknight.biz > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612=20 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Facebook: http://fb.me/blacknight > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business = Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --Apple-Mail=_EDCA1313-A0BB-43DE-B345-CEDD3E9F9D7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iD8DBQFPVJ3IrMabGguI180RAvECAKCUtcWFIH+yOrmQAMA2z80Ka88l0ACfek+A o9T4w4Ubb6IUatVQS7knvTI= =3LcP -----END PGP SIGNATURE----- --Apple-Mail=_EDCA1313-A0BB-43DE-B345-CEDD3E9F9D7C-- From Anthony.Kirby@nominet.org.uk Mon Mar 5 03:32:37 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3DC21F866D for ; Mon, 5 Mar 2012 03:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uMdsty3Bqst for ; Mon, 5 Mar 2012 03:32:36 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 54B9C21F8638 for ; Mon, 5 Mar 2012 03:32:35 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rhkzqnmwiiXrWK8H+Y6mZdWnxr2g/lu8XcE+1gwde74+QnZVfmH+9okx dVRendNvPOJrPXa5FL2ZDLZUNw3pKKCEDhXLbkeB6gIctaX/3GZDVUBmn SAfMyOBmET4NT75; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Anthony.Kirby@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1330947156; x=1362483156; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Anthony=20Kirby=20 |Subject:=20RE:=20[provreg]=20Example=20of=20stupid=20inc onsistencies=20between=20registries|Date:=20Mon,=205=20Ma r=202012=2011:32:33=20+0000|Message-ID:=20<15D149AB24B920 4EB78FB7F7B036265A1872DA8E@wds-exc1.okna.nominet.org.uk> |To:=20=3D?iso-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

,=0D=0A=09"provreg@ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|In-Reply-To:=20<0B90F8B4-8780-4FC4-8D 12-161E1AB466C3@frobbit.se>|References:=20<0B90F8B4-8780- 4FC4-8D12-161E1AB466C3@frobbit.se>; bh=377I0xJPprDhfpumrSae8sa4zsCVB+wAwuMTy2ex2+w=; b=eGHYUuaXfWDNmsL7g+Y51K2lnQ3jO1WHIUUog6VFqAVBmVR1K52DP1rN qfZpveUWuAtIsDlJX7QtsCQZaj4MPUMNqRYigFYYYr8Zeh3RqYfzwvQHu d2TwpKybV0dAaSR; X-IronPort-AV: E=Sophos;i="4.73,533,1325462400"; d="scan'208";a="38643326" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 05 Mar 2012 11:32:34 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 5 Mar 2012 11:32:34 +0000 From: Anthony Kirby To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "provreg@ietf.org" Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: AQHM+r0qGGR1l17slU+u86MtvA+g6ZZbhh0H Date: Mon, 5 Mar 2012 11:32:33 +0000 Message-ID: <15D149AB24B9204EB78FB7F7B036265A1872DA8E@wds-exc1.okna.nominet.org.uk> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> In-Reply-To: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:32:37 -0000 Hi Patrik,=0A= =0A= FWIW, we (Nominet / .uk) chose the DS interface for 2 reasons:=0A= - compatibility; DS data can be generated from key data but not vice-versa= =0A= - simplicity & clarity of responsibility (we just publish what we're given)= =0A= =0A= On the other hand, we chose to be cautious about the set of algorithms/dige= st types/digests to allow for the DS record, because 3rd party components m= ight allow nonstandard values on input, but then fail. That said, no-one's= yet asked for GOST support.=0A= =0A= I haven't read the RFC recently, but I recall the choice of interface was a= n either/or - so a MUST implies the loss of the key interface (not that I'd= cry for it).=0A= =0A= Anthony=0A= =0A= =0A= ________________________________________=0A= From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Patr= ik F=E4ltstr=F6m [patrik@frobbit.se]=0A= Sent: 05 March 2012 10:43=0A= To: provreg@ietf.org=0A= Subject: [provreg] Example of stupid inconsistencies between registries=0A= =0A= According to RFC 5910, section 4, there are two alternative interfaces for = managing DNSSEC key data when interfacing with a registry. The RFC does not= explicitly say whether a registry must implement one or the other.=0A= =0A= I have successfully implemented in a web interface, an API for registrants = etc, the DS interface as the client do believe passing DS data is the easie= st. After all that is what is to be signed by the parent.=0A= =0A= I just encountered a registry that "want to set a limit on what digest algo= rithms to use" and to do that, they have decided to not implement the DS in= terface and only support the KEY interface.=0A= =0A= I can accept limitations on what digest algorithms they accept, but not lim= itations by not supporting DS.=0A= =0A= Reactions?=0A= =0A= Patrik=0A= =0A= _______________________________________________=0A= provreg mailing list=0A= provreg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/provreg=0A= From peter@denic.de Mon Mar 5 03:50:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCF621F8697 for ; Mon, 5 Mar 2012 03:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjklH9PxItZ6 for ; Mon, 5 Mar 2012 03:50:01 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id BD76021F858D for ; Mon, 5 Mar 2012 03:50:01 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S4WQS-0005Qt-8L; Mon, 05 Mar 2012 12:50:00 +0100 Received: from localhost by x27.adm.denic.de with local id 1S4WQS-0000m4-4L; Mon, 05 Mar 2012 12:50:00 +0100 Date: Mon, 5 Mar 2012 12:50:00 +0100 From: Peter Koch To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20120305115000.GF22296@x27.adm.denic.de> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch X-Mailman-Approved-At: Mon, 05 Mar 2012 04:33:01 -0800 Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:50:02 -0000 Patrik, > According to RFC 5910, section 4, there are two alternative interfaces for managing DNSSEC key data when interfacing with a registry. The RFC does not explicitly say whether a registry must implement one or the other. exactly, this is an improvement over its predecessor RFC 4310 that mandated DS. > I just encountered a registry that "want to set a limit on what digest algorithms to use" and to do that, they have decided to not implement the DS interface and only support the KEY interface. Some registries have decided to operate on DNSKEY rather than DS. It appears reasonable to me to reflect this in the provisioning protocol. This is exactly not an EPP inconsistency, because EPP is policy neutral here and can thus well be used for either way. -Peter PS: for "full disclosure": DENIC does not use EPP and we do DNSSEC provisioning based on the DNSKEY RRSet only From patrik@frobbit.se Mon Mar 5 05:02:22 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9804321F86B0 for ; Mon, 5 Mar 2012 05:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTreW9XR8SjC for ; Mon, 5 Mar 2012 05:02:22 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id E572921F853B for ; Mon, 5 Mar 2012 05:02:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 87A46133B452E; Mon, 5 Mar 2012 14:02:20 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw-O-wUmVVYz; Mon, 5 Mar 2012 14:02:20 +0100 (CET) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 3B604133B4524; Mon, 5 Mar 2012 14:02:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D12E2E5F-2FA4-4FD6-B807-B23291BA647E"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120305115000.GF22296@x27.adm.denic.de> Date: Mon, 5 Mar 2012 14:02:19 +0100 Message-Id: <75397F81-613C-4807-BAEA-276D489EBA22@frobbit.se> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305115000.GF22296@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:02:22 -0000 --Apple-Mail=_D12E2E5F-2FA4-4FD6-B807-B23291BA647E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 mar 2012, at 12:50, Peter Koch wrote: >> I just encountered a registry that "want to set a limit on what = digest algorithms to use" and to do that, they have decided to not = implement the DS interface and only support the KEY interface. >=20 > Some registries have decided to operate on DNSKEY rather than DS. It = appears > reasonable to me to reflect this in the provisioning protocol. > This is exactly not an EPP inconsistency, because EPP is policy = neutral here > and can thus well be used for either way. ...and as you understand I think that the fact that there seems to be an = ability for registries to choose in their epp interface is extremely bad = for the registrant. I.e. why should a registrant have to send _different_ information to the = registrar for example.A and example.B? Where "example" is the same for both TLDs. In one case DS, in another case KEY? I want to admit that when I read the RFC in question, I read it as if = both interfaces should exist. Not that a registry could say no to one. = So I personally missed this during last call. Patrik --Apple-Mail=_D12E2E5F-2FA4-4FD6-B807-B23291BA647E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iD8DBQFPVLlbrMabGguI180RAvKAAJ9avBPSgTy0ykJKFpN3EVViPk2eagCeNdiI kpYMtWI7wTvfN6z30iBFO1A= =wOCo -----END PGP SIGNATURE----- --Apple-Mail=_D12E2E5F-2FA4-4FD6-B807-B23291BA647E-- From JGould@verisign.com Mon Mar 5 05:21:41 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AD321F8697 for ; Mon, 5 Mar 2012 05:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aehbKy5X0M9i for ; Mon, 5 Mar 2012 05:21:37 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id A8B6D21F8664 for ; Mon, 5 Mar 2012 05:21:34 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKT1S91ywHY8AWgVSP06aJU+GwqrF6PT1G@postini.com; Mon, 05 Mar 2012 05:21:37 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q25DLKHK010076; Mon, 5 Mar 2012 08:21:23 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 08:21:20 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 08:21:20 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 08:21:19 -0500 From: "Gould, James" To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , "Michele Neylon :: Blacknight" Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: AQHM+r0q7eo1z51rQ0WnxvppIby9dZZb3HqAgAABYgD//9JTgA== Date: Mon, 5 Mar 2012 13:21:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <1D9D1CF46EA6DB4A935F9EDC63C774AE@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2012 13:21:20.0010 (UTC) FILETIME=[DA56CEA0:01CCFAD2] Cc: "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:21:41 -0000 UGF0cmlrLA0KDQpUaGlzIHdhcyBkaXNjdXNzZWQgb24gdGhpcyBsaXN0IGluIGxhdGUgMjAwOS4g IFVscmljaCBXaXNzZXIgYnJvdWdodCB1cCBvbg0KdGhlIGxpc3Qgb24gT2N0b2JlciAyOCwgMjAw OSAidGhhdCAuU0UgYW5kIG90aGVyIHJlZ2lzdHJpZXMgY29uc2lkZXJlZCB0bw0KYmVjb21lIGEg ImZhdCIgcmVnaXN0cnkgYW5kIHRha2UgaW4gdGhlIHB1YmxpYyBrZXlzIGluc3RlYWQgb2YgdGhl IGRzDQpyZWNvcmRzIi4gIFN1cHBvcnQgZm9yIGEgInRoaW4iIEROU1NFQyByZWdpc3RyeSBhcyBh IE1VU1Qgd2l0aCB0aGUgb3B0aW9uDQpmb3IgYSAiZmF0IiByZWdpc3RyeSB3YXMgbmV2ZXIgZGlz Y3Vzc2VkIG9uIHRoZSBsaXN0LiAgSSBiZWxpZXZlIHRoYXQgYQ0KbWl4IG9mICJ0aGluIiBhbmQg ImZhdCIgd291bGQgbWFrZSB0aGluZ3MgbW9yZSBjb21wbGV4IHNpbmNlIHRoZQ0KcmVnaXN0cmFy cyB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgYm90aCBpbnN0ZWFkIG9mIG9uZSBpbnRlcmZhY2UgZm9y IHRoZQ0KcmVnaXN0cmllcyB0aGF0IGRvIHN1cHBvcnQgdGhlICJmYXQiIG1vZGVsLiAgVGhpbmsg YWJvdXQgaGFuZGxpbmcNCnRyYW5zZmVycyBiZXR3ZWVuIHJlZ2lzdHJhcnMgd2hlcmUgdGhlIGdh aW5pbmcgcmVnaXN0cmFyIHN1cHBvcnRzIG9ubHkgdGhlDQoidGhpbiIgbW9kZWwgYW5kIHRoZSBs b3NpbmcgcmVnaXN0cmFyIHN1cHBvcnRzIGJvdGggInRoaW4iIGFuZCAiZmF0Ii4NClRoZXJlIHdh cyBzdXBwb3J0IG9uIHRoaXMgbGlzdCBhbmQgbm8gY29uY2VybnMgcmFpc2VkIGluIGFkZGluZyBz dXBwb3J0DQpmb3IgdGhlIGtleSBkYXRhIGludGVyZmFjZSB0byB0aGUgZHJhZnQuICBZb3Ugd2Vy ZSBhY3RpdmUgb24gdGhlIGxpc3QNCndoaWxlIHRoaXMgd2FzIGJlaW5nIGRpc2N1c3NlZCBhbmQg bmV2ZXIgZXhwcmVzc2VkIGFueSBjb25jZXJucyBpbiBzdXBwb3J0DQpmb3IgdGhlIGtleSBkYXRh IGludGVyZmFjZS4gIFdoYXQgaXMgaW4gdGhlIFJGQyBzdXBwb3J0cyB0aGUgbW9kZWxzIG9mDQoi dGhpbiIgd2l0aCB0aGUgZHMgZGF0YSBpbnRlcmZhY2UgYW5kICJmYXQiIHdpdGggdGhlIGtleSBk YXRhIGludGVyZmFjZQ0Kd2l0aCBhbiBlaXRoZXIgb3Igb3B0aW9uIGZvciB0aGUgcmVnaXN0cmll cy4gIFRoZSByZWdpc3RyaWVzIHRoYXQgSSB3b3JrDQpvbiBzdXBwb3J0IHRoZSAidGhpbiIgbW9k ZWwgd2l0aCB0aGUgZHMgZGF0YSBpbnRlcmZhY2UuDQoNCi0tDQogIA0KSkcNCiANCg0KIA0KSmFt ZXMgR291bGQNClByaW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlcg0KamdvdWxkQHZlcmlzaWduLmNv bQ0KIA0KNzAzLTk0OC0zMjcxIChPZmZpY2UpDQoxMjA2MSBCbHVlbW9udCBXYXkNClJlc3Rvbiwg VkEgMjAxOTANClZlcmlzaWduSW5jLmNvbQ0KDQoNCg0KDQoNCg0KDQpPbiAzLzUvMTIgNjowNCBB TSwgIlBhdHJpayBGw6RsdHN0csO2bSIgPHBhdHJpa0Bmcm9iYml0LnNlPiB3cm90ZToNCg0KPlRo aXMgb25lIGlzIHNwZWNpZmljYWxseSBpcnJpdGF0aW5nIGFzIGl0IHJlcXVpcmVzIGluIHdvcnN0 IGNhc2UgbWFzc2l2ZQ0KPmV4cGxhbmF0aW9ucywgZWR1Y2F0aW9uIGFuZCB3ZWIvUkVTVCBpbnRl cmZhY2UgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlDQo+ZGVwZW5kZW50IG9uIHRoZSBUTEQuIEku ZS4gc29tZXRoaW5nIGEgcmVnaXN0cmFyIGNhbiBub3QgImhpZGUiIGZyb20gdGhlDQo+cmVnaXN0 cmFudC4NCj4NCj5JIGFtIG5vdCBoYXBweSBhYm91dCBkaWZmZXJlbmNlcyB0aGF0IGNvc3QgcmVn aXN0cmFycyBoYXJkIHdvcmsgb2YNCj52YXJpb3VzIGtpbmRzLiBCdXQgSSBhbSBkZWZpbml0ZWx5 IG5vdCBoYXBweSBvZiB0aGluZ3MgdGhhdCBjb3N0DQo+cmVnaXN0cmFudCB0aGluZ3MuDQo+DQo+ U28sIGZvciB0aGlzIHNwZWNpZmljIGNhc2UsIEkgd291bGQgbGlrZSB0byBzZWUgYSBNVVNUIGlu IGF0IGxlYXN0IHRoZSBEUw0KPmludGVyZmFjZS4NCj4NCj4gICBQYXRyaWsNCj4NCj5PbiA1IG1h ciAyMDEyLCBhdCAxMTo1OSwgTWljaGVsZSBOZXlsb24gOjogQmxhY2tuaWdodCB3cm90ZToNCj4N Cj4+IFBhdHJpaw0KPj4gDQo+PiBXZWxjb21lIHRvIG91ciB3b3JsZCA6KQ0KPj4gDQo+PiBXZSBz ZWUgaW5jb25zaXN0ZW5jaWVzIGJldHdlZW4gcmVnaXN0cmllcyBhbGwgdGhlIHRpbWUgLSBpdCBt YWtlcw0KPj5pbnRlZ3JhdGlvbiB3aXRoIG5ldyByZWdpc3RyeSBwcm92aWRlcnMgcGFpbmZ1bCBh bmQgYXMgYSByZXN1bHQgd2UgdGVuZA0KPj50byBmb2N1cyBvbiB0aGUgb25lcyB3aG9zZSBxdWly a3Mgd2UndmUgYWxyZWFkeSBkZWFsdCB3aXRoDQo+PiANCj4+IFJlZ2FyZHMNCj4+IA0KPj4gTWlj aGVsZQ0KPj4gDQo+PiANCj4+IE9uIDUgTWFyIDIwMTIsIGF0IDEwOjQzLCBQYXRyaWsgRsOkbHRz dHLDtm0gd3JvdGU6DQo+PiANCj4+PiBBY2NvcmRpbmcgdG8gUkZDIDU5MTAsIHNlY3Rpb24gNCwg dGhlcmUgYXJlIHR3byBhbHRlcm5hdGl2ZSBpbnRlcmZhY2VzDQo+Pj5mb3IgbWFuYWdpbmcgRE5T U0VDIGtleSBkYXRhIHdoZW4gaW50ZXJmYWNpbmcgd2l0aCBhIHJlZ2lzdHJ5LiBUaGUgUkZDDQo+ Pj5kb2VzIG5vdCBleHBsaWNpdGx5IHNheSB3aGV0aGVyIGEgcmVnaXN0cnkgbXVzdCBpbXBsZW1l bnQgb25lIG9yIHRoZQ0KPj4+b3RoZXIuDQo+Pj4gDQo+Pj4gSSBoYXZlIHN1Y2Nlc3NmdWxseSBp bXBsZW1lbnRlZCBpbiBhIHdlYiBpbnRlcmZhY2UsIGFuIEFQSSBmb3INCj4+PnJlZ2lzdHJhbnRz IGV0YywgdGhlIERTIGludGVyZmFjZSBhcyB0aGUgY2xpZW50IGRvIGJlbGlldmUgcGFzc2luZyBE Uw0KPj4+ZGF0YSBpcyB0aGUgZWFzaWVzdC4gQWZ0ZXIgYWxsIHRoYXQgaXMgd2hhdCBpcyB0byBi ZSBzaWduZWQgYnkgdGhlDQo+Pj5wYXJlbnQuDQo+Pj4gDQo+Pj4gSSBqdXN0IGVuY291bnRlcmVk IGEgcmVnaXN0cnkgdGhhdCAid2FudCB0byBzZXQgYSBsaW1pdCBvbiB3aGF0IGRpZ2VzdA0KPj4+ YWxnb3JpdGhtcyB0byB1c2UiIGFuZCB0byBkbyB0aGF0LCB0aGV5IGhhdmUgZGVjaWRlZCB0byBu b3QgaW1wbGVtZW50DQo+Pj50aGUgRFMgaW50ZXJmYWNlIGFuZCBvbmx5IHN1cHBvcnQgdGhlIEtF WSBpbnRlcmZhY2UuDQo+Pj4gDQo+Pj4gSSBjYW4gYWNjZXB0IGxpbWl0YXRpb25zIG9uIHdoYXQg ZGlnZXN0IGFsZ29yaXRobXMgdGhleSBhY2NlcHQsIGJ1dA0KPj4+bm90IGxpbWl0YXRpb25zIGJ5 IG5vdCBzdXBwb3J0aW5nIERTLg0KPj4+IA0KPj4+IFJlYWN0aW9ucz8NCj4+PiANCj4+PiBQYXRy aWsNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+Pj4gcHJvdnJlZ0BpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJvdnJlZw0KPj4gDQo+PiBN ciBNaWNoZWxlIE5leWxvbg0KPj4gQmxhY2tuaWdodCBTb2x1dGlvbnMg4pmeDQo+PiBIb3N0aW5n ICYgQ29sb2NhdGlvbiwgQnJhbmQgUHJvdGVjdGlvbg0KPj4gSUNBTk4gQWNjcmVkaXRlZCBSZWdp c3RyYXINCj4+IGh0dHA6Ly93d3cuYmxhY2tuaWdodC5jb20vDQo+PiBodHRwOi8vYmxvZy5ibGFj a25pZ2h0LmNvbS8NCj4+IGh0dHA6Ly9ibGFja25pZ2h0LmJpeg0KPj4gaHR0cDovL21uZXlsb24u dGVsDQo+PiBJbnRsLiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KPj4gVVM6IDIxMy0yMzMtMTYxMg0K Pj4gTG9jYWxsOiAxODUwIDkyOSA5MjkNCj4+IERpcmVjdCBEaWFsOiArMzUzICgwKTU5IDkxODMw OTANCj4+IEZhY2Vib29rOiBodHRwOi8vZmIubWUvYmxhY2tuaWdodA0KPj4gVHdpdHRlcjogaHR0 cDovL3R3aXR0ZXIuY29tL21uZXlsb24NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+IEJsYWNrbmlnaHQgSW50ZXJuZXQgU29sdXRpb25zIEx0ZCwgVW5pdCAxMkEsQmFycm93 c2lkZSBCdXNpbmVzcw0KPj5QYXJrLFNsZWF0eQ0KPj4gUm9hZCxHcmFpZ3VlY3VsbGVuLENhcmxv dyxJcmVsYW5kICBDb21wYW55IE5vLjogMzcwODQ1DQo+PiANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBwcm92cmVnIG1haWxpbmcgbGlzdA0K Pj4gcHJvdnJlZ0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wcm92cmVnDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5wcm92cmVnIG1haWxpbmcgbGlzdA0KPnByb3ZyZWdAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Byb3ZyZWcNCg0K From patrik@frobbit.se Mon Mar 5 05:31:41 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138A021F86DC for ; Mon, 5 Mar 2012 05:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSGDb4Oo0FDw for ; Mon, 5 Mar 2012 05:31:40 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 7107921F86B9 for ; Mon, 5 Mar 2012 05:31:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3360A133B56C8; Mon, 5 Mar 2012 14:31:39 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZOBOq8Mp2FD; Mon, 5 Mar 2012 14:31:38 +0100 (CET) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 43145133B56B8; Mon, 5 Mar 2012 14:31:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_BCBF61E8-02B5-44DA-A2B7-ED780328CEAF"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 5 Mar 2012 14:31:36 +0100 Message-Id: <25B0F12F-91FE-40CB-8B90-510C3FB217F9@frobbit.se> References: To: "Gould, James" X-Mailer: Apple Mail (2.1257) Cc: "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:31:41 -0000 --Apple-Mail=_BCBF61E8-02B5-44DA-A2B7-ED780328CEAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 mar 2012, at 14:21, Gould, James wrote: > I believe that a > mix of "thin" and "fat" would make things more complex since the > registrars would need to support both instead of one interface for the > registries that do support the "fat" model. Today that is obviously what we have as the registries do support either = DS or KEY (and not both). > Think about handling > transfers between registrars where the gaining registrar supports only = the > "thin" model and the losing registrar supports both "thin" and "fat". Yup, that creates problems for the registrant as well. > The registries that I work > on support the "thin" model with the ds data interface. ...and the registries I work with so far (which include .SE) support the = DS interface. But I stumbled upon one that only support KEY interface. Patrik --Apple-Mail=_BCBF61E8-02B5-44DA-A2B7-ED780328CEAF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iD8DBQFPVMA4rMabGguI180RArxnAJ0R0+o2IWQm/1u94fabB42Pi21idQCgh7vK kveP1ie6UXoV/zLQL5xCaR4= =fhLF -----END PGP SIGNATURE----- --Apple-Mail=_BCBF61E8-02B5-44DA-A2B7-ED780328CEAF-- From michael@mwyoung.ca Mon Mar 5 05:39:08 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDB021F86FD for ; Mon, 5 Mar 2012 05:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiyYfCa6ZiPl for ; Mon, 5 Mar 2012 05:39:07 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9A21F86B9 for ; Mon, 5 Mar 2012 05:39:06 -0800 (PST) Received: by iazz13 with SMTP id z13so6537572iaz.31 for ; Mon, 05 Mar 2012 05:39:06 -0800 (PST) Received-SPF: pass (google.com: domain of michael@mwyoung.ca designates 10.43.134.199 as permitted sender) client-ip=10.43.134.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of michael@mwyoung.ca designates 10.43.134.199 as permitted sender) smtp.mail=michael@mwyoung.ca Received: from mr.google.com ([10.43.134.199]) by 10.43.134.199 with SMTP id id7mr13085057icc.21.1330954746681 (num_hops = 1); Mon, 05 Mar 2012 05:39:06 -0800 (PST) Received: by 10.43.134.199 with SMTP id id7mr10778955icc.21.1330954746514; Mon, 05 Mar 2012 05:39:06 -0800 (PST) Received: from [10.244.70.34] (static-67-226-172-181.ptr.terago.net. [67.226.172.181]) by mx.google.com with ESMTPS id x1sm11519700igc.16.2012.03.05.05.39.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 05:39:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_CD132993-AA2A-497F-9D78-C19366D9D4F3" From: MICHAEL YOUNG In-Reply-To: Date: Mon, 5 Mar 2012 08:38:50 -0500 Message-Id: <4A48A5DC-683E-4B9E-9485-EB22A1301895@mwyoung.ca> References: To: "Gould, James" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkIVzL8lsYsKQh3CbgjRRD6g7pcavi2C1XZOpdNwjtwGKhoJn57X7ztUK5jubk3R2Bnl85U Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:39:08 -0000 --Apple-Mail=_CD132993-AA2A-497F-9D78-C19366D9D4F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 James, I'm not sure from what you've written here, what your vote is, I = think it's for the ds data interface? I'm for the "thin" model and agree it should be a must.=20 BTW, in all fairness, we all miss the opportunity to raise issues on = these lists - it's tough to stay on top of the discussion flow when you = have a day job as well. -Michael On 2012-03-05, at 8:21 AM, Gould, James wrote: > Patrik, >=20 > This was discussed on this list in late 2009. Ulrich Wisser brought = up on > the list on October 28, 2009 "that .SE and other registries considered = to > become a "fat" registry and take in the public keys instead of the ds > records". Support for a "thin" DNSSEC registry as a MUST with the = option > for a "fat" registry was never discussed on the list. I believe that = a > mix of "thin" and "fat" would make things more complex since the > registrars would need to support both instead of one interface for the > registries that do support the "fat" model. Think about handling > transfers between registrars where the gaining registrar supports only = the > "thin" model and the losing registrar supports both "thin" and "fat". > There was support on this list and no concerns raised in adding = support > for the key data interface to the draft. You were active on the list > while this was being discussed and never expressed any concerns in = support > for the key data interface. What is in the RFC supports the models of > "thin" with the ds data interface and "fat" with the key data = interface > with an either or option for the registries. The registries that I = work > on support the "thin" model with the ds data interface. >=20 > -- >=20 > JG >=20 >=20 >=20 > James Gould > Principal Software Engineer > jgould@verisign.com >=20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 3/5/12 6:04 AM, "Patrik F=C3=A4ltstr=C3=B6m" = wrote: >=20 >> This one is specifically irritating as it requires in worst case = massive >> explanations, education and web/REST interface implementations that = are >> dependent on the TLD. I.e. something a registrar can not "hide" from = the >> registrant. >>=20 >> I am not happy about differences that cost registrars hard work of >> various kinds. But I am definitely not happy of things that cost >> registrant things. >>=20 >> So, for this specific case, I would like to see a MUST in at least = the DS >> interface. >>=20 >> Patrik >>=20 >> On 5 mar 2012, at 11:59, Michele Neylon :: Blacknight wrote: >>=20 >>> Patrik >>>=20 >>> Welcome to our world :) >>>=20 >>> We see inconsistencies between registries all the time - it makes >>> integration with new registry providers painful and as a result we = tend >>> to focus on the ones whose quirks we've already dealt with >>>=20 >>> Regards >>>=20 >>> Michele >>>=20 >>>=20 >>> On 5 Mar 2012, at 10:43, Patrik F=C3=A4ltstr=C3=B6m wrote: >>>=20 >>>> According to RFC 5910, section 4, there are two alternative = interfaces >>>> for managing DNSSEC key data when interfacing with a registry. The = RFC >>>> does not explicitly say whether a registry must implement one or = the >>>> other. >>>>=20 >>>> I have successfully implemented in a web interface, an API for >>>> registrants etc, the DS interface as the client do believe passing = DS >>>> data is the easiest. After all that is what is to be signed by the >>>> parent. >>>>=20 >>>> I just encountered a registry that "want to set a limit on what = digest >>>> algorithms to use" and to do that, they have decided to not = implement >>>> the DS interface and only support the KEY interface. >>>>=20 >>>> I can accept limitations on what digest algorithms they accept, but >>>> not limitations by not supporting DS. >>>>=20 >>>> Reactions? >>>>=20 >>>> Patrik >>>>=20 >>>> _______________________________________________ >>>> provreg mailing list >>>> provreg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/provreg >>>=20 >>> Mr Michele Neylon >>> Blacknight Solutions =E2=99=9E >>> Hosting & Colocation, Brand Protection >>> ICANN Accredited Registrar >>> http://www.blacknight.com/ >>> http://blog.blacknight.com/ >>> http://blacknight.biz >>> http://mneylon.tel >>> Intl. +353 (0) 59 9183072 >>> US: 213-233-1612 >>> Locall: 1850 929 929 >>> Direct Dial: +353 (0)59 9183090 >>> Facebook: http://fb.me/blacknight >>> Twitter: http://twitter.com/mneylon >>> ------------------------------- >>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business >>> Park,Sleaty >>> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >>>=20 >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_CD132993-AA2A-497F-9D78-C19366D9D4F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


BTW, in all fairness, we all miss = the opportunity to raise issues on these lists - it's tough to stay on = top of the discussion flow when you have a day job as = well.


-Michael


On 2012-03-05, at 8:21 AM, Gould, James wrote:

Patrik,

This was discussed on this list in = late 2009.  Ulrich Wisser brought up on
the list on October 28, = 2009 "that .SE and other registries considered to
become a "fat" = registry and take in the public keys instead of the ds
records". =  Support for a "thin" DNSSEC registry as a MUST with the = option
for a "fat" registry was never discussed on the list.  I = believe that a
mix of "thin" and "fat" would make things more complex = since the
registrars would need to support both instead of one = interface for the
registries that do support the "fat" model. =  Think about handling
transfers between registrars where the = gaining registrar supports only the
"thin" model and the losing = registrar supports both "thin" and "fat".
There was support on this = list and no concerns raised in adding support
for the key data = interface to the draft.  You were active on the list
while this = was being discussed and never expressed any concerns in support
for = the key data interface.  What is in the RFC supports the models = of
"thin" with the ds data interface and "fat" with the key data = interface
with an either or option for the registries.  The = registries that I work
on support the "thin" model with the ds data = interface.

--

JG



James Gould
Principal = Software Engineer
jgould@verisign.com

703-948= -3271 (Office)
12061 Bluemont Way
Reston, VA = 20190
VerisignInc.com







On 3/5/12 6:04 = AM, "Patrik F=C3=A4ltstr=C3=B6m" <patrik@frobbit.se> = wrote:

This one is specifically = irritating as it requires in worst case = massive
explanations, = education and web/REST interface implementations that = are
dependent on the TLD. I.e. = something a registrar can not "hide" from = the
registrant.

I am not happy = about differences that cost registrars hard work = of
various kinds. But I am = definitely not happy of things that cost
registrant things.

So, for this = specific case, I would like to see a MUST in at least the = DS
interface.

=  Patrik

On 5 mar 2012, = at 11:59, Michele Neylon :: Blacknight = wrote:

Patrik

Welcome to our world = :)

We see inconsistencies between = registries all the time - it = makes
integration with new registry providers painful and as a = result we tend
to focus on the ones whose = quirks we've already dealt with

Regards

Michele


On 5 Mar 2012, at 10:43, Patrik = F=C3=A4ltstr=C3=B6m wrote:

According to RFC 5910, section 4, there are two = alternative = interfaces
for = managing DNSSEC key data when interfacing with a registry. The = RFC
does = not explicitly say whether a registry must implement one or = the
other.

I have = successfully implemented in a web interface, an API = for
registrants etc, the DS interface as the client do believe = passing DS
data = is the easiest. After all that is what is to be signed by = the
parent.

I just = encountered a registry that "want to set a limit on what = digest
algorithms to use" and to do that, they have decided to = not implement
the DS = interface and only support the KEY = interface.

I can = accept limitations on what digest algorithms they accept, = but
not = limitations by not supporting = DS.

Reactions?

Patrik

_______________________________________________
provreg mailing = list
provreg@ietf.org
<= blockquote type=3D"cite">
https://www.ietf.org/mailman/listinfo/provreg

Mr Michele = Neylon
Blacknight Solutions = =E2=99=9E
Hosting & Colocation, Brand = Protection
ICANN Accredited = Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.biz
http://mneylon.tel
Intl. +353 (0) 59 =  9183072
US: = 213-233-1612
Locall: 1850 929 = 929
Direct Dial: +353 (0)59 = 9183090
Facebook: = http://fb.me/blacknight
Twitter: = http://twitter.com/mneylon
-------------------------------
Blacknight Internet = Solutions Ltd, Unit 12A,Barrowside = Business
Park,Sleaty
Road,Graiguecullen,Carlow,Ireland =  Company No.: 370845

_______________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg<= br>




MICHAEL = YOUNG




= --Apple-Mail=_CD132993-AA2A-497F-9D78-C19366D9D4F3-- From ajs@anvilwalrusden.com Mon Mar 5 05:45:05 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D608521F8568 for ; Mon, 5 Mar 2012 05:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWMA2H8zLqUp for ; Mon, 5 Mar 2012 05:45:05 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E148821F8555 for ; Mon, 5 Mar 2012 05:45:04 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E221F1ECB41D for ; Mon, 5 Mar 2012 13:45:03 +0000 (UTC) Date: Mon, 5 Mar 2012 08:45:03 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120305134455.GA76465@mail.yitter.info> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:45:06 -0000 On Mon, Mar 05, 2012 at 11:43:30AM +0100, Patrik Fältström wrote: > According to RFC 5910, section 4, there are two alternative > interfaces for managing DNSSEC key data when interfacing with a > registry. The RFC does not explicitly say whether a registry must > implement one or the other. Of course it doesn't. Registries are going to have policies, and those policies might differ. For instance, > I have successfully implemented in a web interface, an API for > registrants etc, the DS interface as the client do believe passing > DS data is the easiest. After all that is what is to be signed by > the parent. even though the client might believe that passing the DS data is the easiest, the registry might want the DNSKEY data. The reason to prefer the DNSKEY data is because the DS is authoritative _only at the parent_. In principle, then, it is a mistake to accept any old DS data from the child side of the zone cut and publish it as authoritative data: the registry can't be sure it has that right. Therefore, it either should accept DS data with a DNSKEY that it can validate the DS with, or else it should just accept the DNSKEY data and generate the DS itself. Many (most?) registries are drawing an analogy with NS and IP addresses in A/AAAA records, and simply accepting what the client sends them. The problem with that analogy is that neither of those types of data are actually authoritative (or anyway, only authoritative) on the parent side. The apex NS records, for instance, are authoritative data (some implementations treat them as the _only_ authoritative data, checking the apex record after receiving the delegation-NS RRset); and glue records are certainly not authoritative, which is why we no longer promote glue from the Additional section. I find the complaints about inconsistencies across registries to be a little odd: the whole point of EPP is supposed to be its extensibility, and that will necessarily mean inconsistencies. I'd be more interested in arguments about why it is so difficult to find and use the extensions. It always seemed to me that the client libraries were the problem: they don't have a good plugin architecture, which should make the use of extensions easy. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From JGould@verisign.com Mon Mar 5 05:50:03 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47BB21F85EC for ; Mon, 5 Mar 2012 05:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsQMj-n5pmcp for ; Mon, 5 Mar 2012 05:50:02 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5A22F21F8599 for ; Mon, 5 Mar 2012 05:49:54 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKT1TEeht5u6EN7KnXvDd1GA1kNgo6BAgt@postini.com; Mon, 05 Mar 2012 05:49:56 PST 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 q25DnksU000781; Mon, 5 Mar 2012 08:49:46 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 08:49:46 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 08:49:45 -0500 From: "Gould, James" To: MICHAEL YOUNG Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: AQHM+r0q7eo1z51rQ0WnxvppIby9dZZb3HqAgAABYgD//9JTgIAAWMAA//+vN4A= Date: Mon, 5 Mar 2012 13:49:45 +0000 Message-ID: In-Reply-To: <4A48A5DC-683E-4B9E-9485-EB22A1301895@mwyoung.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CB7A2CE219783jgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2012 13:49:46.0153 (UTC) FILETIME=[D3479190:01CCFAD6] Cc: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:50:04 -0000 --_004_CB7A2CE219783jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CB7A2CE219783jgouldverisigncom_" --_000_CB7A2CE219783jgouldverisigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWljaGFlbCwNCg0KSSdtIG5vdCB2b3RpbmcgYnV0IHNpbXBseSBjb3ZlcmluZyBob3cgdGhlIHR3 byBpbnRlcmZhY2VzIG1hZGUgaXQgaW50byB0aGUgUkZDLiAgSSBjYW4gc2VlIHRoZSBiYXNpcyBm b3IgYm90aCBpbnRlcmZhY2VzLCBidXQgSSBjZXJ0YWludHkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGEg bWl4IGluIGEgc2luZ2xlIHJlZ2lzdHJ5IGlzIHdvcmthYmxlLg0KDQotLQ0KDQpKRw0KDQpbY2lk OkQ3QjA0NTUxLTE1Q0ItNDI4NC04QTNGLURBMjk4N0ZBQjRCNF0NCg0KSmFtZXMgR291bGQNClBy aW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlcg0KamdvdWxkQHZlcmlzaWduLmNvbQ0KDQo3MDMtOTQ4 LTMyNzEgKE9mZmljZSkNCjEyMDYxIEJsdWVtb250IFdheQ0KUmVzdG9uLCBWQSAyMDE5MA0KVmVy aXNpZ25JbmMuY29tDQoNCg0KRnJvbTogTUlDSEFFTCBZT1VORyA8bWljaGFlbEBtd3lvdW5nLmNh PG1haWx0bzptaWNoYWVsQG13eW91bmcuY2E+Pg0KRGF0ZTogTW9uLCA1IE1hciAyMDEyIDA4OjM4 OjUwIC0wNTAwDQpUbzogSmFtZXMgR291bGQgPGpnb3VsZEB2ZXJpc2lnbi5jb208bWFpbHRvOmpn b3VsZEB2ZXJpc2lnbi5jb20+Pg0KQ2M6IFBhdHJpayBGw6RsdHN0csO2bSA8cGF0cmlrQGZyb2Ji aXQuc2U8bWFpbHRvOnBhdHJpa0Bmcm9iYml0LnNlPj4sICJNaWNoZWxlIE5leWxvbiA6OiBCbGFj a25pZ2h0IiA8bWljaGVsZUBibGFja25pZ2h0LmllPG1haWx0bzptaWNoZWxlQGJsYWNrbmlnaHQu aWU+PiwgIjxwcm92cmVnQGlldGYub3JnPG1haWx0bzpwcm92cmVnQGlldGYub3JnPj4iIDxwcm92 cmVnQGlldGYub3JnPG1haWx0bzpwcm92cmVnQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcHJv dnJlZ10gRXhhbXBsZSBvZiBzdHVwaWQgaW5jb25zaXN0ZW5jaWVzIGJldHdlZW4gcmVnaXN0cmll cw0KDQpKYW1lcywgSSdtIG5vdCBzdXJlIGZyb20gd2hhdCB5b3UndmUgd3JpdHRlbiBoZXJlLCB3 aGF0IHlvdXIgdm90ZSBpcywgSSB0aGluayBpdCdzIGZvciB0aGUgZHMgZGF0YSBpbnRlcmZhY2U/ DQoNCkknbSBmb3IgdGhlICJ0aGluIiBtb2RlbCBhbmQgYWdyZWUgaXQgc2hvdWxkIGJlIGEgbXVz dC4NCg0KQlRXLCBpbiBhbGwgZmFpcm5lc3MsIHdlIGFsbCBtaXNzIHRoZSBvcHBvcnR1bml0eSB0 byByYWlzZSBpc3N1ZXMgb24gdGhlc2UgbGlzdHMgLSBpdCdzIHRvdWdoIHRvIHN0YXkgb24gdG9w IG9mIHRoZSBkaXNjdXNzaW9uIGZsb3cgd2hlbiB5b3UgaGF2ZSBhIGRheSBqb2IgYXMgd2VsbC4N Cg0KDQotTWljaGFlbA0KDQoNCk9uIDIwMTItMDMtMDUsIGF0IDg6MjEgQU0sIEdvdWxkLCBKYW1l cyB3cm90ZToNCg0KUGF0cmlrLA0KDQpUaGlzIHdhcyBkaXNjdXNzZWQgb24gdGhpcyBsaXN0IGlu IGxhdGUgMjAwOS4gIFVscmljaCBXaXNzZXIgYnJvdWdodCB1cCBvbg0KdGhlIGxpc3Qgb24gT2N0 b2JlciAyOCwgMjAwOSAidGhhdCAuU0UgYW5kIG90aGVyIHJlZ2lzdHJpZXMgY29uc2lkZXJlZCB0 bw0KYmVjb21lIGEgImZhdCIgcmVnaXN0cnkgYW5kIHRha2UgaW4gdGhlIHB1YmxpYyBrZXlzIGlu c3RlYWQgb2YgdGhlIGRzDQpyZWNvcmRzIi4gIFN1cHBvcnQgZm9yIGEgInRoaW4iIEROU1NFQyBy ZWdpc3RyeSBhcyBhIE1VU1Qgd2l0aCB0aGUgb3B0aW9uDQpmb3IgYSAiZmF0IiByZWdpc3RyeSB3 YXMgbmV2ZXIgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0LiAgSSBiZWxpZXZlIHRoYXQgYQ0KbWl4IG9m ICJ0aGluIiBhbmQgImZhdCIgd291bGQgbWFrZSB0aGluZ3MgbW9yZSBjb21wbGV4IHNpbmNlIHRo ZQ0KcmVnaXN0cmFycyB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgYm90aCBpbnN0ZWFkIG9mIG9uZSBp bnRlcmZhY2UgZm9yIHRoZQ0KcmVnaXN0cmllcyB0aGF0IGRvIHN1cHBvcnQgdGhlICJmYXQiIG1v ZGVsLiAgVGhpbmsgYWJvdXQgaGFuZGxpbmcNCnRyYW5zZmVycyBiZXR3ZWVuIHJlZ2lzdHJhcnMg d2hlcmUgdGhlIGdhaW5pbmcgcmVnaXN0cmFyIHN1cHBvcnRzIG9ubHkgdGhlDQoidGhpbiIgbW9k ZWwgYW5kIHRoZSBsb3NpbmcgcmVnaXN0cmFyIHN1cHBvcnRzIGJvdGggInRoaW4iIGFuZCAiZmF0 Ii4NClRoZXJlIHdhcyBzdXBwb3J0IG9uIHRoaXMgbGlzdCBhbmQgbm8gY29uY2VybnMgcmFpc2Vk IGluIGFkZGluZyBzdXBwb3J0DQpmb3IgdGhlIGtleSBkYXRhIGludGVyZmFjZSB0byB0aGUgZHJh ZnQuICBZb3Ugd2VyZSBhY3RpdmUgb24gdGhlIGxpc3QNCndoaWxlIHRoaXMgd2FzIGJlaW5nIGRp c2N1c3NlZCBhbmQgbmV2ZXIgZXhwcmVzc2VkIGFueSBjb25jZXJucyBpbiBzdXBwb3J0DQpmb3Ig dGhlIGtleSBkYXRhIGludGVyZmFjZS4gIFdoYXQgaXMgaW4gdGhlIFJGQyBzdXBwb3J0cyB0aGUg bW9kZWxzIG9mDQoidGhpbiIgd2l0aCB0aGUgZHMgZGF0YSBpbnRlcmZhY2UgYW5kICJmYXQiIHdp dGggdGhlIGtleSBkYXRhIGludGVyZmFjZQ0Kd2l0aCBhbiBlaXRoZXIgb3Igb3B0aW9uIGZvciB0 aGUgcmVnaXN0cmllcy4gIFRoZSByZWdpc3RyaWVzIHRoYXQgSSB3b3JrDQpvbiBzdXBwb3J0IHRo ZSAidGhpbiIgbW9kZWwgd2l0aCB0aGUgZHMgZGF0YSBpbnRlcmZhY2UuDQoNCi0tDQoNCkpHDQoN Cg0KDQpKYW1lcyBHb3VsZA0KUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyDQpqZ291bGRAdmVy aXNpZ24uY29tPG1haWx0bzpqZ291bGRAdmVyaXNpZ24uY29tPg0KDQo3MDMtOTQ4LTMyNzEgKE9m ZmljZSkNCjEyMDYxIEJsdWVtb250IFdheQ0KUmVzdG9uLCBWQSAyMDE5MA0KVmVyaXNpZ25JbmMu Y29tDQoNCg0KDQoNCg0KDQoNCk9uIDMvNS8xMiA2OjA0IEFNLCAiUGF0cmlrIEbDpGx0c3Ryw7Zt IiA8cGF0cmlrQGZyb2JiaXQuc2U8bWFpbHRvOnBhdHJpa0Bmcm9iYml0LnNlPj4gd3JvdGU6DQoN ClRoaXMgb25lIGlzIHNwZWNpZmljYWxseSBpcnJpdGF0aW5nIGFzIGl0IHJlcXVpcmVzIGluIHdv cnN0IGNhc2UgbWFzc2l2ZQ0KZXhwbGFuYXRpb25zLCBlZHVjYXRpb24gYW5kIHdlYi9SRVNUIGlu dGVyZmFjZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUNCmRlcGVuZGVudCBvbiB0aGUgVExELiBJ LmUuIHNvbWV0aGluZyBhIHJlZ2lzdHJhciBjYW4gbm90ICJoaWRlIiBmcm9tIHRoZQ0KcmVnaXN0 cmFudC4NCg0KSSBhbSBub3QgaGFwcHkgYWJvdXQgZGlmZmVyZW5jZXMgdGhhdCBjb3N0IHJlZ2lz dHJhcnMgaGFyZCB3b3JrIG9mDQp2YXJpb3VzIGtpbmRzLiBCdXQgSSBhbSBkZWZpbml0ZWx5IG5v dCBoYXBweSBvZiB0aGluZ3MgdGhhdCBjb3N0DQpyZWdpc3RyYW50IHRoaW5ncy4NCg0KU28sIGZv ciB0aGlzIHNwZWNpZmljIGNhc2UsIEkgd291bGQgbGlrZSB0byBzZWUgYSBNVVNUIGluIGF0IGxl YXN0IHRoZSBEUw0KaW50ZXJmYWNlLg0KDQogUGF0cmlrDQoNCk9uIDUgbWFyIDIwMTIsIGF0IDEx OjU5LCBNaWNoZWxlIE5leWxvbiA6OiBCbGFja25pZ2h0IHdyb3RlOg0KDQpQYXRyaWsNCg0KV2Vs Y29tZSB0byBvdXIgd29ybGQgOikNCg0KV2Ugc2VlIGluY29uc2lzdGVuY2llcyBiZXR3ZWVuIHJl Z2lzdHJpZXMgYWxsIHRoZSB0aW1lIC0gaXQgbWFrZXMNCmludGVncmF0aW9uIHdpdGggbmV3IHJl Z2lzdHJ5IHByb3ZpZGVycyBwYWluZnVsIGFuZCBhcyBhIHJlc3VsdCB3ZSB0ZW5kDQp0byBmb2N1 cyBvbiB0aGUgb25lcyB3aG9zZSBxdWlya3Mgd2UndmUgYWxyZWFkeSBkZWFsdCB3aXRoDQoNClJl Z2FyZHMNCg0KTWljaGVsZQ0KDQoNCk9uIDUgTWFyIDIwMTIsIGF0IDEwOjQzLCBQYXRyaWsgRsOk bHRzdHLDtm0gd3JvdGU6DQoNCkFjY29yZGluZyB0byBSRkMgNTkxMCwgc2VjdGlvbiA0LCB0aGVy ZSBhcmUgdHdvIGFsdGVybmF0aXZlIGludGVyZmFjZXMNCmZvciBtYW5hZ2luZyBETlNTRUMga2V5 IGRhdGEgd2hlbiBpbnRlcmZhY2luZyB3aXRoIGEgcmVnaXN0cnkuIFRoZSBSRkMNCmRvZXMgbm90 IGV4cGxpY2l0bHkgc2F5IHdoZXRoZXIgYSByZWdpc3RyeSBtdXN0IGltcGxlbWVudCBvbmUgb3Ig dGhlDQpvdGhlci4NCg0KSSBoYXZlIHN1Y2Nlc3NmdWxseSBpbXBsZW1lbnRlZCBpbiBhIHdlYiBp bnRlcmZhY2UsIGFuIEFQSSBmb3INCnJlZ2lzdHJhbnRzIGV0YywgdGhlIERTIGludGVyZmFjZSBh cyB0aGUgY2xpZW50IGRvIGJlbGlldmUgcGFzc2luZyBEUw0KZGF0YSBpcyB0aGUgZWFzaWVzdC4g QWZ0ZXIgYWxsIHRoYXQgaXMgd2hhdCBpcyB0byBiZSBzaWduZWQgYnkgdGhlDQpwYXJlbnQuDQoN CkkganVzdCBlbmNvdW50ZXJlZCBhIHJlZ2lzdHJ5IHRoYXQgIndhbnQgdG8gc2V0IGEgbGltaXQg b24gd2hhdCBkaWdlc3QNCmFsZ29yaXRobXMgdG8gdXNlIiBhbmQgdG8gZG8gdGhhdCwgdGhleSBo YXZlIGRlY2lkZWQgdG8gbm90IGltcGxlbWVudA0KdGhlIERTIGludGVyZmFjZSBhbmQgb25seSBz dXBwb3J0IHRoZSBLRVkgaW50ZXJmYWNlLg0KDQpJIGNhbiBhY2NlcHQgbGltaXRhdGlvbnMgb24g d2hhdCBkaWdlc3QgYWxnb3JpdGhtcyB0aGV5IGFjY2VwdCwgYnV0DQpub3QgbGltaXRhdGlvbnMg Ynkgbm90IHN1cHBvcnRpbmcgRFMuDQoNClJlYWN0aW9ucz8NCg0KUGF0cmlrDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwcm92cmVnIG1haWxpbmcg bGlzdA0KcHJvdnJlZ0BpZXRmLm9yZzxtYWlsdG86cHJvdnJlZ0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJvdnJlZw0KDQpNciBNaWNoZWxlIE5leWxv bg0KQmxhY2tuaWdodCBTb2x1dGlvbnMg4pmeDQpIb3N0aW5nICYgQ29sb2NhdGlvbiwgQnJhbmQg UHJvdGVjdGlvbg0KSUNBTk4gQWNjcmVkaXRlZCBSZWdpc3RyYXINCmh0dHA6Ly93d3cuYmxhY2tu aWdodC5jb20vDQpodHRwOi8vYmxvZy5ibGFja25pZ2h0LmNvbS8NCmh0dHA6Ly9ibGFja25pZ2h0 LmJpeg0KaHR0cDovL21uZXlsb24udGVsDQpJbnRsLiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KVVM6 IDIxMy0yMzMtMTYxMg0KTG9jYWxsOiAxODUwIDkyOSA5MjkNCkRpcmVjdCBEaWFsOiArMzUzICgw KTU5IDkxODMwOTANCkZhY2Vib29rOiBodHRwOi8vZmIubWUvYmxhY2tuaWdodA0KVHdpdHRlcjog aHR0cDovL3R3aXR0ZXIuY29tL21uZXlsb24NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkJsYWNrbmlnaHQgSW50ZXJuZXQgU29sdXRpb25zIEx0ZCwgVW5pdCAxMkEsQmFycm93c2lk ZSBCdXNpbmVzcw0KUGFyayxTbGVhdHkNClJvYWQsR3JhaWd1ZWN1bGxlbixDYXJsb3csSXJlbGFu ZCAgQ29tcGFueSBOby46IDM3MDg0NQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcHJvdnJlZyBtYWlsaW5nIGxpc3QNCnByb3ZyZWdAaWV0Zi5vcmc8 bWFpbHRvOnByb3ZyZWdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Byb3ZyZWcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnByb3ZyZWcgbWFpbGluZyBsaXN0DQpwcm92cmVnQGlldGYub3JnPG1haWx0bzpw cm92cmVnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w cm92cmVnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpwcm92cmVnIG1haWxpbmcgbGlzdA0KcHJvdnJlZ0BpZXRmLm9yZzxtYWlsdG86cHJvdnJlZ0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJvdnJlZw0K DQoNCg0KDQpNSUNIQUVMIFlPVU5HDQptaWNoYWVsQG13eW91bmcuY2E8bWFpbHRvOm1pY2hhZWxA bXd5b3VuZy5jYT4NCg0KDQoNCg0K --_000_CB7A2CE219783jgouldverisigncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8B4607B14542F14DBB35BFA68D317368@verisign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj5NaWNoYWVsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSdtIG5vdCB2b3Rp bmcgYnV0IHNpbXBseSBjb3ZlcmluZyBob3cgdGhlIHR3byBpbnRlcmZhY2VzIG1hZGUgaXQgaW50 byB0aGUgUkZDLiAmbmJzcDtJIGNhbiBzZWUgdGhlIGJhc2lzIGZvciBib3RoIGludGVyZmFjZXMs IGJ1dCBJIGNlcnRhaW50eSBkb24ndCBiZWxpZXZlIHRoYXQgYSBtaXggaW4gYSBzaW5nbGUgcmVn aXN0cnkgaXMgd29ya2FibGUuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPGZvbnQgY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkNhbGlicmkiIHNpemU9IjQiPjxzcGFuIGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj48L3NwYW4+PC9mb250PjwvcD4NCjxmb250IGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBmYWNlPSJDYWxpYnJpIiBzaXplPSI0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IENhbWJyaWE7ICI+DQo8Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg ZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSJmb250LXNpemU6IDE0cHg7ICI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPG86cD48Zm9udCBjbGFzcz0iQXBw bGUtc3R5bGUtc3BhbiIgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxl LXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7ICI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L286cD48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ2FsaWJyaSIgc2l6 ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0 cHg7ICI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENh bWJyaWE7ICI+DQo8Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ2FsaWJyaSIg c2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6 IDE0cHg7ICI+Skc8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiBDYW1icmlhOyAiPg0KPG86cD48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg ZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSJmb250LXNpemU6IDE0cHg7ICI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbWJyaWE7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsgIj48aW1nIHdpZHRoPSI3NSIgaGVpZ2h0PSI2 NiIgc3JjPSJjaWQ6RDdCMDQ1NTEtMTVDQi00Mjg0LThBM0YtREEyOTg3RkFCNEI0IiB2OnNoYXBl cz0iUGljdHVyZV94MDAyMF8xIiB0eXBlPSJpbWFnZS9wbmciPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsgIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbWJyaWE7ICI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxNnB0OyBmb250LWZhbWlseTogVGltZXM7ICI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGNvbG9yOiByZ2IoMTAsIDgyLCAxNTUpOyAi Pjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzaXplPSIzIj48c3BhbiBjbGFzcz0iQXBw bGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgIj5KYW1lcyBHb3VsZDxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogQ2FtYnJpYTsgIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBjb2xv cjogcmdiKDg4LCA5MCwgOTQpOyAiPjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzaXpl PSI0Ij48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRw eDsgIj5QcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6 IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FtYnJpYTsgIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBjb2xvcjogcmdiKDE0LCAwLCAyMzcpOyAiPjxm b250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzaXplPSI0Ij48c3BhbiBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgIj5qZ291bGRAdmVyaXNpZ24uY29t PC9zcGFuPjwvZm9udD48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGNvbG9yOiByZ2IoODgsIDkwLCA5NCk7ICI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4i IHNpemU9IjQiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXpl OiAxNHB4OyAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGNvbG9yOiByZ2IoODgsIDkwLCA5NCk7ICI+PG86cD48Zm9udCBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxl PSJmb250LXNpemU6IDE0cHg7ICI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGNvbG9yOiByZ2IoODgsIDkwLCA5NCk7ICI+PGZvbnQgY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIHNpemU9IjQiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu IiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPjcwMy05NDgtMzI3MSAoT2ZmaWNlKTxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1i cmlhOyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGNvbG9yOiByZ2Io ODYsIDg4LCA5Mik7ICI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHNpemU9IjQiPjxz cGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPjEy MDYxIEJsdWVtb250IFdheTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGNvbG9yOiByZ2IoODYsIDg4LCA5Mik7ICI+PGZvbnQgY2xhc3M9IkFwcGxl LXN0eWxlLXNwYW4iIHNpemU9IjQiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls ZT0iZm9udC1zaXplOiAxNHB4OyAiPlJlc3RvbiwgVkEgMjAxOTA8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FtYnJpYTsgIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBjb2xvcjogcmdiKDEwLCA4MiwgMTU1 KTsgIj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7ICI+VmVyaXNpZ25JbmMu Y29tPC9zcGFuPjwvZm9udD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBjb2xvcjogcmdiKDEwLCA4MiwgMTU1KTsgIj48Zm9udCBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxl LXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7ICI+PGJyPg0KPC9zcGFuPjwvZm9udD48L3Nw YW4+PC9kaXY+DQo8L2ZvbnQ+DQo8cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+TUlDSEFFTCBZT1VORyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1pY2hhZWxAbXd5b3VuZy5jYSI+bWljaGFlbEBtd3lvdW5nLmNhPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbiwgNSBNYXIg MjAxMiAwODozODo1MCAtMDUwMDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPkphbWVzIEdvdWxkICZsdDs8YSBocmVmPSJtYWlsdG86amdvdWxkQHZlcmlzaWdu LmNvbSI+amdvdWxkQHZlcmlzaWduLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+UGF0cmlrIEbDpGx0c3Ryw7ZtICZsdDs8YSBocmVmPSJt YWlsdG86cGF0cmlrQGZyb2JiaXQuc2UiPnBhdHJpa0Bmcm9iYml0LnNlPC9hPiZndDssICZxdW90 O01pY2hlbGUgTmV5bG9uIDo6IEJsYWNrbmlnaHQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpt aWNoZWxlQGJsYWNrbmlnaHQuaWUiPm1pY2hlbGVAYmxhY2tuaWdodC5pZTwvYT4mZ3Q7LCAmcXVv dDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnByb3ZyZWdAaWV0Zi5vcmciPnByb3ZyZWdAaWV0Zi5vcmc8 L2E+Jmd0OyZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86cHJvdnJlZ0BpZXRmLm9yZyI+cHJv dnJlZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlN1YmplY3Q6IDwvc3Bhbj5SZTogW3Byb3ZyZWddIEV4YW1wbGUgb2Ygc3R1cGlkIGluY29uc2lz dGVuY2llcyBiZXR3ZWVuIHJlZ2lzdHJpZXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8 ZGl2PkphbWVzLCBJJ20gbm90IHN1cmUgZnJvbSB3aGF0IHlvdSd2ZSB3cml0dGVuIGhlcmUsIHdo YXQgeW91ciB2b3RlIGlzLCBJIHRoaW5rIGl0J3MgZm9yIHRoZSBkcyBkYXRhIGludGVyZmFjZT88 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkknbSBmb3IgdGhlICZxdW90O3RoaW4mcXVv dDsgbW9kZWwgYW5kIGFncmVlIGl0IHNob3VsZCBiZSBhIG11c3QuJm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5CVFcsIGluIGFsbCBmYWlybmVzcywgd2UgYWxsIG1pc3MgdGhl IG9wcG9ydHVuaXR5IHRvIHJhaXNlIGlzc3VlcyBvbiB0aGVzZSBsaXN0cyAtIGl0J3MgdG91Z2gg dG8gc3RheSBvbiB0b3Agb2YgdGhlIGRpc2N1c3Npb24gZmxvdyB3aGVuIHlvdSBoYXZlIGEgZGF5 IGpvYiBhcyB3ZWxsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pi1NaWNoYWVsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxk aXY+T24gMjAxMi0wMy0wNSwgYXQgODoyMSBBTSwgR291bGQsIEphbWVzIHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj5QYXRyaWssPGJyPg0KPGJyPg0KVGhpcyB3YXMgZGlzY3Vzc2VkIG9uIHRo aXMgbGlzdCBpbiBsYXRlIDIwMDkuICZuYnNwO1VscmljaCBXaXNzZXIgYnJvdWdodCB1cCBvbjxi cj4NCnRoZSBsaXN0IG9uIE9jdG9iZXIgMjgsIDIwMDkgJnF1b3Q7dGhhdCAuU0UgYW5kIG90aGVy IHJlZ2lzdHJpZXMgY29uc2lkZXJlZCB0bzxicj4NCmJlY29tZSBhICZxdW90O2ZhdCZxdW90OyBy ZWdpc3RyeSBhbmQgdGFrZSBpbiB0aGUgcHVibGljIGtleXMgaW5zdGVhZCBvZiB0aGUgZHM8YnI+ DQpyZWNvcmRzJnF1b3Q7LiAmbmJzcDtTdXBwb3J0IGZvciBhICZxdW90O3RoaW4mcXVvdDsgRE5T U0VDIHJlZ2lzdHJ5IGFzIGEgTVVTVCB3aXRoIHRoZSBvcHRpb248YnI+DQpmb3IgYSAmcXVvdDtm YXQmcXVvdDsgcmVnaXN0cnkgd2FzIG5ldmVyIGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gJm5ic3A7 SSBiZWxpZXZlIHRoYXQgYTxicj4NCm1peCBvZiAmcXVvdDt0aGluJnF1b3Q7IGFuZCAmcXVvdDtm YXQmcXVvdDsgd291bGQgbWFrZSB0aGluZ3MgbW9yZSBjb21wbGV4IHNpbmNlIHRoZTxicj4NCnJl Z2lzdHJhcnMgd291bGQgbmVlZCB0byBzdXBwb3J0IGJvdGggaW5zdGVhZCBvZiBvbmUgaW50ZXJm YWNlIGZvciB0aGU8YnI+DQpyZWdpc3RyaWVzIHRoYXQgZG8gc3VwcG9ydCB0aGUgJnF1b3Q7ZmF0 JnF1b3Q7IG1vZGVsLiAmbmJzcDtUaGluayBhYm91dCBoYW5kbGluZzxicj4NCnRyYW5zZmVycyBi ZXR3ZWVuIHJlZ2lzdHJhcnMgd2hlcmUgdGhlIGdhaW5pbmcgcmVnaXN0cmFyIHN1cHBvcnRzIG9u bHkgdGhlPGJyPg0KJnF1b3Q7dGhpbiZxdW90OyBtb2RlbCBhbmQgdGhlIGxvc2luZyByZWdpc3Ry YXIgc3VwcG9ydHMgYm90aCAmcXVvdDt0aGluJnF1b3Q7IGFuZCAmcXVvdDtmYXQmcXVvdDsuPGJy Pg0KVGhlcmUgd2FzIHN1cHBvcnQgb24gdGhpcyBsaXN0IGFuZCBubyBjb25jZXJucyByYWlzZWQg aW4gYWRkaW5nIHN1cHBvcnQ8YnI+DQpmb3IgdGhlIGtleSBkYXRhIGludGVyZmFjZSB0byB0aGUg ZHJhZnQuICZuYnNwO1lvdSB3ZXJlIGFjdGl2ZSBvbiB0aGUgbGlzdDxicj4NCndoaWxlIHRoaXMg d2FzIGJlaW5nIGRpc2N1c3NlZCBhbmQgbmV2ZXIgZXhwcmVzc2VkIGFueSBjb25jZXJucyBpbiBz dXBwb3J0PGJyPg0KZm9yIHRoZSBrZXkgZGF0YSBpbnRlcmZhY2UuICZuYnNwO1doYXQgaXMgaW4g dGhlIFJGQyBzdXBwb3J0cyB0aGUgbW9kZWxzIG9mPGJyPg0KJnF1b3Q7dGhpbiZxdW90OyB3aXRo IHRoZSBkcyBkYXRhIGludGVyZmFjZSBhbmQgJnF1b3Q7ZmF0JnF1b3Q7IHdpdGggdGhlIGtleSBk YXRhIGludGVyZmFjZTxicj4NCndpdGggYW4gZWl0aGVyIG9yIG9wdGlvbiBmb3IgdGhlIHJlZ2lz dHJpZXMuICZuYnNwO1RoZSByZWdpc3RyaWVzIHRoYXQgSSB3b3JrPGJyPg0Kb24gc3VwcG9ydCB0 aGUgJnF1b3Q7dGhpbiZxdW90OyBtb2RlbCB3aXRoIHRoZSBkcyBkYXRhIGludGVyZmFjZS48YnI+ DQo8YnI+DQotLTxicj4NCjxicj4NCkpHPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KSmFtZXMgR291 bGQ8YnI+DQpQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXI8YnI+DQo8YSBocmVmPSJtYWlsdG86 amdvdWxkQHZlcmlzaWduLmNvbSI+amdvdWxkQHZlcmlzaWduLmNvbTwvYT48YnI+DQo8YnI+DQo3 MDMtOTQ4LTMyNzEgKE9mZmljZSk8YnI+DQoxMjA2MSBCbHVlbW9udCBXYXk8YnI+DQpSZXN0b24s IFZBIDIwMTkwPGJyPg0KVmVyaXNpZ25JbmMuY29tPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMy81LzEyIDY6MDQgQU0sICZxdW90O1BhdHJpayBGw6Rs dHN0csO2bSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdHJpa0Bmcm9iYml0LnNlIj5wYXRy aWtAZnJvYmJpdC5zZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPlRoaXMgb25lIGlzIHNwZWNpZmljYWxseSBpcnJpdGF0aW5nIGFzIGl0IHJlcXVpcmVz IGluIHdvcnN0IGNhc2UgbWFzc2l2ZTxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPmV4cGxhbmF0aW9ucywgZWR1Y2F0aW9uIGFuZCB3ZWIvUkVTVCBpbnRlcmZhY2Ug aW1wbGVtZW50YXRpb25zIHRoYXQgYXJlPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+ZGVwZW5kZW50IG9uIHRoZSBUTEQuIEkuZS4gc29tZXRoaW5nIGEgcmVnaXN0 cmFyIGNhbiBub3QgJnF1b3Q7aGlkZSZxdW90OyBmcm9tIHRoZTxicj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPnJlZ2lzdHJhbnQuPGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+SSBhbSBub3QgaGFwcHkgYWJvdXQgZGlmZmVyZW5jZXMgdGhhdCBjb3N0IHJl Z2lzdHJhcnMgaGFyZCB3b3JrIG9mPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+dmFyaW91cyBraW5kcy4gQnV0IEkgYW0gZGVmaW5pdGVseSBub3QgaGFwcHkgb2Yg dGhpbmdzIHRoYXQgY29zdDxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPnJlZ2lzdHJhbnQgdGhpbmdzLjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlNv LCBmb3IgdGhpcyBzcGVjaWZpYyBjYXNlLCBJIHdvdWxkIGxpa2UgdG8gc2VlIGEgTVVTVCBpbiBh dCBsZWFzdCB0aGUgRFM8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij5pbnRlcmZhY2UuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+Jm5ic3A7UGF0cmlr PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gNSBtYXIgMjAxMiwgYXQgMTE6NTks IE1pY2hlbGUgTmV5bG9uIDo6IEJsYWNrbmlnaHQgd3JvdGU6PGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5QYXRyaWs8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+V2VsY29tZSB0byBv dXIgd29ybGQgOik8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+V2Ugc2VlIGluY29uc2lzdGVuY2llcyBiZXR3ZWVuIHJlZ2lzdHJpZXMgYWxs IHRoZSB0aW1lIC0gaXQgbWFrZXM8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPmludGVncmF0 aW9uIHdpdGggbmV3IHJlZ2lzdHJ5IHByb3ZpZGVycyBwYWluZnVsIGFuZCBhcyBhIHJlc3VsdCB3 ZSB0ZW5kPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj50byBmb2N1cyBvbiB0aGUgb25lcyB3 aG9zZSBxdWlya3Mgd2UndmUgYWxyZWFkeSBkZWFsdCB3aXRoPGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlJlZ2FyZHM8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+TWljaGVsZTxicj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIDUgTWFyIDIwMTIsIGF0IDEwOjQzLCBQYXRyaWsg RsOkbHRzdHLDtm0gd3JvdGU6PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+QWNjb3JkaW5nIHRv IFJGQyA1OTEwLCBzZWN0aW9uIDQsIHRoZXJlIGFyZSB0d28gYWx0ZXJuYXRpdmUgaW50ZXJmYWNl czxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5mb3IgbWFuYWdpbmcgRE5TU0VDIGtleSBkYXRhIHdoZW4gaW50ZXJmYWNp bmcgd2l0aCBhIHJlZ2lzdHJ5LiBUaGUgUkZDPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPmRvZXMgbm90IGV4cGxpY2l0 bHkgc2F5IHdoZXRoZXIgYSByZWdpc3RyeSBtdXN0IGltcGxlbWVudCBvbmUgb3IgdGhlPGJyPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPm90aGVyLjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SSBoYXZlIHN1Y2Nlc3NmdWxs eSBpbXBsZW1lbnRlZCBpbiBhIHdlYiBpbnRlcmZhY2UsIGFuIEFQSSBmb3I8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ cmVnaXN0cmFudHMgZXRjLCB0aGUgRFMgaW50ZXJmYWNlIGFzIHRoZSBjbGllbnQgZG8gYmVsaWV2 ZSBwYXNzaW5nIERTPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPmRhdGEgaXMgdGhlIGVhc2llc3QuIEFmdGVyIGFsbCB0 aGF0IGlzIHdoYXQgaXMgdG8gYmUgc2lnbmVkIGJ5IHRoZTxicj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5wYXJlbnQuPGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JIGp1c3QgZW5jb3VudGVyZWQgYSByZWdpc3RyeSB0aGF0 ICZxdW90O3dhbnQgdG8gc2V0IGEgbGltaXQgb24gd2hhdCBkaWdlc3Q8YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+YWxn b3JpdGhtcyB0byB1c2UmcXVvdDsgYW5kIHRvIGRvIHRoYXQsIHRoZXkgaGF2ZSBkZWNpZGVkIHRv IG5vdCBpbXBsZW1lbnQ8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+dGhlIERTIGludGVyZmFjZSBhbmQgb25seSBzdXBw b3J0IHRoZSBLRVkgaW50ZXJmYWNlLjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SSBjYW4gYWNj ZXB0IGxpbWl0YXRpb25zIG9uIHdoYXQgZGlnZXN0IGFsZ29yaXRobXMgdGhleSBhY2NlcHQsIGJ1 dDxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5ub3QgbGltaXRhdGlvbnMgYnkgbm90IHN1cHBvcnRpbmcgRFMuPGJyPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj5SZWFjdGlvbnM/PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5Q YXRyaWs8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPnByb3ZyZWcgbWFpbGluZyBsaXN0PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxhIGhyZWY9Im1haWx0bzpwcm92cmVnQGlldGYub3JnIj5wcm92cmVnQGlldGYu b3JnPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Byb3ZyZWciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHJvdnJlZzwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxi cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+TXIgTWljaGVsZSBOZXlsb248YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPkJsYWNrbmlnaHQgU29sdXRpb25zIOKZnjxicj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+SG9zdGluZyAmYW1wOyBDb2xvY2F0aW9uLCBCcmFuZCBQcm90ZWN0aW9uPGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JQ0FOTiBBY2NyZWRpdGVkIFJlZ2lzdHJhcjxicj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGEgaHJlZj0iaHR0cDovL3d3dy5ibGFja25pZ2h0LmNv bS8iPmh0dHA6Ly93d3cuYmxhY2tuaWdodC5jb20vPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGEgaHJlZj0iaHR0cDovL2Jsb2cuYmxhY2tuaWdodC5jb20vIj5odHRwOi8vYmxvZy5i bGFja25pZ2h0LmNvbS88L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YSBocmVmPSJo dHRwOi8vYmxhY2tuaWdodC5iaXoiPmh0dHA6Ly9ibGFja25pZ2h0LmJpejwvYT48YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxhIGhyZWY9Imh0dHA6Ly9tbmV5bG9uLnRlbCI+aHR0cDovL21u ZXlsb24udGVsPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SW50bC4gJiM0MzszNTMg KDApIDU5ICZuYnNwOzkxODMwNzI8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlVTOiAyMTMt MjMzLTE2MTI8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkxvY2FsbDogMTg1MCA5MjkgOTI5 PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5EaXJlY3QgRGlhbDogJiM0MzszNTMgKDApNTkg OTE4MzA5MDxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+RmFjZWJvb2s6IDxhIGhyZWY9Imh0 dHA6Ly9mYi5tZS9ibGFja25pZ2h0Ij5odHRwOi8vZmIubWUvYmxhY2tuaWdodDwvYT48YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPlR3aXR0ZXI6IDxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNv bS9tbmV5bG9uIj5odHRwOi8vdHdpdHRlci5jb20vbW5leWxvbjwvYT48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPkJsYWNrbmlnaHQgSW50ZXJuZXQgU29sdXRpb25zIEx0ZCwgVW5pdCAx MkEsQmFycm93c2lkZSBCdXNpbmVzczxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+UGFyayxT bGVhdHk8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlJvYWQsR3JhaWd1ZWN1bGxlbixDYXJs b3csSXJlbGFuZCAmbmJzcDtDb21wYW55IE5vLjogMzcwODQ1PGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5w cm92cmVnIG1haWxpbmcgbGlzdDxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGEgaHJlZj0i bWFpbHRvOnByb3ZyZWdAaWV0Zi5vcmciPnByb3ZyZWdAaWV0Zi5vcmc8L2E+PGJyPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Byb3ZyZWciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJv dnJlZzwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPnByb3ZyZWcgbWFpbGluZyBsaXN0PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGEgaHJlZj0ibWFpbHRv OnByb3ZyZWdAaWV0Zi5vcmciPnByb3ZyZWdAaWV0Zi5vcmc8L2E+PGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wcm92cmVnIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Byb3ZyZWc8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwcm92cmVnIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpwcm92cmVnQGlldGYub3JnIj5wcm92cmVnQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcHJvdnJlZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcm92cmVn PC9hPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGFwcGxl LWNvbnRlbnQtZWRpdGVkPSJ0cnVlIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5 bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IC13ZWJraXQtYXV0bzsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3Bh Y2luZzogMHB4OyAtd2Via2l0LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LXNpemU6IG1lZGl1 bTsgIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBz ZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IDI7IHRleHQtYWxpZ246IC13ZWJraXQtYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0 LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1p bi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LXNpemU6IG1lZGl1bTsgIj4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj48YnIgY2xhc3M9IkFwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5NSUNIQUVMIFlPVU5HPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzptaWNoYWVsQG13 eW91bmcuY2EiPm1pY2hhZWxAbXd5b3VuZy5jYTwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PC9zcGFuPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CB7A2CE219783jgouldverisigncom_-- --_004_CB7A2CE219783jgouldverisigncom_ Content-Type: image/png; name="86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[22].png" Content-Description: 86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[22].png Content-Disposition: inline; filename="86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[22].png"; size=4109; creation-date="Mon, 05 Mar 2012 13:49:44 GMT"; modification-date="Mon, 05 Mar 2012 13:49:44 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CB7A2CE219783jgouldverisigncom_-- From paf@frobbit.se Mon Mar 5 05:52:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B546221F8736 for ; Mon, 5 Mar 2012 05:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPdBbJLDkRLA for ; Mon, 5 Mar 2012 05:51:49 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 5439E21F871D for ; Mon, 5 Mar 2012 05:51:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 1DFC9133B60C1; Mon, 5 Mar 2012 14:51:48 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuzYac92Q8xD; Mon, 5 Mar 2012 14:51:47 +0100 (CET) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id CC4D9133B60B7; Mon, 5 Mar 2012 14:51:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_F431EBC1-5FD8-4383-8E6C-D733FDB748CF"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120305134455.GA76465@mail.yitter.info> Date: Mon, 5 Mar 2012 14:51:46 +0100 Message-Id: <5B7ABF53-5070-4949-A665-93B4192DBEC2@frobbit.se> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:52:02 -0000 --Apple-Mail=_F431EBC1-5FD8-4383-8E6C-D733FDB748CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 mar 2012, at 14:45, Andrew Sullivan wrote: > even though the client might believe that passing the DS data is the > easiest, the registry might want the DNSKEY data. The reason to > prefer the DNSKEY data is because the DS is authoritative _only at the > parent_. In principle, then, it is a mistake to accept any old DS > data from the child side of the zone cut and publish it as > authoritative data: the registry can't be sure it has that right. > Therefore, it either should accept DS data with a DNSKEY that it can > validate the DS with, or else it should just accept the DNSKEY data > and generate the DS itself. Who is responsible for doing the validation? The registry or the = registrar? That is what you say, right? And sure, the view on that differs. > I find the complaints about inconsistencies across registries to be a > little odd: the whole point of EPP is supposed to be its > extensibility, and that will necessarily mean inconsistencies. I'd be > more interested in arguments about why it is so difficult to find and > use the extensions. It always seemed to me that the client libraries > were the problem: they don't have a good plugin architecture, which > should make the use of extensions easy. =20 The problem here is that a registrant must give different data to the = same registrar depending on the TLD. That is different from having the = same registrar implement the same thing differently two two different = registrars (so that the registrant can do for example transfer or renew = the same way when talking with the same registrar regardless of = registry). That is creating problems and it does not matter what the registrar does = to resolve this. My point is that I clearly see that the chance that the same registrar = will implement both DS and KEY interface to TLDs is extremely small. = Simply because the interaction with the registrant is too complicated. = Instead, I think we will see registrars supporting either DS or KEY, and = because of that support for DNSSEC will differ depending on support at = registry. And as (as you say) most registries support DS, I see a risk registries = that do not support DS will not get as many registrars support DNSSEC = operations with them. I.e. a non-harmonization that I think is of a much different kind than = what we otherwise talk about on this list. Patrik --Apple-Mail=_F431EBC1-5FD8-4383-8E6C-D733FDB748CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iD8DBQFPVMTyrMabGguI180RAtfAAJ9pNsJYKWYzln2eyhCrvDRoX6KhkACfYp/k YQuDrKKNTm9p7fpqQgZrqJQ= =OUeP -----END PGP SIGNATURE----- --Apple-Mail=_F431EBC1-5FD8-4383-8E6C-D733FDB748CF-- From patrik@frobbit.se Mon Mar 5 05:52:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1468021F8739 for ; Mon, 5 Mar 2012 05:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XooSx0fVhu7 for ; Mon, 5 Mar 2012 05:52:16 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57421F872E for ; Mon, 5 Mar 2012 05:52:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id C913D133B610F; Mon, 5 Mar 2012 14:52:15 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irwqY6ijrVKy; Mon, 5 Mar 2012 14:52:15 +0100 (CET) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 8ACE3133B6103; Mon, 5 Mar 2012 14:52:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_3AF4082B-5E96-4B0F-B725-1F433307FA01"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 5 Mar 2012 14:52:15 +0100 Message-Id: <5200A65C-6C6D-4B33-AAC7-6F94438565A2@frobbit.se> References: To: "Gould, James" X-Mailer: Apple Mail (2.1257) Cc: "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:52:17 -0000 --Apple-Mail=_3AF4082B-5E96-4B0F-B725-1F433307FA01 Content-Type: multipart/alternative; boundary="Apple-Mail=_45DC27F6-4135-40AF-B5CC-BC4545124063" --Apple-Mail=_45DC27F6-4135-40AF-B5CC-BC4545124063 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 mar 2012, at 14:49, Gould, James wrote: > I'm not voting but simply covering how the two interfaces made it into = the RFC. I can see the basis for both interfaces, but I certainty don't = believe that a mix in a single registry is workable. =20 >=20 Similarly, I do not see a mix in a single registrar is workable. paf --Apple-Mail=_45DC27F6-4135-40AF-B5CC-BC4545124063 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I'm not voting but simply covering how the two = interfaces made it into the RFC.  I can see the basis for both = interfaces, but I certainty don't believe that a mix in a single = registry is workable.  


Similarly,= I do not see a mix in a single registrar is = workable.

  =  paf

= --Apple-Mail=_45DC27F6-4135-40AF-B5CC-BC4545124063-- --Apple-Mail=_3AF4082B-5E96-4B0F-B725-1F433307FA01 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iD8DBQFPVMUPrMabGguI180RAiAdAJ0etq31LlhgJ9UktljUWBqIn+2c4QCbBWAv jr9+ketWfD4rgTO7Yxjxgls= =N14i -----END PGP SIGNATURE----- --Apple-Mail=_3AF4082B-5E96-4B0F-B725-1F433307FA01-- From michele@blacknight.ie Mon Mar 5 05:53:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B6521F8731 for ; Mon, 5 Mar 2012 05:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlIsjBRXYEpm for ; Mon, 5 Mar 2012 05:53:47 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE6C21F8730 for ; Mon, 5 Mar 2012 05:53:47 -0800 (PST) Received: from bkexchmbx02.blacknight.local ([fe80::d4d7:819a:4fb5:c923]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 13:53:46 +0000 From: "Michele Neylon :: Blacknight" To: MICHAEL YOUNG Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: AQHM+r00tHy4v05x7kyzT+4+6EfUaZZbiKmAgAABYgCAACYugIAABOQAgAAD2IA= Date: Mon, 5 Mar 2012 13:53:45 +0000 Message-ID: References: <4A48A5DC-683E-4B9E-9485-EB22A1301895@mwyoung.ca> In-Reply-To: <4A48A5DC-683E-4B9E-9485-EB22A1301895@mwyoung.ca> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <9ABD5CD4D053D745B0DB8E13FDC82514@blacknight.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:53:48 -0000 DQpPbiA1IE1hciAyMDEyLCBhdCAxMzozOCwgTUlDSEFFTCBZT1VORyB3cm90ZToNCg0KPiBKYW1l cywgSSdtIG5vdCBzdXJlIGZyb20gd2hhdCB5b3UndmUgd3JpdHRlbiBoZXJlLCB3aGF0IHlvdXIg dm90ZSBpcywgSSB0aGluayBpdCdzIGZvciB0aGUgZHMgZGF0YSBpbnRlcmZhY2U/DQo+IA0KPiBJ J20gZm9yIHRoZSAidGhpbiIgbW9kZWwgYW5kIGFncmVlIGl0IHNob3VsZCBiZSBhIG11c3QuIA0K PiANCj4gQlRXLCBpbiBhbGwgZmFpcm5lc3MsIHdlIGFsbCBtaXNzIHRoZSBvcHBvcnR1bml0eSB0 byByYWlzZSBpc3N1ZXMgb24gdGhlc2UgbGlzdHMgLSBpdCdzIHRvdWdoIHRvIHN0YXkgb24gdG9w IG9mIHRoZSBkaXNjdXNzaW9uIGZsb3cgd2hlbiB5b3UgaGF2ZSBhIGRheSBqb2IgYXMgd2VsbC4N Cg0KKzENCg0KDQpNciBNaWNoZWxlIE5leWxvbg0KQmxhY2tuaWdodCBTb2x1dGlvbnMg4pmeDQpI b3N0aW5nICYgQ29sb2NhdGlvbiwgQnJhbmQgUHJvdGVjdGlvbg0KSUNBTk4gQWNjcmVkaXRlZCBS ZWdpc3RyYXINCmh0dHA6Ly93d3cuYmxhY2tuaWdodC5jb20vDQpodHRwOi8vYmxvZy5ibGFja25p Z2h0LmNvbS8NCmh0dHA6Ly9ibGFja25pZ2h0LmJpeg0KaHR0cDovL21uZXlsb24udGVsDQpJbnRs LiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KVVM6IDIxMy0yMzMtMTYxMiANCkxvY2FsbDogMTg1MCA5 MjkgOTI5DQpEaXJlY3QgRGlhbDogKzM1MyAoMCk1OSA5MTgzMDkwDQpGYWNlYm9vazogaHR0cDov L2ZiLm1lL2JsYWNrbmlnaHQNClR3aXR0ZXI6IGh0dHA6Ly90d2l0dGVyLmNvbS9tbmV5bG9uDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCbGFja25pZ2h0IEludGVybmV0IFNvbHV0 aW9ucyBMdGQsIFVuaXQgMTJBLEJhcnJvd3NpZGUgQnVzaW5lc3MgUGFyayxTbGVhdHkNClJvYWQs R3JhaWd1ZWN1bGxlbixDYXJsb3csSXJlbGFuZCAgQ29tcGFueSBOby46IDM3MDg0NQ0KDQo= From peter@denic.de Mon Mar 5 05:54:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C6821F8559 for ; Mon, 5 Mar 2012 05:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OFpuK8XnwYR for ; Mon, 5 Mar 2012 05:54:35 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id DA35821F8736 for ; Mon, 5 Mar 2012 05:54:31 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S4YMw-0006BA-Qe; Mon, 05 Mar 2012 14:54:30 +0100 Received: from localhost by x27.adm.denic.de with local id 1S4YMw-0003dP-NB; Mon, 05 Mar 2012 14:54:30 +0100 Date: Mon, 5 Mar 2012 14:54:30 +0100 From: Peter Koch To: provreg@ietf.org Message-ID: <20120305135430.GH22296@x27.adm.denic.de> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305115000.GF22296@x27.adm.denic.de> <75397F81-613C-4807-BAEA-276D489EBA22@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75397F81-613C-4807-BAEA-276D489EBA22@frobbit.se> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:54:36 -0000 On Mon, Mar 05, 2012 at 02:02:19PM +0100, Patrik Fältström wrote: > ...and as you understand I think that the fact that there seems to be an ability for registries to choose in their epp interface is extremely bad for the registrant. quite frankly, I don't. Since the registry is free(*) to decide to support DNSSEC (or not) in the first place, there's probably other things to worry about. > I.e. why should a registrant have to send _different_ information to the registrar for example.A and example.B? Because that's already the fact regardless of DNSSEC? And if as a registrar you'd like to be of help, just accept the key and compute the DS. Or ask both the DS and the DNSKEY from the registrant (or their DNS operator). > I want to admit that when I read the RFC in question, I read it as if both interfaces should exist. Not that a registry could say no to one. So I personally missed this during last call. The provisioning protocol should implement policy, not dictate it. Otherwise you'd really end up with incompatible extensions. -Peter (*) Within the boundaries of the applicable policy process. From paf@frobbit.se Mon Mar 5 05:59:04 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF76D21F8746 for ; Mon, 5 Mar 2012 05:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9yD+C+-wuBK for ; Mon, 5 Mar 2012 05:59:04 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAAA21F8736 for ; Mon, 5 Mar 2012 05:59:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id A6B6D133B657F; Mon, 5 Mar 2012 14:59:03 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voM4K-TleCNe; Mon, 5 Mar 2012 14:59:03 +0100 (CET) Received: from dyn-fg104.sth.netnod.se (dyn-fg104.sth.netnod.se [77.72.226.104]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 65DA2133B6575; Mon, 5 Mar 2012 14:59:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_7BAF64A3-FDC1-461C-9727-6C58CC8EE42E"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120305135430.GH22296@x27.adm.denic.de> Date: Mon, 5 Mar 2012 14:59:02 +0100 Message-Id: <81F33B90-6C79-4D31-8B4F-63624D8E012E@frobbit.se> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305115000.GF22296@x27.adm.denic.de> <75397F81-613C-4807-BAEA-276D489EBA22@frobbit.se> <20120305135430.GH22296@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:59:05 -0000 --Apple-Mail=_7BAF64A3-FDC1-461C-9727-6C58CC8EE42E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 5 mar 2012, at 14:54, Peter Koch wrote: > The provisioning protocol should implement policy, not dictate it. > Otherwise you'd really end up with incompatible extensions. Absolutely! There is always a balance between freedom in protocol specifications and = interoperability... Patrik --Apple-Mail=_7BAF64A3-FDC1-461C-9727-6C58CC8EE42E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iD8DBQFPVMamrMabGguI180RAhzAAJ0ZVBImXlRpZ1JhHYF52nnq4d7c5ACdFYvN mYvV2ujR61s2nkedGz6XhZA= =dO7S -----END PGP SIGNATURE----- --Apple-Mail=_7BAF64A3-FDC1-461C-9727-6C58CC8EE42E-- From Klaus.Malorny@knipp.de Mon Mar 5 06:00:22 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C3421F8551 for ; Mon, 5 Mar 2012 06:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VonDWPFspOZK for ; Mon, 5 Mar 2012 06:00:21 -0800 (PST) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id A0FC421F8539 for ; Mon, 5 Mar 2012 06:00:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id B68F445; Mon, 5 Mar 2012 15:00:19 +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 xv-595XKP9aV; Mon, 5 Mar 2012 15:00:14 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id BBA3B67; Mon, 5 Mar 2012 15:00: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 q25DrbnS026835; Mon, 5 Mar 2012 14:53:37 +0100 (MEZ) Message-ID: <4F54C561.8010405@knipp.de> Date: Mon, 05 Mar 2012 14:53:37 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120304 Thunderbird/13.0a1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305115000.GF22296@x27.adm.denic.de> <75397F81-613C-4807-BAEA-276D489EBA22@frobbit.se> In-Reply-To: <75397F81-613C-4807-BAEA-276D489EBA22@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Peter Koch , provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:00:22 -0000 On 05/03/12 14:02, Patrik F=E4ltstr=F6m wrote: > On 5 mar 2012, at 12:50, Peter Koch wrote: > >>> I just encountered a registry that "want to set a limit on what diges= t >>> algorithms to use" and to do that, they have decided to not implement= the >>> DS interface and only support the KEY interface. >> >> Some registries have decided to operate on DNSKEY rather than DS. It >> appears reasonable to me to reflect this in the provisioning protocol.= This >> is exactly not an EPP inconsistency, because EPP is policy neutral her= e and >> can thus well be used for either way. > > ...and as you understand I think that the fact that there seems to be a= n > ability for registries to choose in their epp interface is extremely ba= d for > the registrant. > > I.e. why should a registrant have to send _different_ information to th= e > registrar for example.A and example.B? > > Where "example" is the same for both TLDs. > > In one case DS, in another case KEY? > > I want to admit that when I read the RFC in question, I read it as if b= oth > interfaces should exist. Not that a registry could say no to one. So I > personally missed this during last call. > > Patrik > > There are surely good reasons for each choice: for example, requiring DS = data=20 saves the registry from the duty of calculating the DS data with the=20 responsibility for errors in this calculation. On the other hand, using D= NSKEY=20 data makes it easier for the registry to deal with IDN variants -- if the= y are=20 not published via DNAMEs (or similar future xNAME) but via duplicated NS = records, the submission of a single DNSKEY data record is sufficient for = both=20 the main domain and the variants (with the consequence that all zones nee= d to be=20 signed with the same key, of course). I myself am a bit undetermined what I shall regard as the better solution= , but I=20 tend towards the second one. My original preference however was to allow = both on=20 a per-domain base, although RFC 5910 does not recommend this. Regards, Klaus From Klaus.Malorny@knipp.de Mon Mar 5 06:29:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26A221F8513 for ; Mon, 5 Mar 2012 06:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6dRkmuyEpv9 for ; Mon, 5 Mar 2012 06:29:35 -0800 (PST) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id C917D21F8512 for ; Mon, 5 Mar 2012 06:29:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id E65AA4C; Mon, 5 Mar 2012 15:29:32 +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 k7FB2P5Vz8Sd; Mon, 5 Mar 2012 15:29:24 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 5AF294B; Mon, 5 Mar 2012 15:29:24 +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 q25ETNNW004193; Mon, 5 Mar 2012 15:29:24 +0100 (MEZ) Message-ID: <4F54CDC3.1070509@knipp.de> Date: Mon, 05 Mar 2012 15:29:23 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120305 Thunderbird/13.0a1 MIME-Version: 1.0 To: "Gould, James" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr?= =?ISO-8859-1?Q?=F6m?= , "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:29:35 -0000 On 05/03/12 14:49, Gould, James wrote: > Michael, > > I'm not voting but simply covering how the two interfaces made it into the RFC. > I can see the basis for both interfaces, but I certainty don't believe that a > mix in a single registry is workable. > Why? The only problematic situation is the transfer of a domain. But the DNSSEC related data is not deleted during the transfer, so it stays as long as the new registrar desires. And if the registrar wants to update the DNSSEC data, he can specify to delete all previous data (be it DS or DNSKEY) and replace it with his preferable representation. Generally, I think the topic is overestimated -- I think it is more critical that the various registries allow different sets of algorithms for the DNSKEY and I cannot choose the same algorithm for all my domains. Klaus From michael@mwyoung.ca Mon Mar 5 06:34:28 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2921F8729 for ; Mon, 5 Mar 2012 06:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvHX1GEjt7Xz for ; Mon, 5 Mar 2012 06:34:27 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B863E21F8725 for ; Mon, 5 Mar 2012 06:34:26 -0800 (PST) Received: by ghbg16 with SMTP id g16so1836572ghb.31 for ; Mon, 05 Mar 2012 06:34:26 -0800 (PST) Received-SPF: pass (google.com: domain of michael@mwyoung.ca designates 10.50.106.200 as permitted sender) client-ip=10.50.106.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of michael@mwyoung.ca designates 10.50.106.200 as permitted sender) smtp.mail=michael@mwyoung.ca Received: from mr.google.com ([10.50.106.200]) by 10.50.106.200 with SMTP id gw8mr7148814igb.10.1330958066067 (num_hops = 1); Mon, 05 Mar 2012 06:34:26 -0800 (PST) Received: by 10.50.106.200 with SMTP id gw8mr5914221igb.10.1330958065969; Mon, 05 Mar 2012 06:34:25 -0800 (PST) Received: from [10.244.70.34] (static-67-226-172-181.ptr.terago.net. [67.226.172.181]) by mx.google.com with ESMTPS id eo1sm7907632igc.17.2012.03.05.06.34.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 06:34:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_7C831EC4-3432-43B4-9923-8D9CDD853E5B" From: MICHAEL YOUNG In-Reply-To: Date: Mon, 5 Mar 2012 09:34:17 -0500 Message-Id: <98C8BD1A-3EA8-4DEF-B424-F513FEF4A1AB@mwyoung.ca> References: To: "Gould, James" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQku+BI7qG+GoO/23FfZZBzOcxSUX76/2SQ4a53DML30VwjtJrpBGDAq8s7g/pHo2IbW/6UW Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:34:28 -0000 --Apple-Mail=_7C831EC4-3432-43B4-9923-8D9CDD853E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry I was being quip, I didn't literally mean "vote" :-) I agree with you, a mix is not adding true value to the solution. -M On 2012-03-05, at 8:49 AM, Gould, James wrote: > Michael, >=20 > I'm not voting but simply covering how the two interfaces made it into = the RFC. I can see the basis for both interfaces, but I certainty don't = believe that a mix in a single registry is workable. =20 >=20 > -- > =20 > JG > =20 > <86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[22].png> > =20 > James Gould > Principal Software Engineer > jgould@verisign.com > =20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 >=20 >=20 > From: MICHAEL YOUNG > Date: Mon, 5 Mar 2012 08:38:50 -0500 > To: James Gould > Cc: Patrik F=C3=A4ltstr=C3=B6m , "Michele Neylon :: = Blacknight" , "" = > Subject: Re: [provreg] Example of stupid inconsistencies between = registries >=20 > James, I'm not sure from what you've written here, what your vote is, = I think it's for the ds data interface? >=20 > I'm for the "thin" model and agree it should be a must.=20 >=20 > BTW, in all fairness, we all miss the opportunity to raise issues on = these lists - it's tough to stay on top of the discussion flow when you = have a day job as well. >=20 >=20 > -Michael >=20 >=20 > On 2012-03-05, at 8:21 AM, Gould, James wrote: >=20 >> Patrik, >>=20 >> This was discussed on this list in late 2009. Ulrich Wisser brought = up on >> the list on October 28, 2009 "that .SE and other registries = considered to >> become a "fat" registry and take in the public keys instead of the ds >> records". Support for a "thin" DNSSEC registry as a MUST with the = option >> for a "fat" registry was never discussed on the list. I believe that = a >> mix of "thin" and "fat" would make things more complex since the >> registrars would need to support both instead of one interface for = the >> registries that do support the "fat" model. Think about handling >> transfers between registrars where the gaining registrar supports = only the >> "thin" model and the losing registrar supports both "thin" and "fat". >> There was support on this list and no concerns raised in adding = support >> for the key data interface to the draft. You were active on the list >> while this was being discussed and never expressed any concerns in = support >> for the key data interface. What is in the RFC supports the models = of >> "thin" with the ds data interface and "fat" with the key data = interface >> with an either or option for the registries. The registries that I = work >> on support the "thin" model with the ds data interface. >>=20 >> -- >>=20 >> JG >>=20 >>=20 >>=20 >> James Gould >> Principal Software Engineer >> jgould@verisign.com >>=20 >> 703-948-3271 (Office) >> 12061 Bluemont Way >> Reston, VA 20190 >> VerisignInc.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/5/12 6:04 AM, "Patrik F=C3=A4ltstr=C3=B6m" = wrote: >>=20 >>> This one is specifically irritating as it requires in worst case = massive >>> explanations, education and web/REST interface implementations that = are >>> dependent on the TLD. I.e. something a registrar can not "hide" from = the >>> registrant. >>>=20 >>> I am not happy about differences that cost registrars hard work of >>> various kinds. But I am definitely not happy of things that cost >>> registrant things. >>>=20 >>> So, for this specific case, I would like to see a MUST in at least = the DS >>> interface. >>>=20 >>> Patrik >>>=20 >>> On 5 mar 2012, at 11:59, Michele Neylon :: Blacknight wrote: >>>=20 >>>> Patrik >>>>=20 >>>> Welcome to our world :) >>>>=20 >>>> We see inconsistencies between registries all the time - it makes >>>> integration with new registry providers painful and as a result we = tend >>>> to focus on the ones whose quirks we've already dealt with >>>>=20 >>>> Regards >>>>=20 >>>> Michele >>>>=20 >>>>=20 >>>> On 5 Mar 2012, at 10:43, Patrik F=C3=A4ltstr=C3=B6m wrote: >>>>=20 >>>>> According to RFC 5910, section 4, there are two alternative = interfaces >>>>> for managing DNSSEC key data when interfacing with a registry. The = RFC >>>>> does not explicitly say whether a registry must implement one or = the >>>>> other. >>>>>=20 >>>>> I have successfully implemented in a web interface, an API for >>>>> registrants etc, the DS interface as the client do believe passing = DS >>>>> data is the easiest. After all that is what is to be signed by the >>>>> parent. >>>>>=20 >>>>> I just encountered a registry that "want to set a limit on what = digest >>>>> algorithms to use" and to do that, they have decided to not = implement >>>>> the DS interface and only support the KEY interface. >>>>>=20 >>>>> I can accept limitations on what digest algorithms they accept, = but >>>>> not limitations by not supporting DS. >>>>>=20 >>>>> Reactions? >>>>>=20 >>>>> Patrik >>>>>=20 >>>>> _______________________________________________ >>>>> provreg mailing list >>>>> provreg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/provreg >>>>=20 >>>> Mr Michele Neylon >>>> Blacknight Solutions =E2=99=9E >>>> Hosting & Colocation, Brand Protection >>>> ICANN Accredited Registrar >>>> http://www.blacknight.com/ >>>> http://blog.blacknight.com/ >>>> http://blacknight.biz >>>> http://mneylon.tel >>>> Intl. +353 (0) 59 9183072 >>>> US: 213-233-1612 >>>> Locall: 1850 929 929 >>>> Direct Dial: +353 (0)59 9183090 >>>> Facebook: http://fb.me/blacknight >>>> Twitter: http://twitter.com/mneylon >>>> ------------------------------- >>>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business >>>> Park,Sleaty >>>> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >>>>=20 >>>> _______________________________________________ >>>> provreg mailing list >>>> provreg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/provreg >>>=20 >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 >=20 >=20 > MICHAEL YOUNG > michael@mwyoung.ca >=20 >=20 >=20 >=20 MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_7C831EC4-3432-43B4-9923-8D9CDD853E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I agree with you, a mix is not adding true = value to the solution.

-M

On = 2012-03-05, at 8:49 AM, Gould, James wrote:

Michael,

I'm not voting but simply covering how the two interfaces made it = into the RFC.  I can see the basis for both interfaces, but I = certainty don't believe that a mix in a single registry is workable. =  

 
James = Gould
Principal Software = Engineer
jgould@verisign.com<= /span> 703-948-3271 = (Office)
12061 Bluemont = Way
Reston, VA = 20190



From: MICHAEL YOUNG <michael@mwyoung.ca>
Date: Mon, 5 Mar 2012 08:38:50 = -0500
To: James Gould <jgould@verisign.com>
Cc: Patrik F=C3=A4ltstr=C3=B6m = <patrik@frobbit.se>, = "Michele Neylon :: Blacknight" <michele@blacknight.ie>, = "<provreg@ietf.org>" <provreg@ietf.org>
Subject: Re: [provreg] Example = of stupid inconsistencies between registries

James, I'm not sure from what you've written here, what your vote = is, I think it's for the ds data interface?

I'm for the "thin" model and agree it should be a must. 

BTW, in all fairness, we all miss the opportunity to raise issues = on these lists - it's tough to stay on top of the discussion flow when = you have a day job as well.


-Michael


On 2012-03-05, at 8:21 AM, Gould, James wrote:

Patrik,

This was discussed on this list in late 2009.  Ulrich Wisser = brought up on
the list on October 28, 2009 "that .SE and other registries considered = to
become a "fat" registry and take in the public keys instead of the = ds
records".  Support for a "thin" DNSSEC registry as a MUST with the = option
for a "fat" registry was never discussed on the list.  I believe = that a
mix of "thin" and "fat" would make things more complex since the
registrars would need to support both instead of one interface for = the
registries that do support the "fat" model.  Think about = handling
transfers between registrars where the gaining registrar supports only = the
"thin" model and the losing registrar supports both "thin" and = "fat".
There was support on this list and no concerns raised in adding = support
for the key data interface to the draft.  You were active on the = list
while this was being discussed and never expressed any concerns in = support
for the key data interface.  What is in the RFC supports the models = of
"thin" with the ds data interface and "fat" with the key data = interface
with an either or option for the registries.  The registries that I = work
on support the "thin" model with the ds data interface.

--

JG



James Gould
Principal Software Engineer
jgould@verisign.com

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 3/5/12 6:04 AM, "Patrik F=C3=A4ltstr=C3=B6m" <patrik@frobbit.se> wrote:

This one is specifically irritating as it = requires in worst case massive
explanations, education and web/REST interface = implementations that are
dependent on the TLD. I.e. something a = registrar can not "hide" from the
registrant.

I am not happy about differences that cost = registrars hard work of
various kinds. But I am definitely not happy = of things that cost
registrant things.

So, for this specific case, I would like to = see a MUST in at least the DS
interface.

 Patrik

On 5 mar 2012, at 11:59, Michele Neylon :: = Blacknight wrote:

Patrik

Welcome to our world :)

We see inconsistencies between registries all = the time - it makes
integration with new registry providers = painful and as a result we tend
to focus on the ones whose quirks we've = already dealt with

Regards

Michele


On 5 Mar 2012, at 10:43, Patrik F=C3=A4ltstr=C3=B6= m wrote:

According to RFC 5910, section 4, there are = two alternative interfaces
for managing DNSSEC key data when interfacing = with a registry. The RFC
does not explicitly say whether a registry = must implement one or the
other.

I have successfully implemented in a web = interface, an API for
registrants etc, the DS interface as the = client do believe passing DS
data is the easiest. After all that is what is = to be signed by the
parent.

I just encountered a registry that "want to = set a limit on what digest
algorithms to use" and to do that, they have = decided to not implement
the DS interface and only support the KEY = interface.

I can accept limitations on what digest = algorithms they accept, but
not limitations by not supporting DS.

Reactions?

Patrik

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.or= g/mailman/listinfo/provreg

Mr Michele Neylon
Blacknight Solutions =E2=99=9E
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.biz
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Facebook: http://fb.me/blacknight
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit = 12A,Barrowside Business
Park,Sleaty
Road,Graiguecullen,Carlow,Ireland =  Company No.: 370845

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.or= g/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.or= g/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.or= g/mailman/listinfo/provreg




MICHAEL YOUNG




MICHAEL = YOUNG




= --Apple-Mail=_7C831EC4-3432-43B4-9923-8D9CDD853E5B-- From michael@mwyoung.ca Mon Mar 5 06:48:24 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2325521F8624 for ; Mon, 5 Mar 2012 06:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP6t72RD9UGM for ; Mon, 5 Mar 2012 06:48:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD4F21F866D for ; Mon, 5 Mar 2012 06:48:13 -0800 (PST) Received: by iazz13 with SMTP id z13so6625567iaz.31 for ; Mon, 05 Mar 2012 06:48:13 -0800 (PST) Received: by 10.50.140.106 with SMTP id rf10mr5775183igb.36.1330958893102; Mon, 05 Mar 2012 06:48:13 -0800 (PST) Received: from [10.244.70.34] (static-67-226-172-181.ptr.terago.net. [67.226.172.181]) by mx.google.com with ESMTPS id n8sm7936013igw.14.2012.03.05.06.48.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 06:48:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C95E257F-9A7D-4356-992B-928449F3935B" From: MICHAEL YOUNG In-Reply-To: <20120305134455.GA76465@mail.yitter.info> Date: Mon, 5 Mar 2012 09:48:04 -0500 Message-Id: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk9my9IU/wQy/tnfkzvuaxKBoLzvHy+KQT3cJl/r9RP3KymFzEjOVrb81kutzrLae2GbXVr Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:48:24 -0000 --Apple-Mail=_C95E257F-9A7D-4356-992B-928449F3935B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ok I see this argument but on the other hand I have to ask how much = responsibility does the registry want to take on? Some ccTLDs won't = even complete the registration process until the proposed child zone is = up and verification checks are run by the registry. I can see a logical = extension of that practice would be to verify the DS data. However, = lets face it, I can publish whatever I want to the registry and then = later on mess my zone up because I mis-manage something. =20 Besides, if the DS data is wrong, then DNSSEC validation is just going = to choke anyways right? Seems like its a self-regulating problem that = the registry doesn't need to try and solve. The fact that most of the = registries are going the DS route implies they aren't that interested = the job of verifying the data.=20 Michael On 2012-03-05, at 8:45 AM, Andrew Sullivan wrote: > On Mon, Mar 05, 2012 at 11:43:30AM +0100, Patrik F=E4ltstr=F6m wrote: >=20 >>=20 > even though the client might believe that passing the DS data is the > easiest, the registry might want the DNSKEY data. The reason to > prefer the DNSKEY data is because the DS is authoritative _only at the > parent_. In principle, then, it is a mistake to accept any old DS > data from the child side of the zone cut and publish it as > authoritative data: the registry can't be sure it has that right. > Therefore, it either should accept DS data with a DNSKEY that it can > validate the DS with, or else it should just accept the DNSKEY data > and generate the DS itself. >=20 >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_C95E257F-9A7D-4356-992B-928449F3935B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On = Mon, Mar 05, 2012 at 11:43:30AM +0100, Patrik F=E4ltstr=F6m = wrote:


even though the = client might believe that passing the DS data is the
easiest, the = registry might want the DNSKEY data.  The reason to
prefer the = DNSKEY data is because the DS is authoritative _only at the
parent_. =  In principle, then, it is a mistake to accept any old DS
data = from the child side of the zone cut and publish it as
authoritative = data: the registry can't be sure it has that right.
Therefore, it = either should accept DS data with a DNSKEY that it can
validate the = DS with, or else it should just accept the DNSKEY data
and generate = the DS itself.


Best,

A

--
Andrew = Sullivan
ajs@anvilwalrusden.com
_____= __________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg<= br>




MICHAEL = YOUNG




= --Apple-Mail=_C95E257F-9A7D-4356-992B-928449F3935B-- From JGould@verisign.com Mon Mar 5 06:55:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6E21F85C3 for ; Mon, 5 Mar 2012 06:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.467 X-Spam-Level: X-Spam-Status: No, score=-4.467 tagged_above=-999 required=5 tests=[AWL=-1.868, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZevcBroFEZYi for ; Mon, 5 Mar 2012 06:55:33 -0800 (PST) Received: from chip2og118.obsmtp.com (chip2og118.obsmtp.com [64.18.13.85]) by ietfa.amsl.com (Postfix) with ESMTP id C557F21F866D for ; Mon, 5 Mar 2012 06:55:31 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by chip2ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKT1TT4VW+9yDTNrZjf44bSrBunCx/3LZ7@postini.com; Mon, 05 Mar 2012 06:55:33 PST 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 q25EtMwj002806; Mon, 5 Mar 2012 09:55:25 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 09:55:22 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 09:55:22 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 09:55:22 -0500 From: "Gould, James" To: Klaus Malorny Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: AQHM+r0q7eo1z51rQ0WnxvppIby9dZZb3HqAgAABYgD//9JTgIAAWMAA//+vN4CAAF7pgP//s2iA Date: Mon, 5 Mar 2012 14:55:20 +0000 Message-ID: In-Reply-To: <4F54CDC3.1070509@knipp.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9E8320497067ED4D87F6AE9C66989CAD@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2012 14:55:22.0255 (UTC) FILETIME=[FD6111F0:01CCFADF] Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:55:35 -0000 Klaus, Yes, the gaining registrar could delete and reset the DS or Key Data after the transfer, but if the interface was consistent for the registry no update would be required of the DNSSEC data after transfer. Supporting a mix of server-generated DS with the Key Data Interface as well as client specified DS with the DS Data Interface across domain names or within domain names of a single registry will add undue complexity for the client and the server. I believe if there is support for "thin" (DS Data Interface) and "fat" (Key Data Interface) DNSSEC models in the protocol that a server should choose just one model / interface. Requiring the "thin" model in the protocol would result in registries that want to support the "fat" DNSSEC model to create custom extensions that would not be beneficial to anyone. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/5/12 9:29 AM, "Klaus Malorny" wrote: >On 05/03/12 14:49, Gould, James wrote: >> Michael, >> >> I'm not voting but simply covering how the two interfaces made it into >>the RFC. >> I can see the basis for both interfaces, but I certainty don't believe >>that a >> mix in a single registry is workable. >> > >Why? The only problematic situation is the transfer of a domain. But the >DNSSEC=20 >related data is not deleted during the transfer, so it stays as long as >the new=20 >registrar desires. And if the registrar wants to update the DNSSEC data, >he can=20 >specify to delete all previous data (be it DS or DNSKEY) and replace it >with his=20 >preferable representation. > >Generally, I think the topic is overestimated -- I think it is more >critical=20 >that the various registries allow different sets of algorithms for the >DNSKEY=20 >and I cannot choose the same algorithm for all my domains. > >Klaus > > > > From ajs@anvilwalrusden.com Mon Mar 5 07:04:57 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEDF21F8664 for ; Mon, 5 Mar 2012 07:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoFEKcuwURJd for ; Mon, 5 Mar 2012 07:04:56 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4F32A21F85CC for ; Mon, 5 Mar 2012 07:04:56 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9EB031ECB41D for ; Mon, 5 Mar 2012 15:04:55 +0000 (UTC) Date: Mon, 5 Mar 2012 10:05:04 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120305150504.GD76465@mail.yitter.info> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> <5B7ABF53-5070-4949-A665-93B4192DBEC2@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5B7ABF53-5070-4949-A665-93B4192DBEC2@frobbit.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:04:57 -0000 On Mon, Mar 05, 2012 at 02:51:46PM +0100, Patrik Fältström wrote: > > Who is responsible for doing the validation? The registry or the registrar? The registrar isn't publishing the authoritative zone, so it seems to me that the registry is the one on the hook here. Again, I want to emphasise the difference between DS and, say, NS. There is nothing in the history of the DNS that is remotely analogous to the DS record: nothing else is parent-side-only authoritative data. (One might lament that fact, but it's still the case). > The problem here is that a registrant must give different data to > the same registrar depending on the TLD. Your complaint seems to be that a registrant has to provide different data for different names. I fail completely to see why that is a problem. (To put this slightly differently, you seem to be arguing that a registrant shouldn't need to understand that example.com and example.org are different domains. This seems a little bit at odds with your views on the many things people call "variants".) > That is creating problems and it does not matter what the registrar does to resolve this. Well, one possibility, it seems, is for the registrar to accept a DS record for the name, look for the corresponding DNSKEY in the DNS, pull that out, and send it along. If the DNSKEY isn't there (see a note downthread about this) then you have a problem. But if the registrant is too badly informed to understand the difference between DNSKEY and DS, then I suspect s/he won't know how to prepublish DS either. > My point is that I clearly see that the chance that the same > registrar will implement both DS and KEY interface to TLDs is > extremely small. Simply because the interaction with the registrant > is too complicated. Instead, I think we will see registrars > supporting either DS or KEY, and because of that support for DNSSEC > will differ depending on support at registry. Surely this is the point of having a competitive market? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Mar 5 07:11:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E46C21F8789 for ; Mon, 5 Mar 2012 07:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qwn7FYzVO0W for ; Mon, 5 Mar 2012 07:11:00 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B254121F8786 for ; Mon, 5 Mar 2012 07:11:00 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ECA8A1ECB420 for ; Mon, 5 Mar 2012 15:10:59 +0000 (UTC) Date: Mon, 5 Mar 2012 10:11:08 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120305151108.GF76465@mail.yitter.info> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:11:01 -0000 On Mon, Mar 05, 2012 at 09:48:04AM -0500, MICHAEL YOUNG wrote: > Ok I see this argument but on the other hand I have to ask how much > responsibility does the registry want to take on? The registry took on the responsibility for authoritative data in its zone by virtue of accepting the delegation from its parent (usually the root). You might as well argue that the registry doesn't really have to keep its apex records well-maintained. > verify the DS data. However, lets face it, I can publish whatever I > want to the registry and then later on mess my zone up because I > mis-manage something. That's just irrelevant. The issue here is data that is authoritative _only_ in the parent-side zone. > Besides, if the DS data is wrong, then DNSSEC validation is just > going to choke anyways right? Could be, but you might not know it. One rollover mechanism is to pre-publish a DS record on the parent side of the zone cut before you publish the DNSKEY on the child side. You generate RRSIGs with the stand-by key as well, but never publish the new DNSKEY until the end; this way you always have a stand-by key in place, so that if your active key is compromised you just publish the new key and remove the old key. Your exposure in that case is only as long as the TTL on the DNSKEY record. A -- Andrew Sullivan ajs@anvilwalrusden.com From heland@afilias.info Mon Mar 5 07:30:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6521E21F877F for ; Mon, 5 Mar 2012 07:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbqbbrC1f7ns for ; Mon, 5 Mar 2012 07:30:48 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id BD57921F877B for ; Mon, 5 Mar 2012 07:30:48 -0800 (PST) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S4Zs8-00069x-6c for provreg@ietf.org; Mon, 05 Mar 2012 15:30:48 +0000 Received: from mail-gx0-f178.google.com ([209.85.161.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S4Zs7-0005Zb-67 for provreg@ietf.org; Mon, 05 Mar 2012 15:30:47 +0000 Received: by ggno1 with SMTP id o1so1644562ggn.9 for ; Mon, 05 Mar 2012 07:30:47 -0800 (PST) Received-SPF: pass (google.com: domain of heland@afilias.info designates 10.236.185.4 as permitted sender) client-ip=10.236.185.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of heland@afilias.info designates 10.236.185.4 as permitted sender) smtp.mail=heland@afilias.info Received: from mr.google.com ([10.236.185.4]) by 10.236.185.4 with SMTP id t4mr19811275yhm.129.1330961447432 (num_hops = 1); Mon, 05 Mar 2012 07:30:47 -0800 (PST) Received: by 10.236.185.4 with SMTP id t4mr15657106yhm.129.1330961447149; Mon, 05 Mar 2012 07:30:47 -0800 (PST) Received: from alamo.elandmeadery.info (cpe-72-177-97-55.austin.res.rr.com. [72.177.97.55]) by mx.google.com with ESMTPS id j22sm25031334ann.0.2012.03.05.07.30.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 07:30:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Howard Eland In-Reply-To: <20120305151108.GF76465@mail.yitter.info> Date: Mon, 5 Mar 2012 09:30:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <64F5B422-3E01-4F9C-A690-2663348A5FD2@afilias.info> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> <20120305151108.GF76465@mail.yitter.info> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmodch8FcRQgrT4m6NHMRI8cikQmMzc0xKA0nuurfs8kebyjqFzxbz02VmhzLTsXjKvmYMv Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:30:49 -0000 On Mar 5, 2012, at 9:11 AM, Andrew Sullivan wrote: > On Mon, Mar 05, 2012 at 09:48:04AM -0500, MICHAEL YOUNG wrote: >> Ok I see this argument but on the other hand I have to ask how much >> responsibility does the registry want to take on?=20 >=20 > The registry took on the responsibility for authoritative data in its > zone by virtue of accepting the delegation from its parent (usually > the root). You might as well argue that the registry doesn't really > have to keep its apex records well-maintained. Yes - when working on this RFC, we were torn between two different = realities: (1) that there were already many registries that either (1a) = want to take the "registrar is responsible for the data they send to the = registry" model, or (1b) are already working fine with accepting DS = data, and don't want to change; vs. (2) The DS record is a completely = different dragon, and (2a) the registry should generate any data for = which it is authoritative, or (2b) the registry wants to make sure that = it has some control over which algorithms are in use (i.e. registry X = does not want to see GOST, or registry Y wants to make sure they only = see GOST). Consensus was that both arguments (1) and (2) were valid, so the RFC was = worded to allow either. >=20 >> verify the DS data. However, lets face it, I can publish whatever I >> want to the registry and then later on mess my zone up because I >> mis-manage something. >=20 > That's just irrelevant. The issue here is data that is authoritative > _only_ in the parent-side zone. Right - see (1a) above. -Howard From benoit.levac@cira.ca Mon Mar 5 13:49:12 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564E221F87ED for ; Mon, 5 Mar 2012 13:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSx-7i4Xc1Ks for ; Mon, 5 Mar 2012 13:49:11 -0800 (PST) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C521F87E8 for ; Mon, 5 Mar 2012 13:49:11 -0800 (PST) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 8B639EFC6C for ; Mon, 5 Mar 2012 16:49:06 -0500 (EST) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id 6D7A3EFC6C for ; Mon, 5 Mar 2012 16:49:06 -0500 (EST) Received: from MBX01.cira1.cira.ca ([10.2.16.30]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Mon, 5 Mar 2012 16:49:42 -0500 From: Benoit Levac To: "provreg@ietf.org" Date: Mon, 5 Mar 2012 16:47:35 -0500 Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: Acz65PUziHWfZWS1SJy4jDEbHCs51gALheiA Message-ID: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> <20120305151108.GF76465@mail.yitter.info> <64F5B422-3E01-4F9C-A690-2663348A5FD2@afilias.info> In-Reply-To: <64F5B422-3E01-4F9C-A690-2663348A5FD2@afilias.info> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VAMS: NONE Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:49:12 -0000 My name is Benoit Levac and I'm the new development manager at CIRA (.ca). = This discussion is quite timely for us since we are just in the process of= specking our registry support for DNSSEC. =20 It sounds to me like the following arguments are being made for each of the= interfaces: DS Data Interface: more commonly used by major Registrars and Registries so= adoption is would probably be more favorable Key Data Interface: seems more technically correct - if the registry is aut= horitative for the DS record, it should make sure that it is correct before= publishing it to the zone (although it is understood that a change by the = dns operator could later render it invalid) For those registries that have taken the Key Data approach, have you found = that it has been a barrier for registrars to start publishing DNSSEC inform= ation for their domains? As well, does anyone have a list of use cases / scenarios used in the quali= ty assurance process for the registry implementation of DNS SEC in the regi= stry. Thank you. Ben=20 -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of Howard Eland Sent: March-05-12 10:31 AM To: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries On Mar 5, 2012, at 9:11 AM, Andrew Sullivan wrote: > On Mon, Mar 05, 2012 at 09:48:04AM -0500, MICHAEL YOUNG wrote: >> Ok I see this argument but on the other hand I have to ask how much=20 >> responsibility does the registry want to take on? >=20 > The registry took on the responsibility for authoritative data in its=20 > zone by virtue of accepting the delegation from its parent (usually=20 > the root). You might as well argue that the registry doesn't really=20 > have to keep its apex records well-maintained. Yes - when working on this RFC, we were torn between two different realitie= s: (1) that there were already many registries that either (1a) want to tak= e the "registrar is responsible for the data they send to the registry" mod= el, or (1b) are already working fine with accepting DS data, and don't want= to change; vs. (2) The DS record is a completely different dragon, and (2= a) the registry should generate any data for which it is authoritative, or = (2b) the registry wants to make sure that it has some control over which al= gorithms are in use (i.e. registry X does not want to see GOST, or registry= Y wants to make sure they only see GOST). Consensus was that both arguments (1) and (2) were valid, so the RFC was wo= rded to allow either. >=20 >> verify the DS data. However, lets face it, I can publish whatever I=20 >> want to the registry and then later on mess my zone up because I=20 >> mis-manage something. >=20 > That's just irrelevant. The issue here is data that is authoritative=20 > _only_ in the parent-side zone. Right - see (1a) above. -Howard _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From paf@frobbit.se Mon Mar 5 13:57:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3783321F87FC for ; Mon, 5 Mar 2012 13:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlC0nHWQxucY for ; Mon, 5 Mar 2012 13:57:47 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB0921F87C9 for ; Mon, 5 Mar 2012 13:57:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4E8DA133C29B4; Mon, 5 Mar 2012 22:57:45 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI7yNNVkVZ48; Mon, 5 Mar 2012 22:57:43 +0100 (CET) Received: from [10.0.1.8] (s83-180-234-193.cust.tele2.se [83.180.234.193]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 73034133C29A8; Mon, 5 Mar 2012 22:57:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_B7447347-C231-4C25-8669-0A1897EC53B1"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120305150504.GD76465@mail.yitter.info> Date: Mon, 5 Mar 2012 22:57:42 +0100 Message-Id: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> <5B7ABF53-5070-4949-A665-93B4192DBEC2@frobbit.se> <20120305150504.GD76465@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:57:48 -0000 --Apple-Mail=_B7447347-C231-4C25-8669-0A1897EC53B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 mar 2012, at 16:05, Andrew Sullivan wrote: > Your complaint seems to be that a registrant has to provide different > data for different names. I fail completely to see why that is a > problem. (To put this slightly differently, you seem to be arguing > that a registrant shouldn't need to understand that example.com and > example.org are different domains. This seems a little bit at odds > with your views on the many things people call "variants".) No, I am just talking about how to design for example a web interface = and instructions to the one that is to paste data into it. You have a = number of fields, and different fields are mandatory depending on what = TLD it is. Same with for example an API. If you run a DNS hosting, would it not be = easier if you can pass the same information to all registrars, and not = have to do different depending on which one it is? I am just talking about how much more difficult it is for everyone but = the registry if it asks for something else than the DS, and in many = cases it can also fetch the Key from the auth server if it want to = validate the DS... Part from some cases where one want DS pre-published = in the parent zone when the parent simply must trust whatever the = registrar send anyway as it can not validate the data passed to it. As = nothing is in the child zone that the data can be validated against. Patrik --Apple-Mail=_B7447347-C231-4C25-8669-0A1897EC53B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iD8DBQFPVTbWrMabGguI180RAiPtAJ9RHGqcqYkSm80DsA7SO9klvX2KVACdFYcB j4rbWEW7z//sUr0siid+tpw= =d24i -----END PGP SIGNATURE----- --Apple-Mail=_B7447347-C231-4C25-8669-0A1897EC53B1-- From james.mitchell@ausregistry.com.au Mon Mar 5 15:10:50 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE2A21F87E8 for ; Mon, 5 Mar 2012 15:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNVxai9y-Hk0 for ; Mon, 5 Mar 2012 15:10:45 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7352221F87E6 for ; Mon, 5 Mar 2012 15:10:42 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2012 10:10:31 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Tue, 6 Mar 2012 10:10:17 +1100 From: James Mitchell To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Andrew Sullivan Date: Tue, 6 Mar 2012 10:10:16 +1100 Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: Acz7GwAe6T8jgAR0TGWsjoWcVEp+mQACXW8g Message-ID: <8CEF048B9EC83748B1517DC64EA130FB6B2AE144CE@off-win2003-01.ausregistrygroup.local> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <20120305134455.GA76465@mail.yitter.info> <5B7ABF53-5070-4949-A665-93B4192DBEC2@frobbit.se> <20120305150504.GD76465@mail.yitter.info> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:10:50 -0000 You can solve your interface dilemma by always accepting key data and have = your provisioning system generate the DS data in the background for the reg= istries that require it :) Doing so also allows you to generate the DS usin= g the algorithms required by the registry. I don't believe that DS should be a must. As Klaus mentioned, server-side v= ariants mean that key data may be preferred. James > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Patrik F=E4ltstr=F6m > Sent: Tuesday, 6 March 2012 8:58 AM > To: Andrew Sullivan > Cc: provreg@ietf.org > Subject: Re: [provreg] Example of stupid inconsistencies between > registries >=20 >=20 > On 5 mar 2012, at 16:05, Andrew Sullivan wrote: >=20 > > Your complaint seems to be that a registrant has to provide different > > data for different names. I fail completely to see why that is a > > problem. (To put this slightly differently, you seem to be arguing > > that a registrant shouldn't need to understand that example.com and > > example.org are different domains. This seems a little bit at odds > > with your views on the many things people call "variants".) >=20 > No, I am just talking about how to design for example a web interface > and instructions to the one that is to paste data into it. You have a > number of fields, and different fields are mandatory depending on what > TLD it is. >=20 > Same with for example an API. If you run a DNS hosting, would it not be > easier if you can pass the same information to all registrars, and not > have to do different depending on which one it is? >=20 > I am just talking about how much more difficult it is for everyone but > the registry if it asks for something else than the DS, and in many > cases it can also fetch the Key from the auth server if it want to > validate the DS... Part from some cases where one want DS pre-published > in the parent zone when the parent simply must trust whatever the > registrar send anyway as it can not validate the data passed to it. As > nothing is in the child zone that the data can be validated against. >=20 > Patrik From aroberts@domicilium.com Wed Mar 7 07:42:24 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2F21E8082 for ; Wed, 7 Mar 2012 07:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGsxM6A37bDt for ; Wed, 7 Mar 2012 07:42:24 -0800 (PST) Received: from mail.domicilium.com (wormhole.domicilium.com [217.23.163.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7C021F8608 for ; Wed, 7 Mar 2012 07:42:23 -0800 (PST) Received: from LISA.internal.domicilium.com ([fe80::e8e2:5e30:5ac3:660c]) by LISA.internal.domicilium.com ([fe80::e8e2:5e30:5ac3:660c%10]) with mapi; Wed, 7 Mar 2012 15:42:22 +0000 From: Aaron Roberts To: "provreg@ietfa.amsl.com" Date: Wed, 7 Mar 2012 15:42:20 +0000 Thread-Topic: clTRID element clarification Thread-Index: Acz8eLORbTGZxkatRKGW4iL8IYZIBA== Message-ID: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:42:25 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On=20 > Behalf Of Aaron Roberts > Sent: 29 February 2012 15:24 > To: provreg@ietf.org > Subject: [provreg] clTRID element clarification >=20 > Hi all, > I'm looking to gauge domain registries' interpretation and use of the=20 > clTRID EPP command element in their EPP server implementations. >=20 > It seems that some registry EPP servers (namely .za and .im) use a=20 > kind of "cache/lookup" mechanism, based on the clTRID and (hopefully)=20 > scoped to individual registrars. Where a command is received from a=20 > registrar with a clTRID which has been previously used by the same=20 > registrar, the cached server response is returned to the client,=20 > instead of the command being executed a second time. The intention is=20 > to provide idempotency at the server level, when commands are issued mult= iple times. >=20 > My interpretation of the RFCs is that the clTRID is just a handy=20 > identifier for debugging etc.. managed by the client end and that EPP=20 > commands are designed to be idempotent by nature so can be safely=20 > executed multiple times without any considerations given to previous exec= utions. >=20 > I'd be very interested to know what everybody is doing in this regard? >=20 Thanks to everyone for your responses. The consensus from the responses that I received are that an EPP server sho= uld not be doing anything with the clTRID, (except returning it to the clie= nt in responses, as RFC5730 section 2.6 states). Does anybody feel that se= ction 2.5 of RFC5730 ("command format") should include some extra text to e= xplicitly prohibit servers from making assumptions about the clTRID element= (or something similar)? Thanks, Aaron From shollenbeck@verisign.com Wed Mar 7 09:08:27 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4A821E80E8 for ; Wed, 7 Mar 2012 09:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJMxYUt1lbPs for ; Wed, 7 Mar 2012 09:08:27 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 85D6121E80E7 for ; Wed, 7 Mar 2012 09:08:26 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT1eWCEL6vi1ZSjoX/FHrBrvFsi4VDpx3@postini.com; Wed, 07 Mar 2012 09:08:26 PST 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 q27H8NjF011263; Wed, 7 Mar 2012 12:08:23 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 12:08:23 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 12:08:23 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 7 Mar 2012 12:08:22 -0500 From: "Hollenbeck, Scott" To: Aaron Roberts , "provreg@ietfa.amsl.com" Thread-Topic: clTRID element clarification Thread-Index: Acz8eLORbTGZxkatRKGW4iL8IYZIBAACrDXg Date: Wed, 7 Mar 2012 17:08:22 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> In-Reply-To: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Mar 2012 17:08:23.0119 (UTC) FILETIME=[E72BC5F0:01CCFC84] Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:08:27 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Aaron Roberts > Sent: Wednesday, March 07, 2012 10:42 AM > To: provreg@ietfa.amsl.com > Subject: Re: [provreg] clTRID element clarification >=20 > The consensus from the responses that I received are that an EPP server > should not be doing anything with the clTRID, (except returning it to > the client in responses, as RFC5730 section 2.6 states). Does anybody > feel that section 2.5 of RFC5730 ("command format") should include some > extra text to explicitly prohibit servers from making assumptions about > the clTRID element (or something similar)? Given that RFC 5730 is part of Standard 69 there's not much chance of a nea= r-term amendment, but our process allows us to collect errata. I'm not conv= inced that there's anything here to correct, though. Section 2.5 currently = says this: "MAY be used to uniquely identify the command *to the client*" (emphasis mine), and "Clients are responsible for maintaining their own transaction identifier s= pace to ensure uniqueness." This doesn't seem ambiguous to me. Scott From lem@isc.org Wed Mar 7 09:11:38 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C61021F876C for ; Wed, 7 Mar 2012 09:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+dSQyjDQV6B for ; Wed, 7 Mar 2012 09:11:37 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 223D121F86DC for ; Wed, 7 Mar 2012 09:11:37 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0C6015F9865; Wed, 7 Mar 2012 17:11:24 +0000 (UTC) (envelope-from lem@isc.org) Received: from [192.168.0.129] (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A41FC216C36; Wed, 7 Mar 2012 17:11:21 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 7 Mar 2012 12:11:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <782F2B39-75FB-4532-BA6C-3CB222619436@isc.org> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1257) Cc: "provreg@ietfa.amsl.com" Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:11:38 -0000 On Mar 7, 2012, at 12:08 PM, Hollenbeck, Scott wrote: > "MAY be used to uniquely identify the command *to the client*" >=20 > (emphasis mine), and >=20 > "Clients are responsible for maintaining their own transaction = identifier space to ensure uniqueness." >=20 > This doesn't seem ambiguous to me. That language does not directly contradicts a server using it to provide = a cached response to a command with the same (command, clTRID, = arguments...) n-tuple, right? -lem= From aroberts@domicilium.com Wed Mar 7 09:32:41 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE04221E8017 for ; Wed, 7 Mar 2012 09:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpI3bSa-7Ytg for ; Wed, 7 Mar 2012 09:32:41 -0800 (PST) Received: from mail.domicilium.com (wormhole.domicilium.com [217.23.163.125]) by ietfa.amsl.com (Postfix) with ESMTP id 00ED021F8618 for ; Wed, 7 Mar 2012 09:32:40 -0800 (PST) Received: from LISA.internal.domicilium.com ([fe80::e8e2:5e30:5ac3:660c]) by LISA.internal.domicilium.com ([fe80::e8e2:5e30:5ac3:660c%10]) with mapi; Wed, 7 Mar 2012 17:32:38 +0000 From: Aaron Roberts To: =?iso-8859-1?Q?Luis_Mu=F1oz?= , "Hollenbeck, Scott" Date: Wed, 7 Mar 2012 17:32:37 +0000 Thread-Topic: [provreg] clTRID element clarification Thread-Index: Acz8hVwE5p3OVyFdT52dZWkKZLFOrAAACWUw Message-ID: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E68A@LISA.internal.domicilium.com> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <782F2B39-75FB-4532-BA6C-3CB222619436@isc.org> In-Reply-To: <782F2B39-75FB-4532-BA6C-3CB222619436@isc.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietfa.amsl.com" Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:32:41 -0000 > -----Original Message----- > From: Luis Mu=F1oz [mailto:lem@isc.org] > Sent: 07 March 2012 17:11 > To: Hollenbeck, Scott > Cc: Aaron Roberts; provreg@ietfa.amsl.com > Subject: Re: [provreg] clTRID element clarification >=20 >=20 > On Mar 7, 2012, at 12:08 PM, Hollenbeck, Scott wrote: >=20 > > "MAY be used to uniquely identify the command *to the client*" > > > > (emphasis mine), and > > > > "Clients are responsible for maintaining their own transaction identifi= er space > to ensure uniqueness." > > > > This doesn't seem ambiguous to me. >=20 > That language does not directly contradicts a server using it to provide = a > cached response to a command with the same (command, clTRID, > arguments...) n-tuple, right? >=20 It is pretty clear that the cached response server behaviour is miles outsi= de the definition of the clTRID. However, all the stuff which should not b= e done with the clTRID, at the server end, is only covered by the implicati= on of the statement that the clTRID "MAY be used to uniquely identify the c= ommand to the client". One of the other registries, in their responses, sa= id that they had seriously considered this sort of server behaviour, at poi= nts in their development. If registries are making the decision to impleme= nt this cached response behaviour (or even thinking about it), a statement = like "The server shouldn't make any assumptions about the clTRID" could sto= p the discussion, before it even started? Aaron From shollenbeck@verisign.com Wed Mar 7 10:07:42 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9699921F85F9 for ; Wed, 7 Mar 2012 10:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x6oAtQng2BG for ; Wed, 7 Mar 2012 10:07:42 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 817E121F8473 for ; Wed, 7 Mar 2012 10:07:37 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKT1ej5E5ZWa+QIcjHWorw8ergjSl0INnb@postini.com; Wed, 07 Mar 2012 10:07:40 PST 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 q27I7SQ2013270; Wed, 7 Mar 2012 13:07:32 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 13:07:28 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 7 Mar 2012 13:07:27 -0500 From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?Luis_Mu=F1oz?= Thread-Topic: [provreg] clTRID element clarification Thread-Index: Acz8eLORbTGZxkatRKGW4iL8IYZIBAACrDXgAAr1QgAACJhB8A== Date: Wed, 7 Mar 2012 18:07:27 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5BB754@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <782F2B39-75FB-4532-BA6C-3CB222619436@isc.org> In-Reply-To: <782F2B39-75FB-4532-BA6C-3CB222619436@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Mar 2012 18:07:28.0351 (UTC) FILETIME=[284B3EF0:01CCFC8D] Cc: "provreg@ietfa.amsl.com" Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:07:42 -0000 > -----Original Message----- > From: Luis Mu=F1oz [mailto:lem@isc.org] > Sent: Wednesday, March 07, 2012 12:11 PM > To: Hollenbeck, Scott > Cc: Aaron Roberts; provreg@ietfa.amsl.com > Subject: Re: [provreg] clTRID element clarification >=20 >=20 > On Mar 7, 2012, at 12:08 PM, Hollenbeck, Scott wrote: >=20 > > "MAY be used to uniquely identify the command *to the client*" > > > > (emphasis mine), and > > > > "Clients are responsible for maintaining their own transaction > identifier space to ensure uniqueness." > > > > This doesn't seem ambiguous to me. >=20 > That language does not directly contradicts a server using it to > provide a cached response to a command with the same (command, clTRID, > arguments...) n-tuple, right? No, it doesn't. It also doesn't include restrictions for any number of othe= r behaviors. It describes who owns the item and what may do with it. One sh= ouldn't assume that something is allowable unless it's expressly prohibited= . Scott From jay@nzrs.net.nz Wed Mar 7 17:28:20 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299C21E8025 for ; Wed, 7 Mar 2012 17:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTev0a0AceBi for ; Wed, 7 Mar 2012 17:28:19 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 88B8621E8011 for ; Wed, 7 Mar 2012 17:28:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 238CD2CE002; Thu, 8 Mar 2012 14:28:16 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr6a86JM1apt; Thu, 8 Mar 2012 14:28:16 +1300 (NZDT) Received: from [192.168.22.132] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A370A2DA2B5; Thu, 8 Mar 2012 14:28:15 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jay Daley In-Reply-To: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> Date: Thu, 8 Mar 2012 14:28:15 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:28:20 -0000 On 5/03/2012, at 11:43 PM, Patrik F=E4ltstr=F6m wrote: > [snipped] > Reactions? If we start with the recognition that some registries want thin DNSSEC = while others want thick and this difference is currently irreconcilable = then what we are really talking about is the balance between consistency = and choice in EPP and whether that's good now and will it get better = over time. Your complaint in essence is that in this case balance is = not good now as choice has won out over consistency. =20 I tend to agree with you that this is not good enough now because, in my = view, policy and protocol have been too tightly coupled.=20 To explain what I mean, here's a simple idea - could the protocol have = been designed to better minimise pain for registrars while maintaining = the choice for registries? For example, could the interface have = required registrars to provide both the DS records and the keys with = registries using whichever of the two they want? The implication of = doing so is that we get consistency of interface while individual = registries maintain choice on policy. Is a registrar more or less = likely to be confused by this than by two variants of the protocol? My = view is that they have to learn the policy difference anyway but they = don't need to learn policy from implementing the protocol. The second question is whether this balance is going to get better in = future, where again I am not that hopeful. With two variants of the protocol as tightly coupled to policy as this, = then when a registry changes policy it has to change interface. For a = start that's a disincentive to change as it imposes a cost on = registrars. There's also the issue that they registry making the change = doesn't have the historical data to conduct a 'what if our policy had = been different' exercise. The more general problem is that there is a strong school of thought = around EPP that goes - the core protocol is done and does not need changing - everything else we need can go in an extension - competition will sort out what extensions (or variants within = extensions) dominate I would suggest that is insufficient because policy, which eventually = drives the technology, works differently and so the core will gradually = become less suitable and the cruft of undead extensions (and variants) = will become unmanageable. Instead a more methodical process is needed = that periodically reviews the core and extensions and where appropriate = change the core and kills extensions. Some of this review needs to be = quite rapid to keep pace with the rapid pace of policy change. cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From patrik@frobbit.se Wed Mar 7 22:02:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A81621F84F7 for ; Wed, 7 Mar 2012 22:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owJuF6+pFIbD for ; Wed, 7 Mar 2012 22:02:16 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9F21F84F6 for ; Wed, 7 Mar 2012 22:02:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 6DFE4134300CD; Thu, 8 Mar 2012 07:02:13 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB+6628pCynE; Thu, 8 Mar 2012 07:02:13 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 3E008134300C6; Thu, 8 Mar 2012 07:02:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> Date: Thu, 8 Mar 2012 07:02:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:02:17 -0000 On 8 mar 2012, at 02:28, Jay Daley wrote: > To explain what I mean, here's a simple idea - could the protocol have = been designed to better minimise pain for registrars while maintaining = the choice for registries? I think this is a case that creates a problem for the _registrant_. If = it was only a registry/registrar battle (as in most cases we discuss on = this list ;-) ) I would not have spent so much time on this. > With two variants of the protocol as tightly coupled to policy as = this, then when a registry changes policy it has to change interface. A registry that want to be "thick" can still receive the DS, then fetch = the DNSKEY from DNS which they validate against the DS. If they want = create a new DS they can do so with whatever digest algorithm they want = and not even publish the DS that the client passes to them. So the DS should be enough. Everything else is bonus. Or am I completely = confused before enough coffee here in the morning? Btw, I will be at the ICANN meeting in Costa Rica and do not mind = talking with people about this. Patrik From jay@nzrs.net.nz Wed Mar 7 22:35:55 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D0E21F869C for ; Wed, 7 Mar 2012 22:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MylAgzQe-vFT for ; Wed, 7 Mar 2012 22:35:54 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 888C621F866E for ; Wed, 7 Mar 2012 22:35:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 393AA2CE1C3; Thu, 8 Mar 2012 19:35:52 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOSy+kc+LA+m; Thu, 8 Mar 2012 19:35:52 +1300 (NZDT) Received: from [172.20.10.2] (unknown [122.63.181.132]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 19E4A2CE002; Thu, 8 Mar 2012 19:35:50 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jay Daley In-Reply-To: <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> Date: Thu, 8 Mar 2012 19:35:48 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <93E3DACF-2BCE-479B-A8E8-3B80326F6DDE@nzrs.net.nz> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:35:55 -0000 On 8/03/2012, at 7:02 PM, Patrik F=E4ltstr=F6m wrote: >> To explain what I mean, here's a simple idea - could the protocol = have been designed to better minimise pain for registrars while = maintaining the choice for registries? >=20 > I think this is a case that creates a problem for the _registrant_. How? > If it was only a registry/registrar battle (as in most cases we = discuss on this list ;-) ) I would not have spent so much time on this. >=20 >> With two variants of the protocol as tightly coupled to policy as = this, then when a registry changes policy it has to change interface. >=20 > A registry that want to be "thick" can still receive the DS, then = fetch the DNSKEY from DNS which they validate against the DS. If they = want create a new DS they can do so with whatever digest algorithm they = want and not even publish the DS that the client passes to them. >=20 > So the DS should be enough. Everything else is bonus. Or am I = completely confused before enough coffee here in the morning? You are assuming a particular sequence of provisioning (i.e. that there = are published DNSKEY records when the DS is received). Many registries = make no assumptions and so don't expect to contact delegated nameservers = during the provisioning process. cheers Jay >=20 > Btw, I will be at the ICANN meeting in Costa Rica and do not mind = talking with people about this. >=20 > Patrik >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From patrik@frobbit.se Wed Mar 7 22:41:13 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980C421E8017 for ; Wed, 7 Mar 2012 22:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO1noiAurxem for ; Wed, 7 Mar 2012 22:41:13 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id B5BBB21E801C for ; Wed, 7 Mar 2012 22:41:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B4B2E13430AFE; Thu, 8 Mar 2012 07:41:11 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj-91LmQgLFb; Thu, 8 Mar 2012 07:41:11 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 8AF8F13430AF7; Thu, 8 Mar 2012 07:41:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <93E3DACF-2BCE-479B-A8E8-3B80326F6DDE@nzrs.net.nz> Date: Thu, 8 Mar 2012 07:41:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DAAF8C7-E80C-4E77-9B8E-92C673DAB730@frobbit.se> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <93E3DACF-2BCE-479B-A8E8-3B80326F6DDE@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:41:13 -0000 On 8 mar 2012, at 07:35, Jay Daley wrote: > On 8/03/2012, at 7:02 PM, Patrik F=E4ltstr=F6m wrote: >=20 >>> To explain what I mean, here's a simple idea - could the protocol = have been designed to better minimise pain for registrars while = maintaining the choice for registries? >>=20 >> I think this is a case that creates a problem for the _registrant_. >=20 > How? Because compared to other discussions we have, this implies the = registrant (or, more correctly, the DNS hosting provider) have to do = completely different actions depending on the policy of the TLD. >> So the DS should be enough. Everything else is bonus. Or am I = completely confused before enough coffee here in the morning? >=20 > You are assuming a particular sequence of provisioning (i.e. that = there are published DNSKEY records when the DS is received). Many = registries make no assumptions and so don't expect to contact delegated = nameservers during the provisioning process. Correct, just like many registries already today require delegations to = be made before registration can be done. I.e. some registries do not = allow registration without delegation. My point is that without delegation, sending KEY does not make any = sense. It is when delegating the dnssec data is needed and because of = that the KEY can be fetched at time of delegation. Patrik From peter@denic.de Thu Mar 8 00:16:07 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E388921F848F for ; Thu, 8 Mar 2012 00:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHnlsjAdE7Vm for ; Thu, 8 Mar 2012 00:16:07 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 63BB921F849C for ; Thu, 8 Mar 2012 00:16:06 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S5YW5-0006g3-0O; Thu, 08 Mar 2012 09:16:05 +0100 Received: from localhost by x27.adm.denic.de with local id 1S5YW4-0004bQ-Q3; Thu, 08 Mar 2012 09:16:04 +0100 Date: Thu, 8 Mar 2012 09:16:04 +0100 From: Peter Koch To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20120308081604.GK4480@x27.adm.denic.de> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:16:08 -0000 Patrik, > A registry that want to be "thick" can still receive the DS, then fetch the DNSKEY from DNS which they validate against the DS. If they want create a new DS they can do so with whatever digest algorithm they want and not even publish the DS that the client passes to them. i'm not sure what exactly you mean by thick (or "fat", as others have said) vs. thin here since in the realm of registries these terms are already occupied. I think the validation is related to, but otherwise independent of the type of object passed. In your scenario any DNSKEY that would end up in the registry db would have to be present at the apex at the time of registration, which prohibits pre-publication of a DS RR for a DNSKEY not yet present at the apex DNSKEY RRSet. I don't understand how the DNSKEY would be worse for the registrant than the DS given that the DNSKEY is what they already have in their hands. -Peter From Antoin.Verschuren@sidn.nl Thu Mar 8 00:35:55 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA80821F85DB for ; Thu, 8 Mar 2012 00:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4xO6MXEELPw for ; Thu, 8 Mar 2012 00:35:55 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id BAC2F21F85DA for ; Thu, 8 Mar 2012 00:35:54 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q288ZpNo021133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 8 Mar 2012 09:35:51 +0100 Received: from [192.168.129.215] (192.168.129.215) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 8 Mar 2012 09:35:50 +0100 Message-ID: <4F586F70.3050000@sidn.nl> Date: Thu, 8 Mar 2012 09:36:00 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> In-Reply-To: <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [192.168.129.215] Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:35:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08-03-12 07:02, Patrik Fältström wrote: > I think this is a case that creates a problem for the _registrant_. If it was only a registry/registrar battle (as in most cases we discuss on this list ;-) ) I would not have spent so much time on this. > Patrick, I think you are correct that multiple options are confusing for the users. In fact that is why we chose for DNSKEY in stead of DS, let me explain. In the beginning of DNSSEC, where procedures were not well worked out yet, registries chose for DS because that's what they minimally need to enter into the parent zone for a new DNSSEC delegation to work, and it's shorter and perhaps easier to copy-paste. However we encountered problems with other procedures when dealing with DNSSEC, like the transfer issue. Please read http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-03 To deal with the dns-operator change, users need to relay ZSK's, which is a KEY and not a DS. The losing operator needs the KEY from the gaining operator. So when we chose to use DS or DNSKEY, one of the rationales was that users need to send DS with no transfer, but need to send a KEY (ZSK) as well when there is a transfer. Let's just use KEYs all the time, it's less confusing. When the draft describing the transfer issue is done, I expect a new standard EPP extension that contains the "DNSKEY to be relayed" to the losing DNS operator, that contains a KEY (Any volunteers to take that up in this group ?). I also expect by that time that registries will see that it makes no sense to ask for a KEY one time, and a DS another time. The only reason to still support DS is then legacy support. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJPWG9sAAoJEDqHrM883AgnRa4H/jc79//8AiFTV0q/UYUUsFkw a4U/pevfcbs8TLU0QzdCDie0nuPO7Eeg/aF5FXY3uFknTgS+nWDAkatAXKBNFNQZ vzdICrxLY905wO9sOmV9nuAPTEvy4ae42tt4TRwid8/5Q6BOnhgglPt/oYc1qb5d Ga+V6YUDEYRYEVLdEPPOdXfAzwEPFbtvObKvF6cKayiNr+a4szxSH7YAaLSkkwdy u0Vc19h9Ztpi06Ohm4ZfzMyxEEqS7ec1qEG3H5bDZt2UFi2C9f60f1KoUtWU3EXa QYiP+oT3ThgwpT9qOrwZRjlIhp88JsG4AhOEg3D4fpqhgPmyuMbaQ6IvsxgEz20= =ktvM -----END PGP SIGNATURE----- From mje@posix.co.za Thu Mar 8 03:23:27 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B721F86DD for ; Thu, 8 Mar 2012 03:23:27 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhdTm7z8ZLUL for ; Thu, 8 Mar 2012 03:23:26 -0800 (PST) Received: from mje99.posix.co.za (xn--caf-dma.dnssec.co.za [IPv6:2001:42a0:1000:ff02::8]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14621F86D8 for ; Thu, 8 Mar 2012 03:23:25 -0800 (PST) Received: from [41.138.105.157] (helo=[192.168.1.122]) by mje99.posix.co.za with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from ) id 1S5bR7-0004fy-LI for provreg@ietf.org; Thu, 08 Mar 2012 13:23:19 +0200 From: Mark Elkins To: provreg@ietf.org In-Reply-To: <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-ITYQNZulA6zkXYxdUZn8" Organization: Posix Systems Date: Thu, 08 Mar 2012 12:52:18 +0200 Message-ID: <1331203938.7842.51.camel@mjelap.posix.co.za> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mje@posix.co.za List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 11:23:27 -0000 --=-ITYQNZulA6zkXYxdUZn8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-03-08 at 07:02 +0100, Patrik F=C3=A4ltstr=C3=B6m wrote: > A registry that want to be "thick" can still receive the DS, then fetch > the DNSKEY from DNS which they validate against the DS. If they want > create a new DS they can do so with whatever digest algorithm they want > and not even publish the DS that the client passes to them. >=20 > So the DS should be enough. Everything else is bonus. Or am I > completely confused before enough coffee here in the morning? I'd agree with you. A DS record over EPP (I'd thus assume a SSL/TLS type of secured link) gives the Registry enough validatable information to fetch DNSKEY records via unsigned DNS and then validate them. Personally - just sending a trigger to the Registry to come fetch my DNSKEY from me would statistically be enough. The Registry has my Nameservers - they can ask each NS in turn for my DNSKEY - if all Nameservers agree - its most probably correct... OK - so I'll send a valid DS record as a trigger. Once signed, a simple trigger should be enough though? The Registry can ask via DNSSEC for any new DNSKEY records as then the DNS transaction is signed (as in the AD bit is set)... OK - It'll still be a DS Record trigger. This is probably of insignificance to anyone running a properly configured Registry<-->Registrar systems but for anyone doing EPP type updates via a web portal, the less one has to type - the better.=20 --=20 . . ___. .__ Posix Systems - (South) Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 --=-ITYQNZulA6zkXYxdUZn8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINTjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHEjCCBfqg AwIBAgIDAxijMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTExMDExMDYwMjE2WhcNMTIxMDExMDA0OTIyWjBcMSAwHgYDVQQNExc1MzQyMTQtTkFUaGplVGJx N2RTTW9lNTEYMBYGA1UEAwwPbWplQHBvc2l4LmNvLnphMR4wHAYJKoZIhvcNAQkBFg9tamVAcG9z aXguY28uemEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAAhfxcV4rk1kcA6KMtMNz gAw9iRdTWLGd5y+hkky6zqfFwMNoXqOu+G49a0RWkgr9wJvkpbp7rAqJaM4NmVd4JpCrEoIhxyv5 IMtkgGRhgY/dQuAdHxRmdo4tSSRG1Mo+AkWaTBiZqGlaH6pQ4IbU7hqrUKfjrBgzA9BNyazh0sQ2 fV6WrWZC0Ly0ttHZ/30hdRZBytSnPzhR0I2olzDtEzzbzksbtDR7+xB6YC2EOgwZXtOyX8wmCWkn CQ6lrnfwlpazz0cyEnCjnEL0yczDD5dCAayThUBYjig1hE2jWrPbbfAtEOxrAU8ft8ToDHKOXix4 bb4iH+LufY4wEokDAgMBAAGjggOqMIIDpjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFGYTC59VuxNJw3HNkd04LTkGWPYVMB8G A1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBoGA1UdEQQTMBGBD21qZUBwb3NpeC5jby56 YTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAHifc+akGXPVQMCFiu/hjUJ5JGGisH/IFXcrXCu15N3607LKx9AO19fUU0pFgxR+ 2rHPYEr1wIuT7RHI7N/XTvLlI31p+UxD1rDDAj53sPxwv+l9NANdpLqrRiWq1GJ0TzHv1WuWMWNy hxPpfA3eqgZrLcQsDtFoQ9HFC5o9A8fp7nuhNS80GdXC13E1PWIYe9pEjH4GPZfegmiLK8qfmviZ wz2kzQcYf0Ku3APZ/5OKBLBoJOeyJgI3HYWV6bhKk1vUgy9HoImN2U8V4w5UH0k23tWI4pMXE4Px jejpzr6iEfwZcQxgIGWJy6F4cb64J9gYPWdjDCvehW2uGW5zAbsxggIbMIICFwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMDGKMwCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwODEwNTIxOFowIwYJKoZIhvcNAQkEMRYE FKrrcOY7up6UUFqtqKvc2uwg4fLOMA0GCSqGSIb3DQEBAQUABIIBACtyjYNpiRaJd3PaTb8fTdQm /mb2UHD6Ps8Gbl8qZzf5n0NcMQtKv4ZLRlbQ9v7t7u0uHhX6z2gkSuemAGUrzcUpkNnF4a4myWXx yCFV5qjsRkNaZJGNHg2LXdbN2Kk3BmFcgYujAk7wV1DqibfK8M3XEx22fXqd6XJSjUnmTAQBGdAa XLMqzlkfgkP1zyAyVlzestCE8jzIqHfwTV+jd4SF9iToZP0pA+7snL0cjXeSr7mLNoWLnqSUhUC/ lLzp/s1ucGs/5LvMzDf4VTEr9QjjYzQxHF0TXzGZzDgg5SZkLy6ba5Qv38aVsybnklgpxvs/xtRt JOHY6hdsOQSCUhIAAAAAAAA= --=-ITYQNZulA6zkXYxdUZn8-- From Antoin.Verschuren@sidn.nl Thu Mar 8 03:52:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3121F869E for ; Thu, 8 Mar 2012 03:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZwNAHX8fLN0 for ; Thu, 8 Mar 2012 03:52:00 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id B44FF21F8699 for ; Thu, 8 Mar 2012 03:51:58 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q28Bpvns005294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 8 Mar 2012 12:51:57 +0100 Received: from [192.168.129.215] (192.168.129.215) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 8 Mar 2012 12:51:57 +0100 Message-ID: <4F589D66.7080500@sidn.nl> Date: Thu, 8 Mar 2012 12:52:06 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <1331203938.7842.51.camel@mjelap.posix.co.za> In-Reply-To: <1331203938.7842.51.camel@mjelap.posix.co.za> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.129.215] Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 11:52:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08-03-12 11:52, Mark Elkins wrote: > Once signed, a simple trigger should be enough though? The Registry can > ask via DNSSEC for any new DNSKEY records as then the DNS transaction is > signed (as in the AD bit is set)... OK - It'll still be a DS Record > trigger. We have discussed such a principle some time ago, but it is/will be rejected by the politics of ICANN registrars. In our technical vision, EPP only needs to be used for bootstrapping the original delegation and chain of trust. After that, all technical stuff can be done over (secure) DNS, and EPP is only needed for administrative data. ICANN registrars disagree. According to their contract, ALL changes to the delegation may only be done by submission by the registrar over EPP to the registry, so that they are aware and can intercept technical changes. Even if that means the delegation is technically incorrect. NS changes can also be done over DNS if that is a secure channel, but registrars want to be able to block technical changes when f.e. a bill has not been paid. The motivation they use is that provisioning the registry data then comes from 2 channels, DNS and EPP, and the discussion may arise which one is authoritative. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJPWJ1mAAoJEDqHrM883Agn5V8H/jXRFzOgnZMFsbVKUcYOC9wF l9g2sZ2BQ/hZZEA3dXLQy6dMiJ+MlnmHSUSow3r1pM59SX3la7gsYmvlKUO+8Rpd OSy/R/7yO09zyO8+Ia5P18LGn2FJ+nnrWY+ARuCoUOCh8DyS/gsoABvDA47p+4hU JvtXVsyg6mppjqocS/d37uQhLqYoLDMqDTtVQz91+UhVkncUcSJrVHtnbkNMIUtF pjSYEq/yMXOcZQrW8HI3avL0UvomZoDMJAmYoynVjy/gSfUlKvw8Lhcv+jAp/hXT 8mLJEKacV6nE5OCYr1kWI3TwDo+U7CjItuDCfRH1D5b8dTGN9CjC3Zw789aOue4= =FaUI -----END PGP SIGNATURE----- From JGould@verisign.com Thu Mar 8 05:30:50 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B76E21F85A2 for ; Thu, 8 Mar 2012 05:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74VUTpCGF4yC for ; Thu, 8 Mar 2012 05:30:49 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8B21F84D4 for ; Thu, 8 Mar 2012 05:30:49 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT1i0WuHh5bJpF2GWm7oUzOzIQROHtjTq@postini.com; Thu, 08 Mar 2012 05:30:49 PST 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 q28DTu3R022093; Thu, 8 Mar 2012 08:29:58 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 08:29:56 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Thu, 8 Mar 2012 08:29:55 -0500 From: "Gould, James" To: "mje@posix.co.za" , "provreg@ietf.org" Thread-Topic: [provreg] Example of stupid inconsistencies between registries Thread-Index: AQHM+r0q7eo1z51rQ0WnxvppIby9dZZf886AgABMiwCAAFENAP//2DGA Date: Thu, 8 Mar 2012 13:29:55 +0000 Message-ID: In-Reply-To: <1331203938.7842.51.camel@mjelap.posix.co.za> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 13:29:56.0118 (UTC) FILETIME=[8D33E360:01CCFD2F] Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:30:50 -0000 This has been a very interesting thread. The key is what the provisioning interface should be for the DNSSEC information. I don't believe that the Registrar should provide a hint to the Registry to go retrieve information from DNS. EPP is the secure provisioning protocol that should be used for passing information that makes it into the resolution services provided by the Registry. In RFC 5910 the two interfaces define what objects in the Registry are managed by the Registrars. The DS Data Interface has the Registrar manage the DS Data that is directly placed into the parent zone by the Registry. The Key Data Interface has the Registrar manage the Key Data and the Registry generates the DS Data to place in the parent zone. RFC 5910 supports passing both DS Data and the associated Key Data for validation purposes by the Registry, but that still is considered the DS Data Interface. Back when we started working on the update to RFC 4310 that eventually became RFC 5910, the concept of supporting a Key Data Interface was discussed with no concerns expressed at the time or as RFC 5910 went through the standards process. The only real discussion was around supporting a mix of the DS Data Interface and the Key Data Interface which resulted in having the server support one or the other and only a mix during a transition period. Support for both models in RFC 5910 is no different than support for multiple models for hosts (host objects or host attributes) or contacts (thin or thick) in RFC 5731, where the protocol does not dictate the model but supports the different models. If the registries are going to support the different models, as in this case, the only alternative would be the creation of a one or more custom extensions for the less popular model, which as I posted previously wouldn't benefit anyone. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/8/12 5:52 AM, "Mark Elkins" wrote: >On Thu, 2012-03-08 at 07:02 +0100, Patrik F=E4ltstr=F6m wrote: > >> A registry that want to be "thick" can still receive the DS, then fetch >> the DNSKEY from DNS which they validate against the DS. If they want >> create a new DS they can do so with whatever digest algorithm they want >> and not even publish the DS that the client passes to them. >>=20 >> So the DS should be enough. Everything else is bonus. Or am I >> completely confused before enough coffee here in the morning? > >I'd agree with you. A DS record over EPP (I'd thus assume a SSL/TLS type >of secured link) gives the Registry enough validatable information to >fetch DNSKEY records via unsigned DNS and then validate them. > >Personally - just sending a trigger to the Registry to come fetch my >DNSKEY from me would statistically be enough. The Registry has my >Nameservers - they can ask each NS in turn for my DNSKEY - if all >Nameservers agree - its most probably correct... OK - so I'll send a >valid DS record as a trigger. > >Once signed, a simple trigger should be enough though? The Registry can >ask via DNSSEC for any new DNSKEY records as then the DNS transaction is >signed (as in the AD bit is set)... OK - It'll still be a DS Record >trigger. > >This is probably of insignificance to anyone running a properly >configured Registry<-->Registrar systems but for anyone doing EPP type >updates via a web portal, the less one has to type - the better. >--=20 > . . ___. .__ Posix Systems - (South) Africa > /| /| / /__ mje@posix.co.za - Mark J Elkins, Cisco CCIE >/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From michael@mwyoung.ca Thu Mar 8 09:50:47 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151D321F8630 for ; Thu, 8 Mar 2012 09:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5cX-652ARRr for ; Thu, 8 Mar 2012 09:50:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3101021F8628 for ; Thu, 8 Mar 2012 09:50:44 -0800 (PST) Received: by vbbez10 with SMTP id ez10so705524vbb.31 for ; Thu, 08 Mar 2012 09:50:44 -0800 (PST) Received: by 10.52.240.177 with SMTP id wb17mr11606590vdc.63.1331229044328; Thu, 08 Mar 2012 09:50:44 -0800 (PST) Received: from DUN20111 (CPEf81edff844ad-CM00080da07047.cpe.net.cable.rogers.com. [99.226.80.88]) by mx.google.com with ESMTPS id ht6sm4956821vdb.8.2012.03.08.09.50.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 09:50:42 -0800 (PST) From: "Michael Young" To: "'Antoin Verschuren'" , References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <4F586F70.3050000@sidn.nl> In-Reply-To: <4F586F70.3050000@sidn.nl> Date: Thu, 8 Mar 2012 12:50:40 -0500 Message-ID: <003f01ccfd53$faca5a20$f05f0e60$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrpg3o4e7HoHCoUFE6MW+JZqT2LwHI98yiAIL9A7ACgwHAY5X8we3Q Content-Language: en-ca X-Gm-Message-State: ALoCoQldiZIUW+FLjveP3uNsP2XT9rAC91JOck8pjBT4TLOFepYBfEho8W3czmj8nCqSW9dpZtgo Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:50:47 -0000 I'm not sure why as a DNS operator I would want to either send a ZSK = (signed by my KSK) or receive a ZSK signed by a KSK I don't control through the domain registry. I tend to think this should stay between the two DNS operators, as the = keys are being managed in the delegate zone, all the TLD zone should care = about is that whoever controls the domain has submitted what they consider to = be a valid DS. As Patrik said, if the registry wants to be generous, it can validate the DS against the key by looking it up in the subordinate = zone - but that should be at the decision (option) of the registry. DNSSEC is only one of numerous out of (registry) band activities that = happen around a transfer. Personally, if I was processing a DNS operator transfer for a signed = zone, and I was the losing DNS operator, I would prefer the requesting DNS operator to provide a ZSK that they generated and I would incoporate = that into my key rollover. I don't think the registry's responsibilities should try and overreach, = for example, what if I am switching registrars but not DNS operators? I = could run a transfer with no related DNS/DNSSEC changes. What if I change DNS operators but stay with the same registrar? Again, other than switching = up DS records through my registrar, the registry doesn't need to be = involved any further. I think the registry's role should stay constrained to what it's responsibilities are at it's level of the hierachary. Now I suppose we argue about what those responsibilities really should be, but I think it starts and ends with what they can control. =20 Best Regards, Michael Young M:+1-647-289-1220 -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On = Behalf Of Antoin Verschuren Sent: March-08-12 3:36 AM To: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between = registries -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08-03-12 07:02, Patrik F=E4ltstr=F6m wrote: > I think this is a case that creates a problem for the _registrant_. If = it was only a registry/registrar battle (as in most cases we discuss on = this list ;-) ) I would not have spent so much time on this. >=20 Patrick, I think you are correct that multiple options are confusing for the = users. In fact that is why we chose for DNSKEY in stead of DS, let me explain. In the beginning of DNSSEC, where procedures were not well worked out = yet, registries chose for DS because that's what they minimally need to enter into the parent zone for a new DNSSEC delegation to work, and it's = shorter and perhaps easier to copy-paste. However we encountered problems with other procedures when dealing with DNSSEC, like the transfer issue. Please read http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-03 To deal with the dns-operator change, users need to relay ZSK's, which = is a KEY and not a DS. The losing operator needs the KEY from the gaining operator. So when we chose to use DS or DNSKEY, one of the rationales was that = users need to send DS with no transfer, but need to send a KEY (ZSK) as well = when there is a transfer. Let's just use KEYs all the time, it's less = confusing. When the draft describing the transfer issue is done, I expect a new standard EPP extension that contains the "DNSKEY to be relayed" to the losing DNS operator, that contains a KEY (Any volunteers to take that up = in this group ?). I also expect by that time that registries will see that = it makes no sense to ask for a KEY one time, and a DS another time. The only reason to still support DS is then legacy support. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJPWG9sAAoJEDqHrM883AgnRa4H/jc79//8AiFTV0q/UYUUsFkw a4U/pevfcbs8TLU0QzdCDie0nuPO7Eeg/aF5FXY3uFknTgS+nWDAkatAXKBNFNQZ vzdICrxLY905wO9sOmV9nuAPTEvy4ae42tt4TRwid8/5Q6BOnhgglPt/oYc1qb5d Ga+V6YUDEYRYEVLdEPPOdXfAzwEPFbtvObKvF6cKayiNr+a4szxSH7YAaLSkkwdy u0Vc19h9Ztpi06Ohm4ZfzMyxEEqS7ec1qEG3H5bDZt2UFi2C9f60f1KoUtWU3EXa QYiP+oT3ThgwpT9qOrwZRjlIhp88JsG4AhOEg3D4fpqhgPmyuMbaQ6IvsxgEz20=3D =3DktvM -----END PGP SIGNATURE----- _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From ajs@anvilwalrusden.com Thu Mar 8 10:17:26 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE4921F86BA for ; Thu, 8 Mar 2012 10:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0zidq3CiDFX for ; Thu, 8 Mar 2012 10:17:25 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BBBCB21F86B9 for ; Thu, 8 Mar 2012 10:17:25 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A943B1ECB41D for ; Thu, 8 Mar 2012 18:17:19 +0000 (UTC) Date: Thu, 8 Mar 2012 13:17:08 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120308181708.GC80327@mail.yitter.info> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <4F586F70.3050000@sidn.nl> <003f01ccfd53$faca5a20$f05f0e60$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003f01ccfd53$faca5a20$f05f0e60$@mwyoung.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:17:26 -0000 On Thu, Mar 08, 2012 at 12:50:40PM -0500, Michael Young wrote: > argue about what those responsibilities really should be, but I think it > starts and ends with what they can control. If that's your position, then you must agree that they should require the DNSKEY and generate the DS themselves, because the DS is data for which they are authoritative. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Thu Mar 8 10:35:54 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23D921F858D for ; Thu, 8 Mar 2012 10:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+u+PjZCbEyp for ; Thu, 8 Mar 2012 10:35:48 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7EDE21F8572 for ; Thu, 8 Mar 2012 10:35:48 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so764589vcb.31 for ; Thu, 08 Mar 2012 10:35:48 -0800 (PST) Received: by 10.52.90.111 with SMTP id bv15mr11871823vdb.34.1331231748016; Thu, 08 Mar 2012 10:35:48 -0800 (PST) Received: from [172.16.1.43] (CPEf81edff844ad-CM00080da07047.cpe.net.cable.rogers.com. [99.226.80.88]) by mx.google.com with ESMTPS id hf9sm5191633vdb.7.2012.03.08.10.35.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 10:35:47 -0800 (PST) References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <4F586F70.3050000@sidn.nl> <003f01ccfd53$faca5a20$f05f0e60$@mwyoung.ca> <20120308181708.GC80327@mail.yitter.info> In-Reply-To: <20120308181708.GC80327@mail.yitter.info> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Michael Young Date: Thu, 8 Mar 2012 13:35:44 -0500 To: Andrew Sullivan X-Gm-Message-State: ALoCoQkd/CUQBjiakm7pt8aC+LoWGLuUmUideHRLGFnG4FzzgTM/ndpogsQWJNetKQgqbaQ7XEM1 Cc: "provreg@ietf.org" Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:35:54 -0000 Nice turn Andrew, reminds that you have a background in logic :-) However I would say the dnskey belongs to the subordinate zone and the DS is= an artifact of that key - making them responsible, not the registry. Having= a bad DS in the registry breaks the validation path but then so does have t= he wrong delegated nameservers. The registry IMHO authenticates the party au= thorized to make changes regarding a registration, not determine if the regi= strant set their related DNS data right ( and yes I know that there are ccTL= Ds that prevent registration if this isn't right.) I think monitoring, testi= ng and notifying registrars of mistakes is great and everyone should do it. = But ultimately if they get it wrong it's their zone that breaks, not the TL= Ds hence why it's their job,...... Michael Young M:647-289-1220 On 2012-03-08, at 1:17 PM, Andrew Sullivan wrote: > On Thu, Mar 08, 2012 at 12:50:40PM -0500, Michael Young wrote: >> argue about what those responsibilities really should be, but I think it >> starts and ends with what they can control. =20 >=20 > If that's your position, then you must agree that they should require > the DNSKEY and generate the DS themselves, because the DS is data for > which they are authoritative. >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From peter@denic.de Thu Mar 8 10:50:31 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CFF21F85A0 for ; Thu, 8 Mar 2012 10:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7B9DXnHqWxO for ; Thu, 8 Mar 2012 10:50:31 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 1E43D21F84A7 for ; Thu, 8 Mar 2012 10:50:31 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S5iQ1-0001gb-Sd; Thu, 08 Mar 2012 19:50:29 +0100 Received: from localhost by x27.adm.denic.de with local id 1S5iQ1-0008LG-Om; Thu, 08 Mar 2012 19:50:29 +0100 Date: Thu, 8 Mar 2012 19:50:29 +0100 From: Peter Koch To: Michael Young Message-ID: <20120308185029.GQ4480@x27.adm.denic.de> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <4F586F70.3050000@sidn.nl> <003f01ccfd53$faca5a20$f05f0e60$@mwyoung.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003f01ccfd53$faca5a20$f05f0e60$@mwyoung.ca> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: provreg@ietf.org Subject: [provreg] DNSSEC operator change [Re: Example of stupid inconsistencies between registries] X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:50:31 -0000 Michael, > I'm not sure why as a DNS operator I would want to either send a ZSK (signed > by my KSK) or receive a ZSK signed by a KSK I don't control through the > domain registry. may i humbly ask whether you have read the draft Antoin pointed to? > I tend to think this should stay between the two DNS operators, as the keys Absolutely, but in the process of the operator change, these two entities for which we cannot safely assume an authenticated, secure channel to exist, need to exchange ZSK information. Old data can be gathered DNSSEC secured from the DNS but there is no generic way for the losing operator to access the gaining operator's ZSK. That's where the registry comes in providing a dropbox that both operators (at least through their registrars) have access to. In that sense, the ZSk is not registered and is not processed by the registry other than being relayed. I'd hope that the draft is clear about this and the difficulties arose from the fact it was dropped inmidst this discussion about which object to register. If the draft is not explaining that background well, that's a pity, and we'd appreciate feedback. That said, a -04 version is in preparation and while there is a provisioning (read: EPP) component to it that would go into a separate document, we are most likely going to ask for feedback on the DNSOP WG mailing list to address the key timing issues first. Other comments are of course welcome, just trying to avoid the spread. Best regards, Peter From michael@mwyoung.ca Thu Mar 8 11:52:44 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A9421F8658 for ; Thu, 8 Mar 2012 11:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3x-JT5JZwgx for ; Thu, 8 Mar 2012 11:52:43 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0723521F8657 for ; Thu, 8 Mar 2012 11:52:40 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so846781vcb.31 for ; Thu, 08 Mar 2012 11:52:40 -0800 (PST) Received: by 10.52.180.38 with SMTP id dl6mr10681373vdc.105.1331236360431; Thu, 08 Mar 2012 11:52:40 -0800 (PST) Received: from DUN20111 (CPEf81edff844ad-CM00080da07047.cpe.net.cable.rogers.com. [99.226.80.88]) by mx.google.com with ESMTPS id ew2sm5562810vdc.16.2012.03.08.11.52.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 11:52:39 -0800 (PST) From: "Michael Young" To: "'Peter Koch'" References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <4F586F70.3050000@sidn.nl> <003f01ccfd53$faca5a20$f05f0e60$@mwyoung.ca> <20120308185029.GQ4480@x27.adm.denic.de> In-Reply-To: <20120308185029.GQ4480@x27.adm.denic.de> Date: Thu, 8 Mar 2012 14:52:31 -0500 Message-ID: <007601ccfd65$03d5a8c0$0b80fa40$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrpg3o4e7HoHCoUFE6MW+JZqT2LwHI98yiAIL9A7ACgwHAYwFuAiaxAJedXLKV7NEvEA== Content-Language: en-ca X-Gm-Message-State: ALoCoQkgaMdQ3jt4KnY0HLdTi/GCOldnf1JaHB4SigAtxibvzM7FvdPy7w4xa7wGFAoEEE3T/6yG Cc: provreg@ietf.org Subject: Re: [provreg] DNSSEC operator change [Re: Example of stupid inconsistencies between registries] X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:52:44 -0000 I did read it, I was basically agreeing with the process that document lays out, except I don't like the registry being the dropbox for the zsk exchange from old to new operator. Clearing I wasn't expressing that well enough! However I suppose since I have an opinion, I should suggest another alternative then, let me think on that and I'm happy to comment on your next version. -M -----Original Message----- From: Peter Koch [mailto:peter@denic.de] On Behalf Of Peter Koch Sent: March-08-12 1:50 PM To: Michael Young Cc: provreg@ietf.org Subject: DNSSEC operator change [Re: [provreg] Example of stupid inconsistencies between registries] Michael, > I'm not sure why as a DNS operator I would want to either send a ZSK > (signed by my KSK) or receive a ZSK signed by a KSK I don't control > through the domain registry. may i humbly ask whether you have read the draft Antoin pointed to? > I tend to think this should stay between the two DNS operators, as the > keys Absolutely, but in the process of the operator change, these two entities for which we cannot safely assume an authenticated, secure channel to exist, need to exchange ZSK information. Old data can be gathered DNSSEC secured from the DNS but there is no generic way for the losing operator to access the gaining operator's ZSK. That's where the registry comes in providing a dropbox that both operators (at least through their registrars) have access to. In that sense, the ZSk is not registered and is not processed by the registry other than being relayed. I'd hope that the draft is clear about this and the difficulties arose from the fact it was dropped inmidst this discussion about which object to register. If the draft is not explaining that background well, that's a pity, and we'd appreciate feedback. That said, a -04 version is in preparation and while there is a provisioning (read: EPP) component to it that would go into a separate document, we are most likely going to ask for feedback on the DNSOP WG mailing list to address the key timing issues first. Other comments are of course welcome, just trying to avoid the spread. Best regards, Peter From fneves@registro.br Thu Mar 8 16:52:43 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1921F85A8 for ; Thu, 8 Mar 2012 16:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdARP3ZpTSKF for ; Thu, 8 Mar 2012 16:52:43 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 070DC21F85A5 for ; Thu, 8 Mar 2012 16:52:40 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 4BF8DE0474; Thu, 8 Mar 2012 21:52:38 -0300 (BRT) Date: Thu, 8 Mar 2012 21:52:38 -0300 From: Frederico A C Neves To: Peter Koch Message-ID: <20120309005238.GA39082@registro.br> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <20120308081604.GK4480@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120308081604.GK4480@x27.adm.denic.de> Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:52:43 -0000 On Thu, Mar 08, 2012 at 09:16:04AM +0100, Peter Koch wrote: ... > In your scenario any DNSKEY that would end up in the registry db > would have to be present at the apex at the time of registration, > which prohibits pre-publication of a DS RR for a DNSKEY not yet > present at the apex DNSKEY RRSet. Which basically proofs that the DNSKEY interface is not suitable for pre-publications too. Remember the purpose of this is to not pre-expose the public-key, so why show it to your registry. So plain DS, without DNSKEY fetch and check, is the only suitable interface for this corner case scenario. ... > -Peter Fred From theo@flame.co.za Thu Mar 8 20:32:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC51821E8062 for ; Thu, 8 Mar 2012 20:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETMZlCoEh1v0 for ; Thu, 8 Mar 2012 20:32:46 -0800 (PST) Received: from flame.co.za (ns.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CE921E804B for ; Thu, 8 Mar 2012 20:32:45 -0800 (PST) Received: from [192.168.14.175] (unknown [201.199.192.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 5BEB48005E for ; Fri, 9 Mar 2012 06:32:38 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 8 Mar 2012 22:32:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8C58E70F-EA7D-4FE5-8335-4EB0A3E5BDF9@flame.co.za> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: provreg@ietfa.amsl.com X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:32:47 -0000 On 07 Mar 2012, at 11:08 AM, Hollenbeck, Scott wrote: >=20 > Given that RFC 5730 is part of Standard 69 there's not much chance of = a near-term amendment, but our process allows us to collect errata. I'm = not convinced that there's anything here to correct, though. Section 2.5 = currently says this: >=20 > "MAY be used to uniquely identify the command *to the client*" >=20 Is that not perhaps something that slipped through the cracks? Ie. = should it not read "MAY be used to uniquely identify the command from the client" ? --=20 Regards Theo From patrik@frobbit.se Thu Mar 8 20:33:57 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5468821F84EE for ; Thu, 8 Mar 2012 20:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.764 X-Spam-Level: X-Spam-Status: No, score=-101.764 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zuvQv74EwUK for ; Thu, 8 Mar 2012 20:33:38 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 5320021E803A for ; Thu, 8 Mar 2012 20:33:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 7041313452C9B; Fri, 9 Mar 2012 05:33:27 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2di+9mlnvTQ; Fri, 9 Mar 2012 05:33:27 +0100 (CET) Received: from [10.0.1.3] (unknown [201.204.76.162]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7DE5713452C93; Fri, 9 Mar 2012 05:33:26 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120308081604.GK4480@x27.adm.denic.de> Date: Thu, 8 Mar 2012 17:58:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92E9822B-A7BB-42DB-9944-59569664089B@frobbit.se> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <20120308081604.GK4480@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:33:57 -0000 On 8 mar 2012, at 09:16, Peter Koch wrote: >> A registry that want to be "thick" can still receive the DS, then = fetch the DNSKEY from DNS which they validate against the DS. If they = want create a new DS they can do so with whatever digest algorithm they = want and not even publish the DS that the client passes to them. >=20 > i'm not sure what exactly you mean by thick (or "fat", as others have = said) > vs. thin here since in the realm of registries these terms are already = occupied. Well, I use it because other people started using it ;-) I think people = have used "thick" or "fat" for registries that want to have the DNSKEY = for all the DS they have, and "thin" if they just have the DS. > I think the validation is related to, but otherwise independent of the = type > of object passed. > In your scenario any DNSKEY that would end up in the registry db would = have > to be present at the apex at the time of registration, No, not at the time of registration. At the time the DS is to appear in = the zone (after validation that the DNSKEY and DS matches each other). = Just like NS records, they can be added much later than time of = registration. The validation is similar to the validation some = registries do for lame delegation (at time of addition of NS to the = parent zone). It has nothing to do with registration per se, although some registries = require delegation at time of registration. > which prohibits > pre-publication of a DS RR for a DNSKEY not yet present at the apex = DNSKEY RRSet. This is correct. If the registry want to hold the DNSKEY and they only get the DS and the = DNSKEY is not in the apex DNSKEY RRSet, then... A lot of "if" there ;-) I see such policies be policies that a registry can implement anyway = with the DS interface. For example, I sort of can understand that a = registry only want to accept some digest types. That can be done by only = accepting some digest types when DS is passed to them. In the case of = pre-publication of DS, the registry can say that "if you use the DS = interface, the DNSKEY must be present in the DNSKEY apex RRSet at time = of passing the DS via epp". I think both of those solutions would be = better than refusing to support the DS interface. That said, I do not understand registries that do not accept DS = interface and "just" pass that to their zone and sign it. It seems to = much much easier than the for me more complicated DNSKEY interface. > I don't understand how the DNSKEY would be worse for the registrant = than the DS given that > the DNSKEY is what they already have in their hands. Correct, we could as well have always passed the DNSKEY to the registry. = The problem is not even that some registries ask for DS, some for = DNSKEY, but that some refuse to accept DS (in my case). It could, as you = say, also have been that some refuse to accept DNSKEY. To repeat, I have encountered a number of registries accepting DS (they = might accept DNSKEY as well) and now suddenly one that only accept = DNSKEY and not DS. I felt that was a situation complicated enough for the registrar (me) = and the registrant (our customers) that I wanted to discuss the = situation on this list. Which I thank you all for the ability to do. It has been a good = conversation. Patrik From shollenbeck@verisign.com Fri Mar 9 04:04:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B7221F85B6 for ; Fri, 9 Mar 2012 04:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS2DR9eeCK1U for ; Fri, 9 Mar 2012 04:04:34 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4241221F85AA for ; Fri, 9 Mar 2012 04:04:34 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT1nxvxgztfhmabmaM8NnQCdYTb2fnMgb@postini.com; Fri, 09 Mar 2012 04:04:34 PST 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 q29C4EIp029289; Fri, 9 Mar 2012 07:04:14 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 07:04:14 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 07:04:13 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 9 Mar 2012 07:04:13 -0500 From: "Hollenbeck, Scott" To: Theo Kramer , "provreg@ietfa.amsl.com" Thread-Topic: [provreg] clTRID element clarification Thread-Index: AQHM/a2wkIzf9pW/uUqlnHSoKVQcCZZh3PVQ Date: Fri, 9 Mar 2012 12:04:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5BCF53@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E679@LISA.internal.domicilium.com> <831693C2CDA2E849A7D7A712B24E257F0D5BB6A9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <8C58E70F-EA7D-4FE5-8335-4EB0A3E5BDF9@flame.co.za> In-Reply-To: <8C58E70F-EA7D-4FE5-8335-4EB0A3E5BDF9@flame.co.za> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Mar 2012 12:04:13.0683 (UTC) FILETIME=[BE7C5430:01CCFDEC] Subject: Re: [provreg] clTRID element clarification X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:04:35 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Theo Kramer > Sent: Thursday, March 08, 2012 11:33 PM > To: provreg@ietfa.amsl.com > Subject: Re: [provreg] clTRID element clarification >=20 >=20 > On 07 Mar 2012, at 11:08 AM, Hollenbeck, Scott wrote: > > > > Given that RFC 5730 is part of Standard 69 there's not much chance of > a near-term amendment, but our process allows us to collect errata. I'm > not convinced that there's anything here to correct, though. Section > 2.5 currently says this: > > > > "MAY be used to uniquely identify the command *to the client*" > > >=20 > Is that not perhaps something that slipped through the cracks? Ie. > should it not read >=20 > "MAY be used to uniquely identify the command from the client" ? No, the intention is for the clTRID to have meaning only in the client's co= ntext. That's not a typo about sending commands to clients. Scott From peter@denic.de Fri Mar 9 06:23:51 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C9A21F84F2 for ; Fri, 9 Mar 2012 06:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3yMPvj0mOPf for ; Fri, 9 Mar 2012 06:23:50 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25221F8516 for ; Fri, 9 Mar 2012 06:23:50 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S60jV-00010Y-3M; Fri, 09 Mar 2012 15:23:49 +0100 Received: from localhost by x27.adm.denic.de with local id 1S60jU-0005x9-Vq; Fri, 09 Mar 2012 15:23:49 +0100 Date: Fri, 9 Mar 2012 15:23:48 +0100 From: Peter Koch To: provreg@ietf.org Message-ID: <20120309142348.GE16377@x27.adm.denic.de> References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <20120308081604.GK4480@x27.adm.denic.de> <20120309005238.GA39082@registro.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120309005238.GA39082@registro.br> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:23:51 -0000 Fred, > Which basically proofs that the DNSKEY interface is not suitable for > pre-publications too. Remember the purpose of this is to not > pre-expose the public-key, so why show it to your registry. i was not referring to the purpose of hiding the key (a myth anyway) but to what 4641bis (4.1.3) calls "double DS rollover". That section explains why there is not always a DNSKEY RR in the DNS for a DS to be published at the parent. -Peter From heland@afilias.info Fri Mar 9 08:40:05 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD2B21F861D for ; Fri, 9 Mar 2012 08:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLuDVQm7-FEk for ; Fri, 9 Mar 2012 08:40:04 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9690221F8615 for ; Fri, 9 Mar 2012 08:40:03 -0800 (PST) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S62rK-0007lb-7r for provreg@ietf.org; Fri, 09 Mar 2012 16:40:02 +0000 Received: from mail-yw0-f50.google.com ([209.85.213.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S62rK-0002J1-42 for provreg@ietf.org; Fri, 09 Mar 2012 16:40:02 +0000 Received: by yhjj63 with SMTP id j63so987303yhj.9 for ; Fri, 09 Mar 2012 08:40:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=GD5BxqEqSS+omTty0yipgZOFUNnQw6Td8DLLiEGoF6Q=; b=nkmewSPwHh7vPXm7XbwXcEQe1xbDoqD8n91Q7gDYavMC/wY/wdPQhpHOyiXZDaZ0H4 GivNFRZr9R+iMhzioNkvk/pHjvsBKrezMm7t7fTQhThxmt8S2Dsm2LUTZktcPTVRraH9 rEk66b83vHr8+iMFvEkoryxFMLKCVXes3Za/yK8Gn8LOZfRV5aZVlFCyHfPNHfgLGPZ7 hr7S/GwaQhjfHhDE6YbLiGbdi9fJNmZn5MKTCnHeNvHhobJ8Ef/up3OlEi/jcWTHZcY5 XA025lMqrRNgq1Od5zfePpzwRBoYR9OQBqpe3c4i9l6U9JEer3R5ggSOXE/wDwIeWy5b xjoQ== Received: by 10.236.187.5 with SMTP id x5mr3144254yhm.35.1331311201743; Fri, 09 Mar 2012 08:40:01 -0800 (PST) Received: from alamo.elandmeadery.info (cpe-72-177-97-55.austin.res.rr.com. [72.177.97.55]) by mx.google.com with ESMTPS id q14sm9956958anj.9.2012.03.09.08.40.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 08:40:01 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Howard Eland In-Reply-To: <92E9822B-A7BB-42DB-9944-59569664089B@frobbit.se> Date: Fri, 9 Mar 2012 10:39:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <20120308081604.GK4480@x27.adm.denic.de> <92E9822B-A7BB-42DB-9944-59569664089B@frobbit.se> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQndGLE34O8hYhYpgS/twJuh9hcwfdzEve6k4FvdsddPNB27WcTQ1eH0mYEunX2n1s4/4Jrn Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:40:05 -0000 On Mar 8, 2012, at 10:58 AM, Patrik F=E4ltstr=F6m wrote: >> I don't understand how the DNSKEY would be worse for the registrant = than the DS given that >> the DNSKEY is what they already have in their hands. >=20 > Correct, we could as well have always passed the DNSKEY to the = registry. The problem is not even that some registries ask for DS, some = for DNSKEY, but that some refuse to accept DS (in my case). It could, as = you say, also have been that some refuse to accept DNSKEY. Ah, but this gets back to registry policy. Earlier in this thread, = someone had mentioned that protocol should not (as far as possible) = dictate policy. Because the ultimate party responsible for the DS RR is = the parent, they should have the flexibility to set policy on how they = want to generate this record - either have it handed to them, or to = generate it themselves. As I've stated earlier, both have valid points, = so the protocol was written to allow either. >=20 > To repeat, I have encountered a number of registries accepting DS = (they might accept DNSKEY as well) and now suddenly one that only accept = DNSKEY and not DS. ... and this sounds like a poor (or non-existant) transition plan, not a = fault of the protocol. >=20 > I felt that was a situation complicated enough for the registrar (me) = and the registrant (our customers) that I wanted to discuss the = situation on this list. >=20 > Which I thank you all for the ability to do. It has been a good = conversation. Indeed it has. =20 -Howard= From ulrich@wisser.se Sat Mar 10 13:58:53 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27D021F84D9 for ; Sat, 10 Mar 2012 13:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnm46g2fBx7Z for ; Sat, 10 Mar 2012 13:58:53 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7D5821F84C4 for ; Sat, 10 Mar 2012 13:58:52 -0800 (PST) Received: by lagj5 with SMTP id j5so3144399lag.31 for ; Sat, 10 Mar 2012 13:58:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=hulv1JB7ZQkverSIiRi9X0ZQP5USExOFcTLIuklYjqs=; b=b7JYom1+MtfDQ9bz0qG8/omFIJnwQUh4tESe0fQlSsf7AXvYpZVqvniNsZ6va/TP93 uwZ9atItvH7Z8ZJ4bvH8al/bvvvvmECo16JQmA1cF3f5KDAod8THH0CfJkoYcdc1byqb Cs4CVruN6YaXI7Ta6AWPOLurBgOFnUFd3Ho8AiiRYbA2DRpOpf5/4/ISgjl5TNr70LQy GVdaur0JudMWMuw1an8WLXpjl4bRZ70w06UOD3VIZCI2kHD19IIDNzdLy+vQHIbstk1i pKtNplrVnBjPU/WU2SLE+RZsKmcyNa5gye/aVr++WQe5mDXj604/29F0XE0+ji5u3eMY XnuQ== Received: by 10.152.148.2 with SMTP id to2mr5186649lab.39.1331416731182; Sat, 10 Mar 2012 13:58:51 -0800 (PST) Received: from ulrich-wissers-macbook-pro.local (h211n3-rny-a12.ias.bredband.telia.com. [213.65.82.211]) by mx.google.com with ESMTPS id pw4sm8882883lab.8.2012.03.10.13.58.49 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 13:58:49 -0800 (PST) Message-ID: <4F5BCE98.6070509@wisser.se> Date: Sat, 10 Mar 2012 22:58:48 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: provreg@ietf.org References: <0B90F8B4-8780-4FC4-8D12-161E1AB466C3@frobbit.se> <579351ED-B21E-46A2-AE50-31C6F82D11BD@nzrs.net.nz> <70E8A7F2-9FA7-44F8-935C-5FD05101E71B@frobbit.se> <20120308081604.GK4480@x27.adm.denic.de> <92E9822B-A7BB-42DB-9944-59569664089B@frobbit.se> In-Reply-To: <92E9822B-A7BB-42DB-9944-59569664089B@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkmHEUOmKTblPPr2xAw9W0XCDQpIYJec9x+jEf+YmlX+R0uO/QVJcOojEM2sgEHg4wtH2CJ Subject: Re: [provreg] Example of stupid inconsistencies between registries X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 21:58:53 -0000 Hello everybody, sorry I am late for the party. :-) In my opinion we did quite well with 5910. We allowed both policies and made it possible for registrars to interact with hundreds of registries with only two distinct interfaces. Maybe we could have done better on EPP implementation policies. Maybe Postel's Law, "be conservative in what you do, be liberal in what you accept from others" could be applied here. If a registrar sends both DS and DNSKEY interface the registry should choose one and ignore the other. And not reject the command. Although I am not really convince that this would be a good thing. /Ulrich From benoit.levac@cira.ca Thu Mar 29 18:49:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6382621E8043 for ; Thu, 29 Mar 2012 18:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPXUfnhbDJj8 for ; Thu, 29 Mar 2012 18:48:59 -0700 (PDT) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB321E801C for ; Thu, 29 Mar 2012 18:48:59 -0700 (PDT) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 571AE13FB01 for ; Thu, 29 Mar 2012 21:48:54 -0400 (EDT) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id 3DFE713FB01 for ; Thu, 29 Mar 2012 21:48:54 -0400 (EDT) Received: from MBX01.cira1.cira.ca ([10.2.16.29]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Thu, 29 Mar 2012 21:49:31 -0400 From: Benoit Levac To: "provreg@ietf.org" Date: Thu, 29 Mar 2012 21:46:41 -0400 Thread-Topic: IDN administrative bundling Thread-Index: Ac0OCbjTQNEqFFr7Q3Grshprx4SNTw== Message-ID: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E442MBX01cira1c_" MIME-Version: 1.0 X-VAMS: NONE Subject: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 01:49:01 -0000 --_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E442MBX01cira1c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CIRA is considering the implementation of administrative bundling for the r= elease of French character IDNs in the registry. Under the proposed policy= , each IDN domain would be independent from a registration and DNS manageme= nt perspective. However, all domains that share the same canonical form as= defined by our policy (caf=E9.ca, cafe.ca, =E7afe.ca ...) would have to be= registered by the same registrar and to the same registrant contact id. We have started discussing the registry implementation, and one of the bigg= est challenges comes with registrar transfers or the updating a domain's re= gistrant contact id. Under our proposed policy we have to find a way to en= sure that all registered variants maintain the same registrar and registran= t contact. The most promising implementation proposal is to queue the update and trans= fer requests until a request has been submitted for all variants in a bundl= e. While we wait for all actions, would apply "pendingTransfer" and "pendi= ngUpdate" statuses as described in sections 2.3 and 3.3 of RFC 5731. 1 - Does anyone know of a similar domain bundling policy so that we could l= ook at its implementation? Or might there be an RFC that would define some= thing similar? 2 - Does anyone on this list have experience for using offline review of re= quested actions other than transfer? Is there anything we should be carefu= l about in picking this implementation? 3 - With domain transfer, there is a defined way of cancelling a pending tr= ansfer (as per section 2.9.3.4 of RFC 5730), but for a pending domain updat= e, there is no defined way to cancel a pending operation. Any suggestions = out there. Ben --_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E442MBX01cira1c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

CIRA is consider= ing the implementation of administrative bundling for the release of French= character IDNs in the registry.=A0 Under the proposed policy, each IDN dom= ain would be independent from a registration and DNS management perspective= .=A0 However, all domains that share the same canonical form as defined by = our policy (caf=E9.ca, cafe.ca, =E7afe.ca …) would have to be registe= red by the same registrar and to the same registrant contact id.=

 

We have = started discussing the registry implementation, and one of the biggest chal= lenges comes with registrar transfers or the updating a domain’s regi= strant contact id.=A0 Under our proposed policy we have to find a way to en= sure that all registered variants maintain the same registrar and registran= t contact.

 

The most promising implementation proposal is to queue the upd= ate and transfer requests until a request has been submitted for all varian= ts in a bundle.=A0 While we wait for all actions, would apply “pendin= gTransfer” and “pendingUpdate” statuses as described in s= ections 2.3 and 3.3 of RFC 5731.

&n= bsp;

1 – Does anyone know of a similar = domain bundling policy so that we could look at its implementation?=A0 Or m= ight there be an RFC that would define something similar?

 

2 – Does = anyone on this list have experience for using offline review of requested a= ctions other than transfer?=A0 Is there anything we should be careful about= in picking this implementation?

&n= bsp;

3 – With domain transfer, there is= a defined way of cancelling a pending transfer (as per section 2.9.3.4 of = RFC 5730), but for a pending domain update, there is no defined way to canc= el a pending operation.=A0 Any suggestions out there.

 

Ben=

= --_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E442MBX01cira1c_-- From fobispo@isc.org Thu Mar 29 19:06:21 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33FA21F85D0 for ; Thu, 29 Mar 2012 19:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjWvLzSEuch5 for ; Thu, 29 Mar 2012 19:06:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 4711C21E801C for ; Thu, 29 Mar 2012 19:06:17 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4E3975F98B9; Fri, 30 Mar 2012 02:05:59 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:c96a:687f:e95e:435e] (unknown [IPv6:2001:4f8:3:64:c96a:687f:e95e:435e]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C635C216C33; Fri, 30 Mar 2012 02:05:57 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Francisco Obispo In-Reply-To: Date: Thu, 29 Mar 2012 19:05:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36C74236-4949-4E97-AC58-AB4980A0BEC8@isc.org> References: To: Benoit Levac X-Mailer: Apple Mail (2.1257) Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 02:06:21 -0000 On Mar 29, 2012, at 6:46 PM, Benoit Levac wrote: > 1 =96 Does anyone know of a similar domain bundling policy so that we = could look at its implementation? Or might there be an RFC that would = define something similar? > =20 > 2 =96 Does anyone on this list have experience for using offline = review of requested actions other than transfer? Is there anything we = should be careful about in picking this implementation? >=20 > =20 you could treat them as a bundle, so if you get a transfer or registrant = update request, you will always apply the change to the whole set=85 It = would be useful for you to have some sort of messaging mechanism to let = the registrar know that the change/action has been applied to all, this = could be done via an EPP message, or via some custom extension. I think the most difficult part of this implementation, is to define = upfront how to do the bundling=85 that is, how do you know that those = names (caf=E9.ca, cafe.ca, =E7afe.ca =85) are to be treated as a bundle? > =20 > 3 =96 With domain transfer, there is a defined way of cancelling a = pending transfer (as per section 2.9.3.4 of RFC 5730), but for a pending = domain update, there is no defined way to cancel a pending operation. = Any suggestions out there. If you are just waiting for the registrar to send the same command over = and over again until it completes the names in the bundle, why don't you = process it upfront with the first one? In any case, it seems like if you don't do the bundle treatment, you = will have to code your own extension to manage it. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From paf@frobbit.se Thu Mar 29 19:12:32 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B7B21F85E1 for ; Thu, 29 Mar 2012 19:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixZbdfkbdiKl for ; Thu, 29 Mar 2012 19:12:31 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id E15ED21F85DD for ; Thu, 29 Mar 2012 19:12:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 09A901374B40D; Fri, 30 Mar 2012 04:12:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdpuOD54KNFK; Fri, 30 Mar 2012 04:12:28 +0200 (CEST) Received: from [192.168.1.53] (frobbit.cust.teleservice.net [85.30.128.225]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id CAEC01374B406; Fri, 30 Mar 2012 04:12:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <36C74236-4949-4E97-AC58-AB4980A0BEC8@isc.org> Date: Fri, 30 Mar 2012 04:12:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36C74236-4949-4E97-AC58-AB4980A0BEC8@isc.org> To: Francisco Obispo X-Mailer: Apple Mail (2.1257) Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 02:12:32 -0000 On 30 mar 2012, at 04:05, Francisco Obispo wrote: > If you are just waiting for the registrar to send the same command = over and over again until it completes the names in the bundle, why = don't you process it upfront with the first one? The main difference between the two models is whether the registry = should do changes that are to be reflected in the registrar database, or = whether the registrar should do all commands. I am personally as a registrar in favor of the latter. That the registry = should really minimize the number of changes made that have to be = reflected in the registrar database. And because of that it is better if = the status is "pending" until the registrar have made changes to all = objects involved. Is there an alternative when some domain names in the bundle is not = registered? Not delegated? Requirements on same delegation of all of = them? I.e. I think we have a generic issue related to bundles to = discuss. Similar problems happens when both the holder and the registrar changes = for a domain name in the bundle btw. How do you handle the contact = object when changes happens to the domain object? But, just like Francisco I also ask what mechanism is to be used to = ensure the registrant and registrar (and everyone else) know what domain = names are in the bundle? Orthogonal question, but also important. Patrik From xiejiagui@cnnic.cn Thu Mar 29 19:17:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A92121F8518 for ; Thu, 29 Mar 2012 19:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQkbB0lVShIy for ; Thu, 29 Mar 2012 19:17:17 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6E73221E801C for ; Thu, 29 Mar 2012 19:17:15 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: xiejiagui@cnnic.cn Received: from unknown218.241.111.81 (HELO [218.241.111.81]) (218.241.111.81) by 159.226.7.146 with SMTP; Fri, 30 Mar 2012 10:17:13 +0800 From: Kevin Tes To: Benoit Levac In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1ngq3NEoNR8y333oVKRN" Organization: CNNIC Date: Fri, 30 Mar 2012 10:17:11 +0800 Message-ID: <1333073831.1585.43.camel@zenus> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiejiagui@cnnic.cn List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 02:17:18 -0000 --=-1ngq3NEoNR8y333oVKRN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I do think this draft "http://tools.ietf.org/html/draft-kong-epp-idn-variants-mapping-00" may help you a lot. In this draft,it let the registrant to create 'bundle' members in epp command and let the registrant 'add' or 'rem' bundle members in command.All the members in this bundle share the same informations. Renew and Transfer ,Delete command are all to this bundle. On Thu, 2012-03-29 at 21:46 -0400, Benoit Levac wrote: > CIRA is considering the implementation of administrative bundling for > the release of French character IDNs in the registry. Under the > proposed policy, each IDN domain would be independent from a > registration and DNS management perspective. However, all domains > that share the same canonical form as defined by our policy (caf=C3=A9.ca= , > cafe.ca, =C3=A7afe.ca =E2=80=A6) would have to be registered by the same = registrar > and to the same registrant contact id. >=20 > =20 >=20 > We have started discussing the registry implementation, and one of the > biggest challenges comes with registrar transfers or the updating a > domain=E2=80=99s registrant contact id. Under our proposed policy we hav= e to > find a way to ensure that all registered variants maintain the same > registrar and registrant contact. >=20 > =20 >=20 > The most promising implementation proposal is to queue the update and > transfer requests until a request has been submitted for all variants > in a bundle. While we wait for all actions, would apply > =E2=80=9CpendingTransfer=E2=80=9D and =E2=80=9CpendingUpdate=E2=80=9D sta= tuses as described in > sections 2.3 and 3.3 of RFC 5731. >=20 > =20 >=20 > 1 =E2=80=93 Does anyone know of a similar domain bundling policy so that = we > could look at its implementation? Or might there be an RFC that would > define something similar? >=20 > =20 >=20 > 2 =E2=80=93 Does anyone on this list have experience for using offline re= view > of requested actions other than transfer? Is there anything we should > be careful about in picking this implementation? >=20 > =20 >=20 > 3 =E2=80=93 With domain transfer, there is a defined way of cancelling a > pending transfer (as per section 2.9.3.4 of RFC 5730), but for a > pending domain update, there is no defined way to cancel a pending > operation. Any suggestions out there. >=20 > =20 >=20 > Ben >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --=-1ngq3NEoNR8y333oVKRN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAAECAAYFAk91F6cACgkQatMoyEN1mK+BpQP+M+5cslKzInKwK0W99nCUz9bg JbLTpy8YJhegqKNKRcpvHnxjazuVKNwBGuuaUzH9eWI3NtGPPcL8vPze4x2vL7Xi NRmlw8jbZ+ZSp6wk8JKS8/j6O82MedbjOU2TUuN09YoAiUBwfP4czhNdpcCKbXvn 4JrzOiK04QMwX8LODOQ= =wvaR -----END PGP SIGNATURE----- --=-1ngq3NEoNR8y333oVKRN-- From benoit.levac@cira.ca Thu Mar 29 19:44:57 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E9E21E8093 for ; Thu, 29 Mar 2012 19:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU76c8qG09Uw for ; Thu, 29 Mar 2012 19:44:56 -0700 (PDT) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4A12321E8092 for ; Thu, 29 Mar 2012 19:44:56 -0700 (PDT) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 5E35F13FB01; Thu, 29 Mar 2012 22:44:50 -0400 (EDT) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id 4A0E413FB01; Thu, 29 Mar 2012 22:44:50 -0400 (EDT) Received: from MBX01.cira1.cira.ca ([10.2.16.29]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Thu, 29 Mar 2012 22:45:28 -0400 From: Benoit Levac To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Francisco Obispo Date: Thu, 29 Mar 2012 22:42:35 -0400 Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0OGp6jHN8rnHRoRnydD3TQMr9nwAAAVUrg Message-ID: References: <36C74236-4949-4E97-AC58-AB4980A0BEC8@isc.org> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VAMS: NONE Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 02:44:57 -0000 Patrik, Francisco, Thank you for your comments. I've added comments inline below. Ben -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@frobbit.se]=20 Sent: March-29-12 10:12 PM To: Francisco Obispo Cc: Benoit Levac; provreg@ietf.org Subject: Re: [provreg] IDN administrative bundling On 30 mar 2012, at 04:05, Francisco Obispo wrote: >> If you are just waiting for the registrar to send the same command over = and over again until it completes the names in the bundle, why don't you pr= ocess it upfront with the first one? > The main difference between the two models is whether the registry should= do changes that are to be reflected in the registrar database, or whether = the registrar should do all commands. > I am personally as a registrar in favor of the latter. That the registry = should really minimize the number of changes made that have to be reflected= in the registrar database. And because of that it is better if the status = is "pending" until the registrar have made changes to all objects involved. Actually that is exactly the reason why we are leaning towards using "pendi= ng" statuses as opposed to automatically applying the actions to all varian= ts. For example, a registrar which has not prepared their systems for thes= e changes could end up transferring multiple domains after submitting a sin= gle transfer for a single domain. It also means that they would be charged= for all of these domains (one request could cause a charge for multiple tr= ansfers). > Is there an alternative when some domain names in the bundle is not regis= tered? Not delegated? Requirements on same delegation of all of them? I.e. = I think we have a generic issue related to bundles to discuss. Under our currently proposed administrative bundling, each domain object is= managed independently. So there is no requirement on delegation. > Similar problems happens when both the holder and the registrar changes f= or a domain name in the bundle btw. How do you handle the contact object wh= en changes happens to the domain object? In our current system, when domains are transferred, we create a clone of t= he contact objects sponsored by the gaining registrar and assign them to th= e domain. Because all of the variants would have the same contact at the l= oosing registrar, we would assign a clone of that contact to all the varian= ts when the transfer takes place (which would happen to all the variants at= the same time). > But, just like Francisco I also ask what mechanism is to be used to ensur= e the registrant and registrar (and everyone else) know what domain names a= re in the bundle? Orthogonal question, but also important. We are just starting to define our implementation, but the current proposal= is that the info command could return a list of allocated variants as part= of an extension. This would only be returned to the sponsoring registrar,= or a non-sponsoring registrar with the auth-code. > Patrik From wil@cloudregistry.net Thu Mar 29 19:46:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E10221E8092 for ; Thu, 29 Mar 2012 19:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBDhhGZSL7Mc for ; Thu, 29 Mar 2012 19:46:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62C7521E8044 for ; Thu, 29 Mar 2012 19:46:34 -0700 (PDT) Received: by iazz13 with SMTP id z13so334854iaz.31 for ; Thu, 29 Mar 2012 19:46:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-gm-message-state:content-type; bh=6UduIQ6m5G5ZSbrxjgdOijUh7vAD8J9OjHYSaCc/GkI=; b=OVjGoMDAbwdUhnk3F3LeXvLXoZtluV1h6Sbvr2rcFCOqhADODuR2VKZeNHTrSgdOpp g7e/uaiU8mAg7yemfPvoeeuanidJ75hsKU3sLmyvuIQ9TZ+Ip+9KDemTNDEAohyLGY3z UBxedcqaytjcxYdK8SBxwtbFN/t0dCTSt7M5wOvagPlkNBeYb6s6bQ9bnHYwPf6bU0lV gtxC15vuiTJRwNNwA/9hOoE+rteUQVTJ8F+iv4dc60QrV7v/Y5NTt5+y1K6KgkbVhyWp 2FX88+uXSvzHH8LJXirGHRrCGe1arhlFzHj3ZljUGZ/VYmXAZ2LY/v6q1lcI0TPtXIo4 xhlw== Received: by 10.50.153.163 with SMTP id vh3mr202519igb.43.1333075593982; Thu, 29 Mar 2012 19:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.100.197 with HTTP; Thu, 29 Mar 2012 19:45:53 -0700 (PDT) In-Reply-To: <36C74236-4949-4E97-AC58-AB4980A0BEC8@isc.org> References: <36C74236-4949-4E97-AC58-AB4980A0BEC8@isc.org> From: Wil Tan Date: Fri, 30 Mar 2012 13:45:53 +1100 Message-ID: To: Francisco Obispo X-Gm-Message-State: ALoCoQkIpRIz39cxphuFkkuoKf/84WPBL6r8omwrKcFYtqTwADo2FvkCgPPFIPNXkOZUfyChDBUM Content-Type: multipart/alternative; boundary=e89a8f2347f53cf24804bc6cd9fb Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 02:46:35 -0000 --e89a8f2347f53cf24804bc6cd9fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2012 at 1:17 PM, Kevin Tes wrote: > In this draft,it let the registrant to create 'bundle' members in epp > and On Fri, Mar 30, 2012 at 1:05 PM, Francisco Obispo wrote: > you could treat them as a bundle, so if you get a transfer or registrant > update request, you will always apply the change to the whole set=E2=80= =A6 > According to Ben, keeping the domains "independent from a registration and DNS management perspective" is an explicit requirement. In that case, bundling (in the RFC4290 / RFC3743 sense) wouldn't help. If it was just a sunrise/grandfathering process as with AFNIC's upcoming launch of French IDNs, you could accept domain creation requests during the process window and handle it in batch mode. Then again, AFNIC's implementation does not seem to require the same registrant or registrar of record once the domains are created. In any case, it seems like if you don't do the bundle treatment, you will > have to code your own extension to manage it. Yes, an extension to force the registrar to realise that there are other domains in the administrative bundle, and send those along in create, update and transfer requests. Once the registry verifies that the bundle members are correct, it can effect the change on all of them. .wil --e89a8f2347f53cf24804bc6cd9fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 30, 2012 at 1:17 PM, Kevin Tes=C2=A0<<= a href=3D"mailto:xiejiagui@cnnic.cn">xiejiagui@cnnic.cn>=C2= =A0wrote:
In this draft,it let the registrant to create 'bundle' members in e= pp

and

On Fri, Mar 30, 2012 at 1:05 PM, Francisco Obispo <fobispo@isc.org> wrote:
you could treat them as a = bundle, so if you get a transfer or registrant update request, you will alw= ays apply the change to the whole set=E2=80=A6

According to Ben,=C2=A0keeping the domains "independent from a registration and DNS management perspectiv= e" is an explicit requirement. In that case, bundli= ng (in the RFC4290 / RFC3743 sense) wouldn't help. If it was just a sun= rise/grandfathering process as with AFNIC's upcoming launch of French I= DNs, you could accept domain creation requests during the process window an= d handle it in batch mode. Then again, AFNIC's implementation does not = seem to require the same registrant or registrar of record once the domains= are created.


In any case, it seems like if you don't do the bundle treat= ment, you will have to code your own extension to manage it.

Yes, an extension to force the registrar to realis= e that there are other domains in the administrative bundle, and send those= along in create, update and transfer requests. Once the registry verifies = that the bundle members are correct, it can effect the change on all of the= m.

.wil
--e89a8f2347f53cf24804bc6cd9fb-- From james.mitchell@ausregistry.com.au Thu Mar 29 22:37:52 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B47621F86C6 for ; Thu, 29 Mar 2012 22:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9pfnFDcAez6 for ; Thu, 29 Mar 2012 22:37:51 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id D262721F86C1 for ; Thu, 29 Mar 2012 22:37:37 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 30 Mar 2012 16:37:35 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Fri, 30 Mar 2012 16:37:20 +1100 From: James Mitchell To: Benoit Levac , "provreg@ietf.org" Date: Fri, 30 Mar 2012 16:37:31 +1100 Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0ONyxhrXO+07dsR4GG93mzNRNAUw== Message-ID: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_CB9B8F1E1BDCFjamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 05:37:52 -0000 --_000_CB9B8F1E1BDCFjamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why treat each variant as a separate domain object that "can" be managed in= dependently when they actually can't? What if you promote the bundle to be a first class object having a canonica= l form, registrant contact, sponsoring registrar etc and have the domain na= mes as attributes of that object. The domain names can be used as keys into= the bundle when mapped onto interfaces such as EPP and WHOIS. You do get i= nto a bit of an ugly however as update domain1 change registrant also chang= es domain2..n, however you could restrict updates to only the primary regis= tered domain name pushing variant names into the background. On the other hand you have to deal with pendingUpdate, registrars failing t= o submit updates for all domains, registrars sending incompatible updates e= tc. James From: Benoit Levac > Date: Fri, 30 Mar 2012 12:46:41 +1100 To: "provreg@ietf.org" > Subject: [provreg] IDN administrative bundling CIRA is considering the implementation of administrative bundling for the r= elease of French character IDNs in the registry. Under the proposed policy= , each IDN domain would be independent from a registration and DNS manageme= nt perspective. However, all domains that share the same canonical form as= defined by our policy (caf=E9.ca, cafe.ca, =E7afe.ca =85) would have to be= registered by the same registrar and to the same registrant contact id. We have started discussing the registry implementation, and one of the bigg= est challenges comes with registrar transfers or the updating a domain=92s = registrant contact id. Under our proposed policy we have to find a way to = ensure that all registered variants maintain the same registrar and registr= ant contact. The most promising implementation proposal is to queue the update and trans= fer requests until a request has been submitted for all variants in a bundl= e. While we wait for all actions, would apply =93pendingTransfer=94 and = =93pendingUpdate=94 statuses as described in sections 2.3 and 3.3 of RFC 57= 31. 1 =96 Does anyone know of a similar domain bundling policy so that we could= look at its implementation? Or might there be an RFC that would define so= mething similar? 2 =96 Does anyone on this list have experience for using offline review of = requested actions other than transfer? Is there anything we should be care= ful about in picking this implementation? 3 =96 With domain transfer, there is a defined way of cancelling a pending = transfer (as per section 2.9.3.4 of RFC 5730), but for a pending domain upd= ate, there is no defined way to cancel a pending operation. Any suggestion= s out there. Ben --_000_CB9B8F1E1BDCFjamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Why treat each variant as a sep= arate domain object that "can" be managed independently when they= actually can't?

What if you promote the bundle to= be a first class object having a canonical form, registrant contact, spons= oring registrar etc and have the domain names as attributes of that object.= The domain names can be used as keys into the bundle when mapped onto inte= rfaces such as EPP and WHOIS. You do get into a bit of an ugly however= as update domain1 change registrant also changes domain2..n, however you c= ould restrict updates to only the primary registered domain name pushing va= riant names into the background.

On the other hand= you have to deal with pendingUpdate, registrars failing to submit updates = for all domains, registrars sending incompatible updates etc.
James

From: Benoit Levac <ben= oit.levac@cira.ca>
Date: = Fri, 30 Mar 2012 12:46:41 +1100
To= : "provreg@ietf.org&qu= ot; <provreg@ietf.org>
Subject: [provreg] IDN administrative= bundling

CIRA is cons= idering the implementation of administrative bundling for the release of Fr= ench character IDNs in the registry.  Under the proposed policy, each = IDN domain would be independent from a registration and DNS management pers= pective.  However, all domains that share the same canonical form as d= efined by our policy (caf=E9.ca, cafe.ca, =E7afe.ca =85) would have to be r= egistered by the same registrar and to the same registrant contact id.=

 

We have started discussing the registry implementation, and one of the bi= ggest challenges comes with registrar transfers or the updating a domain=92= s registrant contact id.  Under our proposed policy we have to find a = way to ensure that all registered variants maintain the same registrar and = registrant contact.

 <= /p>

The most promising implementation proposal is to = queue the update and transfer requests until a request has been submitted f= or all variants in a bundle.  While we wait for all actions, would app= ly =93pendingTransfer=94 and =93pendingUpdate=94 statuses as described in s= ections 2.3 and 3.3 of RFC 5731.

=  

1 =96 Does anyone know of a similar = domain bundling policy so that we could look at its implementation?  O= r might there be an RFC that would define something similar?

=

 

2 =96 Do= es anyone on this list have experience for using offline review of requeste= d actions other than transfer?  Is there anything we should be careful= about in picking this implementation?

 

3 =96 With domain transfer, th= ere is a defined way of cancelling a pending transfer (as per section 2.9.3= .4 of RFC 5730), but for a pending domain update, there is no defined way t= o cancel a pending operation.  Any suggestions out there.

 

Ben

--_000_CB9B8F1E1BDCFjamesmitchellausregistrycomau_-- From ajs@anvilwalrusden.com Thu Mar 29 22:49:16 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96A521F86D1 for ; Thu, 29 Mar 2012 22:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOlj+b-gOhmq for ; Thu, 29 Mar 2012 22:49:16 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3118621F8577 for ; Thu, 29 Mar 2012 22:49:16 -0700 (PDT) Received: from mail.yitter.info (unknown [83.145.64.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7960E1ECB41C for ; Fri, 30 Mar 2012 05:49:15 +0000 (UTC) Date: Fri, 30 Mar 2012 01:49:11 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120330054911.GC21389@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 05:49:16 -0000 On Fri, Mar 30, 2012 at 04:37:31PM +1100, James Mitchell wrote: > Why treat each variant as a separate domain object that "can" be managed independently when they actually can't? > I can see one reason: no requirement of a completely new EPP object type. This isn't nothing. Also, EPP already has to support registry policies that place restrictions on what you can do to a name even though the restriction isn't reflected anywhere in the registry; we call this "registry policy" usually. For instance, some names require a "presence" requirement be fulfilled. The presence precondition is satisfied by the address value in the primary contact associated with the domain. You can tell, if you look, whether a given contact object will satisfy a given presence precondition, but there's no way to tell just by looking at a name whether some contact or other will fulfill its presence preconditions. (Nevertheless, there is something that feels unnatural under EPP about linking different objects together this way, however loosely.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From mcanix@gmail.com Fri Mar 30 00:13:20 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C489D21E8056 for ; Fri, 30 Mar 2012 00:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WLqBxGP10DD for ; Fri, 30 Mar 2012 00:13:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB53E21E8049 for ; Fri, 30 Mar 2012 00:13:16 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so227280wib.13 for ; Fri, 30 Mar 2012 00:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=kBa02wHGH6g1sGreV+Bxul+Re1XybDA1+4vBO3yXnks=; b=yrRpHSufh5e6+7IJmNNz7yZllzOFxtW66zdvCpKEwu7Qh+kyonTdkm1CkU1FCwY+OU zisHYsQx7cE0NoLh5+Ctot5CWRQWimejb4ApnyFd+PAiLSUOasM0gkjM3s8EWQfcPs4H nrBQf3Zg+olacmelEXz+zrSWIeSfnveLAWpYofA9USAo7F2VZVElAtxZ3fFKbnpY+mMU ZkYVn9OUQQh1d8kvpj2WfdjkMN7YDv4MNTcJf68xzc9rNYuT5GrupASylDumza2Tcc0h AaLO3jUoR+v3C8ZaNWBM5AFMnjL+L6Pu+BDH1AAQYQTBpC8uH0pWcW4GmU6GvQpxzQBC jeug== Received: by 10.180.73.143 with SMTP id l15mr3501562wiv.11.1333091595915; Fri, 30 Mar 2012 00:13:15 -0700 (PDT) Received: from [41.23.6.80] ([41.23.6.80]) by mx.google.com with ESMTPS id gg2sm6643144wib.7.2012.03.30.00.13.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 00:13:14 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-25CD5D4A-B85D-421C-A5CA-587182822E3F Message-Id: <905F713F-2A65-4863-A602-2211474915A1@gmail.com> X-Mailer: iPhone Mail (9B176) From: mike Date: Fri, 30 Mar 2012 09:11:52 +0200 To: Benoit Levac Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:13:20 -0000 --Apple-Mail-25CD5D4A-B85D-421C-A5CA-587182822E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, > 3 =E2=80=93 With domain transfer, there is a defined way of cancelling a p= ending transfer (as per section 2.9.3.4 of RFC 5730), but for a pending doma= in update, there is no defined way to cancel a pending operation. Any sugge= stions out there. >=20 We have a draft extension for cancelling pending actions on the registry, th= is allows the registrar to cancel a suspension, deletion, update, or deletio= n due to expiry by the action name. This creates some pretty complex policy h= andling esp. when expiry was due to non payment and cancelling that action r= esults in billing. If you want a copy we can submit it for draft review. Kind Regards, Mike co.za= --Apple-Mail-25CD5D4A-B85D-421C-A5CA-587182822E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Ben,

3 =E2= =80=93 With domain transfer, there is a defined way of cancelling a pending t= ransfer (as per section 2.9.3.4 of RFC 5730), but for a pending domain updat= e, there is no defined way to cancel a pending operation.  Any suggesti= ons out there.

We have a draft extension fo= r cancelling pending actions on the registry, this allows the registrar to c= ancel a suspension, deletion, update, or deletion due to expiry by the actio= n name. This creates some pretty complex policy handling esp. when expiry wa= s due to non payment and cancelling that action results in billing. If you w= ant a copy we can submit it for draft review.

Kind R= egards,

Mike

co.za
= --Apple-Mail-25CD5D4A-B85D-421C-A5CA-587182822E3F-- From james.mitchell@ausregistry.com.au Fri Mar 30 00:46:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6C621F87B8 for ; Fri, 30 Mar 2012 00:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKsZ0xVdcYa9 for ; Fri, 30 Mar 2012 00:46:01 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8298321F87B7 for ; Fri, 30 Mar 2012 00:46:00 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 30 Mar 2012 18:45:57 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Fri, 30 Mar 2012 18:45:41 +1100 From: James Mitchell To: Andrew Sullivan , "provreg@ietf.org" Date: Fri, 30 Mar 2012 18:45:54 +1100 Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0OSRqePzCZEVAeS+yoZ7kVt3YwFA== Message-ID: In-Reply-To: <20120330054911.GC21389@mail.yitter.info> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:46:01 -0000 One could implement variant domain names as attributes of the primary domain name achieved through the use of object extensions preserving the domain object mapping. Underneath the registry object can still be a bundle having a canonical form, primary domain name, registrant contact etc and a list of (activated) variant domain names. Treating all names as individual yet linked domain names does not make much sense for both registry and registrar if the variant model is "you can have this variant on the condition that it is identical to the primary name". James On 30/03/12 4:49 PM, "Andrew Sullivan" wrote: >On Fri, Mar 30, 2012 at 04:37:31PM +1100, James Mitchell wrote: >> Why treat each variant as a separate domain object that "can" be >>managed independently when they actually can't? >>=20 > >I can see one reason: no requirement of a completely new EPP object >type. This isn't nothing. > >Also, EPP already has to support registry policies that place >restrictions on what you can do to a name even though the restriction >isn't reflected anywhere in the registry; we call this "registry >policy" usually. For instance, some names require a "presence" >requirement be fulfilled. The presence precondition is satisfied by >the address value in the primary contact associated with the domain. >You can tell, if you look, whether a given contact object will satisfy >a given presence precondition, but there's no way to tell just by >looking at a name whether some contact or other will fulfill its >presence preconditions. > >(Nevertheless, there is something that feels unnatural under EPP about >linking different objects together this way, however loosely.) > >Best, > >A > > >--=20 >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From fneves@registro.br Fri Mar 30 01:14:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802DF21F86D4 for ; Fri, 30 Mar 2012 01:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHN+G6-zchge for ; Fri, 30 Mar 2012 01:14:15 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE4321F86DC for ; Fri, 30 Mar 2012 01:14:12 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id B227CE0513; Fri, 30 Mar 2012 05:14:11 -0300 (BRT) Date: Fri, 30 Mar 2012 05:14:11 -0300 From: Frederico A C Neves To: "provreg@ietf.org" Message-ID: <20120330081411.GA57619@registro.br> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:14:17 -0000 Benoit, On Thu, Mar 29, 2012 at 09:46:41PM -0400, Benoit Levac wrote: > CIRA is considering the implementation of administrative bundling for the release of French character IDNs in the registry. Under the proposed policy, each IDN domain would be independent from a registration and DNS management perspective. However, all domains that share the same canonical form as defined by our policy (café.ca, cafe.ca, çafe.ca ...) would have to be registered by the same registrar and to the same registrant contact id. > > We have started discussing the registry implementation, and one of the biggest challenges comes with registrar transfers or the updating a domain's registrant contact id. Under our proposed policy we have to find a way to ensure that all registered variants maintain the same registrar and registrant contact. > > The most promising implementation proposal is to queue the update and transfer requests until a request has been submitted for all variants in a bundle. While we wait for all actions, would apply "pendingTransfer" and "pendingUpdate" statuses as described in sections 2.3 and 3.3 of RFC 5731. > > 1 - Does anyone know of a similar domain bundling policy so that we could look at its implementation? Or might there be an RFC that would define something similar? > This is almost exactly what we do for IDN registrations in .br since 2005 [1], but we do the "equivalence check" only at registration time leveraging the fact that .br require a unique public organization identifier. After initial registration the maintenance of the "holdership" of the domain is up to the registrant as long as the domain name is not canceled. ... > Ben Fred [1] http://registro.br/anuncios/20050504.html (3rd paragraph portuguese only) From ajs@anvilwalrusden.com Fri Mar 30 02:25:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EDC21F8842 for ; Fri, 30 Mar 2012 02:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWp6pYU6urBL for ; Fri, 30 Mar 2012 02:25:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4552621F883E for ; Fri, 30 Mar 2012 02:25:18 -0700 (PDT) Received: from mail.yitter.info (dhcp-21ac.meeting.ietf.org [130.129.33.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B5FA51ECB41C for ; Fri, 30 Mar 2012 09:25:07 +0000 (UTC) Date: Fri, 30 Mar 2012 05:24:57 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120330092448.GA21703@mail.yitter.info> References: <20120330054911.GC21389@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:25:19 -0000 On Fri, Mar 30, 2012 at 06:45:54PM +1100, James Mitchell wrote: > Treating all names as individual yet linked domain names does not make > much sense for both registry and registrar if the variant model is "you > can have this variant on the condition that it is identical to the primary > name". But of course, they're _not_ identical. They're different names, and in Latin they might not even be labels that anyone would ever actually use (at least on purpose without fraudulent intent). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From benoit.levac@cira.ca Fri Mar 30 05:31:36 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF0221F8621 for ; Fri, 30 Mar 2012 05:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAJlg12MC1+4 for ; Fri, 30 Mar 2012 05:31:36 -0700 (PDT) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id E30A321F864D for ; Fri, 30 Mar 2012 05:31:35 -0700 (PDT) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 4432A13FB01; Fri, 30 Mar 2012 08:31:31 -0400 (EDT) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id 2ECC913FB01; Fri, 30 Mar 2012 08:31:31 -0400 (EDT) Received: from MBX01.cira1.cira.ca ([10.2.16.29]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Fri, 30 Mar 2012 08:32:09 -0400 From: Benoit Levac To: Andrew Sullivan , "provreg@ietf.org" Date: Fri, 30 Mar 2012 08:29:16 -0400 Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0OVwo2ENccZJnuSC+HSqo65YQyBAAGArPg Message-ID: References: <20120330054911.GC21389@mail.yitter.info> <20120330092448.GA21703@mail.yitter.info> In-Reply-To: <20120330092448.GA21703@mail.yitter.info> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VAMS: NONE Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:31:36 -0000 > One could implement variant domain names as attributes of the primary dom= ain name achieved through the use of object extensions preserving the domai= n object mapping. Underneath the registry object can still be a bundle havi= ng a canonical form, primary domain name, registrant contact etc and a list= of (activated) variant domain names. We did consider the notion of adding an EPP bundle mapping object, but as m= entioned by Andrew, the complexity and effort required for that option was = not negligible. =20 As for variants being attributes of domain object, that would cause an issu= e if we wish to allow registrars to manage DNS on each variant independentl= y. > Treating all names as individual yet linked domain names does not make mu= ch sense for both registry and registrar if the variant model is "you can h= ave this variant on the condition that it is identical to the primary name"= . While I agree conceptually that there is something unnatural about the admi= nistrative link, I do second Andrew's point that this could be viewed as re= gistry policy. I think the important part here is to make sure that regist= rars can get information regarding availability of a variant as well as the= other variants of particular domain in a bundle. Cheers, Ben -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of Andrew Sullivan Sent: March-30-12 5:25 AM To: provreg@ietf.org Subject: Re: [provreg] IDN administrative bundling On Fri, Mar 30, 2012 at 06:45:54PM +1100, James Mitchell wrote: > Treating all names as individual yet linked domain names does not make=20 > much sense for both registry and registrar if the variant model is=20 > "you can have this variant on the condition that it is identical to=20 > the primary name". But of course, they're _not_ identical. They're different names, and in La= tin they might not even be labels that anyone would ever actually use (at l= east on purpose without fraudulent intent). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From benoit.levac@cira.ca Fri Mar 30 05:44:55 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FF521F853A for ; Fri, 30 Mar 2012 05:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A49fn1GiO0Mg for ; Fri, 30 Mar 2012 05:44:54 -0700 (PDT) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4326321F852C for ; Fri, 30 Mar 2012 05:44:54 -0700 (PDT) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 405D513FB01; Fri, 30 Mar 2012 08:44:49 -0400 (EDT) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id 2E80A13FB01; Fri, 30 Mar 2012 08:44:49 -0400 (EDT) Received: from MBX01.cira1.cira.ca ([10.2.16.29]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Fri, 30 Mar 2012 08:45:27 -0400 From: Benoit Levac To: mike Date: Fri, 30 Mar 2012 08:42:35 -0400 Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0ORJ1Zlf4Sa4tqS+aYZsTJRqk8HAALImjw Message-ID: References: <905F713F-2A65-4863-A602-2211474915A1@gmail.com> In-Reply-To: <905F713F-2A65-4863-A602-2211474915A1@gmail.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E4E2MBX01cira1c_" MIME-Version: 1.0 X-VAMS: NONE Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:44:55 -0000 --_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E4E2MBX01cira1c_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCg0KSSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIHJldmlld2luZyB0aGUgZHJhZnQgZm9y IHN1cmUuICBZb3UgY291bGQganVzdCBzZW5kIG1lIGEgY29weSBpZiBpdOKAmXMgbm90IHF1aXRl IHJlYWR5IGZvciBwdWJsaWMgcmV2aWV3Lg0KDQpUaGUgRVBQIFJGQ3Mgb25seSBkZWZpbmUgdGhl IG9mZmxpbmUgcHJvY2Vzc2luZyBhdCBhIGhpZ2ggbGV2ZWwuICBUaGVyZSBhcmUgc29tZSBhc3Bl Y3RzIHRoYXQgYXJlIG5vdCBjb3ZlcmVkIHRoYXQgYnJpbmcgdXAgc29tZSBxdWVzdGlvbnMuICBZ b3UgbWlnaHQgaGF2ZSBleHBlcmllbmNlIHdpdGggdGhlc2Ugc2luY2UgeW91IHNlZW0gdG8gaGF2 ZSBpbXBsZW1lbnRlZCB0aGlzLg0KDQpEb2VzIGEgcGVuZGluZyBzdGF0dXMgc3VjaCBhcyDigJxw ZW5kaW5nVXBkYXRl4oCdIGltcGx5IOKAnHNlcnZlclVwZGF0ZVByb2hpYml0ZWTigJ0/ICBSRkMg NTczMSBvbmx5IG1lbnRpb25zIHRoYXQgdGhleSBjYW5ub3QgYmUgY29tYmluZWQuICBUaGUgaXNz dWUgd2UgaGF2ZSB0byB0aGluayBhYm91dCBpcyB0aGF0IGlmIGEgZG9tYWluIGlzIGluIOKAnHBl bmRpbmdVcGRhdGXigJ0gc3RhdHVzIGJlY2F1c2UgYSByZWdpc3RyYW50IHVwZGF0ZSBhY3Rpb24g aXMgaW4gcHJvZ3Jlc3MsIHdlIHdvdWxkbuKAmXQgd2FudCB0byBwcmV2ZW50IGhvc3QgdXBkYXRl cyBmb3IgZXhhbXBsZSBpZiB0aGV5IGFyZSByZXF1aXJlZC4gIFRoaXMgaXMgbWFpbmx5IHdoeSB3 ZSBhcmUgYXNraW5nIGFib3V0IGEgc3RhbmRhcmQgbWVhbnMgdG8gY2FuY2VsIGEgcGVuZGluZyBh Y3Rpb25zLg0KDQpDaGVlcnMsDQoNCkJlbg0KDQpGcm9tOiBtaWtlIFttYWlsdG86bWNhbml4QGdt YWlsLmNvbV0NClNlbnQ6IE1hcmNoLTMwLTEyIDM6MTIgQU0NClRvOiBCZW5vaXQgTGV2YWMNCkNj OiBwcm92cmVnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Byb3ZyZWddIElETiBhZG1pbmlzdHJh dGl2ZSBidW5kbGluZw0KDQpIaSBCZW4sDQozIOKAkyBXaXRoIGRvbWFpbiB0cmFuc2ZlciwgdGhl cmUgaXMgYSBkZWZpbmVkIHdheSBvZiBjYW5jZWxsaW5nIGEgcGVuZGluZyB0cmFuc2ZlciAoYXMg cGVyIHNlY3Rpb24gMi45LjMuNCBvZiBSRkMgNTczMCksIGJ1dCBmb3IgYSBwZW5kaW5nIGRvbWFp biB1cGRhdGUsIHRoZXJlIGlzIG5vIGRlZmluZWQgd2F5IHRvIGNhbmNlbCBhIHBlbmRpbmcgb3Bl cmF0aW9uLiAgQW55IHN1Z2dlc3Rpb25zIG91dCB0aGVyZS4NCldlIGhhdmUgYSBkcmFmdCBleHRl bnNpb24gZm9yIGNhbmNlbGxpbmcgcGVuZGluZyBhY3Rpb25zIG9uIHRoZSByZWdpc3RyeSwgdGhp cyBhbGxvd3MgdGhlIHJlZ2lzdHJhciB0byBjYW5jZWwgYSBzdXNwZW5zaW9uLCBkZWxldGlvbiwg dXBkYXRlLCBvciBkZWxldGlvbiBkdWUgdG8gZXhwaXJ5IGJ5IHRoZSBhY3Rpb24gbmFtZS4gVGhp cyBjcmVhdGVzIHNvbWUgcHJldHR5IGNvbXBsZXggcG9saWN5IGhhbmRsaW5nIGVzcC4gd2hlbiBl eHBpcnkgd2FzIGR1ZSB0byBub24gcGF5bWVudCBhbmQgY2FuY2VsbGluZyB0aGF0IGFjdGlvbiBy ZXN1bHRzIGluIGJpbGxpbmcuIElmIHlvdSB3YW50IGEgY29weSB3ZSBjYW4gc3VibWl0IGl0IGZv ciBkcmFmdCByZXZpZXcuDQoNCktpbmQgUmVnYXJkcywNCg0KTWlrZQ0KDQpjby56YQ0K --_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E4E2MBX01cira1c_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD11dGYtOCI+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9z b2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2Ut MTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY5MjY3ODg5OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0MzM3MzEyNDIgMTcyNzMyOTczNiAyNjkwMjUyODMg MjY5MDI1Mjg1IDI2OTAyNTI4MSAyNjkwMjUyODMgMjY5MDI1Mjg1IDI2OTAyNTI4MSAyNjkwMjUy ODMgMjY5MDI1Mjg1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTk7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRl IGxhbmc9RU4tQ0EgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9u MT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NaWtlLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIHJldmlld2luZyB0aGUgZHJhZnQg Zm9yIHN1cmUuwqAgWW91IGNvdWxkIGp1c3Qgc2VuZCBtZSBhIGNvcHkgaWYgaXTigJlzIG5vdCBx dWl0ZSByZWFkeSBmb3IgcHVibGljIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBFUFAg UkZDcyBvbmx5IGRlZmluZSB0aGUgb2ZmbGluZSBwcm9jZXNzaW5nIGF0IGEgaGlnaCBsZXZlbC7C oCBUaGVyZSBhcmUgc29tZSBhc3BlY3RzIHRoYXQgYXJlIG5vdCBjb3ZlcmVkIHRoYXQgYnJpbmcg dXAgc29tZSBxdWVzdGlvbnMuIMKgWW91IG1pZ2h0IGhhdmUgZXhwZXJpZW5jZSB3aXRoIHRoZXNl IHNpbmNlIHlvdSBzZWVtIHRvIGhhdmUgaW1wbGVtZW50ZWQgdGhpcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkRvZXMgYSBwZW5kaW5nIHN0YXR1cyBzdWNoIGFzIOKAnHBlbmRpbmdVcGRhdGXigJ0gaW1w bHkg4oCcc2VydmVyVXBkYXRlUHJvaGliaXRlZOKAnT/CoCBSRkMgNTczMSBvbmx5IG1lbnRpb25z IHRoYXQgdGhleSBjYW5ub3QgYmUgY29tYmluZWQuwqAgVGhlIGlzc3VlIHdlIGhhdmUgdG8gdGhp bmsgYWJvdXQgaXMgdGhhdCBpZiBhIGRvbWFpbiBpcyBpbiDigJxwZW5kaW5nVXBkYXRl4oCdIHN0 YXR1cyBiZWNhdXNlIGEgcmVnaXN0cmFudCB1cGRhdGUgYWN0aW9uIGlzIGluIHByb2dyZXNzLCB3 ZSB3b3VsZG7igJl0IHdhbnQgdG8gcHJldmVudCBob3N0IHVwZGF0ZXMgZm9yIGV4YW1wbGUgaWYg dGhleSBhcmUgcmVxdWlyZWQuwqAgVGhpcyBpcyBtYWlubHkgd2h5IHdlIGFyZSBhc2tpbmcgYWJv dXQgYSBzdGFuZGFyZCBtZWFucyB0byBjYW5jZWwgYSBwZW5kaW5nIGFjdGlvbnMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5CZW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gbWlrZSBbbWFpbHRvOm1jYW5peEBnbWFpbC5jb21dIDxicj48Yj5TZW50Ojwv Yj4gTWFyY2gtMzAtMTIgMzoxMiBBTTxicj48Yj5Ubzo8L2I+IEJlbm9pdCBMZXZhYzxicj48Yj5D Yzo8L2I+IHByb3ZyZWdAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbcHJvdnJlZ10g SUROIGFkbWluaXN0cmF0aXZlIGJ1bmRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5IaSBCZW4sPG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9 J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjMg4oCTIFdpdGggZG9tYWluIHRyYW5zZmVyLCB0aGVyZSBpcyBhIGRlZmlu ZWQgd2F5IG9mIGNhbmNlbGxpbmcgYSBwZW5kaW5nIHRyYW5zZmVyIChhcyBwZXIgc2VjdGlvbiAy LjkuMy40IG9mIFJGQyA1NzMwKSwgYnV0IGZvciBhIHBlbmRpbmcgZG9tYWluIHVwZGF0ZSwgdGhl cmUgaXMgbm8gZGVmaW5lZCB3YXkgdG8gY2FuY2VsIGEgcGVuZGluZyBvcGVyYXRpb24uJm5ic3A7 IEFueSBzdWdnZXN0aW9ucyBvdXQgdGhlcmUuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldlIGhhdmUgYSBkcmFmdCBleHRlbnNp b24gZm9yIGNhbmNlbGxpbmcgcGVuZGluZyBhY3Rpb25zIG9uIHRoZSByZWdpc3RyeSwgdGhpcyBh bGxvd3MgdGhlIHJlZ2lzdHJhciB0byBjYW5jZWwgYSBzdXNwZW5zaW9uLCBkZWxldGlvbiwgdXBk YXRlLCBvciBkZWxldGlvbiBkdWUgdG8gZXhwaXJ5IGJ5IHRoZSBhY3Rpb24gbmFtZS4gVGhpcyBj cmVhdGVzIHNvbWUgcHJldHR5IGNvbXBsZXggcG9saWN5IGhhbmRsaW5nIGVzcC4gd2hlbiBleHBp cnkgd2FzIGR1ZSB0byBub24gcGF5bWVudCBhbmQgY2FuY2VsbGluZyB0aGF0IGFjdGlvbiByZXN1 bHRzIGluIGJpbGxpbmcuIElmIHlvdSB3YW50IGEgY29weSB3ZSBjYW4gc3VibWl0IGl0IGZvciBk cmFmdCByZXZpZXcuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+S2luZCBS ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk1pa2U8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jby56YTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_CF3C66A5DB184445AE42748BFA64AAA10124D108E4E2MBX01cira1c_-- From lem@isc.org Fri Mar 30 07:21:51 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEF821F86CE for ; Fri, 30 Mar 2012 07:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+TmGoxuwILA for ; Fri, 30 Mar 2012 07:21:51 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 53CCF21F86C6 for ; Fri, 30 Mar 2012 07:21:51 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 970D65F9887; Fri, 30 Mar 2012 14:21:37 +0000 (UTC) (envelope-from lem@isc.org) Received: from g2x.lem (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6776B216C31; Fri, 30 Mar 2012 14:21:35 +0000 (UTC) (envelope-from lem@isc.org) References: <905F713F-2A65-4863-A602-2211474915A1@gmail.com> User-Agent: K-9 Mail for Android In-Reply-To: <905F713F-2A65-4863-A602-2211474915A1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: =?ISO-8859-1?Q?Luis_Mu=F1oz?= Date: Fri, 30 Mar 2012 10:21:18 -0400 To: mike Message-ID: <284095f9-bba2-4a74-9ae5-d5f8c3d8ac77@email.android.com> Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:21:51 -0000 I for one would like to see that extension. Thanks -lem mike wrote: >Hi Ben, >> 3 – With domain transfer, there is a defined way of cancelling a >pending transfer (as per section 2.9.3.4 of RFC 5730), but for a >pending domain update, there is no defined way to cancel a pending >operation. Any suggestions out there. >> >We have a draft extension for cancelling pending actions on the >registry, this allows the registrar to cancel a suspension, deletion, >update, or deletion due to expiry by the action name. This creates some >pretty complex policy handling esp. when expiry was due to non payment >and cancelling that action results in billing. If you want a copy we >can submit it for draft review. > >Kind Regards, > >Mike > >co.za_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From JGould@verisign.com Fri Mar 30 07:24:33 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3668B21F86A2 for ; Fri, 30 Mar 2012 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31I4cdIFutSA for ; Fri, 30 Mar 2012 07:24:32 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0821F869E for ; Fri, 30 Mar 2012 07:24:31 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT3XCHmu18Ax3mOVbOpVHau7MG2/Sb3e/@postini.com; Fri, 30 Mar 2012 07:24:31 PDT 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 q2UEOPGt003897; Fri, 30 Mar 2012 10:24:28 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 10:24:24 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 10:24:24 -0400 From: "Gould, James" To: Andrew Sullivan , "provreg@ietf.org" Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0OCbjTQNEqFFr7Q3Grshprx4SNTwATwGGAAABoT4AABBOHAAADdZSAAAISoQA= Date: Fri, 30 Mar 2012 14:24:24 +0000 Message-ID: In-Reply-To: <20120330092448.GA21703@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2012 14:24:24.0925 (UTC) FILETIME=[CEA6C0D0:01CD0E80] Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:24:33 -0000 I see three different models for supporting the bundling of related objects. The concept of bundling could apply to domain names in a single TLD, domain names across TLD's, and objects of different kinds within or across TLD's. =20 1. Validate sponsorship (registrar and registrant) only on create with no sharing of attributes 1. This was done in .name between different related objects (domain names and email forwarding). 2. Ensure sponsorship (registrar and registrant) is always the same across the related objects. 1. Transform operations that impact the sponsorship would need to apply the sponsorship changes across all of the related objects. This can be done explicitly in an EPP extension or implicitly. I believe that for transfer requests that it must be explicit since the gaining registrar must be aware that an entire set is being transferred. The update could be implicit but probably should be explicit. 2. One additional issue on the transfer request is passing the non-shared auth-info value for each of the related objects to authorize the transfer of each independent but related object. 3. Another option is to use pending actions and have the registrar use multiple transform operation across the related objects. I believe that this is overly complex from an interface perspective. 3. Ensure sponsorship (registrar and registrant) and other attributes is the same (shared) across the related objects. 1. This is the model chosen for IDN variants in http://www.ietf.org/id/draft-kong-epp-idn-variants-mapping-00.txt. All attributes are shared across all of the related IDN domain names, where the original IDN (OIDN) is the primary domain name and the remaining variants are alternative domain names that can be activated and deactivated but with the same attributes of the primary domain name (OIDN). =20 2. I believe that it's best to utilize the RFC 5731 commands to manage both the primary domain name (OIDN) and the alternative domain names (VIDN), where some of the attributes can be shared and some either can be or must not be shared. The case of "must not be" is the DS information of RFC 5910 when using the DS Data Interface. An alternative approach is to use the RFC 5910 Key Data Interface, that can be shared across the related domain names, since the server would generate the DS for each of the related domain names. 3. An EPP extension is still required for informational and validation purposes. 4. As with model #2, the transfer request must be explicitly include a reference to the entire bundle to ensure that the gaining registrar is aware of the transfer of the set instead of an individual domain name. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/30/12 5:24 AM, "Andrew Sullivan" wrote: >On Fri, Mar 30, 2012 at 06:45:54PM +1100, James Mitchell wrote: >> Treating all names as individual yet linked domain names does not make >> much sense for both registry and registrar if the variant model is "you >> can have this variant on the condition that it is identical to the >>primary >> name". > >But of course, they're _not_ identical. They're different names, and >in Latin they might not even be labels that anyone would ever actually >use (at least on purpose without fraudulent intent). > >Best, > >A > > >--=20 >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From ajs@anvilwalrusden.com Fri Mar 30 16:57:21 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2624D21F848F for ; Fri, 30 Mar 2012 16:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PopcGXzrwlRz for ; Fri, 30 Mar 2012 16:57:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9521F849B for ; Fri, 30 Mar 2012 16:57:20 -0700 (PDT) Received: from mail.yitter.info (unknown [83.145.64.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A3AD11ECB41C for ; Fri, 30 Mar 2012 23:57:19 +0000 (UTC) Date: Fri, 30 Mar 2012 19:57:17 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120330235717.GE21776@mail.yitter.info> References: <20120330092448.GA21703@mail.yitter.info> 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.21 (2010-09-15) Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 23:57:21 -0000 On Fri, Mar 30, 2012 at 02:24:24PM +0000, Gould, James wrote: > objects. The concept of bundling could apply to domain names in a single > TLD, domain names across TLD's, and objects of different kinds within or > across TLD's. I don't care what we call them, but I do not see how anyone can claim that "bundling" in the same sense can cross domain (I'm almost tempted to say "zone") boundaries and also be the narrow meaning often intended by the word. Bundling(n) [n for narrow] is a case where, within the same domain, two subordinate labels are somehow treated as basically linked in some way. This is the meaning of bundling (and one of the meanings of "variant") that has most traditionally been seen in the RFCs. The links may be purely administrative, by which we mean that the administrative details of the name are required to be the same; or they may be technically tighter, such as a requirement for mirroring (either via aliasing or administrative fiat of parallel delegation). An example of this case is example.com and éxample.com: these are both names in the same domain (and zone). Bundling(w) [w for wide], which I would prefer to call "domain linking" or something like that, is where two names in different parts of the DNS namespace are somehow treated in ways that link them together. As above, these links may be stronger or weaker, but the key is that they be in different domains. If example.com and example.net are somehow linked together, for instance, it would be a case of this. best, A -- Andrew Sullivan ajs@anvilwalrusden.com From james.mitchell@ausregistry.com.au Fri Mar 30 22:11:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F30F21F86D6 for ; Fri, 30 Mar 2012 22:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo4zx+ooO7yl for ; Fri, 30 Mar 2012 22:11:17 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id EEAB921F86D1 for ; Fri, 30 Mar 2012 22:11:14 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 31 Mar 2012 16:11:12 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Sat, 31 Mar 2012 16:10:57 +1100 From: James Mitchell To: Andrew Sullivan Date: Sat, 31 Mar 2012 16:11:07 +1100 Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0O/Kd39IWDrTr/TFa/gk5v/xfxrw== Message-ID: <1A7A072C-2448-4143-A08F-0AA744DC91D1@ausregistry.com.au> References: <20120330092448.GA21703@mail.yitter.info> <20120330235717.GE21776@mail.yitter.info> In-Reply-To: <20120330235717.GE21776@mail.yitter.info> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 05:11:18 -0000 WW91IGZvcmdldCB3aGVyZSB0aGUgem9uZSBuYW1lIGFsc28gaGFzIHZhcmlhbnQgbmFtZXMgZGVs ZWdhdGVkIGZyb20gaXRzIHBhcmVudCB6b25lLg0KDQpPbiAzMS8wMy8yMDEyLCBhdCAxMDo1NyBB TSwgIkFuZHJldyBTdWxsaXZhbiIgPGFqc0BhbnZpbHdhbHJ1c2Rlbi5jb20+IHdyb3RlOg0KDQo+ IE9uIEZyaSwgTWFyIDMwLCAyMDEyIGF0IDAyOjI0OjI0UE0gKzAwMDAsIEdvdWxkLCBKYW1lcyB3 cm90ZToNCj4gDQo+PiBvYmplY3RzLiAgVGhlIGNvbmNlcHQgb2YgYnVuZGxpbmcgY291bGQgYXBw bHkgdG8gZG9tYWluIG5hbWVzIGluIGEgc2luZ2xlDQo+PiBUTEQsIGRvbWFpbiBuYW1lcyBhY3Jv c3MgVExEJ3MsIGFuZCBvYmplY3RzIG9mIGRpZmZlcmVudCBraW5kcyB3aXRoaW4gb3INCj4+IGFj cm9zcyBUTEQncy4gIA0KPiANCj4gSSBkb24ndCBjYXJlIHdoYXQgd2UgY2FsbCB0aGVtLCBidXQg SSBkbyBub3Qgc2VlIGhvdyBhbnlvbmUgY2FuIGNsYWltDQo+IHRoYXQgImJ1bmRsaW5nIiBpbiB0 aGUgc2FtZSBzZW5zZSBjYW4gY3Jvc3MgZG9tYWluIChJJ20gYWxtb3N0IHRlbXB0ZWQNCj4gdG8g c2F5ICJ6b25lIikgYm91bmRhcmllcyBhbmQgYWxzbyBiZSB0aGUgbmFycm93IG1lYW5pbmcgb2Z0 ZW4NCj4gaW50ZW5kZWQgYnkgdGhlIHdvcmQuDQo+IA0KPiBCdW5kbGluZyhuKSBbbiBmb3IgbmFy cm93XSBpcyBhIGNhc2Ugd2hlcmUsIHdpdGhpbiB0aGUgc2FtZSBkb21haW4sDQo+IHR3byBzdWJv cmRpbmF0ZSBsYWJlbHMgYXJlIHNvbWVob3cgdHJlYXRlZCBhcyBiYXNpY2FsbHkgbGlua2VkIGlu IHNvbWUNCj4gd2F5LiAgVGhpcyBpcyB0aGUgbWVhbmluZyBvZiBidW5kbGluZyAoYW5kIG9uZSBv ZiB0aGUgbWVhbmluZ3Mgb2YNCj4gInZhcmlhbnQiKSB0aGF0IGhhcyBtb3N0IHRyYWRpdGlvbmFs bHkgYmVlbiBzZWVuIGluIHRoZSBSRkNzLiBUaGUNCj4gbGlua3MgbWF5IGJlIHB1cmVseSBhZG1p bmlzdHJhdGl2ZSwgYnkgd2hpY2ggd2UgbWVhbiB0aGF0IHRoZQ0KPiBhZG1pbmlzdHJhdGl2ZSBk ZXRhaWxzIG9mIHRoZSBuYW1lIGFyZSByZXF1aXJlZCB0byBiZSB0aGUgc2FtZTsgb3INCj4gdGhl eSBtYXkgYmUgdGVjaG5pY2FsbHkgdGlnaHRlciwgc3VjaCBhcyBhIHJlcXVpcmVtZW50IGZvciBt aXJyb3JpbmcNCj4gKGVpdGhlciB2aWEgYWxpYXNpbmcgb3IgYWRtaW5pc3RyYXRpdmUgZmlhdCBv ZiBwYXJhbGxlbCBkZWxlZ2F0aW9uKS4NCj4gQW4gZXhhbXBsZSBvZiB0aGlzIGNhc2UgaXMgZXhh bXBsZS5jb20gYW5kIMOpeGFtcGxlLmNvbTogdGhlc2UgYXJlIGJvdGgNCj4gbmFtZXMgaW4gdGhl IHNhbWUgZG9tYWluIChhbmQgem9uZSkuDQo+IA0KPiBCdW5kbGluZyh3KSBbdyBmb3Igd2lkZV0s IHdoaWNoIEkgd291bGQgcHJlZmVyIHRvIGNhbGwgImRvbWFpbg0KPiBsaW5raW5nIiBvciBzb21l dGhpbmcgbGlrZSB0aGF0LCBpcyB3aGVyZSB0d28gbmFtZXMgaW4gZGlmZmVyZW50IHBhcnRzDQo+ IG9mIHRoZSBETlMgbmFtZXNwYWNlIGFyZSBzb21laG93IHRyZWF0ZWQgaW4gd2F5cyB0aGF0IGxp bmsgdGhlbQ0KPiB0b2dldGhlci4gIEFzIGFib3ZlLCB0aGVzZSBsaW5rcyBtYXkgYmUgc3Ryb25n ZXIgb3Igd2Vha2VyLCBidXQgdGhlDQo+IGtleSBpcyB0aGF0IHRoZXkgYmUgaW4gZGlmZmVyZW50 IGRvbWFpbnMuICBJZiBleGFtcGxlLmNvbSBhbmQNCj4gZXhhbXBsZS5uZXQgYXJlIHNvbWVob3cg bGlua2VkIHRvZ2V0aGVyLCBmb3IgaW5zdGFuY2UsIGl0IHdvdWxkIGJlIGENCj4gY2FzZSBvZiB0 aGlzLg0KPiANCj4gYmVzdCwNCj4gDQo+IEENCj4gDQo+IC0tIA0KPiBBbmRyZXcgU3VsbGl2YW4N Cj4gYWpzQGFudmlsd2FscnVzZGVuLmNvbQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBwcm92cmVnIG1haWxpbmcgbGlzdA0KPiBwcm92cmVnQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJvdnJlZw0K From james.mitchell@ausregistry.com.au Sat Mar 31 01:56:16 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B8621F8713 for ; Sat, 31 Mar 2012 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW8ljBPpNSYX for ; Sat, 31 Mar 2012 01:56:15 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 638E721F870E for ; Sat, 31 Mar 2012 01:56:13 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 31 Mar 2012 19:56:11 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Sat, 31 Mar 2012 19:55:56 +1100 From: James Mitchell To: Andrew Sullivan Date: Sat, 31 Mar 2012 19:56:07 +1100 Thread-Topic: [provreg] IDN administrative bundling Thread-Index: Ac0PHBV2QLZX62iBSJej0ofWla+jMQ== Message-ID: References: <20120330092448.GA21703@mail.yitter.info> <20120330235717.GE21776@mail.yitter.info> <1A7A072C-2448-4143-A08F-0AA744DC91D1@ausregistry.com.au> <4ACA1106-1EA9-4D77-93EC-B590FEBAB10D@crankycanuck.ca> In-Reply-To: <4ACA1106-1EA9-4D77-93EC-B590FEBAB10D@crankycanuck.ca> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] IDN administrative bundling X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 08:56:16 -0000 QWZ0ZXIgcmUtcmVhZGluZyB5b3VyIG1lc3NhZ2UgSSBib3RoIGFncmVlIGFuZCBkaXNhZ3JlZSBk ZXBlbmRpbmcgb24gdGhlIGRvbWFpbiB3aGljaCB5b3UgY29uc2lkZXIgeW91ciBwb2ludCBvZiBy ZWZlcmVuY2UuDQoNCklmIHlvdXIgcG9pbnQgb2YgcmVmZXJlbmNlIGlzIGEgZG9tYWluIHdpdGgg dmFyaWFudCBuYW1lcyB0aGVuIEIobikgc3RpbGwgaG9sZHMgZm9yIGFsbCBzdWJvcmRpbmF0ZSBu YW1lcywgaG93ZXZlciB0aGUgZG9tYWluJ3MgdmFyaWFudCBsYWJlbHMgYWxzbyBmaXQgaW4geW91 ciBkZWZpbml0aW9uIG9mIEIodykuDQoNCkluIHRoaXMgY2FzZSBvbmUgY2FuIGNoYW5nZSB0aGVp ciBwb2ludCBvZiByZWZlcmVuY2UgdG8gdGhlIHBhcmVudCBkb21haW4sIGhvd2V2ZXIgdGhpcyBp cyBzb21ld2hhdCB1bm5hdHVyYWwgYXMgb25lIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGhhdmUgYWRt aW5pc3RyYXRpdmUgY29udHJvbCB0aGUgcGFyZW50IGRvbWFpbi4NCg0KSSdtIG5vdCBzYXlpbmcg eW91IGFyZSB3cm9uZywgdGhlcmUgYXJlIHR3byBkaXN0aW5jdCBjb25jZXB0cyBhcyB5b3UgZGVz Y3JpYmUgYnV0IEkgYmVsaWV2ZSB5b3VyIGRlZmluaXRpb25zIGNvdWxkIHVzZSBzb21lIHRpZ2h0 ZW5pbmcuIEkgYWdyZWUgdGhlIHRlcm0gYnVuZGxpbmcgc2hvdWxkIHByb2JhYmx5IG5vdCBiZSB1 c2VkIHRvIGRlc2NyaWJlIHRoZSBsYXR0ZXIgZ2l2ZW4gaXRzIGN1cnJlbnQgdXNhZ2UuDQoNCkph bWVzDQoNCk9uIDMxLzAzLzIwMTIsIGF0IDc6MzMgUE0sICJBbmRyZXcgU3VsbGl2YW4iIDxhanNA Y3Jhbmt5Y2FudWNrLmNhPiB3cm90ZToNCg0KPiBObywgSSBkb24ndC4gRGVsZWdhdGlvbnMgZnJv bSB0aGUgcGFyZW50IGFyZSBuYW1lcyBpbiBhIGRvbWFpbi4gVGhleSdyZSBjYXNlIEIobikgaW4g d2hhdCBJIHdyb3RlLiANCj4gDQo+IC0tIA0KPiBBbmRyZXcgU3VsbGl2YW4gDQo+IFBsZWFzZSBl eGN1c2UgbXkgY2x1bXN5IHRodW1icy4gDQo+IA0KPiBPbiAyMDEyLTAzLTMxLCBhdCA3OjExLCBK YW1lcyBNaXRjaGVsbCA8amFtZXMubWl0Y2hlbGxAYXVzcmVnaXN0cnkuY29tLmF1PiB3cm90ZToN Cj4gDQo+PiBZb3UgZm9yZ2V0IHdoZXJlIHRoZSB6b25lIG5hbWUgYWxzbyBoYXMgdmFyaWFudCBu YW1lcyBkZWxlZ2F0ZWQgZnJvbSBpdHMgcGFyZW50IHpvbmUuDQo+PiANCj4+IE9uIDMxLzAzLzIw MTIsIGF0IDEwOjU3IEFNLCAiQW5kcmV3IFN1bGxpdmFuIiA8YWpzQGFudmlsd2FscnVzZGVuLmNv bT4gd3JvdGU6DQo+PiANCj4+PiBPbiBGcmksIE1hciAzMCwgMjAxMiBhdCAwMjoyNDoyNFBNICsw MDAwLCBHb3VsZCwgSmFtZXMgd3JvdGU6DQo+Pj4gDQo+Pj4+IG9iamVjdHMuICBUaGUgY29uY2Vw dCBvZiBidW5kbGluZyBjb3VsZCBhcHBseSB0byBkb21haW4gbmFtZXMgaW4gYSBzaW5nbGUNCj4+ Pj4gVExELCBkb21haW4gbmFtZXMgYWNyb3NzIFRMRCdzLCBhbmQgb2JqZWN0cyBvZiBkaWZmZXJl bnQga2luZHMgd2l0aGluIG9yDQo+Pj4+IGFjcm9zcyBUTEQncy4gIA0KPj4+IA0KPj4+IEkgZG9u J3QgY2FyZSB3aGF0IHdlIGNhbGwgdGhlbSwgYnV0IEkgZG8gbm90IHNlZSBob3cgYW55b25lIGNh biBjbGFpbQ0KPj4+IHRoYXQgImJ1bmRsaW5nIiBpbiB0aGUgc2FtZSBzZW5zZSBjYW4gY3Jvc3Mg ZG9tYWluIChJJ20gYWxtb3N0IHRlbXB0ZWQNCj4+PiB0byBzYXkgInpvbmUiKSBib3VuZGFyaWVz IGFuZCBhbHNvIGJlIHRoZSBuYXJyb3cgbWVhbmluZyBvZnRlbg0KPj4+IGludGVuZGVkIGJ5IHRo ZSB3b3JkLg0KPj4+IA0KPj4+IEJ1bmRsaW5nKG4pIFtuIGZvciBuYXJyb3ddIGlzIGEgY2FzZSB3 aGVyZSwgd2l0aGluIHRoZSBzYW1lIGRvbWFpbiwNCj4+PiB0d28gc3Vib3JkaW5hdGUgbGFiZWxz IGFyZSBzb21laG93IHRyZWF0ZWQgYXMgYmFzaWNhbGx5IGxpbmtlZCBpbiBzb21lDQo+Pj4gd2F5 LiAgVGhpcyBpcyB0aGUgbWVhbmluZyBvZiBidW5kbGluZyAoYW5kIG9uZSBvZiB0aGUgbWVhbmlu Z3Mgb2YNCj4+PiAidmFyaWFudCIpIHRoYXQgaGFzIG1vc3QgdHJhZGl0aW9uYWxseSBiZWVuIHNl ZW4gaW4gdGhlIFJGQ3MuIFRoZQ0KPj4+IGxpbmtzIG1heSBiZSBwdXJlbHkgYWRtaW5pc3RyYXRp dmUsIGJ5IHdoaWNoIHdlIG1lYW4gdGhhdCB0aGUNCj4+PiBhZG1pbmlzdHJhdGl2ZSBkZXRhaWxz IG9mIHRoZSBuYW1lIGFyZSByZXF1aXJlZCB0byBiZSB0aGUgc2FtZTsgb3INCj4+PiB0aGV5IG1h eSBiZSB0ZWNobmljYWxseSB0aWdodGVyLCBzdWNoIGFzIGEgcmVxdWlyZW1lbnQgZm9yIG1pcnJv cmluZw0KPj4+IChlaXRoZXIgdmlhIGFsaWFzaW5nIG9yIGFkbWluaXN0cmF0aXZlIGZpYXQgb2Yg cGFyYWxsZWwgZGVsZWdhdGlvbikuDQo+Pj4gQW4gZXhhbXBsZSBvZiB0aGlzIGNhc2UgaXMgZXhh bXBsZS5jb20gYW5kIMOpeGFtcGxlLmNvbTogdGhlc2UgYXJlIGJvdGgNCj4+PiBuYW1lcyBpbiB0 aGUgc2FtZSBkb21haW4gKGFuZCB6b25lKS4NCj4+PiANCj4+PiBCdW5kbGluZyh3KSBbdyBmb3Ig d2lkZV0sIHdoaWNoIEkgd291bGQgcHJlZmVyIHRvIGNhbGwgImRvbWFpbg0KPj4+IGxpbmtpbmci IG9yIHNvbWV0aGluZyBsaWtlIHRoYXQsIGlzIHdoZXJlIHR3byBuYW1lcyBpbiBkaWZmZXJlbnQg cGFydHMNCj4+PiBvZiB0aGUgRE5TIG5hbWVzcGFjZSBhcmUgc29tZWhvdyB0cmVhdGVkIGluIHdh eXMgdGhhdCBsaW5rIHRoZW0NCj4+PiB0b2dldGhlci4gIEFzIGFib3ZlLCB0aGVzZSBsaW5rcyBt YXkgYmUgc3Ryb25nZXIgb3Igd2Vha2VyLCBidXQgdGhlDQo+Pj4ga2V5IGlzIHRoYXQgdGhleSBi ZSBpbiBkaWZmZXJlbnQgZG9tYWlucy4gIElmIGV4YW1wbGUuY29tIGFuZA0KPj4+IGV4YW1wbGUu bmV0IGFyZSBzb21laG93IGxpbmtlZCB0b2dldGhlciwgZm9yIGluc3RhbmNlLCBpdCB3b3VsZCBi ZSBhDQo+Pj4gY2FzZSBvZiB0aGlzLg0KPj4+IA0KPj4+IGJlc3QsDQo+Pj4gDQo+Pj4gQQ0KPj4+ IA0KPj4+IC0tIA0KPj4+IEFuZHJldyBTdWxsaXZhbg0KPj4+IGFqc0BhbnZpbHdhbHJ1c2Rlbi5j b20NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+Pj4gcHJvdnJlZ0BpZXRmLm9yZw0KPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJvdnJlZw0K