Subject: [provreg] Launch Phase EPP Extension Version 10

From: "Gould, James" <[email-masked]>
Date: Wed, 1 May 2013 12:32:56 +0000

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

   1.  Changed noticeIDType from base64Binary to token to be compatible with
       draft-lozano-tmch-func-spec-05<http://tools.ietf.org/html/draft-lozano-tmch-func-spec-05>.
   2.  Changed codeType from base64Binary to token to be more generic.
   3.  Updated based on feedback from Alexander Mayrhofer, which
       include:
       1.   Changed "extension to the domain name extension" to
            "extension to the domain name mapping".
       2.   Changed use of 2004 return code to 2306 return code when
            phase passed mismatches active phase and sub-phase.
       3.   Changed description of "allocated" and "rejected" statuses.
       4.   Moved sentence on a synchronous <domain:create> command
            without the use of an intermediate application, then an
            Application Identifier MAY not be needed to the Application
            Identifier section.
       5.   Restructured the Mark Validation Models section to include
            the "<launch:codeMark> element" sub-section, the "<mark:
            mark> element" sub-section, and the Digital Signature sub-
            section.
       6.   Changed "Registries may" to "Registries MAY".
       7.   Changed "extensed" to "extended" in "Availability Check
            Form" section.
       8.   Broke the mix of create forms in the "EPP <create> Command"
            section to a fourth "Mixed Create Form" with its own sub-
            section.
       9.   Removed "displayed or" from "displayed or accepted" in the
            <launch:acceptedDate> description.
       10.  Replaced "given domain name is supported" with "given domain
            name are supported" in the "Create Response" section.
       11.  Changed the reference of 2303 (object does not exist) in the
            "Security Considerations" section to 2201 (authorization
            error).
       12.  Added arrow from "invalid" status to "pendingValidation"
            status and "pendingAllocation" status to "rejected" status
            in the State Transition Diagram.
   4.  Added the "C:" and "S:" example prefixes and related text in the
       "Conventions Used in This Document" section.

We are hoping that the draft stabilizes with this version.  Please reply
with any feedback.

Thanks,

JG

James F. Gould
Verisign

"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."

---

From: Ben Levac <[email-masked]>
Date: Fri, 3 May 2013 08:46:08 -0700

James,

I do have some questions, specifically around how the proposed model handles simultaneous phases.

1 - The first question is around the handling of overlapping claims and landrush (which will most likely be the case for us).  If I understood section 2.2 of the requirement, a landrush application that was NOT subject to a claim would pass the launch:create extension with just the phase like this:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" type="application">
                <launch:phase>landrush</launch:phase>
</launch:create>

While a landrush application that WAS subject to a claims would pass the following extension:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name="landrush">claims</launch:phase>
  <launch:notice>
  ...
  </launch:notice>
</launch:create>

COMMENT: This means that we can't judge the phase based only the value of the phase element, but we also have to base it off the name which seems a bit awkward.

2 - In the case where we are running a special custom "sunrise 2" to restrict registration to a specific group, it's not clear to me whether we should follow the proposed landrush from 2.2:

Without claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" type="application">
                <launch:phase name="sunrise 2">custom</launch:phase>
</launch:create>

With claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name="sunrise 2">claims</launch:phase>
  <launch:notice>
  ...
  </launch:notice>
</launch:create>

Or whether we should use a custom phase sort of as is proposed in section 3.3.4:

Without claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" type="application">
                <launch:phase name="sunrise 2">custom</launch:phase>
</launch:create>

With claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name="sunrise 2 - claims">custom</launch:phase>
  <launch:notice>
  ...
  </launch:notice>
</launch:create>

3 - Finally there might be a scenario where we might want to run 2 concurrent custom phases.  Say that there are some domains which will require mark data to be registered, even in a custom sunrise or landrush.  We would expect a "custom" phase with mark information to be passed.  But if this happens during a custom sunrise,  then I can't think of a good way to handle this, other than creating a hybrid custom phase, so you would use either:

<launch:phase name="special">custom</launch:phase>
<launch:phase name="sunrise2 - special">custom</launch:phase>

4 - COMMENT: Given 1, 2 and 3, wouldn't it be better if we allowed someone to send multiple independent phases?  Different scenarios include completely different launch:create extensions, one for each phase with the data required for that phase.   Or just allowing multiple phase elements inside the single extension?  There are other options that could be cleaner such as turning the launch:create into a collection, but that would be a big schema change at this point in the game...

