gmane.ietf.provreg

Re: Are escrow deposit files per-TLD,or per-registry operator?

MICHAEL YOUNG — 2013-06-18T21:01:26

Sure Chris, an example would be what if one TLD has a set of extensions the other one doesn't? Makes a single block much more complicated to manage.

Also what if a registry operator uses the escrow file as part of their transition efforts for a single TLD out of several in a non-emergency situation? (As in a sale,....)

-Michael

On 2013-06-18, at 4:51 PM, Christopher Browne <cbbrowne< at >afilias.info> wrote:





MICHAEL YOUNG
michael< at >mwyoung.ca




_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Are escrow deposit files per-TLD,or per-registry operator?

MICHAEL YOUNG — 2013-06-18T20:58:56

I agree with Andrew on this.

-Michael Young


On 2013-06-18, at 4:49 PM, Andrew Sullivan <ajs< at >anvilwalrusden.com> wrote:





MICHAEL YOUNG
michael< at >mwyoung.ca




_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Are escrow deposit files per-TLD,or per-registry operator?

Eric Brunner-Williams — 2013-06-18T20:55:32

While sensible, at no point during the multi-year struggle to impart
sense into the DAG was any argument for any means of recognizing two
or more applications "communicated" (had same applicants, used same
backends, liked the same wine, ...) successful.

I wouldn't gamble that escrow can be "bundled" or that any other
operational activity that exists in contractual form can be, from
insurance to continuity instrument to ... failover flavor preference.

Failure is a property of the registry operator, which in our refined
parlance means the two or three clowns who managed to get a piece of
paper past ICANN legal, who may run out of money or be found to be
sudden guests of the United States (my favorite form of incapacity,
see the Brothers Elashi and the .iq saga, at a google near you), or
encounter some other trigger condition.

YMMV, of course.
Eric
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Are escrow deposit files per-TLD,or per-registry operator?

Christopher Browne — 2013-06-18T20:51:26

Those seem like pretty good questions.

That said, while an aspect of efficiency could be gained by avoiding the
need to write out shared objects multiple times, this involves the
assumption that all of the TLDs would be passed on together as a single
"block."

If there is reason to imagine that the TLDs could be passed on
individually, then combining the data would be pretty hazardous, both
technically, and, I'd think more hazardous, legally.
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Are escrow deposit files per-TLD, or per-registry operator?

Andrew Sullivan — 2013-06-18T20:49:03

But a single file would entail that all the registries move _en masse_
to a single new operator -- an assumption that is pretty brittle.  If
you have one escrow file per escrowed zone, you can always put them
together.  If you have one big file, it's work to take them apart.

Best,

A

Re: Are escrow deposit files per-TLD, or per-registry operator?

Gould, James — 2013-06-18T20:47:25

Seth,

