Please, is there anybody that is aware if exist a (free) p= hp client library that respect RFC5730 standard?

I tried to search it over the internet but I didn= 't find it.=C2=A0

Thank you,

Claudio Eterno

--e89a8fb1f5b0b5ec0f04d3f3f08e-- From mcanix@gmail.com Wed Jan 23 04:42:07 2013 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 E455B21F8AD8 for ; Wed, 23 Jan 2013 04:42:07 -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_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DrosiJZdgWQ for ; Wed, 23 Jan 2013 04:42:04 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8605B21F8607 for ; Wed, 23 Jan 2013 04:42:04 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fs12so1668979lab.25 for ; Wed, 23 Jan 2013 04:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=zezchT/BBZBagTJ6G/R3nwlHZUHWGuIuVLIfkCArO+0=; b=mAUoAt+iMscMNiehomm1p4pKWe7OlnVjLCgWco7wxjoylHRcHSuyVjukvVrrM3o0Nf dasjUY1uVMLOCdAy8+3ffrkePbJFrKqhVSlNqo2QtMO3c27HiSiYi1ESXEDo4sn02EI3 JXWzaJCn8Q5EtGqy7wmVjPFoUm7JvZskdjwC97bwGMMWVicxd+9Ws9kOIeWYJbTObvsW pRDT7qR9iwpZPyoJot6jYgpXy0+iD+UgLgGoFjpj+l1I02i0TBkItlxhKqxqNh4GX55k f+PBW//U9s5XAnj8RAtkilEaWoJrVdumG9Xu1wInSxi1m1i8rpaD6dnvOHUerrigMzzT eQyQ== X-Received: by 10.112.85.193 with SMTP id j1mr691553lbz.49.1358944923483; Wed, 23 Jan 2013 04:42:03 -0800 (PST) Received: from [192.168.0.12] (41-135-11-168.dsl.mweb.co.za. [41.135.11.168]) by mx.google.com with ESMTPS id j9sm7748264lbd.13.2013.01.23.04.42.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 04:42:02 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_75D35A6B-E5F2-4F2B-AD8C-D9215FA62E41" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mike O'Connell In-Reply-To: Date: Wed, 23 Jan 2013 14:41:21 +0200 Message-Id: References:

To: Claudio Eterno X-Mailer: Apple Mail (2.1499) Cc: provreg@ietf.org Subject: Re: [provreg] Fwd: PHP library compliance RFC 5730 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, 23 Jan 2013 12:42:08 -0000 --Apple-Mail=_75D35A6B-E5F2-4F2B-AD8C-D9215FA62E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Claudio, There is a basic EPP PHP library in CO.ZA's sample pack (don't expect it = to brush your teeth though, you'll still need to generate the XML) https://www.registry.net.za/downloads/u/cozaeppbundle-3.0.zip Ciao, Mike -- If you don't know where you are going, any road will get you there. On 23 Jan 2013, at 2:36 PM, Claudio Eterno = wrote: > Please, is there anybody that is aware if exist a (free) php client = library that respect RFC5730 standard? > I tried to search it over the internet but I didn't find it.=20 > Thank you, > Claudio Eterno >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --Apple-Mail=_75D35A6B-E5F2-4F2B-AD8C-D9215FA62E41 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Claudio,

There is a basic EPP PHP library in CO.ZA's sample pack (don't expect it to brush your teeth though, you'll still need to generate the XML)

https://www.registry.net.za/downloads/u/cozaeppbundle-3.0.zip

Ciao,

Mike

If you don't know where you are going, any road will get you there.

On 23 Jan 2013, at 2:36 PM, Claudio Eterno <eterno.claudio@gmail.com> wrote:

Please, is there anybody that is aware if exist a (free) php client library that respect RFC5730 standard?
I tried to search it over the internet but I didn't find it.

Thank you,
Claudio Eterno

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

