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

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 12 Apr 2016 13:37:46 +0000

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

What do others think?  Jim?

Thanks & sorry for all the hassle
Alex

Von: regext [mailto:[email-masked]] Im Auftrag von Hollenbeck, Scott
Gesendet: Dienstag, 12. April 2016 14:32
An: Pat Moroney; Gavin Brown; [email-masked]
Betreff: Re: [regext] Fwd: New Version Notification for draft-brown-epp-fees-07.txt

From: regext [mailto:[email-masked]] On Behalf Of Pat Moroney
Sent: Friday, April 08, 2016 12:06 PM
To: Gavin Brown; [email-masked]<mailto:[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

---

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

From: Alexander Mayrhofer [mailto:[email-masked]]
Sent: Tuesday, April 12, 2016 9:38 AM
To: Hollenbeck, Scott; Pat Moroney; Gavin Brown; [email-masked]
Subject: A modified option "C"?... (was Fwd: New Version Notification for draft-brown-epp-fees-07.txt)

Scott, Pat, Gavin,

I can live with option C with appropriate restrictions. I would defer to Jim Gould for his take on implementation complexity.

Scott

---

From: Roger D Carney <[email-masked]>
Date: Tue, 12 Apr 2016 14:28:41 +0000

Good Morning,

I concur with Alex (almostJ), I would rather see the period element up one level.

<?xml  version="1.0" encoding="utf-8" standalone="no"?>
<epp  xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <check>
      <check  domain="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.foo</name>
        <name>example.bar</name>
      </check>
    </check>
    <extension>
      <check  xmlns="urn:ietf:params:xml:ns:fee-0.11">
        <currency>USD</currency>
        <period unit="y">2</period>
        <command name="create" />
        <command name="renew" />
        <command name="transfer" />
        <command name="redemption" />
      </check>
    </extension>
  </command>
</epp>

Thanks
Roger

From: regext [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Tuesday, April 12, 2016 8:38 AM
To: Hollenbeck, Scott <[email-masked]>; Pat Moroney <[email-masked]>; Gavin Brown <[email-masked]>; [email-masked]
Subject: [regext] A modified option "C"?... (was Fwd: New Version Notification for draft-brown-epp-fees-07.txt)

Scott, Pat, Gavin,

Von: regext [mailto:[email-masked]] Im Auftrag von Hollenbeck, Scott
Gesendet: Dienstag, 12. April 2016 14:32
An: Pat Moroney; Gavin Brown; [email-masked]<mailto:[email-masked]>
Betreff: Re: [regext] Fwd: New Version Notification for draft-brown-epp-fees-07.txt

Hi Gavin,

Scott

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 12 Apr 2016 14:43:36 +0000

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?

Alex

Von: regext [mailto:[email-masked]] Im Auftrag von Roger D Carney
Gesendet: Dienstag, 12. April 2016 16:29
An: [email-masked]
Betreff: Re: [regext] A modified option "C"?... (was Fwd: New Version Notification for draft-brown-epp-fees-07.txt)

Good Morning,

I concur with Alex (almost☺), I would rather see the period element up one level.

Thanks
Roger

From: regext [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Tuesday, April 12, 2016 8:38 AM
To: Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>>; Pat Moroney <[email-masked]<mailto:[email-masked]>>; Gavin Brown <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [regext] A modified option "C"?... (was Fwd: New Version Notification for draft-brown-epp-fees-07.txt)

Scott, Pat, Gavin,

Hi Gavin,

Scott

---

From: "Gould, James" <[email-masked]>
Date: Tue, 12 Apr 2016 15:39:48 +0000

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

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

...

    <extension>

      <fee:chkData xmlns:fee="urn:ietf:params:xml:ns:fee-0.12">

        <fee:currency>USD</fee:currency>

        <fee:cd avail="1">

          <fee:objID>domain.example</fee:objID>

          <fee:command name="create">

            <fee:period unit="y">1</fee:period>

            <fee:fee description="Registration Fee"

              refundable="1" grace-period="P5D">10.00</fee:fee>

          </fee:command>

          <fee:command name="renew">

            <fee:period unit="y">2</fee:period>

            <fee:fee description="Renewal Fee"

              refundable="1" grace-period="P5D">10.00</fee:fee>

          </fee:command>

        </fee:cd>

        <fee:cd avail="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,

Scott
_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext