Re: Launch Phase EPP Extension Version 08

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 protected]> 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 protected]****
>
>  ****
>
> 703-948-3271 (Office)****
>
> 12061 Bluemont Way****
>
> Reston, VA 20190****
>
> VerisignInc.com
>
>   From: Seth Goldman <[email protected]>
> Date: Thursday, March 28, 2013 12:49 PM
> To: Ben Levac <[email protected]>
> Cc: James Gould <[email protected]>, EPP Provreg <[email protected]>
>
> 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 protected]>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
>>
>> -----Original Message-----
>> From: Gould, James [mailto:[email protected]]
>> Sent: Thursday, March 28, 2013 9:21 AM
>> To: Ben Levac; EPP Provreg ([email protected])
>> 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
>> Principal Software Engineer
>> [email protected]
>>
>> 703-948-3271 (Office)
>> 12061 Bluemont Way
>> Reston, VA 20190
>> VerisignInc.com
>>
>>
>>
>>
>>
>> On 3/28/13 12:02 PM, "Ben Levac" <[email protected]> wrote:
>>
>> >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 protected] [mailto:[email protected]] On
>> >Behalf Of Gould, James
>> >Sent: Thursday, March 28, 2013 6:58 AM
>> >To: EPP Provreg ([email protected])
>> >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 protected]
>> >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.
>> >_______________________________________________
>> >provreg mailing list
>> >[email protected]
>> >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.
>> _______________________________________________
>> provreg mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/provreg
>>
>
>

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