Subject: [provreg] Launch Phase EPP Extension Version 08

From: "Gould, James" <[email-masked]>
Date: Thu, 28 Mar 2013 13:58:02 +0000

Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension
Mapping to Version 08.  You can find the draft at the URL
http://tools.ietf.org/html/draft-tan-epp-launchphase-08.  This version
includes the following changes:

   1.  Added support for use of the launch statuses and poll messaging for
Launch Registrations based on feedback from Sharon Wodjenski and Trung
Tran.
   2.  Incorporated changes based on updates or clarifications in
draft-lozano-tmch-func-spec-01
<http://tools.ietf.org/html/draft-lozano-tmch-func-spec-01>, which include:
       1.  Removed the unused <launch:generatedDate> element.
       2.  Removed the <launch:source> element.
       3.  Added the <launch:notAfter> element based on the required
<tmNotice:notAfter> element.

We are hoping that the draft can be stabilized to help with the
implementations.  Please reply with any feedback.

Thanks,

JG

James F. Gould
Verisign

---

From: Ben Levac <[email-masked]>
Date: Thu, 28 Mar 2013 09:02:17 -0700

Guys,

Thank you for the updated spec.

One small comment.  If a registry wishes to use the <launch:create> extension for landrush, the schema forces us to pass either of <launch:codeMark>, <smd:signedMark>, <smd:encodedSignedMark> or <launch:notice>.  However, in most cases, I assume that registries would not expect any Mark information, and for most cases, no notice information during the landrush period.  Could we not make those pieces of information optional by adding a minOccurs = 0 to the choice element?

I guess another option would be to NOT require the <launch:create> in landrush since no other pieces of information are required... However, I feel that it is nice to require it because it confirms that the registrar knows that he's submitting a domain application as opposed to a domain registration.

Cheers,

Ben Levac

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Thursday, March 28, 2013 6:58 AM
To: EPP Provreg ([email-masked])
Subject: [provreg] Launch Phase EPP Extension Version 08

Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 08.  You can find the draft at the URL http://tools.ietf.org/html/draft-tan-epp-launchphase-08.  This version includes the following changes:

   1.  Added support for use of the launch statuses and poll messaging for Launch Registrations based on feedback from Sharon Wodjenski and Trung Tran.
   2.  Incorporated changes based on updates or clarifications in
draft-lozano-tmch-func-spec-01
<http://tools.ietf.org/html/draft-lozano-tmch-func-spec-01>, which include:
       1.  Removed the unused <launch:generatedDate> element.
       2.  Removed the <launch:source> element.
       3.  Added the <launch:notAfter> element based on the required <tmNotice:notAfter> element.

We are hoping that the draft can be stabilized to help with the implementations.  Please reply with any feedback.

Thanks,

JG

James F. Gould
Verisign

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

Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

---

From: "Gould, James" <[email-masked]>
Date: Thu, 28 Mar 2013 16:21:23 +0000

Ben,

If the registry does not require any additional launch information from
the client on the create (mark or notice), then the extension does not
need to be passed.  By making the mark or notice optional on the create,
the only element passed would be the phase.  Do you believe that passing
the phase and requirement the extension will help in the contract between
the client and the server for a non-sunrise phase where a notice is not
required?  I recommend only adding the extension when it is needed.

-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/28/13 12:02 PM, "Ben Levac" <[email-masked]> wrote:

>One small comment.  If a registry wishes to use the <launch:create>
>extension for landrush, the schema forces us to pass either of
><launch:codeMark>, <smd:signedMark>, <smd:encodedSignedMark> or
><launch:notice>.  However, in most cases, I assume that registries would
>not expect any Mark information, and for most cases, no notice
>information during the landrush period.  Could we not make those pieces
>of information optional by adding a minOccurs = 0 to the choice element?
>
>I guess another option would be to NOT require the <launch:create> in
>landrush since no other pieces of information are required... However, I
>feel that it is nice to require it because it confirms that the registrar
>knows that he's submitting a domain application as opposed to a domain
>registration.
>
>Cheers,
>
>Ben Levac
>
>   1.  Added support for use of the launch statuses and poll messaging
>for Launch Registrations based on feedback from Sharon Wodjenski and
>Trung Tran.
>Please NOTE: This electronic message, including any attachments, may
>include privileged, confidential and/or inside information owned by
>Demand Media, Inc. Any distribution or use of this communication by
>anyone other than the intended recipient(s) is strictly prohibited and
>may be unlawful.  If you are not the intended recipient, please notify
>the sender by replying to this message and then delete it from your
>system. Thank you.

