[regext] AD Review: draft-ietf-regext-epp-fees-15

Adam Roach <adam@nostrum.com> Sat, 05 January 2019 03:07 UTC

Return-Path: <adam@nostrum.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 CCE55130DD1; Fri, 4 Jan 2019 19:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 6YGeMOpxHRFb; Fri, 4 Jan 2019 19:07:52 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 192D31271FF; Fri, 4 Jan 2019 19:07:49 -0800 (PST)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0537lvX060193 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Jan 2019 21:07:48 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546657668; bh=yEn8jUHxJeZsQHicCmig40TVYFGJj5MireqmsZszHYc=; h=To:Cc:From:Subject:Date; b=WpgIFluJlT3jQ5sJ2rpBY0ZCaG3bBq/UOzJuB6uNJxmCpqMq2H+VR1uOkS1tfTvRT bYv5aqPt4+j/24VjWI1hA3KL2H56zXBg+TsicdXvZF1oqk2tGwIA4HWhPImDR5Q2l4 mpbYZng7bajFJjkFASrFamrwGGYAvTAKaHGaqRmo=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: draft-ietf-regext-epp-fees.all@ietf.org
Cc: "regext@ietf.org" <regext@ietf.org>
From: Adam Roach <adam@nostrum.com>
Message-ID: <48d51bd3-a454-c087-24bb-a3dc21f5c632@nostrum.com>
Date: Fri, 04 Jan 2019 21:07:41 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/2cGd35E8LJpaI8coQVXeQ13FbB8>
Subject: [regext] AD Review: draft-ietf-regext-epp-fees-15
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: Sat, 05 Jan 2019 03:07:54 -0000

This is my AD review of draft-ietf-regext-epp-fees. It looks to be in 
generally
good shape, although I have marked two of my feedback items below as 
"DISCUSS".
This doesn't necessarily mean they need to result in document changes (as I
might be mistaken), but I would like to make sure we address them in 
some way
before I put the document into IETF last call.

The remainder of my comments should be treated the same as any IETF last
call comments.

Thanks to everyone who has worked on this document, and I apologize for the
longer-than-usual processing time on my part.

---------------------------------------------------------------------------

Abstract:

This section should probably be a bit longer, incorporating some of the
background from the introduction.

---------------------------------------------------------------------------

§1.1:

 >  Indentation and
 >  white space in examples are provided only to illustrate element
 >  relationships and are not a REQUIRED feature of this protocol.

This is a somewhat unconventional use of RFC-2119-style language. I would
recommend using a lowercase "required" in this case.

---------------------------------------------------------------------------

§3.1:

 >  The <fee:command> element is used in the EPP <check> command to
 >  determine the fee which is applicable to the given command.

Nit: "...the fee that is applicable..."

---------------------------------------------------------------------------

DISCUSS:

§3.4:

 >  description: an OPTIONAL attribute which provides a human-readable
 >  description of the fee.  Servers should provide documentation on the
 >  possible values of this attribute, and their meanings.

Since this string is human-readable, localization considerations apply.
Minimally, this needs to include the ability to add a "lang" attribute,
similar to what is done for <fee:reason>

---------------------------------------------------------------------------

DISCUSS:

§3.4.1 says:

 >  If the "refundable" attribute is omitted, then clients SHOULD NOT
 >  make any assumption about the refundability of the fee.

§3.4.3 says:

 >  If a <fee:fee> element has a "grace-period" attribute then it MUST
 >  also be refundable.

This second statement is a bit confusing in the context of the first one.
There's two ways to read it:

1. If a <fee:fee> element has a "grace-period" attribute but does not also
    contain "refundable='1'", then it is malformed; or

2. If a <fee:fee> element has a "grace-period" attribute but does not also
    contain "refundable='1'", then the client is required to make an
    assumption that the fee is refundable.

If the intention is #1, then the language in 3.4.3 needs to be more 
explicit.

If the intention is #2, then it contradicts the language in §3.4.1, and the
language in §3.4.1 needs to be adjusted to indicate this exception.

---------------------------------------------------------------------------

§3.5:

 >  If a server includes a <fee:balance> element in response to transform
 >  commands, the value of the element MUST reflect the client's account
 >  balance after any fees or credits associated with that command have
 >  been applied.

I'm confused about how this value interacts with applied="delayed". 
Since the
charge won't happen during the course of the transaction, does the balance
include the effect of applying the fee? I don't think it matters much 
whether
the answer is "yes" or "no," as long as implementations are consistent 
(which I
believe requires the behavior to be clearly specified in this section).

---------------------------------------------------------------------------

§3.6:

 >  line of credit to the client.  A server MAY also include a
 >  <fee:creditLimit> element in responses which indicates the maximum
 >  credit available to a client

Nit: "...in responses that indicates..."

---------------------------------------------------------------------------

§3.7:

 >  Servers which make use of this element MUST use a <fee:class> element

Nit: "Servers that make use..."