From nobody Wed May 20 01:32:53 2015 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688881A03FF for ; Wed, 20 May 2015 01:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz8VKZnc-8HS for ; Wed, 20 May 2015 01:32:51 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69771A0338 for ; Wed, 20 May 2015 01:32:50 -0700 (PDT) Received: by laat2 with SMTP id t2so62400861laa.1 for ; Wed, 20 May 2015 01:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KtzeqeVIPDFaCDwWJlHoZLJfmFdVUgL/1+N5aqiymE8=; b=a4lRVLH0cp57whbMRbWMjbCv+KJU3a9iY/1OX5SXJgycEO5TguVx8ajzzVs6W9jZDo z8Qar59IrW3ihWhrF45rEQXIXaz+aU1o7HVxbapKJFI/una8xjzZN0lWL69CgDcFDXTM KiV3tnBDqNZlwZ7OQQB6TNvvQvVrVIvltY5S7RYATEGPs+kkfgCX6SQAet5Ysj9/Jkfk cfQht24RqS31GTwzw2fifIOKFbzTEaTjajOFowvH6apfnHz5FqUM8xIFWX/nuI161onc J0Wz+yorx0XWRXFv23sK71xYbnvxfgeeB2mhO/G/SBGI6gP9mmu0vow4RykCnRf3YHoN 5qow== MIME-Version: 1.0 X-Received: by 10.152.234.139 with SMTP id ue11mr25133423lac.28.1432110769353; Wed, 20 May 2015 01:32:49 -0700 (PDT) Received: by 10.152.90.230 with HTTP; Wed, 20 May 2015 01:32:49 -0700 (PDT) In-Reply-To: <8CA76639-AA2E-4E05-93F0-10E5CCD86AB4@verisign.com> References: <8CA76639-AA2E-4E05-93F0-10E5CCD86AB4@verisign.com> Date: Wed, 20 May 2015 10:32:49 +0200 Message-ID: From: Bernhard Reutner-Fischer To: "Gould, James" Content-Type: multipart/alternative; boundary=001a1133a85cafbb0505167f4596 Archived-At: Cc: "ire@ietf.org" Subject: Re: [ire] Escrow, DNRD rdeDomain:trDate vs. rdeDomain:trnData X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 08:32:52 -0000 --001a1133a85cafbb0505167f4596 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 April 2015 at 19:40, Gould, James wrote: > Hi, > > I would go with what is defined > in draft-arias-noguchi-dnrd-objects-mapping as authoritative. > > The question raised is whether the rdeDomain:trDate, rdeContact:trDate, > rdeHost:trDate elements for XML and the rdeCsv:fTrDate element in the > =E2=80=9Cdomain=E2=80=9D, =E2=80=9Chost=E2=80=9D, and =E2=80=9Ccontact=E2= =80=9D CVS files should be removed. These > elements match up to what is supported in the EPP RFC=E2=80=99s. For exa= mple in > the EPP Domain Name RFC 5731, the domain info response includes the > optional domain:trDate element that is separate from the elements returne= d > in a transfer query response. Although the domain:trDate element could b= e > derived from the transfer query response domain:acDate element, from a da= ta > model perspective they may be separate attributes and subsequently the da= ta > escrow should support both the rdeDomain:trDate, rdeContact:trDate, > rdeHost:trDate elements in the XML model and the rdeCsv:fTrDate element i= n > the CSV model. Thoughts on this? > Since the trDate denotes the last successful object transfer as opposed to the trnData describing a currently pending transfer i think it is OK as is, on second thought. I cannot find the word "successful" around the rdeCsv:fTrDate though but i'm not using CSV. > > On the status of the drafts, Barry Leiba, the IETF Applications Area > (app) Area Director (AD), agreed to sponsor the > draft-arias-noguchi-registry-data-escrow and > draft-arias-noguchi-dnrd-objects-mapping drafts for standards track. > Looking forward to that. > Barry will review the drafts and his feedback will be incorporated into > subsequent versions of the drafts. We will be asking for Implementation > Status information similar to section 6 of draft-ietf-eppext-launchphase, > so if you do have Implementation Status information that you would like > incorporated into draft-arias-noguchi-registry-data-escrow or > draft-arias-noguchi-dnrd-objects-mapping, please forward it on. > I will leave it to our customer to provide any Implementation Status information. thanks, --001a1133a85cafbb0505167f4596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 3 April 2015 at 19:40, Gould, James <JGould@verisign.com> = wrote:
Hi,

