Re: 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 protected]>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 protected]]
> *Sent:* Thursday, March 28, 2013 1:20 PM
> *To:* Seth Goldman
> *Cc:* Ben Levac; EPP Provreg ([email protected])
>
> *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****
>
> 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 3:31 PM
> *To: *James Gould <[email protected]>
> *Cc: *Ben Levac <[email protected]>, EPP Provreg <
> [email protected]>
> *Subject: *Re: [provreg] 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****
>
> ** **
>
>   ** **
>
>
> ------------------------------
> 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