Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Tue, 28 March 2017 22:37 UTC

Return-Path: <alexander.mayrhofer@nic.at>
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 AA5BA1271DF for <regext@ietfa.amsl.com>; Tue, 28 Mar 2017 15:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 rUPt1WbMX5i4 for <regext@ietfa.amsl.com>; Tue, 28 Mar 2017 15:37:10 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 AB10A124234 for <regext@ietf.org>; Tue, 28 Mar 2017 15:37:08 -0700 (PDT)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.52f ; Wed, 29 Mar 2017 00:37:06 +0200
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0319.002; Wed, 29 Mar 2017 00:37:03 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: Thomas Corte <Thomas.Corte@knipp.de>, "Gould, James" <jgould@verisign.com>, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>, regext <regext@ietf.org>
CC: "support@tango-rs.com" <support@tango-rs.com>
Thread-Topic: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard
Thread-Index: AQHSp9j5eu61C+ekxUCIb7omMIMUY6Gq1eqA
Date: Tue, 28 Mar 2017 22:37:03 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE07598F3B5C6@NICS-EXCH2.sbg.nic.at>
References: <216C099C-41E6-48EA-8925-E239AA3F2015@verisign.com> <bfe3eb81-dce6-45fe-28a4-3ffdb29639c6@knipp.de>
In-Reply-To: <bfe3eb81-dce6-45fe-28a4-3ffdb29639c6@knipp.de>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.3.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/EIGbpV0MKATsrEXpU78zM0_zv8Q>
Subject: Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 28 Mar 2017 22:37:13 -0000

Thomas,

> What I don't like is that the "avail" attribute has been moved to the framing
> <fee:cd> element, while it's an attribute of <fee:command> in the current
> fee-0.15 draft. The latter has the big advantage of the server being able to
> report e.g. the availability of a fee (and the domain in general) for different
> launch phases.

i think you have mentioned an important argument *against* your own proposal. You write  "availability of a fee (and the domain in general)", which means that your proposal tries to mix in two different semantics into the same element - which, in turn, seems ambigious and probably even dangerous. The "avail" attribute can *either* indicate whether fee information is available, *or* whether a certain commmand on a certain domain in a certain phase (at the current point in time?) is "available". 

I think it's easy to see that the second "type" of availability would entail all kinds of problems. Therefore i'd rather not go down that path. It would pack too much logic into the command (eg. "is a transfer on that domain available for that client during the given phase at the current time?" - i don't want to be in the position to decide about such cases..)

James, what is your most recent proposal for the descriptive text of the "avail" attribute at the "fee:cd" level?

best,
Alex