Subject: [provreg] Launch EPP SDK 2.0.0.2 Preview

From: "Gould, James" <[email-masked]>
Date: Thu, 14 Mar 2013 12:46:01 +0000

Verisign has released the second release of a preview version of the Launch EPP SDK, named Launch EPP SDK 2.0.0.2.  This SDK fully implements draft-tan-epp-launchphase-07 ( http://tools.ietf.org/html/draft-tan-epp-launchphase-07 ) and draft-lozano-tmch-smd-00 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-00 ), referred to simply as 07/00, and includes the following features that can be of use to multiple stakeholders:

  1.  Packet encoder / decoder (CODEC) that will encode the XML from objects and decode the objects from XML.
  2.  Creation and validation code for signed marks (SMD) using an XML signed mark or a base64 encoded signed mark that complies with draft-lozano-tmch-smd-00.
  3.  Use of a test CA issued certificate that is included in the signed mark or base64 encoded signed mark that is chained to the test CA certificate by the EPP Stub Server.  A test certificate in a test Certificate Revocation List (CRL) is also validated by the EPP Stub Server.
  4.  Sample of poll messaging compliant with draft-tan-epp-launchphase-07 in the EPP Stub Server.
  5.  A client API that utilizes the packet encoder / decoder (CODEC) along with other code (e.g. transport, configuration, XML parsing pooling) to interface with an EPP server.
  6.  An EPP Stub Server that includes pre-defined responses to support the client tests.  The EPP Stub Server behavior can be easily customized to suite your testing needs.

The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, and 5734.

Verisign will be integrating the preview of the Launch Phase EPP Extension into its NameStore / SRS Bundle EPP SDK, at which time updates will not be made to the Launch EPP SDK.

The Launch EPP SDK is open source, requires Java 6 or higher, and below are the distributions and documents:

  *   Unix Binary Distribution (.tar.gz) - http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-bin.tar.gz
  *   Unix Source Distribution (.tag.gz) -  http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-src.tar.gz
  *   Windows Binary Distribution (.zip) - http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-bin.zip
  *   Windows Source Distribution (.zip) - http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-src.zip
  *   Readme File - http://www.verisigninc.com/assets/2-0-0-2/epp-launch.README
  *   Install Instructions - http://www.verisigninc.com/assets/2-0-0-2/epp-launch.INSTALL
--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Seth Goldman <[email-masked]>
Date: Fri, 22 Mar 2013 18:13:43 -0400

Hi James,

I had a number of questions around launch phases and subphases.

First, do you envision that a registry would define separate subphases for
the initial sunrise and landrush periods (when applications are accepted),
and a subsequent subphase where conflicting applications are resolved (e.g.
via auction)? I could imagine a server wanting to distinguish that during
the former <info> and <update> commands may still be allowed on unallocated
applications, while <create> and <delete> would be disallowed. If so,
should that be explicitly defined as a first class phase type (perhaps
"evaluation"), or do you think a custom sub-phase (via the name attribute)
would be sufficient there?

Second, I notice that there's no advertising of the current phase(s) of the
registry - only of an application or registration (via the <info> command).
It seems like the registrars must know beforehand (via some out-of-band
mechanism) what the supported launch phases are and what operations are
allowed or disallowed during each phase - which perhaps makes sense the
complex business logic required. Was there any consideration given to
extending the EPP greeting format to enumerate the current phase(s) and
subphase(s) of the server? That might be a nice way for registrars to find
out when a phases has begun or ended, rather than relying on some other
communication channel.

Last, the specification doesn't really say if clients must specify the
launch subphase (if there is one) when sending an EPP launch command. I'm
drawing a blank at the moment of a concrete scenario where this might make
a difference, but it seems like some mention of it might be in order -
either to say that they must match, or that it's up to server policy
whether it matters.

Thanks,
Seth

On Thu, Mar 14, 2013 at 8:46 AM, Gould, James <[email-masked]> wrote:

>   Verisign has released the second release of a preview version of the
> Launch EPP SDK, named Launch EPP SDK 2.0.0.2.  This SDK fully implements
> draft-tan-epp-launchphase-07 (
> http://tools.ietf.org/html/draft-tan-epp-launchphase-07 ) and
> draft-lozano-tmch-smd-00 (
> http://tools.ietf.org/html/draft-lozano-tmch-smd-00 ), referred to simply
> as 07/00, and includes the following features that can be of use to
> multiple stakeholders:
>
>
>    2. Creation and validation code for signed marks (SMD) using an XML
>    signed mark or a base64 encoded signed mark that complies with
>    draft-lozano-tmch-smd-00.
>    3. Use of a test CA issued certificate that is included in the signed
>    mark or base64 encoded signed mark that is chained to the test CA
>    certificate by the EPP Stub Server.  A test certificate in a test
>    Certificate Revocation List (CRL) is also validated by the EPP Stub Server.
>    4. Sample of poll messaging compliant
>    with draft-tan-epp-launchphase-07 in the EPP Stub Server.
>    5. A client API that utilizes the packet encoder / decoder (CODEC)
>    along with other code (e.g. transport, configuration, XML parsing pooling)
>    to interface with an EPP server.
>    6. An EPP Stub Server that includes pre-defined responses to support
>    the client tests.  The EPP Stub Server behavior can be easily customized to
>    suite your testing needs.
>
>  Verisign will be integrating the preview of the Launch Phase EPP
> Extension into its NameStore / SRS Bundle EPP SDK, at which time updates
> will not be made to the Launch EPP SDK.
>
>    - Unix Binary Distribution (.tar.gz) -
>    http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-bin.tar.gz
>    - Unix Source Distribution (.tag.gz) -
>    http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-src.tar.gz
>    - Windows Binary Distribution (.zip) -
>    http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-bin.zip
>    - Windows Source Distribution (.zip) -
>    http://www.verisigninc.com/assets/2-0-0-2/epp-launch-2.0.0.2-src.zip
>    - Readme File -
>    http://www.verisigninc.com/assets/2-0-0-2/epp-launch.README
>    - Install Instructions -
>    http://www.verisigninc.com/assets/2-0-0-2/epp-launch.INSTALL
>
>   -- ****
>
>
>
> JG****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
> Principal Software Engineer****
>
> [email-masked]****
>
>  ****
>
> 703-948-3271 (Office)****
>
> 12061 Bluemont Way****
>
> Reston, VA 20190****
>
> VerisignInc.com
>
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg
>
>

---

From: "Gould, James" <[email-masked]>
Date: Fri, 22 Mar 2013 23:50:01 +0000

Seth,

My feedback is below.

--

JG

James Gould
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Seth Goldman <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 22, 2013 6:13 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch EPP SDK 2.0.0.2 Preview

Hi James,

First, do you envision that a registry would define separate subphases for the initial sunrise and landrush periods (when applications are accepted), and a subsequent subphase where conflicting applications are resolved (e.g. via auction)? I could imagine a server wanting to distinguish that during the former <info> and <update> commands may still be allowed on unallocated applications, while <create> and <delete> would be disallowed. If so, should that be explicitly defined as a first class phase type (perhaps "evaluation"), or do you think a custom sub-phase (via the name attribute) would be sufficient there?

Well the use of the sub-phases is an option, but not required.  If for example, there was a sunrise followed by the claims1 period, the names that go to auction after the sunrise is over should be unavailable for registration during the claims1 period, and may be asynchronously allocated without defining a new phase.  You could utilize server statuses like serverDeleteProhibited for applications that disallow applications from being deleted.  I'm not sure at what point in sunrise you would stop taking new application creates, but I would imagine that sunrise application creates would be allowed all the way to the end of the sunrise period and then the server statuses (serverUpdateProhibited, serverDeleteProhibited) could be set on the applications to explicitly define what is not allowed.

Second, I notice that there's no advertising of the current phase(s) of the registry - only of an application or registration (via the <info> command). It seems like the registrars must know beforehand (via some out-of-band mechanism) what the supported launch phases are and what operations are allowed or disallowed during each phase - which perhaps makes sense the complex business logic required. Was there any consideration given to extending the EPP greeting format to enumerate the current phase(s) and subphase(s) of the server? That might be a nice way for registrars to find out when a phases has begun or ended, rather than relying on some other communication channel.

There was discussion on the list of creating a registry EPP mapping that can provide this information, but there didn't seem to be much interest.  We created a custom EPP mapping (Registry Mapping) for this purpose that covers the available TLD's, their phases, and their features and policies.  Is there general interest in such a mapping now?

Last, the specification doesn't really say if clients must specify the launch subphase (if there is one) when sending an EPP launch command. I'm drawing a blank at the moment of a concrete scenario where this might make a difference, but it seems like some mention of it might be in order - either to say that they must match, or that it's up to server policy whether it matters.

I would leave the enforcement of the sub-phase up to server policy, but I would recommend against it to keep things easier for the Registrars.  The only phase that is somewhat challenging is landrush, which would most likely come right after sunrise.  Since claims1 is most significant from an interface perspective I would propose that it should be the primary phase and landrush could be defined as a sub-phase, so you might have two claims1 sub-phases including "landrush" and "open".  Any thoughts from others on the list related to the definition of the phases for the landrush period that overlaps with the claims1 period?

Thanks,
Seth

On Thu, Mar 14, 2013 at 8:46 AM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Verisign has released the second release of a preview version of the Launch EPP SDK, named Launch EPP SDK 2.0.0.2.  This SDK fully implements draft-tan-epp-launchphase-07 ( http://tools.ietf.org/html/draft-tan-epp-launchphase-07 ) and draft-lozano-tmch-smd-00 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-00 ), referred to simply as 07/00, and includes the following features that can be of use to multiple stakeholders:

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

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