---

From: Ben Levac <[email-masked]>
Date: Thu, 28 Mar 2013 09:36:01 -0700

James,

In an environment where multiple TLDs are hosted on the same server, where TLDs can be in different phases, then it might seem like a good idea to ask the registrar to pass in the <lauch:create> extension to confirm that they know what they are asking for (sunrise application vs landrush application vs registration).  And it might not only be for landrush, but some registries may have multiple sunrise periods where the second sunrise is based on other criteria (belonging to an organization, or to a group for example), and not on Mark data.

But I also realize that making the <choice> optional means that we can't rely on XML validation to ensure that those elements are passed for regular ICANN mandated sunrise periods.

I would be interested to hear from other registries planning on running landrush phases and whether they feel that an extension would be preferable or not.

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked])
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

If the registry does not require any additional launch information from the client on the create (mark or notice), then the extension does not need to be passed.  By making the mark or notice optional on the create, the only element passed would be the phase.  Do you believe that passing the phase and requirement the extension will help in the contract between the client and the server for a non-sunrise phase where a notice is not required?  I recommend only adding the extension when it is needed.

--

JG

James Gould

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

On 3/28/13 12:02 PM, "Ben Levac" <[email-masked]> wrote:

><launch:notice>.  However, in most cases, I assume that registries
>would not expect any Mark information, and for most cases, no notice
>landrush since no other pieces of information are required... However,
>I feel that it is nice to require it because it confirms that the
>registrar knows that he's submitting a domain application as opposed to
>a domain registration.
>
>Cheers,
>
>Ben Levac
>

---

From: Seth Goldman <[email-masked]>
Date: Thu, 28 Mar 2013 12:49:35 -0400

I think the extension would be preferable. It can serve as a signal of
intent from the registrar that they know exactly what phase they're
applying for. I could perhaps envision a scenario where there's
some intercommunication between the registry and registrar on the ending
time of sunrise, and the registrar ends up creating an application instead
of an allocated registration on create.

On Thu, Mar 28, 2013 at 12:36 PM, Ben Levac <[email-masked]>wrote:

> James,
>
> In an environment where multiple TLDs are hosted on the same server, where
> TLDs can be in different phases, then it might seem like a good idea to ask
> the registrar to pass in the <lauch:create> extension to confirm that they
> know what they are asking for (sunrise application vs landrush application
> vs registration).  And it might not only be for landrush, but some
> registries may have multiple sunrise periods where the second sunrise is
> based on other criteria (belonging to an organization, or to a group for
> example), and not on Mark data.
>
> But I also realize that making the <choice> optional means that we can't
> rely on XML validation to ensure that those elements are passed for regular
> ICANN mandated sunrise periods.
>
> I would be interested to hear from other registries planning on running
> landrush phases and whether they feel that an extension would be preferable
> or not.
>
> Cheers,
>
> Ben
>
> the client on the create (mark or notice), then the extension does not need
> to be passed.  By making the mark or notice optional on the create, the
> only element passed would be the phase.  Do you believe that passing the
> phase and requirement the extension will help in the contract between the
> client and the server for a non-sunrise phase where a notice is not
> include privileged, confidential and/or inside information owned by Demand
> Media, Inc. Any distribution or use of this communication by anyone other
> than the intended recipient(s) is strictly prohibited and may be unlawful.
>  If you are not the intended recipient, please notify the sender by
> replying to this message and then delete it from your system. Thank you.

---

From: Seth Goldman <[email-masked]>
Date: Thu, 28 Mar 2013 12:50:08 -0400

s/intercommunication/miscommunication
(bad autocorrect)

On Thu, Mar 28, 2013 at 12:49 PM, Seth Goldman <[email-masked]> wrote:

