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>

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 protected] [mailto:[email protected]] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg ([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.

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