Re: Launch Phase EPP Extension Version 10

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

<launch:phase name="landrush">claims</launch:phase>

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

<launch:phase>landrush</launch:phase>

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 protected]]
Sent: Friday, May 03, 2013 11:39 AM
To: Ben Levac; EPP Provreg ([email protected])
Subject: Re: Launch Phase EPP Extension Version 10

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

[cid:[email protected]]

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

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

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

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>


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" type="application">
                <launch:phase name="landrush">claims</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.


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

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

<launch:notice>
...
</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:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" type="application">
                <launch:phase name="sunrise 2">claims</launch:phase>
</launch:create>

<launch:create xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" type="application">
                <launch:phase name="landrush">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>


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:

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?


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.

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.

Hopefully my suggestions help.


Cheers,

Ben

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

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

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

________________________________
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