I would go with what is defined in=C2=A0draft-arias-noguchi-dnrd-objec= ts-mapping as authoritative. =C2=A0

The question raised is whether the rdeDomain:trDate, rdeContact:trDate= , rdeHost:trDate elements for XML and the rdeCsv:fTrDate element in the =E2= =80=9Cdomain=E2=80=9D, =E2=80=9Chost=E2=80=9D, and =E2=80=9Ccontact=E2=80= =9D CVS files should be removed.=C2=A0 These elements match up to what is s= upported in the EPP RFC=E2=80=99s.=C2=A0 For example in the EPP Domain Name RFC 573= 1, the domain info response includes the optional domain:trDate element tha= t is separate from the elements returned in a transfer query response.=C2= =A0 Although the domain:trDate element could be derived from the transfer query response domain:acDate element, from a data model = perspective they may be separate attributes and subsequently the data escro= w should support both the=C2=A0rdeDomain:trDate, rdeContact:trDate, rdeHost= :trDate=C2=A0elements in the XML model and the rdeCsv:fTrDate element in the CSV model.=C2=A0 Thoughts on this?
=

Since the trDate denotes the last su= ccessful object transfer as opposed to the trnData describing a currently p= ending transfer i think it is OK as is, on second thought.
I cann= ot find the word "successful" around the rdeCsv:fTrDate though bu= t i'm not using CSV.

On the status of the drafts, Barry Leiba, the IETF Applications Area (= app) Area Director (AD), =C2=A0agreed to sponsor the draft-arias-noguchi-re= gistry-data-escrow and draft-arias-noguchi-dnrd-objects-mapping drafts for = standards track.

Looking forwa= rd to that.
=C2=A0
=C2=A0Barry will review the drafts and his feedback will be incorporated into subsequent ve= rsions of the drafts.=C2=A0 We will be asking for Implementation Status inf= ormation similar to section 6 of draft-ietf-eppext-launchphase, so if you d= o have Implementation Status information that you would like incorporated into draft-arias-noguchi-registry-data-es= crow or draft-arias-noguchi-dnrd-objects-mapping, please forward it on. =C2= =A0

I will leave it to our cust= omer to provide any Implementation Status information.

