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

Rubens Kuhl <rubensk@nic.br> Thu, 21 January 2016 23:32 UTC

Return-Path: <rubensk@nic.br>
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 BA83A1B2A41 for <eppext@ietfa.amsl.com>; Thu, 21 Jan 2016 15:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 zJpqmgcNZXYt for <eppext@ietfa.amsl.com>; Thu, 21 Jan 2016 15:32:52 -0800 (PST)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16981B2A47 for <eppext@ietf.org>; Thu, 21 Jan 2016 15:32:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 1F7D61E3014; Thu, 21 Jan 2016 21:32:48 -0200 (BRST)
X-Virus-Scanned: Debian amavisd-new at mail.nic.br
Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IEUTYPI4BZl; Thu, 21 Jan 2016 21:32:46 -0200 (BRST)
Received: from rubens.in.registro.br (unknown [IPv6:2001:12ff:0:3a::195]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id D60801E2FFC; Thu, 21 Jan 2016 21:32:45 -0200 (BRST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1453419165; bh=fytp6A8dA73OZhlS5Pes8mVcLrVkmd0pSoEMl6KmdAU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=AXVvLLhKepa0eQhovF1gVcvyZUA7qnL9qCJkWMRkMWYL11MjwjQdQljZKq46Tkbrk RaO59FATxIj3ZfEoxVF82JH0aJbyCgoJKfSD70w7lEWVk19pISrM2nxgahgg3gE2s7 /LMYSLbD2Oj/QdI4zCqqGzZQPsXJERfbB22fL5AE=
Content-Type: multipart/alternative; boundary="Apple-Mail=_F6862E5D-4CD2-407D-A94E-1BC6055954C5"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Rubens Kuhl <rubensk@nic.br>
In-Reply-To: <D8854036-4108-4E76-8DF3-B4F563FB147C@icann.org>
Date: Thu, 21 Jan 2016 21:32:45 -0200
Message-Id: <259804B5-1C31-4CF0-AFFB-1D658348F6E4@nic.br>
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>
To: Francisco Arias <francisco.arias@icann.org>
X-Mailer: Apple Mail (2.3112)
DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br D60801E2FFC
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/DzeaUTbgp98fClIK-N5wxnqb9dM>
Cc: gtld-tech@icann.org, "eppext@ietf.org" <eppext@ietf.org>, "Gould, James" <JGould@verisign.com>
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: Thu, 21 Jan 2016 23:32:54 -0000

Francisco,

It's possible that Jim and Scott were looking at https://www.icann.org/resources/pages/registrars/consensus-policies-en <https://www.icann.org/resources/pages/registrars/consensus-policies-en> to find an in-force consensus policy covering such requirement. I tried finding it there as well and failed as well... that is consistent with the information that although the policy was approved by GNSO Council and the Board (https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#2.c <https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#2.c>) has still not come through with its IRT (Implementation Review Team), which is why the document is still in public comment and the policy is still a draft. 

So, perhaps the I-D is a few weeks premature and the registries opposing it might see first whether that really becomes in-force ? 

I also wander what happened to the reseller information relaying, which was foreseen in the policy... 




Rubens



> Em 21 de jan de 2016, à(s) 20:51:000, Francisco Arias <francisco.arias@icann.org> escreveu:
> 
> Hi Jim,
> 
> Please see https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-policy-draft-25nov15-en.pdf <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 <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://42/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 <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 <https://www.ietf.org/mailman/listinfo/eppext>
>> 
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext