Subject: Re: [regext] A modified option "C"?... (was Fwd: New Version Notification for draft-brown-epp-fees-07.txt)

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

On 12/04/2016 15:43, Alexander Mayrhofer wrote:
> Hmm, i don’t like the period “permutation” with all the commands,
> because eg. under ICANN rules, a transfer can only be a 1y extension –
> so, one would have to return an error for this combination?

The server would return a <fee:cd avail="0"> element for this
combination if its policy did not permit it.

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:45:19 +0100

Hi everyone,

Thanks for your input, and my apologies for the delay in responding.

It seems like the consenus has switched since we discussed this issue in
BA; like other people, I have changed my mind and I now think Option C
is probably the right choice.

As others have mentioned it has the drawback that, if misused, it could
result in the server doing a lot of work for what was always supposed to
be a fast and lightweight operation, but then, the unextended <check>
could be misused in the same way (RFC 5730 allows an arbitrary number of
objects to be checked), so server operators are already exposed to this
risk, and can mitigate it in the same way (by imposing a limit on the
number of objects/command combinations that can be checked).

Roger proposed moving the <period> element up a level, so that it
applied to every <command> element. This is appealing as it simplifies
the syntax, but would it cause problems for clients when servers offer a
discount for multii-year registrations/renewals, and clients therefore
need to query for the registration/renewal fee over multiple periods in
order to display this information to the user? TBH I don't know if there
are any servers which do this, so feedback on this point will be
appreciated.

My plan is to make the syntax changes prior to uploading the draft as
draft-ietf-regext-epp-fees-00; once I have a clear idea on where the
<period> element should go, this will hopefully happen fairly quickly.

G.