--Apple-Mail=_75D35A6B-E5F2-4F2B-AD8C-D9215FA62E41-- From gavin.brown@centralnic.com Wed Jan 23 04:50:36 2013 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 C8E3121F8AD6 for ; Wed, 23 Jan 2013 04:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo5jNua5J6Ae for ; Wed, 23 Jan 2013 04:50:35 -0800 (PST) Received: from smtp.centralnic.com (unknown [193.105.170.214]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD8221F8A91 for ; Wed, 23 Jan 2013 04:50:34 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 7E3FA720408; Wed, 23 Jan 2013 12:50:32 +0000 (UTC) Message-ID: <50FFDC98.3000001@centralnic.com> Date: Wed, 23 Jan 2013 12:50:32 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Claudio Eterno References:

In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: provreg@ietf.org Subject: Re: [provreg] Fwd: PHP library compliance RFC 5730 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, 23 Jan 2013 12:50:37 -0000 X-List-Received-Date: Wed, 23 Jan 2013 12:50:37 -0000 We (CentralNic) provide a PHP library (work in progress) that can produce some request frames: https://github.com/centralnic/php-epp On 23/01/2013 12:36, Claudio Eterno wrote: > Please, is there anybody that is aware if exist a (free) php client > library that respect RFC5730 standard? > I tried to search it over the internet but I didn't find it. > Thank you, > Claudio Eterno > > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From Klaus.Malorny@knipp.de Wed Jan 23 04:58:05 2013 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 D9DE321F87D1 for ; Wed, 23 Jan 2013 04:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqW76bSleWUf for ; Wed, 23 Jan 2013 04:58:05 -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 603E621F87A9 for ; Wed, 23 Jan 2013 04:58:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 8D59D6A; Wed, 23 Jan 2013 13:58:03 +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 h3KQHlS8bhZZ; Wed, 23 Jan 2013 13:57:58 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 2487B68; Wed, 23 Jan 2013 13:57:58 +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 r0NCvv1P016673; Wed, 23 Jan 2013 13:57:58 +0100 (MEZ) Message-ID: <50FFDE55.5090502@knipp.de> Date: Wed, 23 Jan 2013 13:57:57 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> In-Reply-To: <20130123122049.GO17764@nineve.blacknight.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 12:58:06 -0000 On 23/01/13 13:20, Keith Gaughan wrote: >> 3) is it ok to disclose the contact:disclose itself to third-parties? >> I guess it is, also to alleviate determining what fields contain real >> data instead of workaround fill junk? > > I can't see any harm in doing so. It's not disallowed. Again, we need to know if > this command is being issued with or without a element. Ideally, a third-party person should not be able to distinguish between a field that is not present and a field that is not disclosed. But this is impossible for fields which are considered mandatory by the protocol. Regards, Klaus From rep.dot.nop@gmail.com Wed Jan 23 06:21:53 2013 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 003D521F84B9 for ; Wed, 23 Jan 2013 06:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTlMKSkb1-f4 for ; Wed, 23 Jan 2013 06:21:50 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 56D0421F8481 for ; Wed, 23 Jan 2013 06:21:49 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k11so7925980iea.33 for ; Wed, 23 Jan 2013 06:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=o1eRS0fh+3eIQKMFbbic70KxOc5juFXDtNeF537UAOQ=; b=mn3K+2RyhhoFuUxyzKr8ok5zqghvcPG782/I9yJfgMuN6nzhEv85I6qTp8TFPla0xE voM8BECgrXcLSnwZ2vXRn0Qzp+RgC/8tYONvx/iG0/QhqAtCf3PUfXedC7lLQuIwEhzP i/f+v5mKg2X2Vz7SsLxf+zTM1OXoa5uZs5eVJ8pnKdY/O3Fo09jNUe0Yq3fUqYpKCcP6 ixRAmM4kwP79zY9GsRZvvqOhXnuWVmB/bGoPgmNn4C+fXcvuHnVcjqV+7IxM/LWuQUaf SBI0j3Xl8mH1cvts+XJmEw1UQIw74sMgm6Ob8ciaWTqkbD/jhIUx7gr//xZIrvXI6eVx 9N2g== MIME-Version: 1.0 X-Received: by 10.50.151.227 with SMTP id ut3mr15377909igb.5.1358950908817; Wed, 23 Jan 2013 06:21:48 -0800 (PST) Received: by 10.64.143.228 with HTTP; Wed, 23 Jan 2013 06:21:48 -0800 (PST) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6F1F8C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F0D6F1F8C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 23 Jan 2013 15:21:48 +0100 Message-ID: From: Bernhard Reutner-Fischer To: "Hollenbeck, Scott" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "provreg@ietf.org" Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 14:21:53 -0000 On 23 January 2013 13:28, Hollenbeck, Scott wrot= e: >> -----Original Message----- >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On >> Behalf Of Keith Gaughan >> Sent: Wednesday, January 23, 2013 7:21 AM >> To: Bernhard Reutner-Fischer >> Cc: provreg@ietf.org >> Subject: Re: [provreg] contact:disclose clarifications / best practices >> >> On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer >> wrote: >> >> > I have questions about contact:disclose. > > [snip] > >> I think the disclosure fields deal more with the likes of what's >> published in WHOIS and the likes. > > Yes, that use case certainly applies. I've always thought of it as an ind= ication of registrant disclosure preference in the context of registry oper= ator policy. There is thus no single answer to what gets returned because p= rivacy policies will vary from operator to operator. So you consider any registrar that is not sponsor of that contact to not be third party, is that right? In other words: The disclose flag is completely ignored for every contact:info command from any registrar. It is solely used to determine if the affected contact-data is handed out to entities outside of the registry, like public whois-service. thanks, From rep.dot.nop@gmail.com Wed Jan 23 06:28:29 2013 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 4FCAF21F84BC for ; Wed, 23 Jan 2013 06:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-ETADMfFUsT for ; Wed, 23 Jan 2013 06:28:28 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id C533421F84BA for ; Wed, 23 Jan 2013 06:28:28 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id c14so14010273ieb.0 for ; Wed, 23 Jan 2013 06:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OybU+ZJMt2kXU3/BnrLQ3Y6Qj94xwDOP3kLsfGxMDpc=; b=y9dbmZBMbP6+Nv1a2Uw5OeSpIP818UlwyciPGgLYU+QHLeZWOyLvtQxB44lF78OTt3 mpQckScxwwR6Da8GB/x5XvBnNowYAQf2DqboyaDAskZLiTzLtFMfVLnyrNFOLlTWo89/ vKhHOH74rS9lIJWFBXFFpl46GXMqhWWBjXHMT9SMPXV1iUo6v7Yk+cTITZy/mBLxot9H rr9Kqdd6G1VPWazgbh9mo9aIZgTteJdHtt+Q0afhgLzzDLcCHfeTiryYY6ykDKWgv9aS dMkNP4iBQdWYw6q7N6FyMXwEfStJk7c3/ZZllCH0jkPDksP31lCYFmcjP2NDMdNCOd6P MpLQ== MIME-Version: 1.0 X-Received: by 10.50.149.131 with SMTP id ua3mr1313360igb.5.1358951308458; Wed, 23 Jan 2013 06:28:28 -0800 (PST) Received: by 10.64.143.228 with HTTP; Wed, 23 Jan 2013 06:28:28 -0800 (PST) In-Reply-To: <50FFDE55.5090502@knipp.de> References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> <50FFDE55.5090502@knipp.de> Date: Wed, 23 Jan 2013 15:28:28 +0100 Message-ID: From: Bernhard Reutner-Fischer To: Klaus Malorny Content-Type: text/plain; charset=ISO-8859-1 Cc: provreg@ietf.org Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 14:28:29 -0000 On 23 January 2013 13:57, Klaus Malorny wrote: > Ideally, a third-party person should not be able to distinguish between a > field that is not present and a field that is not disclosed. But this is > impossible for fields which are considered mandatory by the protocol. exactly. Iff you regard all non-sponsoring registrars of a contact as "third party" you would have to fill in dummy data in those fields that are mandatory in the protocol (name, addr/cc, addr/city, email). Scotts reply seems to indicate that this is not the case, though; in this case one can always hand out all contact-data to everybody via EPP and as such the issue is moot. thanks, From keith@blacknight.com Wed Jan 23 06:34:44 2013 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 4D86921F85CE for ; Wed, 23 Jan 2013 06:34:44 -0800 (PST) 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_74=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnALsH0jYsnz for ; Wed, 23 Jan 2013 06:34:43 -0800 (PST) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 890E321F8585 for ; Wed, 23 Jan 2013 06:34:42 -0800 (PST) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 203EF58177; Wed, 23 Jan 2013 14:34:41 +0000 (GMT) Date: Wed, 23 Jan 2013 14:34:41 +0000 From: Keith Gaughan To: Bernhard Reutner-Fischer Message-ID: <20130123143440.GP17764@nineve.blacknight.ie> References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F0D6F1F8C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130123142102.0659E33C102@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123142102.0659E33C102@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "provreg@ietf.org" Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 14:34:44 -0000 On Wed, Jan 23, 2013 at 03:21:48PM +0100, Bernhard Reutner-Fischer wrote: > On 23 January 2013 13:28, Hollenbeck, Scott wrote: > >> -----Original Message----- > >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > >> Behalf Of Keith Gaughan > >> Sent: Wednesday, January 23, 2013 7:21 AM > >> To: Bernhard Reutner-Fischer > >> Cc: provreg@ietf.org > >> Subject: Re: [provreg] contact:disclose clarifications / best practices > >> > >> On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer > >> wrote: > >> > >> > I have questions about contact:disclose. > > > > [snip] > > > >> I think the disclosure fields deal more with the likes of what's published > >> in WHOIS and the likes. > > > > Yes, that use case certainly applies. I've always thought of it as an > > indication of registrant disclosure preference in the context of registry > > operator policy. There is thus no single answer to what gets returned > > because privacy policies will vary from operator to operator. > > So you consider any registrar that is not sponsor of that contact to not be > third party, is that right? If they have the authorisation code for a linked domain, they implicitly have authorisation for querying the contact in question, so while they might be a third party, they're a third party who's authorised to access the information in question. > In other words: The disclose flag is completely ignored for every > contact:info command from any registrar. It is solely used to > determine if the affected contact-data is handed out to entities > outside of the registry, like public whois-service. Lets say that the registry allowed for any contact object, regardless of whether they owned it or not. If it was queried by a registrar who didn't own it without the authorisation code or the authorisation code of a linked object, the disclosure policy would apply. Registrars need to get this periodic raised access to deal with transfers. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From rep.dot.nop@gmail.com Wed Jan 23 07:06:39 2013 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 9B1D621F867D for ; Wed, 23 Jan 2013 07:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waOsAYddnHMN for ; Wed, 23 Jan 2013 07:06:36 -0800 (PST) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 15B9421F8686 for ; Wed, 23 Jan 2013 07:06:32 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id l29so4085202iag.18 for ; Wed, 23 Jan 2013 07:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=18T+E2AoRbUqTlUBuSN6mcvCj2MEbKvjZSk2h5D4j+M=; b=rv2VCUQ9zTir5Gg7tjOtBJll3+IEDSGX+l49zCW7SxMvSsmnD3/OyRJJ1n0Pu8z3IB AhVe+EFHVYKTXPDM2kSBVfx9UkVY7bbWb8IlU5ozp3OjlK2SRhVv2yNHdcyLxYJMAjzG /JpGT6ZoMZkbvxEbjSfmKQmuKXBUf2NdKiuguCaOgMdHWFOH3dDE6l60oWVqcwtwyJK9 jwqtb0HaxnVEqVW37DbgTWuE8Wi13MzILxKTBLS697IlgjeJbX3/6w4yhA/R4VYI2Idv BByNoWDizD5N2olEOPbcs+kS6w0SDJCMSITv6802honP7pq31U6mClM7Rkc9tckTHFy2 qgPg== MIME-Version: 1.0 X-Received: by 10.50.180.226 with SMTP id dr2mr15140701igc.7.1358953591502; Wed, 23 Jan 2013 07:06:31 -0800 (PST) Received: by 10.64.143.228 with HTTP; Wed, 23 Jan 2013 07:06:31 -0800 (PST) In-Reply-To: <20130123122049.GO17764@nineve.blacknight.ie> References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> Date: Wed, 23 Jan 2013 16:06:31 +0100 Message-ID: From: Bernhard Reutner-Fischer To: Keith Gaughan Content-Type: text/plain; charset=ISO-8859-1 Cc: provreg@ietf.org Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 15:06:39 -0000 On 23 January 2013 13:20, Keith Gaughan wrote: > On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer wrote: > >> I have questions about contact:disclose. >> >> 1) How do i correctly handle non-disclosure of all fields of a contact:info >> command from a third party via EPP, especially name, email, addr (city, cc >> therein) etc? > > Are you talking about a request being made against a contact by a > registrar other than the owning registrar, and is a element being > provided? In my example i do not have an authinfo set in the contact, no. > >> 2) what dummy values should i use for the required fields, what is best/common >> practice? > > If you omit them, the default registry policy is applied [SS2.9]: > > A server operator announces a default disclosure policy when establishing a > session with a client. [...] When an object is created or updated, the client > can specify contact attributes that require exceptional disclosure handling > using an OPTIONAL element. > > [SS2.9] http://tools.ietf.org/html/rfc5733#section-2.9 > > Thus, a good default is to comit the block entirely unless > there are specific fields you wish not to be disclosed. right, but that was not my question. I was assuming that a contact:info sent in from a non-sponsoring registrar for a contact that wants not to disclose it's name, email, addr is considered to be from a third party so i would have had to omit those affected fields from the reponse. Since the schema neither allows to omit e.g. the email nor to have it empty, i would have had to fill in some dummy data (see "n/a" in the second response in my initial mail). > >> 3) is it ok to disclose the contact:disclose itself to third-parties? >> I guess it is, also to alleviate determining what fields contain real >> data instead of workaround fill junk? > > I can't see any harm in doing so. It's not disallowed. Again, we need to know if > this command is being issued with or without a element. > >> Long story: >> Ideally i would have expected to be able to return: >> >> >> >> >> >> Command completed successfully >> >> >> >> dnd018360624626 >> C0000000704-BOX >> >> >> >> >> primary >> primary >> 2013-01-22T18:50:12.160307Z >> >> >> >> >> >> >> >> >> >> >> >> 8DE21C7A-64C4-11E2-BE5E-5148DCA3D1ED >> 20130122195013136028C3-secondary-box >> >> >> >> >> But that complains about >> Element '{urn:ietf:params:xml:ns:contact-1.0}clID': This element is not expected. Expected is one of ( {urn:ietf:params:xml:ns:contact-1.0}voice, {urn:ietf:params:xml:ns:contact-1.0}fax, {urn:ietf:params:xml:ns:contact-1.0}email > I assume the it's a client parser that's giving these errors. If a contact is > being queried with an block, I don't think that disclosure flags > actually apply: if you've got a domain's authorisation code, that implies full > access to linked objects for the purpose of issuing commands. yes, agree. > While this is an assumption on my part, there's good reason for it: transfer. > Say you have the email field set for nondisclosure and somebody was transferring > the domain away from you. The gaining registrar needs to be able to get at the > email so that they can contact the registrant for confirmation, so if the the > email field was set for nondisclosure, they wouldn't be able to deal with the > transfer. > >> i.e. fill in name, city, email with an arbitrary token (which one?!) >> and fill in cc with an arbitrary, invalid ccType. > > I think the disclosure fields deal more with the likes of what's published in > WHOIS and the likes. That is one way to see it, agree. thanks, From shollenbeck@verisign.com Wed Jan 23 07:38:17 2013 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 A5C4921F8703 for ; Wed, 23 Jan 2013 07:38:17 -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=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb29cLrVn7QF for ; Wed, 23 Jan 2013 07:38:17 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2621F86E8 for ; Wed, 23 Jan 2013 07:38:14 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUQAD5olNAMzLK5j7tP6NA3bDbJuYDQSu@postini.com; Wed, 23 Jan 2013 07:38:17 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r0NFcBqr014043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 10:38:11 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 10:38:06 -0500 From: "Hollenbeck, Scott" To: Keith Gaughan , Bernhard Reutner-Fischer Thread-Topic: [provreg] contact:disclose clarifications / best practices Thread-Index: AQHN+XbHi3zciB6qO0KP4YKn7JKFXJhXC6gw Date: Wed, 23 Jan 2013 15:38:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6F238F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F0D6F1F8C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130123142102.0659E33C102@merlin.blacknight.ie> <20130123143440.GP17764@nineve.blacknight.ie> In-Reply-To: <20130123143440.GP17764@nineve.blacknight.ie> 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 Cc: "provreg@ietf.org" Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 15:38:17 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Keith Gaughan > Sent: Wednesday, January 23, 2013 9:35 AM > To: Bernhard Reutner-Fischer > Cc: provreg@ietf.org > Subject: Re: [provreg] contact:disclose clarifications / best practices >=20 > On Wed, Jan 23, 2013 at 03:21:48PM +0100, Bernhard Reutner-Fischer > wrote: >=20 > > On 23 January 2013 13:28, Hollenbeck, Scott > wrote: > > >> -----Original Message----- > > >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] > On > > >> Behalf Of Keith Gaughan > > >> Sent: Wednesday, January 23, 2013 7:21 AM > > >> To: Bernhard Reutner-Fischer > > >> Cc: provreg@ietf.org > > >> Subject: Re: [provreg] contact:disclose clarifications / best > > >> practices > > >> > > >> On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer > > >> wrote: > > >> > > >> > I have questions about contact:disclose. > > > > > > [snip] > > > > > >> I think the disclosure fields deal more with the likes of what's > > >> published in WHOIS and the likes. > > > > > > Yes, that use case certainly applies. I've always thought of it as > > > an indication of registrant disclosure preference in the context of > > > registry operator policy. There is thus no single answer to what > > > gets returned because privacy policies will vary from operator to > operator. > > > > So you consider any registrar that is not sponsor of that contact to > > not be third party, is that right? >=20 > If they have the authorisation code for a linked domain, they > implicitly have authorisation for querying the contact in question, so > while they might be a third party, they're a third party who's > authorised to access the information in question. >=20 > > In other words: The disclose flag is completely ignored for every > > contact:info command from any registrar. It is solely used to > > determine if the affected contact-data is handed out to entities > > outside of the registry, like public whois-service. >=20 > Lets say that the registry allowed for any contact > object, regardless of whether they owned it or not. If it was queried > by a registrar who didn't own it without the authorisation code or the > authorisation code of a linked object, the disclosure policy would > apply. >=20 > Registrars need to get this periodic raised access to deal with > transfers. Right. This is a different use case. The registrant makes an informed decis= ion to provide the authInfo to a new registrar so that they can act as thei= r agent to implement a transfer. Scott From shollenbeck@verisign.com Wed Jan 23 07:45:58 2013 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 45D4821F8735 for ; Wed, 23 Jan 2013 07:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0OFWbl94WTW for ; Wed, 23 Jan 2013 07:45:56 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id E4A3821F872C for ; Wed, 23 Jan 2013 07:45:53 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUQAFsWtmQaFR/33qrNWsXBDjnbp68EOC@postini.com; Wed, 23 Jan 2013 07:45:55 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r0NFjqkk009377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 10:45:52 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 10:45:39 -0500 From: "Hollenbeck, Scott" To: Bernhard Reutner-Fischer , Keith Gaughan Thread-Topic: [provreg] contact:disclose clarifications / best practices Thread-Index: AQHN+Xs5i3zciB6qO0KP4YKn7JKFXJhXDadA Date: Wed, 23 Jan 2013 15:45:47 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6F23ED@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> In-Reply-To: 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 Cc: "provreg@ietf.org" Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 15:45:58 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Bernhard Reutner-Fischer > Sent: Wednesday, January 23, 2013 10:07 AM > To: Keith Gaughan > Cc: provreg@ietf.org > Subject: Re: [provreg] contact:disclose clarifications / best practices >=20 > On 23 January 2013 13:20, Keith Gaughan wrote: > > On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer > wrote: > > > >> I have questions about contact:disclose. > >> > >> 1) How do i correctly handle non-disclosure of all fields of a > >> contact:info command from a third party via EPP, especially name, > >> email, addr (city, cc > >> therein) etc? > > > > Are you talking about a request being made against a > > contact by a registrar other than the owning registrar, and is a > > element being provided? >=20 > In my example i do not have an authinfo set in the contact, no. >=20 > > > >> 2) what dummy values should i use for the required fields, what is > >> best/common practice? > > > > If you omit them, the default registry policy is applied [SS2.9]: > > > > A server operator announces a default disclosure policy when > establishing a > > session with a client. [...] When an object is created or updated, > the client > > can specify contact attributes that require exceptional disclosure > handling > > using an OPTIONAL element. > > > > [SS2.9] http://tools.ietf.org/html/rfc5733#section-2.9 > > > > Thus, a good default is to comit the block > entirely > > unless there are specific fields you wish not to be disclosed. >=20 > right, but that was not my question. > I was assuming that a contact:info sent in from a non-sponsoring > registrar for a contact that wants not to disclose it's name, email, > addr is considered to be from a third party so i would have had to omit > those affected fields from the reponse. Since the schema neither allows > to omit e.g. the email nor to have it empty, i would have had to fill > in some dummy data (see "n/a" in the second response in my initial > mail). If the client lacks the appropriate privileges to view the information you = can return a 2201 authorization error in response to the query. Scott From keith@blacknight.com Wed Jan 23 07:54:49 2013 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 4EB8C21F86BE for ; Wed, 23 Jan 2013 07:54:49 -0800 (PST) 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_74=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3MA5c8BR7FO for ; Wed, 23 Jan 2013 07:54:48 -0800 (PST) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 92C9121F86B6 for ; Wed, 23 Jan 2013 07:54:48 -0800 (PST) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id AFFA958177; Wed, 23 Jan 2013 15:54:47 +0000 (GMT) Date: Wed, 23 Jan 2013 15:54:47 +0000 From: Keith Gaughan To: Bernhard Reutner-Fischer Message-ID: <20130123155447.GS17764@nineve.blacknight.ie> References: <20130123102556.65F0533C3D8@merlin.blacknight.ie> <20130123122049.GO17764@nineve.blacknight.ie> <20130123150547.7F4E25A4010@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123150547.7F4E25A4010@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: provreg@ietf.org Subject: Re: [provreg] contact:disclose clarifications / best practices 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, 23 Jan 2013 15:54:49 -0000 On Wed, Jan 23, 2013 at 04:06:31PM +0100, Bernhard Reutner-Fischer wrote: > On 23 January 2013 13:20, Keith Gaughan wrote: > > On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer wrote: > > > >> I have questions about contact:disclose. > >> > >> 1) How do i correctly handle non-disclosure of all fields of a contact:info > >> command from a third party via EPP, especially name, email, addr (city, cc > >> therein) etc? > > > > Are you talking about a request being made against a contact by a > > registrar other than the owning registrar, and is a element being > > provided? > > In my example i do not have an authinfo set in the contact, no. Ok, the clarification that it's about a request issued without an element clears things up a lot. > > > >> 2) what dummy values should i use for the required fields, what is best/common > >> practice? > > > > If you omit them, the default registry policy is applied [SS2.9]: > > > > A server operator announces a default disclosure policy when establishing a > > session with a client. [...] When an object is created or updated, the client > > can specify contact attributes that require exceptional disclosure handling > > using an OPTIONAL element. > > > > [SS2.9] http://tools.ietf.org/html/rfc5733#section-2.9 > > > > Thus, a good default is to comit the block entirely unless > > there are specific fields you wish not to be disclosed. > > right, but that was not my question. Thats because I wasn't entirely clear on whether your were talking about its use in / or . The above cleared it up. Behaviour on this varies from registry to registry. Some omit the elements entirely and assume that clients are not validating their responses against the EPP schemata. Others provide empty elements (such as ''). Most simply claim that the client has no authorisation to perform the operation and issue a 2201 response (though the actual response code used can vary). From the point of view of a registrar, I can say that I prefer this last option. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From Antoin.Verschuren@sidn.nl Thu Jan 24 00:21:44 2013 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 6620721F8497 for ; Thu, 24 Jan 2013 00:21:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYMLV-PELnDg for ; Thu, 24 Jan 2013 00:21:43 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 616FE21F8468 for ; Thu, 24 Jan 2013 00:21:42 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r0O8LfhQ029693-r0O8LfhS029693 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 24 Jan 2013 09:21:41 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 09:21:41 +0100 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 09:21:41 +0100 Message-ID: <5100EF14.4080203@sidn.nl> Date: Thu, 24 Jan 2013 09:21:40 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> In-Reply-To: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 08:21:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, This draft may be of interest to this list. At SIDN, we have documented how we intend to implement secure transfers of DNSSEC domains and this draft is to describe the EPP command we're going to use for that so it may be standardized. Comments are welcome to the authors or on this list. A new version of I-D, draft-gieben-epp-keyrelay-00.txt has been successfully submitted by R. (Miek) Gieben and posted to the IETF repository. Filename: draft-gieben-epp-keyrelay Revision: 00 Title: Key Relay Mapping for the Extensible Provisioning Protocol Creation date: 2013-01-20 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-gieben-epp-keyrelay-00.txt Status: http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay Htmlized: http://tools.ietf.org/html/draft-gieben-epp-keyrelay-00 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the purpose of relaying DNSSEC key material from a one registrar to another. The mapping introduces as a new command in EPP. This command will help facilitating a transfer of a domain while keeping DNSSEC's chain of trust intact. The IETF Secretariat - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRAO8OAAoJEDqHrM883AgnGn8IAI2qQdBdXSYZULn3QlmwUSDS nL7QAyaDwTdd6hoc9nU8mMdBYQ7nGFewrhKrrrs5HNY/zxVPjsDgzyJ9duJ5Y9lL 6TBdPU6zL+1d6gYqyxXWWzo8YnbsBSW3Vf0Nq1YCtdhPkbPOVQwHQKnHdkRr6cjh cMCPXTMfXGjLJ08fa6uKSX39S+s7H9iMHO9YwIk4MbNCeyWkwgMvSkSfqQdyQcrt Jx0zczOD/RAo55G8nQgSVMHh31h5e71t/qR4QKSsG5EOyDs4dQM3kOmqjBVX90wu WyRLtcxr0CYwyFSgltWYx7TEam/1vFLnoLSavUUT9SsbK/3IS+xb7WOaBs66m04= =XH3D -----END PGP SIGNATURE----- From Klaus.Malorny@knipp.de Thu Jan 24 02:27:32 2013 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 85B9621F8503 for ; Thu, 24 Jan 2013 02:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRewOYMQk9av for ; Thu, 24 Jan 2013 02:27:31 -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 6BE7C21F8484 for ; Thu, 24 Jan 2013 02:27:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 429B85F; Thu, 24 Jan 2013 11:27:30 +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 7UBxST+9h9z4; Thu, 24 Jan 2013 11:27:29 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 54C9E5D; Thu, 24 Jan 2013 11:27:29 +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 r0OARSja023979; Thu, 24 Jan 2013 11:27:29 +0100 (MEZ) Message-ID: <51010C90.3090800@knipp.de> Date: Thu, 24 Jan 2013 11:27:28 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> In-Reply-To: <5100EF14.4080203@sidn.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 10:27:32 -0000 On 24/01/13 09:21, Antoin Verschuren wrote: > Hi all, > > This draft may be of interest to this list. > At SIDN, we have documented how we intend to implement secure > transfers of DNSSEC domains and this draft is to describe the EPP > command we're going to use for that so it may be standardized. > Comments are welcome to the authors or on this list. > Hi, interesting draft. On the first glance, I'd like to note the following: 1. why is the use of the authinfo only optional? Isn't it better to make it mandatory and reject the submission if the authinfo is incorrect? In this case, the poll message does not need to contain the authinfo. 2. The current registrar does not know from which registrar the key data is coming. In case of problems, he is unable to contact the respective registrar. Also, he is unable to determine whether the keys come from different sources and need either to be combined or replaced. 3. How long shall the current registrar/name server operator add the DNSKEYs to the respective zone? If, for example, the registrant changes his mind and does no longer want the new registrar to transfer the domain to him, or wants to choose a different registrar, there is no way to indicate this. Alternatively, this could be solved by some kind of automatic timeout, i.e. if the the operation is not repeated periodically, the current registrar shall remove the keys from the zone. If this period is not part of the registry policy, maybe the command should contain a point in time until which the keys shall be added. If the (potentially) gaining registrar determines to need more time for whatever reason, he can submit another command with the same keys, but a later date. Of course, the current registrar (or registry?) should check the time for reasonable limits. Regards, Klaus From james.mitchell@ausregistry.com.au Thu Jan 24 03:08:22 2013 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 3A6CD21F894E for ; Thu, 24 Jan 2013 03:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIBxIohdVBlH for ; Thu, 24 Jan 2013 03:08:20 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id CD92A21F8941 for ; Thu, 24 Jan 2013 03:08:19 -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; 24 Jan 2013 22:08:18 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 24 Jan 2013 22:08:16 +1100 From: James Mitchell To: Antoin Verschuren , "provreg@ietf.org" Date: Thu, 24 Jan 2013 22:08:14 +1100 Thread-Topic: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt Thread-Index: Ac36Ixtjse/ZsG5ESZ2ED/XONall7Q== Message-ID: In-Reply-To: <5100EF14.4080203@sidn.nl> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 11:08:22 -0000 Interesting draft. I hope that registrars warm to the idea and implement it. A few high level questions/comments: Implementing this is of arguable benefit to a registrar on the losing end. Do you have a plan to encourage registrars to use it such that it will see success? Do you have the buy in from existing registrars? Keyrelay messages provide the losing registrar with early notification of an imminent transfer. Do you foresee any potential issues with this, for example the losing registrar attempting to (intentionally or accidentally) block or delay the transfer. I'm thinking that a registrar could be justified in updating the domain authinfo a few days after giving it out for security reasons, thus forcing the registrant to obtain a new authinfo code for the transfer itself. This delay could cause the domain to pass a critical date (for example an expiration date or other relevant date depending on registry lifecycle and policy). I would suggest that an error should be returned for uploading a key for a domain name sponsored by a registrar who has not implemented this extension. This may be considered an "optimisation" at the registry level, however I question if early failure would better inform the gaining registrar? If so a specific code/message may be described to promote interoperability. Would you consider including reasons under which a registry should or should not reject the command? For example I would assume there is no reason for this to succeed should no key material be associated with the domain on receipt of the command. Or would you suggest that the registry not attempt to otherwise interfere with the processing of this command? I notice there is no feedback loop from the losing registrar to the gaining registrar. I assume that the gaining registrar would have to poll the child zone (with its own timeout) to begin relevant cache-busting timers? Note that the losing registrar may not provide DNS services for the given domain name. Or do you consider the transfer pending period of ample time for caches to expire. I would assume that a registry may delete an unread keyrelay message from the queue should a transfer be completed successfully? Some registrars may prefer to process the message queue in batch, potentially increasing the time between submission to the server and retrieval by the losing registrar. Do you foresee any need or reason for a priority-based, or named message queue to better facilitate keyrelay? Regards, James On 24/01/13 7:21 PM, "Antoin Verschuren" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi all, > >This draft may be of interest to this list. >At SIDN, we have documented how we intend to implement secure >transfers of DNSSEC domains and this draft is to describe the EPP >command we're going to use for that so it may be standardized. >Comments are welcome to the authors or on this list. > >A new version of I-D, draft-gieben-epp-keyrelay-00.txt >has been successfully submitted by R. (Miek) Gieben and posted to the >IETF repository. > >Filename: draft-gieben-epp-keyrelay >Revision: 00 >Title: Key Relay Mapping for the Extensible Provisioning Protocol >Creation date: 2013-01-20 >WG ID: Individual Submission >Number of pages: 11 >URL: >http://www.ietf.org/internet-drafts/draft-gieben-epp-keyrelay-00.txt >Status: http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay >Htmlized: http://tools.ietf.org/html/draft-gieben-epp-keyrelay-00 > > >Abstract: > This document describes an Extensible Provisioning Protocol (EPP) > extension mapping for the purpose of relaying DNSSEC key material > from a one registrar to another. The mapping introduces > as a new command in EPP. > > This command will help facilitating a transfer of a domain while > keeping DNSSEC's chain of trust intact. > > > > > >The IETF Secretariat > > >- --=20 >Antoin Verschuren > >Technical Policy Advisor SIDN >Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands > >P: +31 26 3525500 M: +31 6 23368970 >Mailto: antoin.verschuren@sidn.nl >XMPP: antoin.verschuren@jabber.sidn.nl >HTTP://www.sidn.nl/ > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.11 (GNU/Linux) > >iQEcBAEBAgAGBQJRAO8OAAoJEDqHrM883AgnGn8IAI2qQdBdXSYZULn3QlmwUSDS >nL7QAyaDwTdd6hoc9nU8mMdBYQ7nGFewrhKrrrs5HNY/zxVPjsDgzyJ9duJ5Y9lL >6TBdPU6zL+1d6gYqyxXWWzo8YnbsBSW3Vf0Nq1YCtdhPkbPOVQwHQKnHdkRr6cjh >cMCPXTMfXGjLJ08fa6uKSX39S+s7H9iMHO9YwIk4MbNCeyWkwgMvSkSfqQdyQcrt >Jx0zczOD/RAo55G8nQgSVMHh31h5e71t/qR4QKSsG5EOyDs4dQM3kOmqjBVX90wu >WyRLtcxr0CYwyFSgltWYx7TEam/1vFLnoLSavUUT9SsbK/3IS+xb7WOaBs66m04=3D >=3DXH3D >-----END PGP SIGNATURE----- >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From Antoin.Verschuren@sidn.nl Thu Jan 24 04:22:43 2013 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 CFCA021F84E6 for ; Thu, 24 Jan 2013 04:22:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0VIlNv4vGon for ; Thu, 24 Jan 2013 04:22:30 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id C810C21F84D8 for ; Thu, 24 Jan 2013 04:22:29 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r0OCMShe030886-r0OCMShg030886 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 24 Jan 2013 13:22:28 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 13:22:27 +0100 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 13:22:28 +0100 Message-ID: <51012783.2000401@sidn.nl> Date: Thu, 24 Jan 2013 13:22:27 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> In-Reply-To: <51010C90.3090800@knipp.de> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 12:22:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 24-01-13 11:27, Klaus Malorny schreef: > interesting draft. On the first glance, I'd like to note the > following: Hi Klaus, thank you for your feedback. Comments below. > 1. why is the use of the authinfo only optional? Because it is also optional in the EPP transfer command. A registry may declare a transfer token mandatory in local policy, but a registry may also determine that transfers that are not authenticated by a token will proceed if the losing registrar does not object within a certain time frame. A registrar may object if the transfer is not authenticated by a token, but he may also choose not to object, again by his local policy. > 2. The current registrar does not know from which registrar the key > data is coming. In case of problems, he is unable to contact the > respective registrar. Also, he is unable to determine whether the > keys come from different sources and need either to be combined or > replaced. This is a very good suggestion. We will update the message queue format to include the keyrelaying registrar in the next version of the draft. > 3. How long shall the current registrar/name server operator add > the DNSKEYs to the respective zone? This question is process, not syntax. If it needs to be explained, it should be described in koch-dnsop-dnssec-operator-change. I understand your concern. If I were the DNS operator, I would delete the key from my zone if I did not receive a transfer request within a week after the keyrelay request, but again, that is process or local policy and not syntax, and we don't think we need a trigger from the registry for that. We want to keep the keyrelay command as simple as possible for the registry, and leave the logic to the registrars and DNS operators who are in control of the process anyway. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRASd6AAoJEDqHrM883AgnPEYH/i9itOIqB3fWg9Df4YTazGs2 SUWKzuzdQGv0LU+3T8qTsbbOH5TTISgJAMdbwPw0Fi7GTwBjOH4aH5XDHuWUDKJN jpsGFU2WFJsQSe8FoG77uR5hU/4BY7jlN2BCMh+6pJ8WrMLQehwl0bxbsTi9ezui 27dwFVzI41hWJBexXfbkMURkbWk5tOZ0enqJQsX43te6FN3C2zcemBgwzWI3LkZx xY5mSL/NQO7O8jG+BFs6ybosqeLWeQn67VhiCcu6T3jS7HBmQY4I6FLnAWJriZcI 7k1++mw0Atnj7hBF1rm1j00ijXJNdH2NRhIDGwgtz8LjGKRFCrdeh4aXtJ/AZH0= =RS/l -----END PGP SIGNATURE----- From Klaus.Malorny@knipp.de Thu Jan 24 05:13:55 2013 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 81AE721F8884 for ; Thu, 24 Jan 2013 05:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3hKmLKCXZ5K for ; Thu, 24 Jan 2013 05:13:55 -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 9400621F84CC for ; Thu, 24 Jan 2013 05:13:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id BA21F5F; Thu, 24 Jan 2013 14:13:34 +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 lxUNmpCfys2Q; Thu, 24 Jan 2013 14:13:33 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id C69685D; Thu, 24 Jan 2013 14:13:33 +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 r0ODDW15023166; Thu, 24 Jan 2013 14:13:33 +0100 (MEZ) Message-ID: <5101337C.5090107@knipp.de> Date: Thu, 24 Jan 2013 14:13:32 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> <51012783.2000401@sidn.nl> In-Reply-To: <51012783.2000401@sidn.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 13:13:55 -0000 On 24/01/13 13:22, Antoin Verschuren wrote: > Op 24-01-13 11:27, Klaus Malorny schreef: > >> interesting draft. On the first glance, I'd like to note the >> following: > > Hi Klaus, thank you for your feedback. Comments below. > Hi Antoin, >> 1. why is the use of the authinfo only optional? > > Because it is also optional in the EPP transfer command. > A registry may declare a transfer token mandatory in local policy, but > a registry may also determine that transfers that are not > authenticated by a token will proceed if the losing registrar does not > object within a certain time frame. A registrar may object if the > transfer is not authenticated by a token, but he may also choose not > to object, again by his local policy. Ok, although I consider the support for transfers without authinfo as a backward compatible feature no longer required and desired today. > This is a very good suggestion. We will update the message queue > format to include the keyrelaying registrar in the next version of the > draft. > >> 3. How long shall the current registrar/name server operator add >> the DNSKEYs to the respective zone? > > This question is process, not syntax. I cannot agree. There are certain expectations with the protocol, namely that the current registrar performs the necessary steps to have the DNSKEYs published on the domain's name servers, and this is already "process". But defining only the addition and not the removal is only a half thing. Without clear semantics, i.e. with uncertainties about the consequences of its use, the value of a protocol decreases a lot. Of course, the semantics need not to fully cover Peter's/Marcos' paper. Regards, Klaus From Antoin.Verschuren@sidn.nl Thu Jan 24 07:44:17 2013 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 42F4921F87B2 for ; Thu, 24 Jan 2013 07:44:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+V-grR5fYSD for ; Thu, 24 Jan 2013 07:44:03 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 92F0021F8584 for ; Thu, 24 Jan 2013 07:44:03 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r0OFhwdC017474-r0OFhwdE017474 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 24 Jan 2013 16:43:58 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 16:43:58 +0100 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 16:43:58 +0100 Message-ID: <510156BD.7070606@sidn.nl> Date: Thu, 24 Jan 2013 16:43:57 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "provreg@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 15:44:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 24-01-13 12:08, James Mitchell schreef: > Interesting draft. I hope that registrars warm to the idea and > implement it. A few high level questions/comments: Hi James, thank you for your comments. > Do you have a plan to encourage registrars to use it such that it > will see success? Do you have the buy in from existing registrars? We have discussed 3 possible options for DNSSEC transfers with our registrars. The most important outcome is that the registrars want to stay in control of the process, and choosing this method over for example going insecure during a transfer should be at the sole discretion of the gaining registrar even during the process. It is an optional process, not mandatory. (At least not by us, but a registrant may demand it) They all agreed though, that at least one secure transfer method should be implemented by the registry and be available, and the method described in koch-dnsop-dnssec-operator-change was supported with the consensus of our registrars. As for buy in, I cannot say what the promises of our registrars are worth, but most of them told us that they realize that if they don't implement this on their end for customers leaving, then they won't have any new satisfying customers that would come to them. One proof of buy in that I do have is that Bert Hubert's PowerDNS (Which has a >50% marketshare in .nl) has recently built a feature in their DNS software specifically to support this transfer method. > Keyrelay messages provide the losing registrar with early > notification of an imminent transfer. Do you foresee any potential > issues with this, for example the losing registrar attempting to > (intentionally or accidentally) block or delay the transfer. Let the market know who that registrar is, and he will certainly loose customers. Those sort of games don't work out well in the long run I would say. It happens today, and it will happen in the future. I aggree keyrelay does give advance notice that a customer may be leaving, but if you are a good customer, you would have informed your supplier within the notice period to end your contract anyway wouldn't you ? > I would suggest that an error should be returned for uploading a > key for a domain name sponsored by a registrar who has not > implemented this extension. Would you consider including reasons > under which a registry should or should not reject the command? We do not reject anything, we just relay. In a fixed syntax. The question you could ask is what harm does it do if a registrar gets a keyrelay message in it's message queue and does not know how to handle it, or chooses not to handle it. Should the registry mandate that he handles it? We don't mandate anything, we just facilitate registrars that want to do secure transfers. We are no dictator nor god. As a registry, you could choose not to relay for domains that currently don't do DNSSEC, but there may be use cases where even a domain without DNSSEC can benefit from a keyrelay command. For example if the loosing dns-operator can't sign, but has agreed to pre-publish his customers future ZSK. For registries that do want to control their registrar's business processes, I'm open for suggestions of such error messages, but we won't ever use them as we just simply do what our customers want us to do and relay the key. It does nothing to the registration data or status. > I notice there is no feedback loop from the losing registrar to > the gaining registrar. I assume that the gaining registrar would > have to poll the child zone (with its own timeout) to begin > relevant cache-busting timers? The feedback loop is over DNS indeed. The only reason we need this keyrelay command is because we cannot relay the new key over DNS or any other secure channel. It's documented in koch-dnsop-dnssec-operator-change > Note that the losing registrar may not provide DNS services for the > given domain name. Or do you consider the transfer pending period > of ample time for caches to expire. It's the dns-operators and registrars that control that process and it's timing. We only describe the EPP syntax because the registry is the middle man, and communication with the registry is over EPP. Communication between registrars, registrants and their DNS operators can be over EPP, but it usually isn't. It's out of scope for this document, thought we do mention in the security section that that communication channel should also be authenticated, but it's not to us to mandate how. > I would assume that a registry may delete an unread keyrelay > message from the queue should a transfer be completed > successfully? That's local policy. It's not defined in the current EPP RFC's that messages should be deleted from the message queue by the registry. It's only defined how a registrar can delete messages from it's queue after he has read them. As for us, we just leave them there as long as the registrar does not delete them. They do no harm. > Some registrars may prefer to process the message queue in batch, > potentially increasing the time between submission to the server > and retrieval by the losing registrar. Do you foresee any need or > reason for a priority-based, or named message queue to better > facilitate keyrelay? If they read their message queue in batch, it's their thing. How fast registrars or DNS operators should work is not our call. I think it's their customers that decide if it's a good thing. A DNSSEC transfer process takes time anyway. And it's not only reading the queue, it's also what you do with the output and how fast you provision the relayed key. We have nothing to say about how fast some DNS operator handles it's customers requests. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRAVa9AAoJEDqHrM883Agnw3kIAKaRvRcLoABAVhY3jgbXujqf TLDM4nYod8mLX7empnpcttBDvcrE3LAKH+CwtMKTR9zSdWZZD9MuvkhikWhWWs3f illnaHZmfTKnp0+TwpRHF8KsUTgjgUzwMJB9fST2CamBB3mob802GGYqrxpDzqQT Rna6X9RHM/wzKDBl88yL5OhnufVd2Df7k0wqDcXLeN7xNY1T5nA+OCS6XMtChBr4 CfdkUEWvvTazJmhZ+QifrFzOM2y6OgLfpH/LQEBQstqMRsdEOS9lj4yxAJy9TeVJ TehtH13BXdfla6A/Z4t6feFDjwdxOVhSWSY7s9R0RvmPBwaDvVGZ9RdMvQEaUuM= =8dvr -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Thu Jan 24 08:44:26 2013 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 C5EA121F852B for ; Thu, 24 Jan 2013 08:44:26 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiVnofisxU+g for ; Thu, 24 Jan 2013 08:44:25 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5295121F8503 for ; Thu, 24 Jan 2013 08:44:25 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r0OGiNJO018264-r0OGiNJQ018264 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 24 Jan 2013 17:44:23 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 17:44:23 +0100 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 17:44:23 +0100 Message-ID: <510164E6.2000609@sidn.nl> Date: Thu, 24 Jan 2013 17:44:22 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> <51012783.2000401@sidn.nl> <5101337C.5090107@knipp.de> In-Reply-To: <5101337C.5090107@knipp.de> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 16:44:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 24-01-13 14:13, Klaus Malorny schreef: >> >>> 3. How long shall the current registrar/name server operator >>> add the DNSKEYs to the respective zone? >> >> This question is process, not syntax. > > I cannot agree. There are certain expectations with the protocol, > namely that the current registrar performs the necessary steps to > have the DNSKEYs published on the domain's name servers, and this > is already "process". Ah, I see how you look at it. If that's the case, then we should make DNSSEC mandatory, which it isn't. (though I would like it :-)) Secure transfers are not mandatory as well. The only thing koch-dnsop-dnssec-operator-change describes is "if you want to do a secure transfer, this is how you can do it". We don't say you MUST do secure transfers because there is allways an alternative to go insecure and we cannot mandate DNSSEC. So if a key is relayed to a registrar, it is expected that he relays the key to the DNS operator that is appointed by the registant. The DNS operator can then publish the key to satisfy his customer, but we have no contractual control over the DNS operator nor any RFC to make that compulsory. I guess we could have an expiration timer on the key, but who should set that timer then ? Let's say a regular secure transfer can be done in 3 days, what is a reasonable timer? 1 week ? And should the gaining registrar set that timer ? And what if a gaining registrar sets the timer to 1 year? Should the registry prohibit that by local policy ? So suppose a registry does set a local policy of max 2 weeks for the timer. Then the timer can also be set by the losing registrar based on the local policy of the registry, and we don't have to communicate that timer over the protocol. It can be set in the cooperating DNS operator's provisioning system, or even be deleted by hand at will. The only thing a keyrelay command does is relay a key to facilitate a secure transfer process for those that want on both sides, but that is not mandatory to implement for every registrar or DNS operator. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRAWTmAAoJEDqHrM883Agn68wH/1hKS2KI1nVYQLpZaeiYWHO1 ZOPZQ4Ya80fNtTsGiXaXniLeuFXJ4y51wbj4Zn5y4e7vW3ArogbblzRTEtlV05/6 00v5rZN+6QjGPjIj3Rr50EHmFAA86MravJRmOxQ90n937fYC5yXL2VNSoSxkHy3H vRWY9pvNPDaH8v3Jx2f1id/ConKvfRlvTvmH6NMZkWFPKG7f6oVBOWyWXgUhii72 hP7KL5vRnr2JWWyCjGN4Dd+C12S42X40lquhqiJG626BZw55LP41r/IAMzdIzlft i5N7cry2TRhz9BA9KdcpdVdtQPnwNs7ouahIKfiDSuHnySuWra85PTmg4Bi3uvI= =6POX -----END PGP SIGNATURE----- From Klaus.Malorny@knipp.de Thu Jan 24 09:09:16 2013 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 E28F121F8994 for ; Thu, 24 Jan 2013 09:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9clbUljkQYC for ; Thu, 24 Jan 2013 09:09:16 -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 3E8A821F8884 for ; Thu, 24 Jan 2013 09:09:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 7615151; Thu, 24 Jan 2013 18:09:15 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id kf5gRhmoOx5c; Thu, 24 Jan 2013 18:09: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 5B2A750; Thu, 24 Jan 2013 18:09:14 +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 r0OH9Ere004923; Thu, 24 Jan 2013 18:09:14 +0100 (MEZ) Message-ID: <51016ABA.50506@knipp.de> Date: Thu, 24 Jan 2013 18:09:14 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> <51012783.2000401@sidn.nl> <5101337C.5090107@knipp.de> <510164E6.2000609@sidn.nl> In-Reply-To: <510164E6.2000609@sidn.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 17:09:17 -0000 On 24/01/13 17:44, Antoin Verschuren wrote: > Op 24-01-13 14:13, Klaus Malorny schreef: >> >> I cannot agree. There are certain expectations with the protocol, >> namely that the current registrar performs the necessary steps to >> have the DNSKEYs published on the domain's name servers, and this >> is already "process". > > Ah, I see how you look at it. > If that's the case, then we should make DNSSEC mandatory, which it > isn't. (though I would like it :-)) > > Secure transfers are not mandatory as well. > The only thing koch-dnsop-dnssec-operator-change describes is "if you > want to do a secure transfer, this is how you can do it". > We don't say you MUST do secure transfers because there is allways an > alternative to go insecure and we cannot mandate DNSSEC. > > So if a key is relayed to a registrar, it is expected that he relays > the key to the DNS operator that is appointed by the registant. The > DNS operator can then publish the key to satisfy his customer, but we > have no contractual control over the DNS operator nor any RFC to make > that compulsory. > > I guess we could have an expiration timer on the key, but who should > set that timer then ? Let's say a regular secure transfer can be done > in 3 days, what is a reasonable timer? 1 week ? And should the gaining > registrar set that timer ? And what if a gaining registrar sets the > timer to 1 year? Should the registry prohibit that by local policy ? > So suppose a registry does set a local policy of max 2 weeks for the > timer. > Then the timer can also be set by the losing registrar based on the > local policy of the registry, and we don't have to communicate that > timer over the protocol. It can be set in the cooperating DNS > operator's provisioning system, or even be deleted by hand at will. > > The only thing a keyrelay command does is relay a key to facilitate a > secure transfer process for those that want on both sides, but that is > not mandatory to implement for every registrar or DNS operator. > Hi Antoin, while it would be a bit too lax for me, if it is the desired design principle to give no assurances about what the registrar does with the DNSKEY data in the message, you also need not to give any assurances on the expiration timestamp I suggested to be relayed along with the DNSKEYs. Let it simply be a hint to the (potentially) losing registrar. Regards, Klaus From JGould@verisign.com Thu Jan 24 12:51:28 2013 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 518431F0CDF for ; Thu, 24 Jan 2013 12:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OzxiaDFP1dq for ; Thu, 24 Jan 2013 12:51:21 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id B01D71F0CAF for ; Thu, 24 Jan 2013 12:51:18 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUQGexdSxj69tpdgpeBnRfs9rFmJz4kU2@postini.com; Thu, 24 Jan 2013 12:51:20 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r0OKpEWo014448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 15:51:14 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 15:51:08 -0500 From: "Gould, James" To: Klaus Malorny , "provreg@ietf.org" Thread-Topic: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt Thread-Index: AQHN+gvRwHVCYzDg3UC6KIHJMuGj3ZhYmosAgAAgIICAAA5GAIAAOugAgAAG8gD//+bcTg== Date: Thu, 24 Jan 2013 20:51:07 +0000 Message-ID: References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> <51012783.2000401@sidn.nl> <5101337C.5090107@knipp.de> <510164E6.2000609@sidn.nl>,<51016ABA.50506@knipp.de> In-Reply-To: <51016ABA.50506@knipp.de> 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 Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 24 Jan 2013 20:51:29 -0000 Antoin,=0A= =0A= The draft looks to be a good starting point. Below is some feedback which = overlaps a little with Klaus's feedback:=0A= =0A= 1. I too believe that the authinfo should be a required element. This is u= seful for the losing registrar to verify prior to taking action. =0A= 2. I find it interesting that this is the first example of an EPP protocol = extension. You might want to consider making this into a mapping where the= object is keyrelay. The create would create the keyrelay and the info res= ponse would be used in the poll message. You can even generate a server un= ique identifier for the tracking of the keyrelay (was is dequeued and poten= tially to enable the losing registrar to mark it as accepted or rejected). = This might be over-engineering, but making it into an object with various = commands (create, update, info, delete) to have the registry tracking the f= low might be of use.=0A= 3. You might want to allow the gaining registrar to pass the key along with= the associated set of DS records if the registry supports the DS Data Inte= rface of RFC 5910. In this case the losing registrar doesn't need to gener= ate the DS and update the domain in the registry. I wouldn't not recommend= having the registry do any automatic DS updates, so the losing registrar w= ould need to support setting the appropriate DS. =0A= =0A= JG=0A= =0A= James F. Gould=0A= Verisign=0A= =0A= ________________________________________=0A= From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Klau= s Malorny [Klaus.Malorny@knipp.de]=0A= Sent: Thursday, January 24, 2013 12:09 PM=0A= To: provreg@ietf.org=0A= Subject: Re: [provreg] Fwd: New Version Notification for draft-giebe= n-epp-keyrelay-00.txt=0A= =0A= On 24/01/13 17:44, Antoin Verschuren wrote:=0A= > Op 24-01-13 14:13, Klaus Malorny schreef:=0A= >>=0A= >> I cannot agree. There are certain expectations with the protocol,=0A= >> namely that the current registrar performs the necessary steps to=0A= >> have the DNSKEYs published on the domain's name servers, and this=0A= >> is already "process".=0A= >=0A= > Ah, I see how you look at it.=0A= > If that's the case, then we should make DNSSEC mandatory, which it=0A= > isn't. (though I would like it :-))=0A= >=0A= > Secure transfers are not mandatory as well.=0A= > The only thing koch-dnsop-dnssec-operator-change describes is "if you=0A= > want to do a secure transfer, this is how you can do it".=0A= > We don't say you MUST do secure transfers because there is allways an=0A= > alternative to go insecure and we cannot mandate DNSSEC.=0A= >=0A= > So if a key is relayed to a registrar, it is expected that he relays=0A= > the key to the DNS operator that is appointed by the registant. The=0A= > DNS operator can then publish the key to satisfy his customer, but we=0A= > have no contractual control over the DNS operator nor any RFC to make=0A= > that compulsory.=0A= >=0A= > I guess we could have an expiration timer on the key, but who should=0A= > set that timer then ? Let's say a regular secure transfer can be done=0A= > in 3 days, what is a reasonable timer? 1 week ? And should the gaining=0A= > registrar set that timer ? And what if a gaining registrar sets the=0A= > timer to 1 year? Should the registry prohibit that by local policy ?=0A= > So suppose a registry does set a local policy of max 2 weeks for the=0A= > timer.=0A= > Then the timer can also be set by the losing registrar based on the=0A= > local policy of the registry, and we don't have to communicate that=0A= > timer over the protocol. It can be set in the cooperating DNS=0A= > operator's provisioning system, or even be deleted by hand at will.=0A= >=0A= > The only thing a keyrelay command does is relay a key to facilitate a=0A= > secure transfer process for those that want on both sides, but that is=0A= > not mandatory to implement for every registrar or DNS operator.=0A= >=0A= =0A= Hi Antoin,=0A= =0A= while it would be a bit too lax for me, if it is the desired design princip= le to=0A= give no assurances about what the registrar does with the DNSKEY data in th= e=0A= message, you also need not to give any assurances on the expiration timesta= mp I=0A= suggested to be relayed along with the DNSKEYs. Let it simply be a hint to = the=0A= (potentially) losing registrar.=0A= =0A= Regards,=0A= =0A= Klaus=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= provreg mailing list=0A= provreg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/provreg=0A= From Antoin.Verschuren@sidn.nl Fri Jan 25 01:26:55 2013 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 EBD3F21F880E for ; Fri, 25 Jan 2013 01:26: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrzn34LEQ8Or for ; Fri, 25 Jan 2013 01:26:55 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id D97DB21F888B for ; Fri, 25 Jan 2013 01:26:54 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r0P9Qr6Q025100-r0P9Qr6S025100 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Fri, 25 Jan 2013 10:26:53 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 25 Jan 2013 10:26:53 +0100 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 25 Jan 2013 10:26:53 +0100 Message-ID: <51024FDC.8040002@sidn.nl> Date: Fri, 25 Jan 2013 10:26:52 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> <51012783.2000401@sidn.nl> <5101337C.5090107@knipp.de> <510164E6.2000609@sidn.nl> <51016ABA.50506@knipp.de> In-Reply-To: <51016ABA.50506@knipp.de> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 25 Jan 2013 09:26:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 24-01-13 18:09, Klaus Malorny schreef: > while it would be a bit too lax for me, if it is the desired > design principle to give no assurances about what the registrar > does with the DNSKEY data in the message, you also need not to give > any assurances on the expiration timestamp I suggested to be > relayed along with the DNSKEYs. Let it simply be a hint to the > (potentially) losing registrar. Hi Klaus, We have no principal objection to an optional expire field in the keyrelay command just because we do not see any use for it in the experiences with our registrars, but if other registries might want to force their registrars by policy to have their 3th party DNS operators to enter resource records in DNS for a specific time, we wish them luck. So how would such an expire field look like? Would it be an expire timer, like a TTL, or an expire date (not valid after yyyymmdd, unixtime, someting else?) Do you have any sugestion for a field definition? - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRAk/cAAoJEDqHrM883Agnq74H/0wM5ZopQK0AIwrlpCLXDqbE DAplMj8VxskjNHklfJcvIzNpoBA1/l+oFCipY2jeKACvqUkV3X43mAq6oJ5gnIi+ bSnzI604C1sW4+4LOZQx3fj5kUXrRizkmgdUNOIGGouJW/G2RUNFF9V/370lCHhL cHt5HiMHYpCHDS9LwimSc+d4k3nAOZTQsiuHVN/am/8zMevcl3/kAQ8j9sw412o4 wCUCAaVKguGPHhQBpF6oBEYkmlUp6V9C5l8GR+tDGkx1cj4bXMosMl6ennpNMb1x 4eEofXjpkD3cfM6FsXybYedTH1LLOiQmXAu98tHnyoSTNLbA2DyvCY4EZnt1Mtk= =Y+T+ -----END PGP SIGNATURE----- From miekg@atoom.net Fri Jan 25 02:18:23 2013 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 5A8F621F8831 for ; Fri, 25 Jan 2013 02:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.31 X-Spam-Level: * X-Spam-Status: No, score=1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNszKQSomSpR for ; Fri, 25 Jan 2013 02:18:22 -0800 (PST) Received: from elektron.atoom.net (37-251-95-53.FTTH.ispfabriek.nl [37.251.95.53]) by ietfa.amsl.com (Postfix) with ESMTP id AC80F21F8830 for ; Fri, 25 Jan 2013 02:18:22 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id BB29E3FF2F; Fri, 25 Jan 2013 11:18:16 +0100 (CET) Date: Fri, 25 Jan 2013 11:18:16 +0100 From: Miek Gieben To: provreg@ietf.org Message-ID: <20130125101816.GB15307@miek.nl> Mail-Followup-To: provreg@ietf.org References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> <51012783.2000401@sidn.nl> <5101337C.5090107@knipp.de> <510164E6.2000609@sidn.nl> <51016ABA.50506@knipp.de> <51024FDC.8040002@sidn.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <51024FDC.8040002@sidn.nl> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 25 Jan 2013 10:18:23 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [provreg] Fwd: New Version No= ti..." ] > We have no principal objection to an optional expire field in the > keyrelay command just because we do not see any use for it in the > experiences with our registrars, but if other registries might want to > force their registrars by policy to have their 3th party DNS operators > to enter resource records in DNS for a specific time, we wish them luck. >=20 > So how would such an expire field look like? > Would it be an expire timer, like a TTL, or an expire date (not valid > after yyyymmdd, unixtime, someting else?) > Do you have any sugestion for a field definition? I think using the element from 5730 is the right thing to do. Regards, --=20 Miek Gieben http://miek.nl --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlECW+gACgkQJYuFzziA0PY+YACgkLwgClnOx5nxvAKNpvlkDxNs d7oAn2zKVMUZUnuLU1yMeZHFHz7KKfW+ =pxfE -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From david@dnservices.co.za Fri Jan 25 02:21:10 2013 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 9391421F882B for ; Fri, 25 Jan 2013 02:21:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpxhR88e+X1r for ; Fri, 25 Jan 2013 02:21:09 -0800 (PST) Received: from mail.registry.net.za (mail.registry.net.za [IPv6:2001:43f8:30::236]) by ietfa.amsl.com (Postfix) with ESMTP id 505B021F86F0 for ; Fri, 25 Jan 2013 02:20:56 -0800 (PST) Received: from [IPv6:2001:43f8:30:0:299d:e98b:3b0c:d9f8] (unknown [IPv6:2001:43f8:30:0:299d:e98b:3b0c:d9f8]) by mail.registry.net.za (Postfix) with ESMTPSA id BE764807D0 for ; Fri, 25 Jan 2013 12:20:53 +0200 (SAST) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.registry.net.za BE764807D0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dnservices.co.za; s=mail; t=1359109253; bh=3IJdW/UO6UGaLRRXLQ3lHnw/sVHM0sTDLfPAshZX4Eo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=yo7AKNvyOp/uvst7hfb0WTfNOsyqa2vx1BSrXH+yvt78Yd7a0PHLcnQVLSwOwpnf5 CSdpRyhgbG+G7LIavncH2mgeAw1nAjfuMCl1OH2qTqoH3rV2np5R6py8KC96FY2cBp dbQiDIjHoeI1vkQhd+hm65uPf2OBckceL6TiuyYU= Message-ID: <51025C86.3010605@dnservices.co.za> Date: Fri, 25 Jan 2013 12:20:54 +0200 From: David Peall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: provreg@ietf.org References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> In-Reply-To: <5100EF14.4080203@sidn.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 25 Jan 2013 10:21:10 -0000 This is a great concept. It would be useful for the request for a keyrelay to create pending action. This allows the registry to optionally perform some validation steps; to deliver the poll message to the losing registrar; to get a response back from the registrar as to the success of the request; to perform a validation of the response. Then return this pending result to the gaining registrar provide feedback and thus complete the transaction. Possible issue could be the request for invalid DNSKEY data to be inserted that can crash bind? Regards -- David Peall Domain Name Services On 24/01/2013 10:21, Antoin Verschuren wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > This draft may be of interest to this list. > At SIDN, we have documented how we intend to implement secure > transfers of DNSSEC domains and this draft is to describe the EPP > command we're going to use for that so it may be standardized. > Comments are welcome to the authors or on this list. > > A new version of I-D, draft-gieben-epp-keyrelay-00.txt > has been successfully submitted by R. (Miek) Gieben and posted to the > IETF repository. > > Filename: draft-gieben-epp-keyrelay > Revision: 00 > Title: Key Relay Mapping for the Extensible Provisioning Protocol > Creation date: 2013-01-20 > WG ID: Individual Submission > Number of pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-gieben-epp-keyrelay-00.txt > Status: http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay > Htmlized: http://tools.ietf.org/html/draft-gieben-epp-keyrelay-00 > > > Abstract: > This document describes an Extensible Provisioning Protocol (EPP) > extension mapping for the purpose of relaying DNSSEC key material > from a one registrar to another. The mapping introduces > as a new command in EPP. > > This command will help facilitating a transfer of a domain while > keeping DNSSEC's chain of trust intact. > > > > > > The IETF Secretariat > > > - -- > Antoin Verschuren > > Technical Policy Advisor SIDN > Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 M: +31 6 23368970 > Mailto: antoin.verschuren@sidn.nl > XMPP: antoin.verschuren@jabber.sidn.nl > HTTP://www.sidn.nl/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJRAO8OAAoJEDqHrM883AgnGn8IAI2qQdBdXSYZULn3QlmwUSDS > nL7QAyaDwTdd6hoc9nU8mMdBYQ7nGFewrhKrrrs5HNY/zxVPjsDgzyJ9duJ5Y9lL > 6TBdPU6zL+1d6gYqyxXWWzo8YnbsBSW3Vf0Nq1YCtdhPkbPOVQwHQKnHdkRr6cjh > cMCPXTMfXGjLJ08fa6uKSX39S+s7H9iMHO9YwIk4MbNCeyWkwgMvSkSfqQdyQcrt > Jx0zczOD/RAo55G8nQgSVMHh31h5e71t/qR4QKSsG5EOyDs4dQM3kOmqjBVX90wu > WyRLtcxr0CYwyFSgltWYx7TEam/1vFLnoLSavUUT9SsbK/3IS+xb7WOaBs66m04= > =XH3D > -----END PGP SIGNATURE----- > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From Klaus.Malorny@knipp.de Fri Jan 25 02:40:38 2013 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 DB5D021F85DA for ; Fri, 25 Jan 2013 02:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0FLylIXxT2c for ; Fri, 25 Jan 2013 02:40:38 -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 580D521F85CC for ; Fri, 25 Jan 2013 02:40:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id BDC6C45; Fri, 25 Jan 2013 11:40:36 +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 PLYlQGQ+pquG; Fri, 25 Jan 2013 11:40:31 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 395E344; Fri, 25 Jan 2013 11:40:31 +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 r0PAeVaX025702; Fri, 25 Jan 2013 11:40:31 +0100 (MEZ) Message-ID: <5102611F.6060100@knipp.de> Date: Fri, 25 Jan 2013 11:40:31 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51010C90.3090800@knipp.de> <51012783.2000401@sidn.nl> <5101337C.5090107@knipp.de> <510164E6.2000609@sidn.nl> <51016ABA.50506@knipp.de> <51024FDC.8040002@sidn.nl> In-Reply-To: <51024FDC.8040002@sidn.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt 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, 25 Jan 2013 10:40:39 -0000 On 25/01/13 10:26, Antoin Verschuren wrote: > > Hi Klaus, > > We have no principal objection to an optional expire field in the keyrelay > command just because we do not see any use for it in the experiences with our > registrars, but if other registries might want to force their registrars by > policy to have their 3th party DNS operators to enter resource records in DNS > for a specific time, we wish them luck. > > So how would such an expire field look like? Would it be an expire timer, > like a TTL, or an expire date (not valid after yyyymmdd, unixtime, someting > else?) Do you have any sugestion for a field definition? > Hi Antoin, since the submission time may differ from the read time of the message (although likely only minutes), I suggest not to use a relative time, but an absolute, ideally the XML Schema data type "dateTime". BTW, I am still a bit puzzled that you and/or registrars see no use for that. With a registrar hat on, I wouldn't want to accept arbitrary DNSKEY records from third parties and keep them for unlimited time in the zone. But maybe I am in a negligible minority ;-) Regards, Klaus From miekg@atoom.net Fri Jan 25 03:35:39 2013 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 1A2CB21F86D6 for ; Fri, 25 Jan 2013 03:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.31 X-Spam-Level: * X-Spam-Status: No, score=1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpUtc56rSNkN for ; Fri, 25 Jan 2013 03:35:38 -0800 (PST) Received: from elektron.atoom.net (37-251-95-53.FTTH.ispfabriek.nl [37.251.95.53]) by ietfa.amsl.com (Postfix) with ESMTP id 61F6921F866F for ; Fri, 25 Jan 2013 03:35:38 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id A72564003F; Fri, 25 Jan 2013 12:35:37 +0100 (CET) Date: Fri, 25 Jan 2013 12:35:37 +0100 From: Miek Gieben To: provreg@ietf.org Message-ID: <20130125113537.GD15307@miek.nl> Mail-Followup-To: provreg@ietf.org References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51025C86.3010605@dnservices.co.za> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eqp4TxRxnD4KrmFZ" Content-Disposition: inline In-Reply-To: <51025C86.3010605@dnservices.co.za> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: ,