On 3 March 2017 at 14:36, Gould, James <jgo...@verisign.com> wrote: > Antoin, > > I’m willing to help facilitate or participate in the reseller drafts > (draft-ietf-regext-reseller and draft-ietf-regext-reseller-ext) sub-group; > although the draft-ietf-regext-epp-fees sub-group is a high priority for me. > You may be able to split it based on EPP based sub-groups and RDAP based > sub-groups. > > For the draft-ietf-regext-epp-fees sub-group, I particularly would like to > discuss the policies around the handling of premium domain names. The > specific policies that I would like to discuss include: > > 1. Should a create fail if the client does not pass a fee that is greater > than or equal to the premium domain name fee?
I always saw it as a (customer-friendly) "bid". As such the command succeeds if the bid is equal to or greater than the associated price (regardless if the price stems from a non-default amount -- i.e. a fee -- or not). So to answer your question above, of course the create should fail if the registrar is not willing to pay the required amount, i.e. if the bid is below the price. OTOH for 1b) Should a create fail if the client does pass a fee that is greater than the [premium] domain name fee? I think no, it should not fail but just deduct the domain name fee (and of course not more than that). But IIRC that's already in the text somewhere (?). > 2. Should a premium domain name be returned as unavailable in the check if > the fee extension is not passed, since the create would most likely fail > later in the purchase flow? Yes. We have a response-data extension where in this case the reason 'Fee extension required' is returned along the avail=0 to eventually help registrars that do not use the fee-extension understand the situation. > 3. Should we have text in the draft with guidance around these and other > policies? Maybe. I think everybody who implements this extension should strive to make the registrar's life not unnecessarily complex. Remember we want them to succeed with as little effort as possible from their side. cheers, _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