>> In an environment where multiple TLDs are hosted on the same server,
>> where TLDs can be in different phases, then it might seem like a good idea
>> to ask the registrar to pass in the <lauch:create> extension to confirm
>> that they know what they are asking for (sunrise application vs landrush
>> application vs registration).  And it might not only be for landrush, but
>> some registries may have multiple sunrise periods where the second sunrise
>> is based on other criteria (belonging to an organization, or to a group for

---

From: "Gould, James" <[email-masked]>
Date: Thu, 28 Mar 2013 19:13:43 +0000

Seth & Ben,

Being explicit is certainly good.  Do the Registrars have an issue with the registries requiring the extension to be passed as a form of signaling the intent for creates during the launch phases?  If so, should an element or attribute be added on the create to indicate whether the intent is to create an application or registration?  The phase alone might not define the intent.

--

JG

James Gould

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

From: Seth Goldman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 12:49 PM
To: Ben Levac <[email-masked]<mailto:[email-masked]>>
Cc: James Gould <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

I think the extension would be preferable. It can serve as a signal of intent from the registrar that they know exactly what phase they're applying for. I could perhaps envision a scenario where there's some intercommunication between the registry and registrar on the ending time of sunrise, and the registrar ends up creating an application instead of an allocated registration on create.

On Thu, Mar 28, 2013 at 12:36 PM, Ben Levac <[email-masked]<mailto:[email-masked]>> wrote:
James,

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

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

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

On 3/28/13 12:02 PM, "Ben Levac" <[email-masked]<mailto:[email-masked]>> wrote:

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>Behalf Of Gould, James
>To: EPP Provreg ([email-masked]<mailto:[email-masked]>)
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

---

From: Seth Goldman <[email-masked]>
Date: Thu, 28 Mar 2013 15:31:47 -0400

True, the phase may not be sufficient. I guess there are three possible
values here:

   1. Create an application for this domain, otherwise fail.
   2. Allocate this domain, otherwise fail.
   3. Allocate this domain if possible; otherwise create an application.

If registrars are fine with 3) being the default behavior, then there's no
need for them to signal their intent. If they would ever want 1) or 2),
though, then we should make their intent explicit. I was imagining they 1)
or 2) to be desireable because 3) seems like a bad customer experience. But
I'm just speculating, and I don't have any special insight here.

On Thu, Mar 28, 2013 at 3:13 PM, Gould, James <[email-masked]> wrote:

>  Seth & Ben,
>
>  Being explicit is certainly good.  Do the Registrars have an issue
> with the registries requiring the extension to be passed as a form of
> signaling the intent for creates during the launch phases?  If so, should
> an element or attribute be added on the create to indicate whether the
> intent is to create an application or registration?  The phase alone might
> not define the intent.
>
>
>   -- ****
>
>
>
> JG****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
> Principal Software Engineer****
>
> [email-masked]****
>
>  ****
>
> 703-948-3271 (Office)****
>
> 12061 Bluemont Way****
>
> Reston, VA 20190****
>
> VerisignInc.com
>
>   From: Seth Goldman <[email-masked]>
> To: Ben Levac <[email-masked]>
> Cc: James Gould <[email-masked]>, EPP Provreg <[email-masked]>
>

---

From: "Gould, James" <[email-masked]>
Date: Thu, 28 Mar 2013 20:20:18 +0000

Seth,

I believe that the server will support only an application or a registration, but not both,  during a particular phase.  The creation of an application by the server will be indicated by the return of the 1001 result code and the creation of a registration by the server will be indicated by the return of a 1000 result code.  This is the same behavior when dealing with registries that do or don't support the pendingCreate in RFC 5731.  With support of the launch extension, the create response will return the launch extension with the application identifier for an application as well.  The question is whether the client should or be required to explicitly pass the launch extension with the applicable launch phase when the mark or notice is not needed.  If so, should the client also explicitly specify whether the intent is to create an application or a registration.  If the active phase of the server does not support the intent of the client (phase and application/registration) the server should fail the command.  As defined now, the client can not pass the launch extension  when the mark or notice is not required on create, and the server will create the appropriate object (application or registration) based on the active phase.

Should we do the following:

  1.  Leave the draft, where the client only passes the extension when the mark or notice information is needed.  The server will create the appropriate object (application or registration) based on the active phase and return the appropriate result code (1001 or 1000) and optionally with the launch phase extension.
  2.  Update the draft to support the option for the client to explicitly define the intended phase and optionally the intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.
  3.  Update the draft to require the client to explicitly define the intended phase and intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.

I prefer #1 and between #2 and #3, I prefer #2.

Are there any other options that should be considered?  Which option is preferred?

Thanks,

--

JG

James Gould

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

From: Seth Goldman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 3:31 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Ben Levac <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

True, the phase may not be sufficient. I guess there are three possible values here:

If registrars are fine with 3) being the default behavior, then there's no need for them to signal their intent. If they would ever want 1) or 2), though, then we should make their intent explicit. I was imagining they 1) or 2) to be desireable because 3) seems like a bad customer experience. But I'm just speculating, and I don't have any special insight here.

