Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-02.txt

From: [email-masked]
Date: Wed, 08 Mar 2017 15:11:29 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions of the IETF.

        Title           : Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
        Authors         : Roger Carney
                          Gavin Brown
                          Jothan Frakes
	Filename        : draft-ietf-regext-epp-fees-02.txt
	Pages           : 34
	Date            : 2017-03-08

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for registry fees.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-regext-epp-fees-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Thomas Corte <[email-masked]>
Date: Mon, 20 Mar 2017 18:01:51 +0100

Hello,

On 09/03/2017 00:11, [email-masked] wrote:

> ...

Thanks for this updated fee extension draft.
While preparing its implementation, I noticed the following which may be
an error in the spec.

The draft's text suggests that the "name" attribute for the <fee:command>
element in a <fee:check> is mandatory, but this is not reflected in the
XSD (the attribute is left optional in the "commandType" complex type
declaration).

Unless the intention was to offer a "wildcard", enabling a client to
check all supported command without listing them, this attribute should
probably be marked as required.

Best regards,

Thomas Corte

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: Thomas Corte <[email-masked]>
Date: Mon, 20 Mar 2017 18:57:38 +0100

Hello,

another oddity I noticed in draft-ietf-regext-epp-fees-02.txt:

Since "objectCheckType" (for check commands) and "objectCDType" (for
check responses) now practically contain the same elements (and both
reference "commandType"), it is possible for a registrar to specify fees
and credits along with all checked commands. The draft's text makes no
mention of this possibility, so I assume that this is simply not
supported and should either be ignored or cause an error response.

Alternatively, it may be intended that this shall serve as an extended
check whether the specified "assumed" fees and credits are correct for a
given domain name/command/phase/period combination. This should be clarified.

Generally, I'd prefer a schema which more rigidly defines correct
commands and responses, even if this means that certain XSD type
definitions cannot easily be reused for defining requests and responses.

Best regards,

Thomas Corte

---

From: Thomas Corte <[email-masked]>
Date: Wed, 22 Mar 2017 12:08:23 +0100

Hello,

I've noticed two more issues with the latest EPP fee extensions draft,
detailed below.

Generally, I wonder if this mailing list is the right place to report
such issues. Should I rather contact the authors directly, or is there a
bug tracker set up for this purpose?

Issues:

1) There seem to be contradictory requirements regarding the handling of
invalid currency codes. In section 3.2, the draft says:

  "Servers SHOULD NOT perform a currency conversion if a client uses an
   incorrect currency code.  Servers SHOULD return a 2004 "Parameter
   value range" error instead."

However, in 5.1.1, it says:

     "An OPTIONAL <fee:currency> element.  If the server does not
      support <fee:currency> value, it MUST return a 2306 error
      response;"

Further below, the draft offers a third option:

  "The <fee:command> element also has an OPTIONAL "avail" attribute
   which is a boolean.  If the value of this attribute evaluates to
   false, this indicates that the server cannot calculate the relevant
   fees, because the object, command, currency, period or class is
   invalid according to server policy."

So this would indicate that an invalid currency in a <fee:check> should
not result in an EPP error at all, but merely cause a non-available fee
check result (an option which I would prefer).

I believe this requires some unification, or clarification as to when to
use which code (in the responses to transform commands at least), or when
to use avail="false".

2) In the description for the <fee:check> response, the draft says:

     "If a <fee:object> element in the client command contains no
      <fee:command> element the server SHOULD return a <fee:command>
      element for each server billable transaction combination of the
      <fee:object>."

However, such a case cannot occur since the definition of the
"objectCheckType" complex type currently requires at least one
<fee:command> element (minOccurs is not set and defaults to 1).
This should be changed in the schema so that the intended "command
wildcard" option becomes available.

Best regards,

Thomas

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 22 Mar 2017 11:13:24 +0000

Hello Thomas,

> bug tracker set up for this purpose?

(Disclaimer: I'm not a WG chair, personal opinion)

Generally, yes, as the document is a working group item, i would say the mailing list is the right place to send comments for the draft. The IETF works in an open manner, so sending out comments to the group instead to the authors directly is preferred. 

While there is actually a Tracker supplied for IETF working groups and documents on http://tools.ietf.org/, it's not being used in all groups. As you might have seen, we will have a dedicated "working session" on this (and other) documents next week, where we try to resolve all the issues received. We might decide at that meeting that we use the tracker.

So, summary - yes, please send the issues to the list.

best,
Alex

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Thu, 23 Mar 2017 16:04:00 +0100

> use which code (in the responses to transform commands at least), or when

In my view 2004 is more on the protocol-layer, i.e. value supplied not in
curl -s -o- https://www.currency-iso.org/dam/downloads/lists/list_one.xml | \
 sed -n -e "/<Ccy>/s/.*>\([^<]*\)<.*/\1/p" | sort | uniq | tr "\n" " "

2306 is a policy violation, i.e. may be a valid currencyType but is
not supported by your registry.

HTH,

---

From: Roger D Carney <[email-masked]>
Date: Thu, 23 Mar 2017 15:31:36 +0000

Good Morning,

Thanks for the comments Thomas!

I will look at the consistency of the error codes in sections 3.2 and 5.1.1.

As far as the text in the "avail" section you mention, I think this was meant as some combination of these items makes it invalid, not necessarily that a single item is invalid. I will look at wording to clarify.

Thanks for catching the mismatch on the <fee:command>. Before updating the scheme I think it would be good to have the discussion on if this functionality is needed/wanted: would it be useful for the client to be able to not pass a <fee:command> in the <check> command?

Thanks

Roger

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Thomas Corte
Sent: Wednesday, March 22, 2017 6:08 AM
To: [email-masked]
Subject: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello,

I've noticed two more issues with the latest EPP fee extensions draft, detailed below.

Generally, I wonder if this mailing list is the right place to report such issues. Should I rather contact the authors directly, or is there a bug tracker set up for this purpose?

Issues:

1) There seem to be contradictory requirements regarding the handling of invalid currency codes. In section 3.2, the draft says:

      response;"

So this would indicate that an invalid currency in a <fee:check> should not result in an EPP error at all, but merely cause a non-available fee check result (an option which I would prefer).

I believe this requires some unification, or clarification as to when to use which code (in the responses to transform commands at least), or when to use avail="false".

      <fee:object>."

However, such a case cannot occur since the definition of the "objectCheckType" complex type currently requires at least one <fee:command> element (minOccurs is not set and defaults to 1).

This should be changed in the schema so that the intended "command wildcard" option becomes available.

Best regards,

Thomas

--

TANGO REGISTRY SERVICES(r) is a product of:

D-44227 Dortmund                       E-Mail: [email-masked]<mailto:[email-masked]>

Germany

_______________________________________________

regext mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/regext

---

From: Thomas Corte <[email-masked]>
Date: Fri, 24 Mar 2017 11:02:37 +0100

Hello Roger,

On 23/03/2017 16:31, Roger D Carney wrote:

> As far as the text in the "avail" section you mention, I think this was
> meant as some combination of these items makes it invalid, not
> necessarily that a single item is invalid. I will look at wording to clarify.

Ok, that makes sense.

> Thanks for catching the mismatch on the <fee:command>. Before updating
> the scheme I think it would be good to have the discussion on if this
> functionality is needed/wanted: would it be useful for the client to be
> able to not pass a <fee:command> in the <check> command?

While it is useful to perform a quick check for every available command,
it could lead to very large check responses, given that each of the
inferred commands would implicitly also have a "wildcard" launch phase,
meaning that the server would have to return fees for all combinations of
available commands and launch phases. Combined with multiple names to
check, this could cause a lot of processing effort on the server side.

I'd be in favor of keeping the requirement to explicitly specify commands.

Best regards,

Thomas

---

From: Thomas Corte <[email-masked]>
Date: Fri, 24 Mar 2017 11:05:44 +0100

Hello Bernhard,

> not supported by your registry.

I see, however it seems futile to have these two levels of checking...
the server-supported currencies are obviously a subset of the globally
available currencies, so any currency not present in the long list is
bound to be rejected later on when the server checks for support.

If at all, I'd probably rather like to see the restriction to existing
currencies done via the schema, i.e. by an explicit enumeration of valid
values in the XSD.

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Fri, 24 Mar 2017 16:52:25 +0100

On 24 March 2017 11:05:44 CET, Thomas Corte <[email-masked]> wrote:
>> curl -s -o-
>https://www.currency-iso.org/dam/downloads/lists/list_one.xml | \

That's what normative references are for IMHO. You wouldn't want to update the fee RFC if someone invents a new currency.

You might want to throw an error if someone configures the server to use a new/typoed currency and always 2306 when receiving a currency outside of the configured enumeration, thus ignoring 2004 completely at runtime.

cheers,

---

From: Thomas Corte <[email-masked]>
Date: Tue, 28 Mar 2017 12:55:17 +0200

Hello Bernhard,

On 2017-03-24 16:52, Bernhard Reutner-Fischer wrote:

> That's what normative references are for IMHO. You wouldn't want to
> update the fee RFC if someone invents a new currency.

Agreed, that would be cumbersome.

> You might want to throw an error if someone configures the server to
> use a new/typoed currency and always 2306 when receiving a currency
> outside of the configured enumeration, thus ignoring 2004 completely
> at runtime.

This makes sense for the transform commands, yes.

However, for wrong currencies detected within some <fee:object> elements
of a <fee:check> extension, I'm not sure whether letting the entire
check command fail with a 2306 error is the best approach.

Instead, the server could still return useful results for other
<fee:object> elements in the command (which may have contained a correct
currency), or even return additional information in the <reason>
elements returned within the <fee:command avail="false"> elements
returned for all nested <fee:command> affected by the wrong currency.
I think the draft should be clarified regarding when to create an EPP
error result as opposed to <fee:command avail="false"> results in the
response to a <domain:check> command with fee extension.

Best regards,

Thomas