Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol

Patrick Mevzek <Patrick.Mevzek@afnic.fr> Mon, 04 November 2013 22:18 UTC

Return-Path: <Patrick.Mevzek@afnic.fr>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CB121E823B for <provreg@ietfa.amsl.com>; Mon, 4 Nov 2013 14:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOM3JF6XfE4j for <provreg@ietfa.amsl.com>; Mon, 4 Nov 2013 14:18:03 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id EF61C21E817A for <provreg@ietf.org>; Mon, 4 Nov 2013 14:17:44 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6ED122801BE for <provreg@ietf.org>; Mon, 4 Nov 2013 23:17:11 +0100 (CET)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 6AE542801AC for <provreg@ietf.org>; Mon, 4 Nov 2013 23:17:11 +0100 (CET)
Received: from [IPv6:::1] (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:2219:7::86:96]) by relay1.nic.fr (Postfix) with ESMTP id 4454A4C007C; Mon, 4 Nov 2013 23:16:41 +0100 (CET)
Message-ID: <1383603400.7757.12.camel@citrine-mobile>
From: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
To: provreg@ietf.org
Date: Mon, 04 Nov 2013 23:16:40 +0100
In-Reply-To: <B90E03E1-76A2-4806-91F2-608C206B64E6@mwyoung.ca>
References: <CE99706E.51081%jgould@verisign.com> <52779E1E.7070209@centralnic.com> <B90E03E1-76A2-4806-91F2-608C206B64E6@mwyoung.ca>
Organization: AFNIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.4-0ubuntu1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 22:18:09 -0000

Le lundi 04 novembre 2013 à 09:38 -0500, MICHAEL W YOUNG a écrit :
> > I am now agnostic on whether to use <info> or <check> for this extension
> > (having previously been in favour of <info>). When I originally wrote
> > the predecessor to this extension back in 2011, I did have some
> > reservations about which command to use, and spoke to Patrick Mevzek who
> > (at the time) agreed with my decision to use <check>.
> > 
> > If anyone else has thoughts about the choice of command to extend,
> > please speak now!
> 
> 
> 
> I like the principle of extending <info>, it's in keeping with the concept of retrieving clarifying information, whereas <check> was meant to be cheap, fast, light-weight.

The check can remain as light as it is today… since the fee structure is
returned only if the fee extension is added in check command, so it is
totally up to the registrar to see if they want it or not and if they
want the super fast check without it or the heavier one with it.

I have no strong opinion either way (and did not have time to
extensively read the new extension proposal), but I still slightly
prefer the check for this reason:
my reading of the spirit of EPP is that "info" is to query data about an
existing object in the registry database. In that way, a fee is not an
object, and neither a property of a domain (it is a property of a
transaction, not of a live object of a registry database)

Hence, the need to do a domain:info on a *non-existing* yet domain name
to find the cost of this creation is troublesome for me.

While §2.9.2.2. of RFC530 can be read in many ways, I'm assessing it as
"resData is there only in case of success" (and hence also <extension>).
I do also read exactly in the text:
The EPP <info> command is used to retrieve information associated
   with an existing object. 

So domain:info prior to a creation seem counter-nature to me

-- 
Patrick Mevzek