Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

Patrick Mevzek <pm@dotandco.com> Thu, 18 June 2020 01:31 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AD13A0828 for <regext@ietfa.amsl.com>; Wed, 17 Jun 2020 18:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=Yl5b9cVX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Qtf21635
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 Wl_Q4-7Q8KbJ for <regext@ietfa.amsl.com>; Wed, 17 Jun 2020 18:31:19 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6CF3A0824 for <regext@ietf.org>; Wed, 17 Jun 2020 18:31:19 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 874A85C0194 for <regext@ietf.org>; Wed, 17 Jun 2020 21:31:18 -0400 (EDT)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Wed, 17 Jun 2020 21:31:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=YtqZ2R9JLng9Irl2yBz/ny5KVpxk/wV c8yfHgIMoadk=; b=Yl5b9cVXmsQQ+iUof5bAe3t1kmEhX2ubv60rqSV/ojM4Hmj IjpEndxx5CwMpYQly4Rg/BNruAIdfTC/7cJUrZB1hLbkGB5fLN4uym60cQH1n/pu ytFDoZNXMRvgO34TFZzgf0HxJEhjeVUaZjPVG/mInLETOJuD1LNPoXdAPxnqMsFJ qACMf32+YfAmPHNWxZ6QLZFp9NNsksDJPz0kPLdWpGWkbCtXMMTlzDdgqtnlwIT4 +CniEB+pE6xvPajuib2vxLaVvJK8mN+bSuEXNnzDNpE3Kiq7c5fz5oF3V3FsA5yf evT9dadXp2yi5l9uqVCc09OzYCUoGZ8zscPbZIA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=YtqZ2R 9JLng9Irl2yBz/ny5KVpxk/wVc8yfHgIMoadk=; b=Qtf21635sKCjmPnbzq8NGd Ha35YKjorEfL8PNy4Hvc68P4oyaTonJDuHz2AHIlYqGsy2Jfu04c3u8pSiBFfwlx qpT5uBcu8p1rFBTFbBlL47eropa15/b1KJ0HsQFq18F5y1r80WqdChkuumRp0jsl raqXBMBxcfP3Za35kqHh/tYjkSu09hMpS8kPclTYLU4J7MRIn/O5KjOGmCbGl64C 0spRxf6DJGZislFebQhbqPmsgU7oJ0KhgwTxQYmI5W0QGZJ9G+F6sAC0xNgGbPUm nsalBvPe44yJEa6d+1KRePW0WjGClNN2ufncdvqmoVc+HDDl7k635/knGBY79K0g ==
X-ME-Sender: <xms:5sPqXpvBtZdiGyvWRCxvx7-teXO4mQEdvIZXiFprzwSsqUCygUJRgxJimFI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejfedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpedugfffieehffejkeduhfdvke evffdufeeuieekheeuffejfeejieetieehudfgkeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:5sPqXifNLhHfEvTYHsNNQ248HFcdPG68R8ojgQPorcusNvFr9LSHSQ> <xmx:5sPqXsy7kkYO_nm9ipTjm4_FPqOyw4GwU4nDt4dqSKBNqToYyq7GXA> <xmx:5sPqXgOqJi4LCEXvi2WmG78CcbFwPeQ_nwl8ZHQj46DEILoHEj7S6g> <xmx:5sPqXvcRWRLg0IqQ_OePlWykEGDwUxB2jDOFfRkqWjWUgy4kl7qZtw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1CD8D6680078; Wed, 17 Jun 2020 21:31:18 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-529-g3ee424a-fm-20200611.001-g3ee424a1
Mime-Version: 1.0
Message-Id: <e716cec2-f4ee-4ba6-8847-c3e8ede10242@www.fastmail.com>
In-Reply-To: <5d79521690f0478fb51764fb90159538@verisign.com>
References: <159162988692.27209.10007278285596026415@ietfa.amsl.com> <ea6ab7f4-1540-0367-b3cb-b2abd2187752@iit.cnr.it> <5d79521690f0478fb51764fb90159538@verisign.com>
Date: Wed, 17 Jun 2020 20:30:57 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/9aT6TM_1e0cj98q6z8fleLhGpng>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 01:31:21 -0000

On Wed, Jun 17, 2020, at 08:23, Hollenbeck, Scott wrote:
> 7) Section 10.2.3 - The definition of "last changed" event type seems 
> to be inconsistent with "upDate" defined in RFC 5731,5732,5733. For 
> example, I report an extract from RFC5731 here in the following:
> 
>    -  An OPTIONAL <domain:upDate> element that contains the date and
>       time of the most recent domain-object modification.  This element
>       MUST NOT be present if the domain object has never been modified.
> 
> So, should we redefine the "last changed" event accordingly? Should we 
> change all the examples where "last changed" date is equal to 
> "registration" date?
> 
> [SAH] I think we can leave this one alone. The meaning seems clear to 
> me since we also have the registration event. We could change the 
> examples, but before I do that I'd like to know what people have 
> implemented. Do servers return this value for an object that has been 
> registered, but never updated?

The problem I think is that we try to bake too much policy stuff here in the protocol.
There is no harm at the protocol level (both EPP or RDAP) if upDate/last changed is there
even right after just a create.

The EPP wording may infer that should not happen but one could argue that a creation
is a kind of modification in fact. And even without arguing I am sure some EPP
servers set upDate right after creation, probably because, even if the registrar
sees only a create, for the registry it could be internally a create + update
(like create the domain without  the nameservers and then add nameservers).
The EPP text does not specify "if the domain object has never been modified." but
by modified registry or registrar?

Take the case also of defered domain creations, those starting in pendingCreate and
allocated later. It may happen that crDate is the time at which the request came in
but upDate will then be set when the status change from pendingCreate to ok.
This status change is a modification and hence per above text could allow upDate
to be set, yet it is not a registrar triggered modification.

So I am neutral on the change to apply or not apply in RDAP specification, but I
would emphasize that whatever you do, like for EPP, you will find implementations
that add the last changed date right after creation and creation only.
This is for me more policy stuff (and good registry documentation would specify
that somewhere, even if I bet it doesn't happen), as it has no real consequences
on the protocol or interoperability matters.

-- 
  Patrick Mevzek
  pm@dotandco.com