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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Fri, 22 January 2016 14:09 UTC

Return-Path: <shollenbeck@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 A07D21A702F for <eppext@ietfa.amsl.com>; Fri, 22 Jan 2016 06:09:21 -0800 (PST)
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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_22=0.6] 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 21G5Zeu5o_Uq for <eppext@ietfa.amsl.com>; Fri, 22 Jan 2016 06:09:20 -0800 (PST)
Received: from mail-qg0-x262.google.com (mail-qg0-x262.google.com [IPv6:2607:f8b0:400d:c04::262]) (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 26E581A702E for <eppext@ietf.org>; Fri, 22 Jan 2016 06:09:20 -0800 (PST)
Received: by mail-qg0-x262.google.com with SMTP id 6so4093822qgy.1 for <eppext@ietf.org>; Fri, 22 Jan 2016 06:09:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=aR3Zre+rinEK5l9hh1WOB5abAa3y900sysgrzE3XYOY=; b=KRwn/POYntXrKfc4ANxfB76IeJiV/k356gBH7jvTXvQa+xFKNvduGAvcX2XiYVB8UE v7lxcxUfmTL7y6dg7/Vh6ZIkyvgVRzconB8O0VkyWFNJsUVt78/6mxQLxy6K//SfT3E6 d6r0y7SMr5ddQ4u6MX5DSKCrw1Hi3N3B07MpmREXMbazBOseHsGveoYNcssvzZHh6vSC 4S3e80899qC9grTPqqpkrgO393bjkZSNhZfP8oeAiZ2oGhYoUSwyd6dZFNsGbJhZDbUW Ljl+e0HDHbrxfes+EcMDQvxkkKoP42Q1CJHGriGEK1cWkhJ13NNGSkeDpR+txzkJ8t73 oaWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=aR3Zre+rinEK5l9hh1WOB5abAa3y900sysgrzE3XYOY=; b=F1lFQACdV42USMDcl0TZbqPbCzaWW0Xy5gzO0x5rgERR0+sPtzFKEUPr2OPCg26LC6 6h3vaqdmDIuz8BVh44HBP8Cw18v3/FOBC332wQolRDcvTcXxsDd9oHERz02AyO3pQjUV pYwm0OGJGXOhq8hqKZztMz1fH3qEBYNt+M0u/4N8xVHPWUoFnIaWRA8Zloon6Powp5UC dQd1j3TjfDzQ1JW3GwMjrO55YmQdfjkCa18uBHOWCS3cPLzr0md/tD5AGW5kfzzws1h3 7w8isYLhHPg4iw6XvBpwh4QssgmmAhiT3nN7tHVSkPo0TrBA4YGeMc2B70vep8ZOO7wt Ri3w==
X-Gm-Message-State: AG10YOS6p+ajvOZWqMxyjBDGLdGe2zrJUgX4lXa88Lw/n/UYrJdpt3avXfFrxVWSSO/htvyBiV/tLYHFMC9/GWo2ZmA+vp74
X-Received: by 10.55.74.209 with SMTP id x200mr3780469qka.106.1453471759226; Fri, 22 Jan 2016 06:09:19 -0800 (PST)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id y135sm1013182qky.9.2016.01.22.06.09.19 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 22 Jan 2016 06:09:19 -0800 (PST)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u0ME9IHT001027 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jan 2016 09:09:18 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 22 Jan 2016 09:09:17 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Gustavo Lozano <gustavo.lozano@icann.org>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: I-D Action: draft-lozano-ietf-eppext-registrar-expiration-date-00.txt
Thread-Index: AQHRVII5CddH1x7oPEyvfpfQ7AYzkZ8GX2rQgACTRACAAJ8ckA==
Date: Fri, 22 Jan 2016 14:09:17 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A13DDF0@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <20160121193028.13313.82104.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F4A133A9D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <D2C6A87C.F0080%gustavo.lozano@icann.org>
In-Reply-To: <D2C6A87C.F0080%gustavo.lozano@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/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01D154F4.91A5CA50"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/YqRuElEuf6yKVl2AV7X7NAX6ZzI>
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:09:21 -0000

> -----Original Message-----
> From: Gustavo Lozano [mailto:gustavo.lozano@icann.org]
> Sent: Thursday, January 21, 2016 6:32 PM
> To: Hollenbeck, Scott; eppext@ietf.org
> Subject: Re: I-D Action: draft-lozano-ietf-eppext-registrar-expiration-
> date-00.txt
> 
> Scott,
> 
> I don't think it's a good idea to define the meaning of the
> registrar registration expiration date in this specification. The
> Registrar
> Accreditation Agreement 2013
> (https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-
> en#wh
> ois)
> defines that the Whois output of the Registrar must show the "Registrar
> Registration
> Expiration Date", and the draft Thick Whois Policy
> (https://whois.icann.org/sites/default/files/files/thick-rdds-
> consensus-pol
> icy-draft-25nov15-en.pdf)
> requires this field to be passed to the registry, who in turn will show
> it.

I will not support publication of an EPP extension RFC that is unclear about
the purpose of the extension or the fields that are being added. Something
needs to be added to the draft to make that purpose crystal clear. If that
means adding text to an external document, fine. However, you do need to
answer the questions I asked in my last note.
 
> I have seen domains (e.g. whois -h whois.pir.org pir.org / whois
> -h whois.godaddy.com pir.org) in the wild in which the registry
> expiration
> date
> is different from the registrar expiration date. It appears that
> sometimes
> is
> related to an auto-renew that has not been paid by the Registrant,
> other
> cases
> appear to be related to the business model of the registrar, etc.

Then this needs to be spelled out in the draft. We can't publish a
specification that is unclear about the meaning of the information being
exchanged, and we do need to be clear about how that information relates to
other information that's currently part of the protocol.

I really don't like the idea of standardizing broken or otherwise confusing
operational practices. Perhaps the policies and practices should be revised
to ensure that the information is consistent.
 
> From the I-D perspective, the registrar registration
> expiration date is just another data point with no meaning to the
> lifecycle of
> the domain name.

So what's the point of publishing meaningless data?

Scott