On Thu, Mar 28, 2013 at 3:13 PM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Seth & Ben,

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

---

From: Ben Levac <[email-masked]>
Date: Thu, 28 Mar 2013 14:50:23 -0700

James, Seth,

We prefer option #2.    We don't intend to support  more than one type (application/registration) per phase, so I don't see the need to make the object type element (or attribute) mandatory.  We would have to come up with a mechanism to make the mark or notice information optional though.

Cheers,

Ben

From: Gould, James [mailto:[email-masked]]
Sent: Thursday, March 28, 2013 1:20 PM
To: Seth Goldman
Cc: Ben Levac; EPP Provreg ([email-masked])
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

________________________________
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

---

From: Seth Goldman <[email-masked]>
Date: Fri, 29 Mar 2013 10:36:38 -0400

We also prefer #2. It leaves it open for server policy to dictate whether
they require clients to specify it or not, so it's the most flexible.

On Thu, Mar 28, 2013 at 5:50 PM, Ben Levac <[email-masked]>wrote:

>  James, Seth,****
>
> ** **
>
> We prefer option #2.    We don’t intend to support  more than one type
> (application/registration) per phase, so I don’t see the need to make the
> object type element (or attribute) mandatory.  We would have to come up
> with a mechanism to make the mark or notice information optional though.**
> **
>
> ** **
>
> Cheers,****
>
> ** **
>
> Ben****
>
> ** **
>
> *From:* Gould, James [mailto:[email-masked]]
> *Sent:* Thursday, March 28, 2013 1:20 PM
> *To:* Seth Goldman
> *Cc:* Ben Levac; EPP Provreg ([email-masked])
>
> *Subject:* Re: [provreg] Launch Phase EPP Extension Version 08****
>
>  ** **
>
> Seth,****
>
> ** **
>
> I believe that the server will support only an application or a
> registration, but not both,  during a particular phase.  The creation of an
> application by the server will be indicated by the return of the 1001
> result code and the creation of a registration by the server will be
> indicated by the return of a 1000 result code.  This is the same behavior
> when dealing with registries that do or don't support the pendingCreate in
> RFC 5731.  With support of the launch extension, the create response will
> return the launch extension with the application identifier for an
> application as well.  The question is whether the client should or be
> required to explicitly pass the launch extension with the applicable launch
> phase when the mark or notice is not needed.  If so, should the client also
> explicitly specify whether the intent is to create an application or a
> registration.  If the active phase of the server does not support the
> intent of the client (phase and application/registration) the server should
> fail the command.  As defined now, the client can not pass the launch
> extension  when the mark or notice is not required on create, and the
> server will create the appropriate object (application or registration)
> based on the active phase.    ****
>
> ** **
>
> Should we do the following:****
>
>    1. Leave the draft, where the client only passes the extension when
>    the mark or notice information is needed.  The server will create the
>    appropriate object (application or registration) based on the active phase
>    and return the appropriate result code (1001 or 1000) and optionally with
>    the launch phase extension.  ****
>    2. Update the draft to support the option for the client to explicitly
>    define the intended phase and optionally the intended object type
>    (application or registration) in the extension to create.  The server will
>    fail the command if the specified phase does not match and the specified
>    object type does not match.  ****
>    3. Update the draft to require the client to explicitly define
>    the intended phase and intended object type (application or registration)
>    in the extension to create.  The server will fail the command if the
>    specified phase does not match and the specified object type does not match.
>    ****
>
>  I prefer #1 and between #2 and #3, I prefer #2.  ****
>
> ** **
>
> Are there any other options that should be considered?  Which option is
> preferred?****
>
> ** **
>
> Thanks,****
>
> ** **
>
> ** **
>
> -- ****
>
>  ****
>
> JG****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
> VerisignInc.com****
> ** **
> *From: *Seth Goldman <[email-masked]>
> *Date: *Thursday, March 28, 2013 3:31 PM
> *To: *James Gould <[email-masked]>
> *Cc: *Ben Levac <[email-masked]>, EPP Provreg <
> [email-masked]>
> *Subject: *Re: [provreg] Launch Phase EPP Extension Version 08****
>
> ** **
>
> values here:****
>    1. Create an application for this domain, otherwise fail.****
>    2. Allocate this domain, otherwise fail. ****
>    3. Allocate this domain if possible; otherwise create an application.**
>    **
>
>  If registrars are fine with 3) being the default behavior, then there's
> no need for them to signal their intent. If they would ever want 1) or 2),
> I'm just speculating, and I don't have any special insight here.****
>
> ** **
>
> Seth & Ben,****
> ** **
> not define the intent.****
>
> ** **
>
> ** **
>
> -- ****
>
>  ****
>
> JG****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
> VerisignInc.com****
> ** **
> *From: *Seth Goldman <[email-masked]>
> *Date: *Thursday, March 28, 2013 12:49 PM
> *To: *Ben Levac <[email-masked]>
> *Cc: *James Gould <[email-masked]>, EPP Provreg <[email-masked]> **
> **
>
>
> *Subject: *Re: [provreg] Launch Phase EPP Extension Version 08****
>
> ** **
>
> of an allocated registration on create.****
>
> ** **
>
> On Thu, Mar 28, 2013 at 12:36 PM, Ben Levac <[email-masked]>
> wrote:****
>
> James,
>
> Ben****
> https://www.ietf.org/mailman/listinfo/provreg****
>
> ** **
>
>   ** **
>
>
> ------------------------------
> If you are not the intended recipient, please notify the sender by replying
> to this message and then delete it from your system. Thank you.
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 29 Mar 2013 14:52:43 +0000

I'm with Seth and Ben. #2 is the most flexible solution.

My concern is that "most flexible" also means "most potential for confusion". Registrars will have to deal with a lots of (different) phases with hundreds of registries, and they might lose business just because they failed to "label" a certain transaction with the correct phase. Registries would also need to define policy for the case when the phase is not identified, so the question of whether or not to "auto-detect" the correct phase needs to be solved in both options #1 and #2. Option #2 allows in addition, however, transactions without a phase identifier to be rejected.

Alex.

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Seth Goldman
Gesendet: Freitag, 29. März 2013 15:37
An: Ben Levac
Cc: EPP Provreg ([email-masked])
Betreff: Re: [provreg] Launch Phase EPP Extension Version 08

We also prefer #2. It leaves it open for server policy to dictate whether they require clients to specify it or not, so it's the most flexible.

On Thu, Mar 28, 2013 at 5:50 PM, Ben Levac <[email-masked]<mailto:[email-masked]>> wrote:
James, Seth,

Cheers,

Ben

From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 1:20 PM
To: Seth Goldman
Cc: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

---

From: Seth Goldman <[email-masked]>
Date: Fri, 29 Mar 2013 10:56:12 -0400

This is a fair point, but isn't that what OT&E is for? As long as the
server policy is consistent, that type of error should be caught and fixed
very early on.

On Fri, Mar 29, 2013 at 10:52 AM, Alexander Mayrhofer <
[email-masked]> wrote:

>  I’m with Seth and Ben. #2 is the most flexible solution. ****
>
> ** **
>
> My concern is that „most flexible“ also means „most potential for
> confusion“. Registrars will have to deal with a lots of (different) phases
> with hundreds of registries, and they might lose business just because they
> failed to „label“ a certain transaction with the correct phase. Registries
> would also need to define policy for the case when the phase is not
> identified, so the question of whether or not to „auto-detect“ the correct
> phase needs to be solved in both options #1 and #2. Option #2 allows in
> addition, however, transactions without a phase identifier to be rejected.
> ****
>
> ** **
>
> Alex.****
>
> ** **
>
> *Von:* [email-masked] [mailto:[email-masked]] *Im
> Auftrag von *Seth Goldman
> *Gesendet:* Freitag, 29. März 2013 15:37
> *An:* Ben Levac
> *Cc:* EPP Provreg ([email-masked])
> *Betreff:* Re: [provreg] Launch Phase EPP Extension Version 08****
>
> ** **
>
> they require clients to specify it or not, so it's the most flexible.****
>
> ** **
>
> On Thu, Mar 28, 2013 at 5:50 PM, Ben Levac <[email-masked]>
> wrote:****
>
> James, Seth,****
>
>  ****
>
> *Cc:* Ben Levac; EPP Provreg ([email-masked])****
>
>
> to this message and then delete it from your system. Thank you.****
>
> ** **
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 29 Mar 2013 15:00:19 +0000

> This is a fair point, but isn't that what OT&E is for? As long as the server 
> policy is consistent, that type of error should be caught and fixed very early on.

[Alex Mayrhofer]
True. If a TLD operator intends to perform OT&E for each individual phase of the launch :) 
#2 is good. We just need to convince our (registry) customers to keep the number of phases to a reasonable level.

Alex

---

From: Seth Goldman <[email-masked]>
Date: Fri, 29 Mar 2013 11:10:18 -0400

We have heard from at least one large registrar that they would like to
have an OT&E environment that simulates both sunrise and landrush phases
and the transitions out of those phases.

On Fri, Mar 29, 2013 at 11:00 AM, Alexander Mayrhofer <
[email-masked]> wrote:

> server

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 29 Mar 2013 12:13:48 -0300

Which could be done based on TLS certificates… login with certificate S and a Sunrise OT&E appears etc. 

Rubens

Em 29/03/2013, às 12:10, Seth Goldman escreveu:

> We have heard from at least one large registrar that they would like to have an OT&E environment that simulates both sunrise and landrush phases and the transitions out of those phases.
> 
> 
> On Fri, Mar 29, 2013 at 11:00 AM, Alexander Mayrhofer <[email-masked]> wrote:
>

---

From: "Gould, James" <[email-masked]>
Date: Fri, 29 Mar 2013 15:47:01 +0000

I believe that for option #2 it is truly optionally for the Registrars, where if the Registrar wants to ensure that the server validates their intent ahead of accepting the transaction, then they can pass the extension.  By default the server will apply the rules of the active phase and will create the object type (registration or application) of the active phase.  An example I have of specifying the phase is if a launch used a dutch auction, where sub-phases represented the price bands, by default the Registrar would get the active price at the time of the transaction.  If the Registrar wanted to ensure that they got the registration at the desired price band, then they can pass the phase (with the specific sub-phase) that would be validated by the server prior to allowing the transaction to go through.  The option of specifying the type of object (registration or application) is just an indication of the intent of the Registrar, that if it does not match what the server will do, can fast fail.

From what I understand option #2 is preferred.  Does anyone disagree with including option #2 in the draft?

Our hope was to stabilize the draft with the 08 draft, but this change obviously requires an 09 draft.  Since the door is open, are there any other desired changes that should be included in the 09 draft?  We really need to lock it down to support the implementations, so please review the draft and recommend any changes now.

Thanks,

--

JG

James Gould

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

From: Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 29, 2013 10:52 AM
To: Seth Goldman <[email-masked]<mailto:[email-masked]>>, Ben Levac <[email-masked]<mailto:[email-masked]>>
Cc: EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

I’m with Seth and Ben. #2 is the most flexible solution.

My concern is that „most flexible“ also means „most potential for confusion“. Registrars will have to deal with a lots of (different) phases with hundreds of registries, and they might lose business just because they failed to „label“ a certain transaction with the correct phase. Registries would also need to define policy for the case when the phase is not identified, so the question of whether or not to „auto-detect“ the correct phase needs to be solved in both options #1 and #2. Option #2 allows in addition, however, transactions without a phase identifier to be rejected.

Alex.

Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von Seth Goldman
Gesendet: Freitag, 29. März 2013 15:37
An: Ben Levac
Cc: EPP Provreg ([email-masked]<mailto:[email-masked]>)
Betreff: Re: [provreg] Launch Phase EPP Extension Version 08

We prefer option #2.    We don’t intend to support  more than one type (application/registration) per phase, so I don’t see the need to make the object type element (or attribute) mandatory.  We would have to come up with a mechanism to make the mark or notice information optional though.

Cheers,

Ben

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

---

From: Ben Levac <[email-masked]>
Date: Fri, 29 Mar 2013 09:15:55 -0700

James,

I think it should be up to the server policy to decide whether passing the parameter to the server for a phase such as landrush or a special sunrise is mandatory or not.  We view this parameter as a way to avoid all confusion about what the registrar is creating with their create command.  If we don’t enforce it, then it sort of defeats the purpose.

Cheers,

Ben

From: Gould, James [mailto:[email-masked]]
Sent: Friday, March 29, 2013 8:47 AM
To: Alexander Mayrhofer; Seth Goldman; Ben Levac
Cc: EPP Provreg ([email-masked])
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Thanks,

--

JG

James Gould

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

Alex.

Cheers,

Ben

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

---

From: "Gould, James" <[email-masked]>
Date: Fri, 29 Mar 2013 16:52:54 +0000

Ben,