On 12/04/2016 16:39, Gould, James wrote:
> To weigh in on this, I first want to thank Gavin for
> posting draft-brown-epp-fees-07, which is certainly a step in the right
> direction by addressing two concerns that I had with
> draft-brown-epp-fees-06, which included:
> 
>  1. Merging two commands (availability check and fee check) into one for
>     convenience.  
>      1. Extending the objects (domains) of the availability check to
>         include fee information is now a true extension.  
>  2. No clean mechanism to indicate that fee information cannot be
>     provided.  
>      1. Inclusion of the “avail” flag and the reason element follows the
>         mechanics of a check response and enables the server to indicate
>         that the fee cannot be returned with a reason.  
> 
> 
> When it comes to Option B, which I call “Single Fee Input” versus Option
> C, which I call “Multiple Fee Input”, it gets a little bit more complex.
>  How heavy weight do we really want to make the available check command?
>  The great thing about the check command is its simplicity and speed.
>  If we begin overloading it with a host of additional features then the
> simplicity will be lost.  I will stick to my initial vote at the meeting
> to go with Option C; although I like the simplicity of Option B which is
> why I changed my vote.  I would leave the maximum commands to include in
> the extension up to server policy.  The key from the server policy is to
> ensure that the check command and response does not become monolithic
> and complex.  
> 
> My recommendation for the check command extension is below:
> 
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> 
>   <command>
> 
>     <check>
> 
>       <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> 
>         <domain:name>domain.example</domain:name>
> 
>         <domain:name>reserved.example</domain:name>
> 
>       </domain:check>
> 
>     </check>
> 
>     <extension>
> 
>       <fee:check
> 
>         xmlns:fee="urn:ietf:params:xml:ns:fee-0.12">
> 
>         <fee:currency>USD</fee:currency>
> 
>         <fee:command name="create"/>
> 
>         <fee:command name="renew">
> 
>           <fee:period unit="y">2</fee:period>
> 
>         </fee:command>
> 
>         </fee:command>
> 
>       </fee:check>
> 
>     </extension>
> 
>   </command>
> 
> </epp>
> 
> 
> 
> 
> My recommendation for the check response extension is below:
> 
> <eppxmlns="urn:ietf:params:xml:ns:epp-1.0">
> 
> ...
> 
>     <extension>
> 
>       <fee:chkDataxmlns:fee="urn:ietf:params:xml:ns:fee-0.12">
> 
>         <fee:currency>USD</fee:currency>
> 
>         <fee:cdavail="1">
> 
>           <fee:objID>domain.example</fee:objID>
> 
>           <fee:commandname="create">
> 
>             <fee:periodunit="y">1</fee:period>
> 
>             <fee:feedescription="Registration Fee"
> 
>               refundable="1" grace-period="P5D">10.00</fee:fee>
> 
>           </fee:command>
> 
>           <fee:commandname="renew">
> 
>             <fee:periodunit="y">2</fee:period>
> 
>             <fee:feedescription="Renewal Fee"
> 
>               refundable="1" grace-period="P5D">10.00</fee:fee>
> 
>           </fee:command>
> 
>         </fee:cd>
> 
>         <fee:cdavail="0">
> 
>           <fee:objID>reserved.example</fee:objID>
> 
>           <fee:reason>Reserved domain</fee:currency>
> 
>         </fee:cd>
> 
>       </fee:chkData>
> 
>     </extension>…
> 
> </epp>
> 
> 
> —
> 
> JG
> 
> 
> 
> 
> *James Gould
> *Distinguished Engineer
> [email-masked]
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com <http://VerisignInc.com>
> 
>> On Apr 12, 2016, at 10:14 AM, Hollenbeck, Scott
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> *From:* Alexander Mayrhofer [mailto:[email-masked]] 
>> *Sent:* Tuesday, April 12, 2016 9:38 AM
>> *To:* Hollenbeck, Scott; Pat Moroney; Gavin Brown; [email-masked]
>> <mailto:[email-masked]>
>> *Subject:* A modified option "C"?... (was Fwd: New Version
>> Notification for draft-brown-epp-fees-07.txt)
>>  
>> Scott, Pat, Gavin,
>>  
>> We’ve been looking into this a bit closer – and since we are currently
>> in the middle of an implementation, we have also collected feedback
>> from registrars. Based on this feedback (and thinking about the
>> envisioned registration process again), I fear I have to change my
>> mind in favor of (a modified?) option “C”, as described in Gavin’s
>> presentation
>> (https://www.ietf.org/proceedings/95/slides/slides-95-regext-9.pdf).
>> The reason for this is as follows:
>>  
>> During the session last week, I didn’t consider that reducing the
>> check command to that extent would remove the ability of the registrar
>> to check both create and renew prices at the same time. I was scared
>> off by the impression that “C” would allow for an arbitrary number of
>> “fee:check” elements, of which each could contain an arbitrary number
>> of “command” elements – this “DoS threat to the pricing engine” was my
>> main reason for choosing “B” (I’m exaggerating, but eg. 30
>> “check:name” elements, combined with 20 “fee:check” elements, each
>> containing 4 commands, combined with all possible periods from 1 – 10
>> years… 30*20*4*10 requests to the pricing engine, and **huge** EPP
>> frames…)
>>  
>> However, I agree with Pat that being unable to check for create and
>> renew pricing in a single command is a significant issue.
>>  
>> I therefore have to admit that I changed my mind towards strongly
>>  favoring option C, **but** only given the following additional
>> changes are added:
>>  
>> -          Limit the number of “fee:check” elements to one. (if the
>> intention was that it would be unrestricted)
>> -          Allow/Recommend for the registry to constrain the number of
>> “command” elements within the “fee:check” to a sensible number (4?)
>> -          Only allow for one “period” element per “command” element
>>  
>> I think this would keep the number of possible permutations down to a
>> sensible level, particularly if registries also limit the number of
>> “check:name” elements….
>>  
>> I can live with option C with appropriate restrictions. I would defer
>> to Jim Gould for his take on implementation complexity.
>>  
>> Scott
>> _______________________________________________
>> regext mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/regext
> 
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

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

Hi all,

> are any servers which do this, so feedback on this point will be

I've not received any feedback, so I am going to allow the <fee:period>
element to be a child of <fee:command> rather than <fee:check>.

G.