Re: [eppext] I-D Action: draft-lozano-ietf-eppext-registrar-expiration-date-00.txt

"Gould, James" <JGould@verisign.com> Fri, 22 January 2016 14:06 UTC

Return-Path: <JGould@verisign.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9B21A7013 for <eppext@ietfa.amsl.com>; Fri, 22 Jan 2016 06:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 l64ybtu7JUcs for <eppext@ietfa.amsl.com>; Fri, 22 Jan 2016 06:06:38 -0800 (PST)
Received: from mail-qg0-x264.google.com (mail-qg0-x264.google.com [IPv6:2607:f8b0:400d:c04::264]) (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 4AB821A7012 for <eppext@ietf.org>; Fri, 22 Jan 2016 06:06:38 -0800 (PST)
Received: by mail-qg0-x264.google.com with SMTP id b35so4094437qge.0 for <eppext@ietf.org>; Fri, 22 Jan 2016 06:06:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=Xi3DzMnAus2gHlqtAqh1ZGhyr34v17X65/hT4xI+ARQ=; b=biIoJKiQqtZngLkBiHTsu8CR4oOHydKY5l6xNLR4GvkyJJL2MYuTvnO0IbgmFnFPEA 1h+iQ0ALkRgM5iSVEFBv296QMOlcxKTLlQ3MVCRko8TV6jJoGcKC+ZdqOqL1dsnsNeP5 WxJi3k5Luq6hRIm1VZhtyweKqvvrWdVZVw7yu81QDEGtxeZYWvv51qS3+qJlpv3IzHOR 1BurQbIH7Wg+diVNB+TY7sr0n4+kFtU9uZ2f90A7q2zH5PbZ3/Bftp2A5fakSk7zzg2P D1VJ1EbkBHbAGkAwkITl3EwYsw7rKbi1UQzUTU3cryhDiP/QoXibCuxPDUfI6xOxyuNB pjeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=Xi3DzMnAus2gHlqtAqh1ZGhyr34v17X65/hT4xI+ARQ=; b=cWbvefPtO0ErbxsOCixlX679YxnpFWRaJ9Uwrsk67hfw1ROOOd98cfOhFhh84W3UWj 1hYEPAmmhY1p/y6gyldY1w+oqS7Tjd0RTCKHsq1+7Yo2nVJOIiF4Cf+BopqiFF3Gjs/R SPLqeVfNCkcoWFK7nlDL2dogdmJA/iP9P2QHHClBwrrIwKgNZIo9WkJoE7//QxZSyrQg zaOsc/PoIfYa0CLDyjXNTLZZRcPRatoHyY20voxnVjAoy2Y30cBoKMliVH1gKuePVzfu RbqfT+X1q6azv5Iecepu+HYnQM+3wydvrrHts/abkH2l/umbxCfv8MtyD/47oqrSbTIX DQcg==
X-Gm-Message-State: AG10YOQWYw71NsekeEONP9h4mDmxXkWNvK81iTw805IOezzq7AK3s55uYqvDEUZo4a2zz+IxJDGOi3YblH0N7JOx4f+pnOy9
X-Received: by 10.55.195.67 with SMTP id a64mr3933911qkj.4.1453471597285; Fri, 22 Jan 2016 06:06:37 -0800 (PST)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id d3sm863195qkb.3.2016.01.22.06.06.36 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 22 Jan 2016 06:06:37 -0800 (PST)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u0ME6aKv027959 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jan 2016 09:06:36 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 22 Jan 2016 09:06:34 -0500
From: "Gould, James" <JGould@verisign.com>
To: Francisco Arias <francisco.arias@icann.org>
Thread-Topic: [eppext] I-D Action: draft-lozano-ietf-eppext-registrar-expiration-date-00.txt
Thread-Index: AQHRVII5CddH1x7oPEyvfpfQ7AYzkZ8GX2rQgABaQAD//9n8gIABU1gA
Date: Fri, 22 Jan 2016 14:06:33 +0000
Message-ID: <3143A038-A717-45DD-84A3-B43680CC19BC@verisign.com>
References: <20160121193028.13313.82104.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4A133A9D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <3AFA41DD-C236-4E1E-92FB-BDF30BE8E94B@verisign.com> <D8854036-4108-4E76-8DF3-B4F563FB147C@icann.org>
In-Reply-To: <D8854036-4108-4E76-8DF3-B4F563FB147C@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_004_3143A038A71745DD84A3B43680CC19BCverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/1q3kJWBmdGbv0RxHDFp_SnBm8uE>
Cc: "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] I-D Action: draft-lozano-ietf-eppext-registrar-expiration-date-00.txt
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2016 14:06:42 -0000

Francisco,

What is contained in section 2.1 of “Draft Thick RDDS (Whois) Consensus Policy” assumes that the Consensus Policy requires the display of the “Registrar Registration Expiration Date” field as a separate and additive value to the existing “Registry Expiry Date” field.   The only reference to the “Registrar Registration Expiration Date” in the Consensus Policy is provided in the sample Whois output of section 1.4.2 of the RAA.  There is a single expiration date field in the RAA ( “Registrar Registration Expiration Date” ), in the Consensus Policy ( “Registrar Registration Expiration Date” ), and in the RA ( “Registry Expiry Date” ).

There is no mention of a second expiration date field or its meaning in any of the agreements or the Consensus Policy.  There is also no description of the “Registrar Registration Expiration Date” in the RAA or Consensus Policy.  I believe it is a reach to assume that the “Registrar Registration Expiration Date” field in the RAA and the Consensus Policy has a different purpose then the “Registry Expiry Date” field in the RA.  In fact the value of these fields are exactly the same "2010-10-08T00:44:59Z” across all three.  A sample does not make a specification in any of these documents, and there is no basis to make the case that the “Registrar Registration Expiration Date” field has a different meaning or should override the “Registry Expiry Date” field in Thick RDDS. Any variance of the values in the wild is an architectural factor and not a factor of having a different purpose.

The existing registry domain expiration date should be used in Thick RDDS and we should not attempt to invent a second field for expiration date.


—


JG


[cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Jan 21, 2016, at 5:51 PM, Francisco Arias <francisco.arias@icann.org<mailto:francisco.arias@icann.org>> wrote:

Hi Jim,

Please see https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-policy-draft-25nov15-en.pdf, particularly section 2.1, starting on page 8. This document is in public comment at https://www.icann.org/public-comments/rdds-output-2015-12-03-en until 31 January.

The draft provides a reference to the “parent” document of the aforementioned document, which is already in final form. Perhaps the reference in the draft should be to the child document?

Regards,

--
Francisco

On 1/21/16, 12:08 PM, "EppExt on behalf of Gould, James" <eppext-bounces@ietf.org<mailto:eppext-bounces@ietf.org> on behalf of JGould@verisign.com<mailto:JGould@verisign.com>> wrote:

Gustavo,

I agree with Scott, it is not clear the relationship between the two and the relevance in the registry of maintaining this value.  Can the registrar expiration date be greater then the domain expiration date, less then the domain expiration date, or completely different from the domain expiration date?  The reference for the ThickWhoisPolicy is incorrect in the draft.  Please provide the appropriate reference and highlight where in the Thick Whois Policy it defines the requirement for the registry to hold and display a registrar expiration date in addition to the authoritative domain expiration date.

Thanks,

—

JG




James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://133/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

On Jan 21, 2016, at 2:52 PM, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote:

-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: Thursday, January 21, 2016 2:30 PM
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Subject: I-D Action: draft-lozano-ietf-eppext-registrar-expiration-
date-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


       Title           : Registrar Registration Expiration Date
Extension Mapping for the Extensible Provisioning Protocol (EPP)
       Author          : Gustavo Lozano
Filename        : draft-lozano-ietf-eppext-registrar-expiration-
date-00.txt
Pages           : 15
Date            : 2016-01-21

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension mapping for the provisioning and management of the
  registrar registration expiration date for domain names stored in a
  shared central repository.  Specified in XML, this mapping extends
  the EPP domain name mapping.

Gustavo, I wish this document would explain what this value actually means given that registrars are not the authoritative source of information for domain expiration dates. Could you please add some text to the Introduction that explains the purpose of the value and what it means of the context of the expiration date maintained by registries? Can they ever be different? What does it mean if they are different? Why are both needed if they are supposed to be the same?

I'd also like to suggest that you add text to the different command descriptions to make it clear what the values represent when you're extending a renew, transfer, etc.

Scott

_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext