Subject: [regext] Fwd: New Version Notification for draft-brown-epp-fees-07.txt

From: Gavin Brown <[email-masked]>
Date: Fri, 8 Apr 2016 16:04:54 +0100

Just submitted, for your consideration.

Once republished as a WG document, I think it may be ready for Last Call.

Changes from 06 to 07:

   1.  Changed the syntax of the <check> form to be simpler: a single
       set of <fee:command>, <fee:currency> etc elements is applied to
       the objects specified in the main body of the <check> command.

   2.  Simplified the object-agnosticism to simply copy the element from
       the <check> command into the <fee:cd> element.

   3.  Added the "avail" attribute to the <fee:cd> element and added
       commentary about its semantics.

   4.  Added the <fee:reason> element to the <check> response so servers
       can indicate why fee information is not available.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.

Subject: New Version Notification for draft-brown-epp-fees-07.txt
From: [email-masked]
To: "Gavin Brown" <[email-masked]>, "Jothan Frakes" <[email-masked]>
Date: Fri, 08 Apr 2016 08:00:01 -0700

A new version of I-D, draft-brown-epp-fees-07.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:		draft-brown-epp-fees
Revision:	07
Title:		Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
Document date:	2016-04-08
Group:		Individual Submission
Pages:		36
URL:            https://www.ietf.org/internet-drafts/draft-brown-epp-fees-07.txt
Status:         https://datatracker.ietf.org/doc/draft-brown-epp-fees/
Htmlized:       https://tools.ietf.org/html/draft-brown-epp-fees-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-07

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

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.

The IETF Secretariat

---

From: Pat Moroney <[email-masked]>
Date: Fri, 08 Apr 2016 16:05:45 +0000

Hi Gavin,

I am still opposed to the limiting of the check command to one commandType.
This would, at minimum, double the number of check commands that we need to
perform since we need to know fees for the create AND the renew commands.

Also, there seems to be a slight typo in the example check response. The
request is for the example domain in .com, .net, and .xyz, while the
response lists example.com 3 times, which should be impossible because of
the new changes.

-Pat Moroney

On Fri, Apr 8, 2016 at 9:05 AM Gavin Brown <[email-masked]>
wrote:

> ---------- Forwarded message ----------
> To: Gavin Brown <[email-masked]>, Jothan Frakes <
> [email-masked]>
> Cc:
> URL:
> https://www.ietf.org/internet-drafts/draft-brown-epp-fees-07.txt
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Fri, 8 Apr 2016 18:14:58 +0200

> Once republished as a WG document, I think it may be ready for Last Call.

Just skimming over the diff for a start:
s/atribute/attribute/g
s/evalutes/evaluates/g
s/valudate/validate/g

draft-07 still has the bug also present in -06 that the transfer text mentions
an OPTIONAL balance element but the schema (transferResultType)
unfortunately lacks it.

trnData being a transformResultType (as transfer is a transform
command) would make
that consistent but would of course add elements to transfer query
responses that don't
make much sense. I'd consider this less a defect than the current lack
of balance in transfer
command responses, though.

thanks,

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 11 Apr 2016 08:14:53 +0000

Hello Gavin,

thanks for creating the revised version. I appreciate the change of the "check" semantics, and (as I said during the WG session), I think it's much clearer now.

However,

>        the objects specified in the main body of the <check> command.

I understand that the "class" attribute was also added to the check command (which is not listed in the change log, btw!). Looking at section 5.1.1.1, I'm wondering:

- What is the use case for a client to provide the "class" element to the server in the first described case (pricing tiers)? Wouldn't it rather be more helpful to require servers to respond with the "class" element of the check response, in case that a server supports it?

- Dose the second use model describe an "overload" of the "class" attribute, similar to what the "type" attribute of the <launch:create> element in the launch phase extension does. Hence tries use model 2  to change the cardinality of the "class" element from the 1:1 relation described in Section 3.7.? ("to *a* particular class"...) - I think this would be very confusing.

Also - if this use model is actually intended, the "class" element would also need to be carried in the "create" command to "select" between those "modes of registrations"... So, the gist of this - (If I understand the use model correctly) I don't like this use model, and its implementation in the draft is  incomplete.

- However, looking at the server actions required, both use models 1 and 2 actually require the same processing, namely:

1) If server uses classes as described in 3.7, and client gives a value, it must be validated
2) If the given class is not valid for the given object, return "avail=0", otherwise return "avail=1"
3) If the server does not use classes as described in 3.7, ignore "class" element in requests (and do not return an "avail" attribute?)

Therefore, I propose to replace the while  text in section 5.1.1.1 with:

NEW: 

When a server supports Classification as described in Section 3.7, and the 
<fee:class> element was given in the command, a server MUST validate the 
value of this element, and return an error for unknown values. If the given 
value is known, but incorrect for the specified object, the "avail" attribute 
of the corresponding <fee:cd> element MUST be false.

The <fee:cd> section SHOULD contain the <fee:class> element when a server
Support Classification as described in Section 3.7  and the calculation of the 
Fees was successful.

Thanks,
Alex

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Apr 2016 12:32:16 +0000

From: regext [mailto:[email-masked]] On Behalf Of Pat Moroney
Sent: Friday, April 08, 2016 12:06 PM
To: Gavin Brown; [email-masked]
Subject: Re: [regext] Fwd: New Version Notification for draft-brown-epp-fees-07.txt

Hi Gavin,

I am still opposed to the limiting of the check command to one commandType. This would, at minimum, double the number of check commands that we need to perform since we need to know fees for the create AND the renew commands.

Perhaps, but I think it makes the protocol simpler. I very much prefer having one command do one thing, even if it means having to process more commands.

Scott