You would be enforcing that the client knows what they are doing or at least that they explicitly express the intent of the command ahead of the server implying the intent based on the active phase.  Leaving it up to server policy, whether to make it mandatory, will get into that sticky area where registrars either must pass it all of the time to work for all registries or somehow know whether the registry requires it ahead of time.  I believe that it's in the registrar's best interest to explicitly express their intent, but I'm not sure if I would make it mandatory.  I recommend leaving the decision to the registrar and make it purely optional.  The other option is to go with option #3 and make it mandatory across the board to remove any confusion for the registrars.

--

JG

James Gould

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

From: Ben Levac <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 29, 2013 12:15 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>, Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>>, Seth Goldman <[email-masked]<mailto:[email-masked]>>
Cc: EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: RE: [provreg] Launch Phase EPP Extension Version 08

James,

Cheers,

Ben

Thanks,

--

JG

James Gould

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

Alex.

Von:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von Seth Goldman
Gesendet: Freitag, 29. März 2013 15:37
An: Ben Levac
Cc: EPP Provreg ([email-masked]<mailto:[email-masked]>)
Betreff: Re: [provreg] Launch Phase EPP Extension Version 08

Cheers,

Ben

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

---

From: Seth Goldman <[email-masked]>
Date: Fri, 29 Mar 2013 13:06:14 -0400

I like your suggestion, James. We should make it purely optional and only
having the server validate the field if the registrar passes it. That
allows registrars who care the ability to specify it and ensure the correct
behavior, but those that don't care can omit it and not have to worry about
it. And it only imposes a very slight burden on registries to implement
this functionality.

On Fri, Mar 29, 2013 at 12:52 PM, Gould, James <[email-masked]> wrote:

>  Ben,
>
>  You would be enforcing that the client knows what they are doing or at
> least that they explicitly express the intent of the command ahead of the
> server implying the intent based on the active phase.  Leaving it up to
> server policy, whether to make it mandatory, will get into that sticky area
> where registrars either must pass it all of the time to work for all
> registries or somehow know whether the registry requires it ahead of time.
>  I believe that it's in the registrar's best interest to explicitly express
> their intent, but I'm not sure if I would make it mandatory.  I recommend
> leaving the decision to the registrar and make it purely optional.  The
> other option is to go with option #3 and make it mandatory across the board
> to remove any confusion for the registrars.
>
>  -- ****
>
>
>
> JG****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
>   From: Ben Levac <[email-masked]>
> To: James Gould <[email-masked]>, Alexander Mayrhofer <
> [email-masked]>, Seth Goldman <[email-masked]>
> Cc: EPP Provreg <[email-masked]>
>    James,****
> I think it should be up to the server policy to decide whether passing the
> parameter to the server for a phase such as landrush or a special sunrise
> is mandatory or not.  We view this parameter as a way to avoid all
> confusion about what the registrar is creating with their create command.
> If we don’t enforce it, then it sort of defeats the purpose. ****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Ben****
>
> ** **
>
> *From:* Gould, James [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, March 29, 2013 8:47 AM
> *To:* Alexander Mayrhofer; Seth Goldman; Ben Levac
> I believe that for option #2 it is truly optionally for the Registrars,
> where if the Registrar wants to ensure that the server validates their
> intent ahead of accepting the transaction, then they can pass the
> extension.  By default the server will apply the rules of the active phase
> and will create the object type (registration or application) of the active
> phase.  An example I have of specifying the phase is if a launch used a
> dutch auction, where sub-phases represented the price bands, by default the
> Registrar would get the active price at the time of the transaction.  If
> the Registrar wanted to ensure that they got the registration at the
> desired price band, then they can pass the phase (with the specific
> sub-phase) that would be validated by the server prior to allowing the
> transaction to go through.  The option of specifying the type of object
> (registration or application) is just an indication of the intent of the
> Registrar, that if it does not match what the server will do, can fast
> fail.  ****
>
> ** **
>
> From what I understand option #2 is preferred.  Does anyone disagree with
> including option #2 in the draft? ****
>
> ** **
>
> Our hope was to stabilize the draft with the 08 draft, but this change
> obviously requires an 09 draft.  Since the door is open, are there any
> other desired changes that should be included in the 09 draft?  We really
> need to lock it down to support the implementations, so please review the
> draft and recommend any changes now.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> -- ****
>
>  ****
>
> JG****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
> *From: *Alexander Mayrhofer <[email-masked]>
> *Date: *Friday, March 29, 2013 10:52 AM
> *To: *Seth Goldman <[email-masked]>, Ben Levac <
> [email-masked]>
> *Cc: *EPP Provreg <[email-masked]>
> *Von:[email-masked] [mailto:[email-masked]<[email-masked]>]
> * Im Auftrag von *Seth Goldman

---

From: Ben Levac <[email-masked]>
Date: Fri, 29 Mar 2013 12:56:31 -0700

Seth, James,

Even if a registrar decides to implement the optional element on domain create, they could still get into trouble if the server does not enforce it...

In the promised land of 20 TLDs a week coming on board, it is easy to envision that some configuration errors could happen.  If a registrar has configured their system to treat a TLD as "GA" when it's actually in "LANDRUSH", their system would accept registration orders, and the resulting EPP create command would not have the "phase" element.  Not because they didn't "care the ability to specify it and ensure the correct behavior", but because an error happened somewhere.

That domain create command would be successful, resulting in an application rather than a registration (expected behavior).  If the phase was mandatory, the create command would fail, because you need to specify the launch:phase.  Reversing such transactions would be work for everyone.

I would be curious to get the opinion of registrars planning to offer multiple new gTLDs.  Is making this element mandatory going to add a significant effort on their part?

Cheers,

Ben

From: Seth Goldman [mailto:[email-masked]]
Sent: Friday, March 29, 2013 10:06 AM
To: Gould, James
Cc: Ben Levac; Alexander Mayrhofer; EPP Provreg ([email-masked])
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

I like your suggestion, James. We should make it purely optional and only having the server validate the field if the registrar passes it. That allows registrars who care the ability to specify it and ensure the correct behavior, but those that don't care can omit it and not have to worry about it. And it only imposes a very slight burden on registries to implement this functionality.

On Fri, Mar 29, 2013 at 12:52 PM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Ben,

--

JG

James Gould

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

James,

I think it should be up to the server policy to decide whether passing the parameter to the server for a phase such as landrush or a special sunrise is mandatory or not.  We view this parameter as a way to avoid all confusion about what the registrar is creating with their create command.  If we don't enforce it, then it sort of defeats the purpose.

Cheers,

Ben

Thanks,

--

JG

James Gould

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

Alex.

Cheers,

Ben

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

---

From: "Gould, James" <[email-masked]>
Date: Fri, 29 Mar 2013 20:16:26 +0000

Ben,

It sounds like you prefer option #3 (make the extension mandatory) to option #2 (make the extension optional).  A 2b option is to make the extension optional and make the validation by the registry mandatory, so if the extension is passed the server MUST fail the command if the phase passed does not match the active phase or if the type (application or registration) passed does not match the type that will be created.    Are you good with 2b or do you want to press for option #3?

Thanks,

--

JG

James Gould

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

From: Ben Levac <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 29, 2013 3:56 PM
To: Seth Goldman <[email-masked]<mailto:[email-masked]>>, James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: RE: [provreg] Launch Phase EPP Extension Version 08

Seth, James,

Even if a registrar decides to implement the optional element on domain create, they could still get into trouble if the server does not enforce it…

In the promised land of 20 TLDs a week coming on board, it is easy to envision that some configuration errors could happen.  If a registrar has configured their system to treat a TLD as “GA” when it’s actually in “LANDRUSH”, their system would accept registration orders, and the resulting EPP create command would not have the “phase” element.  Not because they didn’t “care the ability to specify it and ensure the correct behavior”, but because an error happened somewhere.

Cheers,

Ben

From: Seth Goldman [mailto:[email-masked]]
Sent: Friday, March 29, 2013 10:06 AM
To: Gould, James
Cc: Ben Levac; Alexander Mayrhofer; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

--

JG

James Gould

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

James,

Cheers,

Ben

Thanks,

--

JG

James Gould

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

Alex.

Cheers,

Ben

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Sun, 31 Mar 2013 20:06:10 +0000

Option #1 would definitely also work for us, since we try to keep the set of EPP extensions / features as simple as possible [Sadly, often enough *technical* availability of a certain feature tends to *triggers* unneccessary creativity in policy-land :-/ ]. Option #3 is hence undesirable for us.

Alex

Von: Gould, James [mailto:[email-masked]]
Gesendet: Freitag, 29. März 2013 16:47
An: Alexander Mayrhofer; Seth Goldman; Ben Levac
Cc: EPP Provreg ([email-masked])
Betreff: Re: [provreg] Launch Phase EPP Extension Version 08

Thanks,

--

JG

James Gould

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

Alex.

Cheers,

Ben

Seth,

Thanks,

--

JG

James Gould

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

--

JG

James Gould

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

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

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