5 - My next question is regarding the INFO command specified in 3.2:

If the application/registration was created as part of a claim request, would the info response ever show the claims information?  So for example, if I created a landrush domain that had a claim against it with what I assume is the proposed method:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name="landrush">claims</launch:phase>
  <launch:notice>
  ...
  </launch:notice>
</launch:create>

Then what INFO command extension phase information would the registrar have to send to get information back on this domain?  And what phase information would the server return to him in the response?

6 - Is phase information really required for INFO requests?  I assume that application IDs are unique to the registry?  So if you pass it in, then we would return information regarding the application including the phase.  Otherwise, we are infoing a registration.  In this case, I'm not sure why we would want to send in the extension?

Sorry for the long list of questions this late in the process, but I just want to make sure that we (and everyone on the list) have a clear understanding of the mechanisms, especially around concurrent phases which does tend to get a bit more complicated.

Cheers,

Ben

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg ([email-masked])
Subject: [provreg] Launch Phase EPP Extension Version 10

       include:

            Identifier section.

            section.

            Form" section.

            section.

            error).

Thanks,

JG

James F. Gould
Verisign

________________________________
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: Fri, 3 May 2013 18:39:29 +0000

Ben,

My feedback is below.  To note, these are suggestions on how I might go about it, but I'm sure there are other ways to skin the cat.

--

JG

James Gould
Principal Software Engineer
[email-masked]

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

From: Ben Levac <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 3, 2013 11:46 AM
To: James Gould <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: RE: Launch Phase EPP Extension Version 10

James,

1 – The first question is around the handling of overlapping claims and landrush (which will most likely be the case for us).  If I understood section 2.2 of the requirement, a landrush application that was NOT subject to a claim would pass the launch:create extension with just the phase like this:

The phase that is being passed should match the phase that the server is activitly running, which is "claims" with the sub-phase "landrush".  It would look like the following in General Create Form according to the overlap handling defined in section 2.2 "Launch Phase":

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name=”landrush”>claims</launch:phase>
  <launch:notice>
  …
  </launch:notice>
</launch:create>

COMMENT: This means that we can’t judge the phase based only the value of the phase element, but we also have to base it off the name which seems a bit awkward.

The phases would be exactly the same for this use case, except the notice would be included:

…
</launch:notice>
</launch:create>

2 – In the case where we are running a special custom “sunrise 2” to restrict registration to a specific group, it’s not clear to me whether we should follow the proposed landrush from 2.2:

Without claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" type="application">
                <launch:phase name=”sunrise 2”>custom</launch:phase>
</launch:create>

With claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name=”sunrise 2”>claims</launch:phase>
  <launch:notice>
  …
  </launch:notice>
</launch:create>

Does the "sunrise 2" overlap with the "claims" phase and does it proceed the "landrush" phase?  If so, I would recommend always specifying "claims" as the phase and "sunrise 2" or "landrush" as a sub-phase for both the General Create Form and the Claims Create Form as in:

…
</launch:notice>
</launch:create>

Without claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" type="application">
                <launch:phase name=”sunrise 2”>custom</launch:phase>
</launch:create>

With claim:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name=”sunrise 2 - claims”>custom</launch:phase>
  <launch:notice>
  …
  </launch:notice>
</launch:create>

I do not believe there is the need for a custom phase.

3 – Finally there might be a scenario where we might want to run 2 concurrent custom phases.  Say that there are some domains which will require mark data to be registered, even in a custom sunrise or landrush.  We would expect a “custom” phase with mark information to be passed.  But if this happens during a custom sunrise,  then I can’t think of a good way to handle this, other than creating a hybrid custom phase, so you would use either:

<launch:phase name=”special”>custom</launch:phase>
<launch:phase name=”sunrise2 - special”>custom</launch:phase>

I always view the server being in a single active phase, where in this use case the active phase will require mark data for a subset of the domains.  The phase value passed can be identical, where it could be a single custom phase (e.g. <launch:phase name="special">custom</launch:phase>), and the passing of the required mark data would be up to the client to pass based on I'm guessing a known set of domains that would require it.  The server would match the custom phase and would apply the server logic for the different groups of domains (requiring the mark data or not).  If this phase overlaps with the "claims" phase, then the same use of a sub-phase would apply that was discussed in the prior use cases.

4 – COMMENT: Given 1, 2 and 3, wouldn’t it be better if we allowed someone to send multiple independent phases?  Different scenarios include completely different launch:create extensions, one for each phase with the data required for that phase.   Or just allowing multiple phase elements inside the single extension?  There are other options that could be cleaner such as turning the launch:create into a collection, but that would be a big schema change at this point in the game…

I believe that you can accomplish this using a combination of the phase and sub-phases with the option of passing the notice and the mark information.  The key is not to make it so custom that it will make it too challenging for the client to now what to do.

5 – My next question is regarding the INFO command specified in 3.2:

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
  <launch:phase name=”landrush”>claims</launch:phase>
  <launch:notice>
  …
  </launch:notice>
</launch:create>

The phase of the info is based on the context of when the application or registration was created.  The only applicable information returned in the extension to the info response during the claims phase is the application information (e.g. status).  The info response does not support the returning of the claims information.

6 – Is phase information really required for INFO requests?  I assume that application IDs are unique to the registry?  So if you pass it in, then we would return information regarding the application including the phase.  Otherwise, we are infoing a registration.  In this case, I’m not sure why we would want to send in the extension?

The draft does not specify that the application ID's are unique, but I believe they should be.  The phase defines the context of the query and the application ID defines the specific application without the phase; although I don't see why an application ID can not be unique across phases. Outside sunrise, the extension to the info command / response is focused on the application status.

Hopefully my suggestions help.

Cheers,

Ben

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: [provreg] Launch Phase EPP Extension Version 10

       include:

            Identifier section.

            section.

            Form" section.

            section.

            error).

Thanks,

JG

James F. Gould
Verisign

“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.”

---

From: Ben Levac <[email-masked]>
Date: Sun, 5 May 2013 16:13:52 -0700

James,

Thank you for your answers.  It certainly does clarifies what the vision behind some of the suggestions in the document.

It seems that you are suggesting that if the claims and landrush phases overlap, then the claims period is the principal phase?  Since ICANN is currently proposing the claims period for 90 days after sunrise, it is likely that landrush and claims will overlap for a lot of registries.  And what seems awkward to me is that we would be asking registrars to send the following phase information for every single application even though (I assume) few of them will ever actually need to pass actual claims notice information...

Wouldn't it make more sense to ask them to provide the following, because to my previous comments on this topic in revision 08, I am most interested in validating their actual intention of submitting a landrush application (as opposed to a general registration).

>From a validation perspective, I'm not sure I care to validate the fact that they passed in "claims" as a phase or sub-phase.  I do however, want to validate that they passed in valid claims notice information if the domain is part of the DNL list.  And we would return an error message if they did not.

What I would also want to avoid is that if the landrush period does last longer than the claims period, to have different phase values for landrush applications.  For example:

1 - Applications submitted before claim ends would have to return the following phase in the info response: <launch:phase name="landrush">claims</launch:phase>
2 - While applications submitted after the claims period ends would have to return the following in the response: <launch:phase>landrush</launch:phase>

Because they are all landrush applications, I would only ever want to have to return <launch:phase>landrush</launch:phase> in the info response, especially since we never even return the claims information.

I have a couple of questions about the following statement:

JG>The draft does not specify that the application ID's are unique, but I believe they should be.  The phase defines the context of the query and the application ID defines the specific application without the phase; although I don't see why an application ID cannot be unique across phases. Outside sunrise, the extension to the info command / response is focused on the application status.

1 - What would the INFO response return if a registrar passed in a phase and no application ID?  Would we return a validation error?  If the domain was registered in that phase, I would expect the INFO to return a regular INFO response.  If the domain created an application, I would expect the application ID to return information about it?
2 - If the INFO request did include the application ID, should we validate the phase to make sure that it matched the phase of the application?  Again, that could get complicated if the phase of the application in landrush used different values depending on overlapping periods.

Cheers,

Ben

From: Gould, James [mailto:[email-masked]]
Sent: Friday, May 03, 2013 11:39 AM
To: Ben Levac; EPP Provreg ([email-masked])
Subject: Re: Launch Phase EPP Extension Version 10

Ben,

--

JG

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

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

James,

<launch:notice>
...
</launch:notice>
</launch:create>

Without claim:

With claim:

<launch:notice>
...
</launch:notice>
</launch:create>

Without claim:

With claim:

Cheers,

Ben

       include:

            Identifier section.

            section.

            Form" section.

            section.

            error).

Thanks,

JG

James F. Gould
Verisign

---

From: "Gould, James" <[email-masked]>
Date: Mon, 6 May 2013 13:00:25 +0000

Ben,

My feedback is below.

--

JG

James Gould

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

From: Ben Levac <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 5, 2013 7:13 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: RE: Launch Phase EPP Extension Version 10

James,

It seems that you are suggesting that if the claims and landrush phases overlap, then the claims period is the principal phase?  Since ICANN is currently proposing the claims period for 90 days after sunrise, it is likely that landrush and claims will overlap for a lot of registries.  And what seems awkward to me is that we would be asking registrars to send the following phase information for every single application even though (I assume) few of them will ever actually need to pass actual claims notice information…

Yes, this is the recommended phase for landrush during the claims period.  There are many ways to handle this, but it was felt that leveraging the existing support for phases and optional sub-phases for the overlapping claims and landrush phases to be the cleanest and least impactful.  Passing the same values for the phase independent of the need for a notice should be easier for the client as well.

Wouldn’t it make more sense to ask them to provide the following, because to my previous comments on this topic in revision 08, I am most interested in validating their actual intention of submitting a landrush application (as opposed to a general registration).

As discussed earlier on the list a landrush could be setup with a first-come-first-serve model in the case of a dutch auction, so there is no implied expectation that the landrush phase will result in an application.  The draft supports the client passing the expected object to create with the optional "type" attribute with the values of "application" or "registration".  The extension could include the following value for an overlapping landrush during claims of applications.  My recommendation is not to require the "type" attribute to be passed, but to simply validate it if passed by the client against the type of object that will be created with the active server launch phase.

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
    type="application">
   <launch:phase name="landrush">claims</launch:phase>
</launch:create>

>From a validation perspective, I’m not sure I care to validate the fact that they passed in “claims” as a phase or sub-phase.  I do however, want to validate that they passed in valid claims notice information if the domain is part of the DNL list.  And we would return an error message if they did not.

1 - Applications submitted before claim ends would have to return the following phase in the info response: <launch:phase name=”landrush”>claims</launch:phase>
2 – While applications submitted after the claims period ends would have to return the following in the response: <launch:phase>landrush</launch:phase>

Yes, this is a corner case that would require you to split the landrush into separate phases: "claims" with "landrush" sub-phase and "landrush".  You could consider extending the "claims" phase to fully cover the "landrush" to forgo the split.  I'm not sure if this is a likely use case considering the requirement for a 90 day claims, but you have the option of having the landrush as a sub-phase of claims, split the phases, or start landrush after claims.

1 – What would the INFO response return if a registrar passed in a phase and no application ID?  Would we return a validation error?  If the domain was registered in that phase, I would expect the INFO to return a regular INFO response.  If the domain created an application, I would expect the application ID to return information about it?

If an info command was sent without the application ID then that would mean that the phase passed was for a none pending launch phase, so if the launch phase was a non pending launch phase the server could return a successful info response.  In the case of sunrise, this could include the <launch:mark> information.  A registration can have launch statuses as well, so the <launch:status> could be returned.  An info command referencing a launch phase that was a pending launch phase without the application ID should result in an error.

2 – If the INFO request did include the application ID, should we validate the phase to make sure that it matched the phase of the application?  Again, that could get complicated if the phase of the application in landrush used different values depending on overlapping periods.

Yes, the correct phase value should be passed to get the information for the application that was created in that phase.  This is one reason that we included the recommendation to use <launch:phase name="landrush">claims</launch:phase> as the phase for the likely combination of landrush and claims.

Cheers,

Ben

From: Gould, James [mailto:[email-masked]]
Sent: Friday, May 03, 2013 11:39 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: Launch Phase EPP Extension Version 10

Ben,

--

JG

James Gould

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

James,

<launch:notice>
…
</launch:notice>
</launch:create>

Without claim:

With claim:

<launch:notice>
…
</launch:notice>
</launch:create>

Without claim:

With claim:

Cheers,

Ben

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: [provreg] Launch Phase EPP Extension Version 10

       include:

            Identifier section.

            section.

            Form" section.

            section.

            error).

Thanks,

JG

James F. Gould
Verisign