=
thanks,
--001a1133a85cafbb0505167f4596-- From nobody Wed May 20 01:50:19 2015 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4781B3598 for ; Wed, 20 May 2015 01:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxOUU6Arv9T6 for ; Wed, 20 May 2015 01:50:17 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8391B359F for ; Wed, 20 May 2015 01:50:16 -0700 (PDT) Received: by lagr1 with SMTP id r1so62930904lag.0 for ; Wed, 20 May 2015 01:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sfV6/RkFQ83aPV/+3/Q2nyhG0VCkavgQ8AvqaA300pM=; b=aPKZOREGMt3Jy/VKYFX/4QZVmZeTUww73huBBQhkuwzLS9Vf2C8bZGs1obSm8rj8xg k4SLeZFIvP/rH68tDI+ynedT+bcD+YNq8lzoiqFIDAiT21YMRPEr6XZdk/RKzkELgyQ/ KC3ch3otDy2Fk47LMtMcNAfhqFJxwABE43SiH9JqKYx2DUnsBzr5UZwFczQUDTiH3AHf 3k8rJ6g+k8vrFmfKUWITq7/vCxWFeCFdfaGLyUwX73BRAUzH6nUrWU2HjKV8tr+IuEM+ LIHbjqypwF+8jKo0WFzQzTUMOEKmDrqQY1gEaUBIXU9RwdCWHoZ7K8lew4erJsKaDgy5 pz0Q== MIME-Version: 1.0 X-Received: by 10.112.63.201 with SMTP id i9mr21395339lbs.93.1432111815469; Wed, 20 May 2015 01:50:15 -0700 (PDT) Received: by 10.152.90.230 with HTTP; Wed, 20 May 2015 01:50:15 -0700 (PDT) Date: Wed, 20 May 2015 10:50:15 +0200 Message-ID: From: Bernhard Reutner-Fischer To: ire@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [ire] XML rgpStatus definition X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 08:50:18 -0000 Hi, If i read rfc3915 (the EPP Grace Period Mapping) RGP state diagram correctly then a domain can only ever be in one gracePeriod. In https://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05 , however, specifies it as Where RFC3915 defines rgp:statusType as 1) Why is the rde:rgpStatus not a single element? Maybe for later extensions? Or is that just a copy'n pasto from the normal object's status? Just curious about this one.. 2) Some poor guy from donuts rightfully noted that the lack of a gracePeriod's endDate in the escrow-data is inconvenient. What about officially adding something like e.g.: thanks, From nobody Wed May 20 02:00:07 2015 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D21A00A7 for ; Wed, 20 May 2015 02:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_pq5yrbhv7J for ; Wed, 20 May 2015 02:00:01 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6681A1AC9 for ; Wed, 20 May 2015 02:00:00 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 1DD385D for ; Wed, 20 May 2015 10:59:59 +0200 (MESZ) 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 QWWpntOuonLd for ; Wed, 20 May 2015 10:59:51 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 27A4B67 for ; Wed, 20 May 2015 10:59:51 +0200 (MESZ) Received: from [195.253.2.105] (thrawn.do.knipp.de [195.253.2.105]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August, 2006/8.13.3) with ESMTP id t4K8xptQ018525 for ; Wed, 20 May 2015 10:59:51 +0200 (MESZ) Message-ID: <555C4C9A.3080403@knipp.de> Date: Wed, 20 May 2015 10:58:02 +0200 From: Michael Bauland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ire@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ire] XML rgpStatus definition X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 09:00:07 -0000 Hi Bernhard, On 20.05.2015 10:50, Bernhard Reutner-Fischer wrote: > Hi, > > If i read rfc3915 (the EPP Grace Period Mapping) RGP state diagram > correctly then a domain can only ever be in one gracePeriod. I think the diagram is just for the redemption grace period, i.e., the one after domain deletion. I see no restriction saying that, e.g., add grace (addPeriod) and renew grace (renewPeriod) cannot occur at the same time. If you create a domain and directly afterwards manually renew it, then the domain is in add grace as well as renew grace and the registrar gets both fees refunded upon deletion. Cheers, Michael From nobody Wed May 20 02:08:28 2015 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40B61A1A42 for ; Wed, 20 May 2015 02:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEElHmbN9TLo for ; Wed, 20 May 2015 02:08:26 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6CB1A1BEF for ; Wed, 20 May 2015 02:08:25 -0700 (PDT) Received: by labbd9 with SMTP id bd9so64369231lab.2 for ; Wed, 20 May 2015 02:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZdJok7sw/nUL4oQ7ibMDxRMkg81DTRQJEJoxcQwr4Hs=; b=GA/3bJgrSP8eqHwRKy3mJx6RgA7BSJWDPnUpebQ6tFvTfYeUxnruVvSEQQBrjqWu5u 4vteApCDwAcM5eEBNb+ijMdf6RMdO3AFa+tKAhuIv5pu6+4fmpbrQ/m0eMW4k8hLpu4m 1zma4BLdwyHEYzwke56Z0rB8pZUzlKKLMBfy57wq0eupfgSYiPYVLdKo0P+hXFAIKwvV dlWGo57HI1IPr91i4t4IB4185bi0oa9yVj5E5ZcN0GBmn+cttYWjGPAr9pfk9c4YmvGV COMatFPepTElxzcOE+jQ79G+IJ/vWyU3uLXspV/EmXUwtGRzcMD/559VfBbN+Re1W6Cf 4XMA== MIME-Version: 1.0 X-Received: by 10.112.16.227 with SMTP id j3mr25070124lbd.43.1432112903838; Wed, 20 May 2015 02:08:23 -0700 (PDT) Received: by 10.152.90.230 with HTTP; Wed, 20 May 2015 02:08:23 -0700 (PDT) In-Reply-To: <555C4C9A.3080403@knipp.de> References: <555C4C9A.3080403@knipp.de> Date: Wed, 20 May 2015 11:08:23 +0200 Message-ID: From: Bernhard Reutner-Fischer To: Michael Bauland Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ire@ietf.org Subject: Re: [ire] XML rgpStatus definition X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 09:08:27 -0000 On 20 May 2015 at 10:58, Michael Bauland wrote: > Hi Bernhard, > > On 20.05.2015 10:50, Bernhard Reutner-Fischer wrote: >> Hi, >> >> If i read rfc3915 (the EPP Grace Period Mapping) RGP state diagram >> correctly then a domain can only ever be in one gracePeriod. > > I think the diagram is just for the redemption grace period, i.e., the > one after domain deletion. > > I see no restriction saying that, e.g., add grace (addPeriod) and renew > grace (renewPeriod) cannot occur at the same time. If you create a > domain and directly afterwards manually renew it, then the domain is in > add grace as well as renew grace and the registrar gets both fees > refunded upon deletion. Ok, i see, this is covered by the registry operational policy then. So what do you think about the rgp endDate in the escrow data? thanks,