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

From: Gavin Brown <[email-masked]>
Date: Thu, 5 May 2016 18:15:16 +0100

Hi Pat,

Apologies for the long delay in responding.

> 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.

This is noted - I will respond to this and the subsequent discussion
shortly.

> 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 <http://example.com> 3 times, which should be
> impossible because of the new changes.

Noted and fixed in my working draft.

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.

---

From: Gavin Brown <[email-masked]>
Date: Thu, 5 May 2016 18:16:08 +0100

Hi Bernhard,

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

Thanks - these are fixed in my working draft.

> 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.

I have updated the schema to allow these elements in transfer responses.

G.

---

From: Gavin Brown <[email-masked]>
Date: Thu, 5 May 2016 18:57:21 +0100

Hi Alex,

Thanks for the feedback.

I have updated my working draft to use more-or-less the wording you
suggested.

G.

On 11/04/2016 09:14, Alexander Mayrhofer wrote:
> 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,
> 
>> 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.
> 
> 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
>  
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>