You might want to post this to the Internet Registration Escrow (IRE) list ( https://www.ietf.org/mailman/listinfo/ire ).  My understanding is that the deposits are per-TLD and not per registry operator.

--

JG

[cid:330C1C8F-95EE-4160-BE78-8271CD0967B2]

James Gould
Principal Software Engineer
jgould< at >verisign.com

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

From: Seth Goldman <sethamin< at >google.com<mailto:sethamin< at >google.com>>
Date: Tuesday, June 18, 2013 4:42 PM
To: EPP Provreg <provreg< at >ietf.org<mailto:provreg< at >ietf.org>>
Subject: [provreg] Are escrow deposit files per-TLD, or per-registry operator?

In the case of a registry operator who operates multiple TLDs in a single database, are the escrow deposit files intended to be per-TLD? Or per-registry operator?

My suspicion is that it should be the latter. The entire reason for the escrow deposit to exist is to transition to an EBERO in the event that a registry operator is unable to perform its duties. That could happen on a per-TLD basis, but it would be a lot more efficient to do it for *all* TLDs that are managed by that registry operator.

So if that is the case, what are we to make of the escrow deposit file naming convention?

Files will be named according to the following convention:

{gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:
5.1 {gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the ASCII-compatible form
(A-Label) must be used;

If there is a single escrow file with multiple TLDs embedded in it, what would you use for "{gTLD}"? Is the assumption that all TLDs will be stored in totally separate databases? Or that they should be written to separate files, even if stored in the same database? That would mean that shared objects (e.g. contacts, hosts, etc.) would have to be written multiple times. That seems less than ideal.
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Are escrow deposit files per-TLD,or per-registry operator?

Seth Goldman — 2013-06-18T20:42:13

In the case of a registry operator who operates multiple TLDs in a single
database, are the escrow deposit files intended to be per-TLD? Or
per-registry operator?

My suspicion is that it should be the latter. The entire reason for the
escrow deposit to exist is to transition to an EBERO in the event that a
registry operator is unable to perform its duties. That could happen on a
per-TLD basis, but it would be a lot more efficient to do it for *all* TLDs
that are managed by that registry operator.

So if that is the case, what are we to make of the escrow deposit file
naming convention?

Files will be named according to the following convention:




If there is a single escrow file with multiple TLDs embedded in it, what
would you use for "{gTLD}"? Is the assumption that all TLDs will be stored
in totally separate databases? Or that they should be written to separate
files, even if stored in the same database? That would mean that shared
objects (e.g. contacts, hosts, etc.) would have to be written multiple
times. That seems less than ideal.
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: launch:phase requirement for Sunrise FCFS

Gould, James — 2013-06-17T19:45:21

Sharon,

We can add some clarifying text to the next version of the draft.  I don't believe that this change alone warrants a new draft version, so we can wait to include it with other updates.

Thanks,

--

JG

[cid:6C2EF356-04B3-47CE-BA8E-B8D03B93BB08]

James Gould
Principal Software Engineer
jgould< at >verisign.com

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

From: <Wodjenski>, Sharon <Sharon.Wodjenski< at >neustar.biz<mailto:Sharon.Wodjenski< at >neustar.biz>>
Date: Tuesday, June 11, 2013 3:39 PM
To: James Gould <jgould< at >verisign.com<mailto:jgould< at >verisign.com>>, EPP Provreg <provreg< at >ietf.org<mailto:provreg< at >ietf.org>>
Subject: RE: [provreg] launch:phase requirement for Sunrise FCFS

As we have not received any feedback, we will take Jim’s suggestion and not require the launch extension and launch:phase for update/delete commands in FCFS Sunrise.

Jim – could you please update the text in the next revision to clarify this point?

Thanks,

Sharon

From: Gould, James [mailto:JGould< at >verisign.com]
Sent: Monday, June 03, 2013 6:26 PM
To: Wodjenski, Sharon; 'provreg< at >ietf.org<mailto:'provreg< at >ietf.org>'
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

Sharon,

The intention in the draft was #2 " For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.".  It would be good to hear from others whether the extension should be included for update and delete commands for launch registrations.

--

JG

[cid:image001.png< at >01CE66B9.DF555EE0]

James Gould
Principal Software Engineer
jgould< at >verisign.com<mailto:jgould< at >verisign.com>

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

From: <Wodjenski>, Sharon <Sharon.Wodjenski< at >neustar.biz<mailto:Sharon.Wodjenski< at >neustar.biz>>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg< at >ietf.org<mailto:provreg< at >ietf.org>>
Subject: [provreg] launch:phase requirement for Sunrise FCFS

Hi Everybody,

We’ve run into a condition during development and are seeking feedback/guidance from the group.

This case is specific to First Come, First Served Sunrises, and the delete/update commands.

When we read this in the spec:

2.2.  Launch Phases

   The server MAY support multiple launch phases sequentially or
   simultaneously.  The <launch:phase> element MUST be included by the
   client to define the target launch phase of the command.

We interpreted that to mean that the launch:phase  was mandatory, and would come in with each command in the extension.

Currently, the XSD for the delete/update commands do not support the application id being optional.  And of course, for a FCFS registration, the application id is not needed/used.


     <element name="update" type="launch:idContainerType"/>

     <element name="delete" type="launch:idContainerType"/>



     <!--

     Common container of id (identifier) element

     -->

     <complexType name="idContainerType">

       <sequence>

         <element name="phase" type="launch:phaseType"/>

         <element name="applicationID" type="launch:applicationIDType"/>

       </sequence>

     </complexType>

So, the question from a client perspective is:


1.        Is the launch:phase, and therefore the extension, mandatory for all commands and the XSD should be modified so that the application id is optional (as it is in the Info command)?

Or

2.       For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.

Thank you for your input on this topic.

Sharon

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: launch:phase requirement for Sunrise FCFS

Wodjenski, Sharon — 2013-06-17T19:33:52

Thank you for the confirmation Seth.

Sharon

From: Seth Goldman [mailto:sethamin< at >google.com]
Sent: Monday, June 17, 2013 3:01 PM
To: Wodjenski, Sharon
Cc: Gould, James; provreg< at >ietf.org
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

I think the idea of the launch update/delete commands is to support operations on applications. If you've already provisioned the domain (presumably you have since it's FCFS), then the standard version of update and delete should be sufficient, in which case you don't need to specify either a phase or an application id.

On Tue, Jun 11, 2013 at 3:39 PM, Wodjenski, Sharon <Sharon.Wodjenski< at >neustar.biz<mailto:Sharon.Wodjenski< at >neustar.biz>> wrote:
As we have not received any feedback, we will take Jim's suggestion and not require the launch extension and launch:phase for update/delete commands in FCFS Sunrise.

Jim - could you please update the text in the next revision to clarify this point?

Thanks,

Sharon

From: Gould, James [mailto:JGould< at >verisign.com<mailto:JGould< at >verisign.com>]
Sent: Monday, June 03, 2013 6:26 PM
To: Wodjenski, Sharon; 'provreg< at >ietf.org<mailto:provreg< at >ietf.org>'
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

Sharon,

The intention in the draft was #2 " For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.".  It would be good to hear from others whether the extension should be included for update and delete commands for launch registrations.

--

JG

[cid:image001.png< at >01CE6B70.11C586B0]

James Gould
Principal Software Engineer
jgould< at >verisign.com<mailto:jgould< at >verisign.com>

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

From: <Wodjenski>, Sharon <Sharon.Wodjenski< at >neustar.biz<mailto:Sharon.Wodjenski< at >neustar.biz>>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg< at >ietf.org<mailto:provreg< at >ietf.org>>
Subject: [provreg] launch:phase requirement for Sunrise FCFS

Hi Everybody,

We've run into a condition during development and are seeking feedback/guidance from the group.

This case is specific to First Come, First Served Sunrises, and the delete/update commands.

When we read this in the spec:

2.2.  Launch Phases

   The server MAY support multiple launch phases sequentially or
   simultaneously.  The <launch:phase> element MUST be included by the
   client to define the target launch phase of the command.

We interpreted that to mean that the launch:phase  was mandatory, and would come in with each command in the extension.

Currently, the XSD for the delete/update commands do not support the application id being optional.  And of course, for a FCFS registration, the application id is not needed/used.

     <element name="update" type="launch:idContainerType"/>

     <element name="delete" type="launch:idContainerType"/>

     <!--

     Common container of id (identifier) element

     -->

     <complexType name="idContainerType">

       <sequence>

         <element name="phase" type="launch:phaseType"/>

         <element name="applicationID" type="launch:applicationIDType"/>

       </sequence>

     </complexType>

So, the question from a client perspective is:

1.        Is the launch:phase, and therefore the extension, mandatory for all commands and the XSD should be modified so that the application id is optional (as it is in the Info command)?

Or

2.       For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.

Thank you for your input on this topic.

Sharon

_______________________________________________
provreg mailing list
provreg< at >ietf.org<mailto:provreg< at >ietf.org>
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: launch:phase requirement for Sunrise FCFS

Seth Goldman — 2013-06-17T19:01:27

I think the idea of the launch update/delete commands is to support
operations on applications. If you've already provisioned the domain
(presumably you have since it's FCFS), then the standard version of update
and delete should be sufficient, in which case you don't need to specify
either a phase or an application id.


On Tue, Jun 11, 2013 at 3:39 PM, Wodjenski, Sharon <
Sharon.Wodjenski< at >neustar.biz> wrote:

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: namestoreExt-1.1 purpose/usage

Keith Gaughan — 2013-06-14T17:03:28


This isn't really the best list to be contacting on this subject. That's
a VeriSign specific extension. You really ought to be contacting
VeriSign's own support desk.

However...


The namestore extension is used by Verisign's EPP infrastructure to
enable proxying of requests.

You see, the EPP server you connect to is simply a proxy in front of
other zone-specific EPP serves, so there's one for .com, one for .net,
&c.

To determine which of these backend EPP servers the request is to be
directed to, you include the namestore extension. Thus, the subproduct
'dotCOM' indicates that the request should be forwarded to the .com
backend EPP server, and so on.

I agree that it's not particularly clear. In my head, this kind of
proxying ought to be done at a transport level rather than at an
application level, but that's the way it's implemented in VeriSign's
case.

K.

Re: namestoreExt-1.1 purpose/usage

Gould, James — 2013-06-14T16:55:06

Ofer,

The namestore extension is a routing extension to specify the target registry for the command using a single EPP connection.  You must have privileges to execute a command against a specific target registry (e.g. dotEDU).  The check command is currently less strict.  The possible values for the extension currently is the TLD prefixed with "dot" but in the future simply the TLD will be supported.  Please contact Verisign Customer Support if you have any specific issues or questions.

Thanks,

JG

James F. Gould
Principal Engineer
Verisign

jgould< at >verisign.com

On Jun 14, 2013, at 12:12 PM, "Ofer Nave" <onave< at >dyn.com> wrote:

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

namestoreExt-1.1 purpose/usage

Ofer Nave — 2013-06-14T16:10:56

Hello!

I'm new to EPP, and am currently working on an implementation.

While implementing the check and info commands against the Verisign OT&E 
server, I discovered that they require the namestoreExt-1.1 extension to 
be implemented, which basically means adding something like this to each 
command frame:

<extension>
     <namestoreExt:namestoreExt 
xmlns:namestoreExt="http://www.verisign-grs.com/epp/namestoreExt-1.1">
<namestoreExt:subProduct>dotCOM</namestoreExt:subProduct>
     </namestoreExt:namestoreExt>
</extension>

However, the docs 
(http://www.verisigninc.com/assets/namestore-extension.pdf) do not 
mention the purpose of this block, or the valid values.  I've guessed 
from using Verisign's epptool 
(https://epptool-ctld.verisign-grs.com/epptool/) that the valid values 
are 'dotCOM', 'dotNET', and 'dotEDU', though I get an authorization 
error when using 'dotEDU'.  However, I'm still confused as to the 
correct usage.

For example, the check command allows you to specify multiple domain 
names in one frame, which may have multiple TLDs.  I tested the 
submission of a frame checking for 'example.com' and 'example.net' in 
the same command, once with the subProduct set to 'dotCOM', and once 
with 'dotNET'.  Both times worked fine.

So really, what's the point of this extension?  And what value am I 
supposed to provide with it?

-ofer
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: launch:phase requirement for Sunrise FCFS

Wodjenski, Sharon — 2013-06-11T19:39:34

As we have not received any feedback, we will take Jim's suggestion and not require the launch extension and launch:phase for update/delete commands in FCFS Sunrise.

Jim - could you please update the text in the next revision to clarify this point?

Thanks,

Sharon

From: Gould, James [mailto:JGould< at >verisign.com]
Sent: Monday, June 03, 2013 6:26 PM
To: Wodjenski, Sharon; 'provreg< at >ietf.org'
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

Sharon,

The intention in the draft was #2 " For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.".  It would be good to hear from others whether the extension should be included for update and delete commands for launch registrations.

--

JG

[cid:image001.png< at >01CE66B9.DF555EE0]

James Gould
Principal Software Engineer
jgould< at >verisign.com<mailto:jgould< at >verisign.com>

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

From: <Wodjenski>, Sharon <Sharon.Wodjenski< at >neustar.biz<mailto:Sharon.Wodjenski< at >neustar.biz>>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg< at >ietf.org<mailto:provreg< at >ietf.org>>
Subject: [provreg] launch:phase requirement for Sunrise FCFS

Hi Everybody,

We've run into a condition during development and are seeking feedback/guidance from the group.

This case is specific to First Come, First Served Sunrises, and the delete/update commands.

When we read this in the spec:

2.2.  Launch Phases

   The server MAY support multiple launch phases sequentially or
   simultaneously.  The <launch:phase> element MUST be included by the
   client to define the target launch phase of the command.

We interpreted that to mean that the launch:phase  was mandatory, and would come in with each command in the extension.

Currently, the XSD for the delete/update commands do not support the application id being optional.  And of course, for a FCFS registration, the application id is not needed/used.


     <element name="update" type="launch:idContainerType"/>

     <element name="delete" type="launch:idContainerType"/>



     <!--

     Common container of id (identifier) element

     -->

     <complexType name="idContainerType">

       <sequence>

         <element name="phase" type="launch:phaseType"/>

         <element name="applicationID" type="launch:applicationIDType"/>

       </sequence>

     </complexType>

So, the question from a client perspective is:


1.        Is the launch:phase, and therefore the extension, mandatory for all commands and the XSD should be modified so that the application id is optional (as it is in the Info command)?

Or

2.       For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.

Thank you for your input on this topic.

Sharon

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: launch:phase requirement for Sunrise FCFS

Gould, James — 2013-06-03T22:26:01

Sharon,

The intention in the draft was #2 " For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.".  It would be good to hear from others whether the extension should be included for update and delete commands for launch registrations.

--

JG

[cid:612CB376-3E9B-4D96-B6C1-DB6A4C804448]

James Gould
Principal Software Engineer
jgould< at >verisign.com

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

From: <Wodjenski>, Sharon <Sharon.Wodjenski< at >neustar.biz<mailto:Sharon.Wodjenski< at >neustar.biz>>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg< at >ietf.org<mailto:provreg< at >ietf.org>>
Subject: [provreg] launch:phase requirement for Sunrise FCFS

Hi Everybody,

We’ve run into a condition during development and are seeking feedback/guidance from the group.

This case is specific to First Come, First Served Sunrises, and the delete/update commands.

When we read this in the spec:

2.2.  Launch Phases

   The server MAY support multiple launch phases sequentially or
   simultaneously.  The <launch:phase> element MUST be included by the
   client to define the target launch phase of the command.

We interpreted that to mean that the launch:phase  was mandatory, and would come in with each command in the extension.

Currently, the XSD for the delete/update commands do not support the application id being optional.  And of course, for a FCFS registration, the application id is not needed/used.


     <element name="update" type="launch:idContainerType"/>

     <element name="delete" type="launch:idContainerType"/>



     <!--

     Common container of id (identifier) element

     -->

     <complexType name="idContainerType">

       <sequence>

         <element name="phase" type="launch:phaseType"/>

         <element name="applicationID" type="launch:applicationIDType"/>

       </sequence>

     </complexType>

So, the question from a client perspective is:


1.        Is the launch:phase, and therefore the extension, mandatory for all commands and the XSD should be modified so that the application id is optional (as it is in the Info command)?

Or

2.       For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.

Thank you for your input on this topic.

Sharon

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

launch:phase requirement for Sunrise FCFS

Wodjenski, Sharon — 2013-06-03T18:05:21

Hi Everybody,

We've run into a condition during development and are seeking feedback/guidance from the group.

This case is specific to First Come, First Served Sunrises, and the delete/update commands.

When we read this in the spec:

2.2.  Launch Phases

   The server MAY support multiple launch phases sequentially or
   simultaneously.  The <launch:phase> element MUST be included by the
   client to define the target launch phase of the command.

We interpreted that to mean that the launch:phase  was mandatory, and would come in with each command in the extension.

Currently, the XSD for the delete/update commands do not support the application id being optional.  And of course, for a FCFS registration, the application id is not needed/used.


     <element name="update" type="launch:idContainerType"/>

     <element name="delete" type="launch:idContainerType"/>



     <!--

     Common container of id (identifier) element

     -->

     <complexType name="idContainerType">

       <sequence>

         <element name="phase" type="launch:phaseType"/>

         <element name="applicationID" type="launch:applicationIDType"/>

       </sequence>

     </complexType>

So, the question from a client perspective is:


1.        Is the launch:phase, and therefore the extension, mandatory for all commands and the XSD should be modified so that the application id is optional (as it is in the Info command)?

Or

2.       For FCFS update/delete commands, the extension is not required at all, and therefore the launch:phase is not specified.

Thank you for your input on this topic.

Sharon

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Launch EPP SDK 2.2.0.0 Preview

Gould, James — 2013-05-31T20:34:43

Verisign has released the fourth release of a preview version of the Launch EPP SDK, named Launch EPP SDK 2.2.0.0. This SDK fully implements draft-tan-epp-launchphase-11 ( http://tools.ietf.org/html/draft-tan-epp-launchphase-11 ) and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-02 ), referred to simply as 11/02, 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-02.
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-11 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, 5734, 3915, and 5910.

Verisign will be integrating the preview of the Launch Phase EPP Extension into its Verisign Bundle 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-2-0-0/epp-launch-bundle-2.2.0.0-bin.tar.gz
* Unix Source Distribution (.tag.gz) - http://www.verisigninc.com/assets/2-2-0-0/epp-launch-bundle-2.2.0.0-src.tar.gz
* Windows Binary Distribution (.zip) - http://www.verisigninc.com/assets/2-2-0-0/epp-launch-bundle-2.2.0.0-bin.zip
* Windows Source Distribution (.zip) - http://www.verisigninc.com/assets/2-2-0-0/epp-launch-bundle-2.2.0.0-src.zip
* Readme File - http://www.verisigninc.com/assets/2-2-0-0/epp-launch.README
* Install Instructions - http://www.verisigninc.com/assets/2-2-0-0/epp-launch.INSTALL
* Change Log - http://www.verisigninc.com/assets/2-2-0-0/changelog.txt
--

[cid:922F2D86-FC79-472E-A0CF-F88984FFA29E]

James Gould
Principal Software Engineer
jgould< at >verisign.com<mailto:jgould< at >verisign.com>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com
"This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately."
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: [tmch-tech] SMD: Restriction of XML DSIG parameter space ...

Gould, James — 2013-05-28T13:29:35

Gustavo,

My feedback is below.

Re: [tmch-tech] SMD: Restriction of XML DSIG parameterspace ...

Gustavo Lozano — 2013-05-28T13:06:39

Alex, all,

Thank you for your feedback.

TMVs (there is only one at the moment) are the only actors generating SMDs
and TMVs must use: xml-exc-c14n, RSA-SHA256, SHA256 and the RSA key size
is 2048 bits. During the LA meeting, we agreed on RSA2048 and SHA256. I
will add text in the new version of the draft to clarify this.

The SMD file downloaded by the TMH from the TMV is encoded in base64 (see
6.4 of draft-lozano-tmch-func-spec). The reason for the base64 encoding is
to mitigate the possiblity that the signature is invalidated by mistake
(e.g. sending the SMD by email).

There is no recommendation/requirement for using an
<smd:encodedSignedMark> instead of <smd:signedMark> in the communication
channel between Registrars and Registries. Maybe a recommendation or
requirement for using <smd:encodedSignedMark> in this channel is worth it?
Maybe the risk is low? Sometimes, it is cheaper wasting CPU cycles
(decoding base64) instead of troubleshooting. Comments?

Regards,


Gustavo

On 5/27/13 7:39 AM, "Alexander Mayrhofer" <alexander.mayrhofer< at >nic.at>
wrote:

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: SMD: Restriction of XML DSIG parameter space ...

Anthony Kirby — 2013-05-28T10:14:03

+1

interoperability for ENUM tokens was hard to achieve, even with this specified

thanks
Anthony


________________________________________
From: provreg-bounces< at >ietf.org [provreg-bounces< at >ietf.org] on behalf of Alexander Mayrhofer [alexander.mayrhofer< at >nic.at]
Sent: 27 May 2013 15:39
To: tmch-tech< at >icann.org; provreg< at >ietf.org
Cc: Otmar Lendl
Subject: [provreg] SMD: Restriction of XML DSIG parameter space ...

All,

looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft currently doesn't seem to restrict the set of XML Signature parameters to be used. The signature and normalization algorithm examples look surprisingly similar to RFC5105 (written by my colleague Otmar Lendl back in 2006/2007).

During his journey to implement the signature technoloy in our ENUM registry software, he found out that some options in XML DSIG (particularly the normalization options) are rather cumbersome and error-prone (AFAIR whitespace changes created by the validating XML parser  triggering validation errors, etc.). Based on this practical experience, he restricted the parameter range for XML DSIG in http://tools.ietf.org/html/rfc5105#section-3 of RFC5105, in order to increase interopability. The concept described in RFC5105 has since been validated in implementations of a few ENUM registry installations (servers), as well as their ENUM registrars (clients).

Since SMD essentially uses the same technology, i'm proposing that the authors also consider restricting the parameter range of XML DSIG in order to reduce implementation effort, and increase interopability.

Comments?

Alex

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

SMD: Restriction of XML DSIG parameter space ...

Alexander Mayrhofer — 2013-05-27T14:39:53

All,

looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft currently doesn't seem to restrict the set of XML Signature parameters to be used. The signature and normalization algorithm examples look surprisingly similar to RFC5105 (written by my colleague Otmar Lendl back in 2006/2007). 

During his journey to implement the signature technoloy in our ENUM registry software, he found out that some options in XML DSIG (particularly the normalization options) are rather cumbersome and error-prone (AFAIR whitespace changes created by the validating XML parser  triggering validation errors, etc.). Based on this practical experience, he restricted the parameter range for XML DSIG in http://tools.ietf.org/html/rfc5105#section-3 of RFC5105, in order to increase interopability. The concept described in RFC5105 has since been validated in implementations of a few ENUM registry installations (servers), as well as their ENUM registrars (clients). 

Since SMD essentially uses the same technology, i'm proposing that the authors also consider restricting the parameter range of XML DSIG in order to reduce implementation effort, and increase interopability.

Comments?

Alex

_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg