Re: Recombining the claims1 and claims2 phases to the claims phase in draft-tan-epp-launchphase?

James,

Thanks for the detailed response with examples on how you will probably handle it.  Our launches are somewhat simplified, where it could look something like:

  *   <create> with phase = "sunrise" will be used for Sunrise (with either <smd:encodedSignedMark> or <smd:signedMark>).
  *   <create> with phase= "claims" for Claims (no requirement to pass the extension when the notice is not required).
     *   If a "landrush" phase is needed, <create> with "claims" and with sub-phase" landrush", but passing the sub-phase or the extension is not required.  The server will validate the values when passed.

I include some feedback below.

--

JG

[cid:5FE982D3-77D6-43E8-AD81-DEE74B281F19]

James Gould
Principal Software Engineer
[email protected]

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

From: James Mitchell <[email protected]<mailto:[email protected]>>
Date: Tuesday, April 9, 2013 9:49 AM
To: James Gould <[email protected]<mailto:[email protected]>>, Alexander Mayrhofer <[email protected]<mailto:[email protected]>>
Cc: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Recombining the claims1 and claims2 phases to the claims phase in draft-tan-epp-launchphase?

Jim

Combining orthogonal concepts (claims, applications, dutch-auctions) in one value (phase) is not a good idea. Our approach was to completely separate claims and applications, leading to our two proposed drafts (as discussed, I do not believe dutch auctions should be executed with the launch extension). I also do not believe registrars need to provide phases during normal registry operations (FCFS), even for temporary activities. I'm going to assume that separation, as described in the two drafts, is off the table given you are pushing hard to avoid any change to the spec.

Yes, the hope would be that the 09 draft would be the candidate draft as a single draft.  We want to minimize the change but we should look to accommodate important changes needed to support the various launches.


IMO it will be by chance that two registries actually provide the same interface for the same business rules, only because this draft leaves almost everything up to the server. Our implementation will probably look like:

  *   <create> with phase="sunrise" will be used for the Sunrise (with <encodedSignedMark>).
  *   <create> with phase="custom" with name="some-value" will be used for Limited Registration Periods (with <notice>*).
  *   <create> with phase="landrush" will be used for General Registration where multiple applications are accepted for one name (with <notice>)
  *   <create> with phase="claims/open" will be used for claims during FCFS (with <notice>).
  *   <check> with phase="claims" will be used to check for claims information, regardless of whether custom, landrush or claims is used during registration.

Clients do not need to tell us they are registering a domain in the "claims" phase. They simply provide claims information in the command when required, and the server will reject commands missing claims information when required.

We will validate the phase value passed against the active phase.  We will not require the extension during the "claims" phase when the notice is not required.


We prefer the sub-phase value over the phase value, meaning that <phase name="sunrise">landrush</phase> results in a sunrise application. For Limited Registration we match the value of the name attribute, and I don't want extra code to work around the spec allowing two input values when one is required. My preference would be that the schema does not enumerate all possible values for the <phase> element, instead allows free form text with definitions of "reserved" values.

In the 09 draft right now we are adding the optional "type" attribute to the <launch:create> element that I believe will meet your needs without having to overload the <launch:phase> element.  A sunrise application could look like:

         <launch:create
          xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
          type="application">
           <launch:phase>sunrise</launch:phase>
           <smd:signedMark id="signedMark"
            xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0">
            ...
           </smd:signedMark>
         </launch:create>


A sunrise registration would look like:

         <launch:create
          xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
          type="registration">
           <launch:phase>sunrise</launch:phase>
           <smd:signedMark id="signedMark"
            xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0">
            ...
           </smd:signedMark>
         </launch:create>

What do you think of this?


* this spec falls short during Limited Registration Periods as it should be possible to provide both an implementation of mark:abstractMark and the claims notice. We have a client that may have a limited registration period for trademarks not in the clearinghouse, during which claims is also required. Moving the notice out of the <choice> element, and making it optional would enable this phase without further extensions.

That can be done.  It makes it a little bit of a challenge to describe the forms of the create that have been expanded from two (Sunrise Create Form, Claims Create Form) to three (Sunrise Create Form, Claims Create Form, General Create Form), where the General Create Form supports passing just the phase and optionally the new type attribute (application or registration).  What do others think on making the proposed change?


Regards,
James

From: <Gould>, James <[email protected]<mailto:[email protected]>>
Date: Tuesday, 9 April 2013 8:23 PM
To: Alexander Mayrhofer <[email protected]<mailto:[email protected]>>
Cc: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Recombining the claims1 and claims2 phases to the claims phase in draft-tan-epp-launchphase?

Alexander,

Yes the overlap of the phases is an open issue.  My thought is that based on the use of the claims check and the extra validation and properties required on the create that the primary phase should be "claims".  The sub-phase could be used  to express an overlapping phase like landrush.  Outside of the TMCH model, landrush should be a first class phase, so the thought is to leave it as a primary phase for non-TMCH launches like for ccTLDs.  Since the definition of the sub-phase should be flexible, maybe for the overlap we just add some text to the draft defining the recommended approach for this.  Should landrush as a sub-phase of claims be the recommended approach?  Are there any other recommendations in dealing with the likely overlapping phases in the TMCH model?

JG

James F. Gould
Principal Engineer
Verisign

[email protected]<mailto:[email protected]>

On Apr 9, 2013, at 3:39 AM, "Alexander Mayrhofer" <[email protected]<mailto:[email protected]>> wrote:

James,

I agree that it doesn’t make sense to keep the two distinct „claims“ phase identifiers in the draft, and hence support (at least) merging them.

On a more general note, i think there’s a layering problem with the „claims“ phase notion in general. Since the time phase during which Claims Services are required to be active might span several other „phases“, during which the client has no choice than provide the claims notice information (or be refused registrations).

For example, a registry might want to do the following sequence:

sunrise(30d) – custom (30d) – landrush/auction (30d) - open

Applying ICANN‘s most recent TMCH RPMs to the example above, Claims services would be required for custom (assuming it’s a „limited registration period“), landrush, and then at least first 60d of the open registration period (. So the „claims“ phase label would actually be an independent „property“ of the full time span of the custom and landrush phases, and the first 60d of the open registration.  In some cases, Claims services might be active for just part of an phase.

So, if „claims“ is just a name of a phase, fine. It would probably not be used in the startup sequence outlined above. But if „claims“ would be required if claims services are active, i don’t see how the above sequence could be expressed using the available names. An option would be to reduce the „claims“ phase to an attribute of all phases, such as:

<launch:phase claims=‘active‘>custom</launch:phase>

But, coming back to my original point: There is almost zero risk when a client fails to designate to the server that claims services are active. Worst that can happen is that the server refuses the transaction because of a claims notice information. Which means that we could probably even drop the „claims“ phase designation entirely?

I’m not asking for any of these changes to be applied to the document – this is supposed to be food for though... Comments?

Alex


Von:[email protected]<mailto:[email protected]> [mailto:[email protected]] Im Auftrag von Gould, James
Gesendet: Montag, 08. April 2013 21:29
An: EPP Provreg
Betreff: [provreg] Recombining the claims1 and claims2 phases to the claims phase in draft-tan-epp-launchphase?

We are currently working on the draft-tan-epp-launchphase-09 updates and wanted to know what the list felt about replacing the "claims1" and "claims2" phases with simply the "claims" phase.  The split of "claims" to "claims1" and "claims2" occurred after the LA meeting in the 04 draft.  Since draft-lozano-tmch-func-spec doesn't reference claims2, it doesn't seem to make sense to continue to reference it within draft-tan-epp-launchphase and recombine "claims1" and "claims2" into "claims".  Please post your thoughts to the list or privately on this potential change.

Thanks,

--

JG

<image001.png>

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

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>
“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.”

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