Subject: [provreg] Recombining the claims1 and claims2 phases to the claims phase in draft-tan-epp-launchphase?

From: "Gould, James" <[email-masked]>
Date: Mon, 8 Apr 2013 19:28:52 +0000

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

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
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."

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 9 Apr 2013 07:39:37 +0000

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-masked] [mailto:[email-masked]] 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?

Thanks,

--

JG

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

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2013 10:23:16 +0000

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

On Apr 9, 2013, at 3:39 AM, "Alexander Mayrhofer" <[email-masked]<mailto:[email-masked]>> 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).

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-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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?

Thanks,

--

JG

James Gould

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

---

From: Seth Goldman <[email-masked]>
Date: Tue, 9 Apr 2013 08:48:25 -0400

The word "subphase" bothers me a bit, since it carries with it the notion
that it's subordinate to the main phase. But that may not be the case; it
could just be that the phases have some partial overlap with no fixed
relationship between them.

Perhaps it would be better to just to express this as multiple "phase"
elements?
On Apr 9, 2013 6:23 AM, "Gould, James" <[email-masked]> wrote:

>  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-masked]
>
> On Apr 9, 2013, at 3:39 AM, "Alexander Mayrhofer" <
> [email-masked]> 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-masked] [mailto:[email-masked]<[email-masked]>]
> *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****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
> Principal Software Engineer****
>
> [email-masked]****
>
>  ****
>
> 703-948-3271 (Office)****
>
> 12061 Bluemont Way****
>
> Reston, VA 20190****
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/provreg
>
>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2013 13:47:37 +0000

Seth,

Let put some options out there to help address this.  Some of the ones that I've thought of include:

  1.  Utilize the sub-phase feature using the "name" attribute that is already in the draft.  Choose a primary phase and a sub-phase, where I believe claims should be the primary and landrush or any other selective or asynchronous phase should be the sub-phase value.  The "name" attribute is freeform, so the use of the sub-phase "landrush" could only be included in the text of the draft and not in the XML schema.
  2.  Add a new "overlap" attribute to the <launch:phase> element that utilizes the same enumerated set of phase values (sunrise, landrush, claims, open, custom) for the <launch:phase> element.  I believe in this case the "overlap" would not be classified as a sub-phase but would be elevated to the same level as the <launch:phase> value.  The concept of the sub-phase using the "name" attribute could still be used to further refine the phase with a freeform value.
  3.  Support more then one <launch:phase> element.  This might cause more confusion over the set of <launch:phase> elements that should be passed and have a greater impact on the interface since it goes from one to a list of phases.

Option #1 would look like:

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

           …

         </launch:create>

Option #2 would look like:

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

           …

         </launch:create>

Option #3 would look like:

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

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

           …

         </launch:create>

Option #2 and #3 could utilize the optional <launch:phase> "name" attribute as well that I don't show above.

I'm really concerned about adding more complexity for this, so I prefer option #1.

Any there any other options to consider and are there any preferences to the options presented above?

--

JG

James Gould

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

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

The word "subphase" bothers me a bit, since it carries with it the notion that it's subordinate to the main phase. But that may not be the case; it could just be that the phases have some partial overlap with no fixed relationship between them.

Perhaps it would be better to just to express this as multiple "phase" elements?

On Apr 9, 2013 6:23 AM, "Gould, James" <[email-masked]<mailto:[email-masked]>> wrote:
Alexander,

JG

James F. Gould
Principal Engineer
Verisign

James,

Alex

Von:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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?

Thanks,

--

JG

James Gould

703-948-3271<tel: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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

---

From: James Mitchell <[email-masked]>
Date: Tue, 9 Apr 2013 23:49:25 +1000

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.

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

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

Regards,
James

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

Alexander,

JG

James F. Gould
Principal Engineer
Verisign

James,

Alex

Thanks,

--

JG

James Gould

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2013 14:28:49 +0000

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

James Gould

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

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

Jim

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.

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.

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?

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

Alexander,

JG

James F. Gould
Principal Engineer
Verisign

James,

Alex

Thanks,

--

JG

James Gould

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

---

From: Seth Goldman <[email-masked]>
Date: Tue, 9 Apr 2013 10:31:11 -0400

All of these options work, in that a registry would be able to express
their current active phase(s). #1 is ambiguous, though, because there are
multiple ways to express the same state. That is, there doesn't seem to be
> <launch:phase name="landrush">claims</launch:phase>

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

As a result, I think it's likely that registry operators will end up
choosing different representations for the same server policy. Or that two
registry operator may use the same representation with different meanings -
one may decide the both phases equal to each other, while the other assigns
some meaning to the "primary" phase over the "subphase".

#2 has the same problem. What's the difference between these two?

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

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

#3 is the clearest, because there's a single, canonical representation for
each state of the server with respect to its currently active phases. I
agree that might cause confusion as to what phase(s) should be sent back to
the server, but #1 and #2 have the same problem - are clients required to
send back the subphase? Or the "overlaps" attribute? Is it acceptable for a
server to be more permissive and accept a subset of that information? The
point of having the client specify the phase(s) is so that the server will
error if the phase changes out from under them (as opposed instead of doing
something unexpected). As such, it makes sense to me that if the client is
going to pass *any* phase information (and take advantage of this feature),
then they should be required to pass *all* phase information.

On Tue, Apr 9, 2013 at 9:47 AM, Gould, James <[email-masked]> wrote:

>    1. Utilize the sub-phase feature using the "name" attribute that is
>    already in the draft.  Choose a primary phase and a sub-phase, where I
>    believe claims should be the primary and landrush or any other selective or
>    asynchronous phase should be the sub-phase value.  The "name" attribute is
>    freeform, so the use of the sub-phase "landrush" could only be included in
>    the text of the draft and not in the XML schema.
>    2. Add a new "overlap" attribute to the <launch:phase> element that
>    utilizes the same enumerated set of phase values (sunrise, landrush,
>    claims, open, custom) for the <launch:phase> element.  I believe in this
>    case the "overlap" would not be classified as a sub-phase but would be
>    elevated to the same level as the <launch:phase> value.  The concept of the
>    sub-phase using the "name" attribute could still be used to further refine
>    the phase with a freeform value.
>    3. Support more then one <launch:phase> element.  This might cause
>    more confusion over the set of <launch:phase> elements that should be
>    passed and have a greater impact on the interface since it goes from one to
>    a list of phases.
>
>
>  Option #2 and #3 could utilize the optional <launch:phase> "name"
> attribute as well that I don't show above.
>
>   From: Seth Goldman <[email-masked]>
> To: James Gould <[email-masked]>
> Cc: Alexander Mayrhofer <[email-masked]>, EPP Provreg <
> [email-masked]>
> Subject: Re: [provreg] Recombining the claims1 and claims2 phases to the
> claims phase in draft-tan-epp-launchphase?
>
>   The word "subphase" bothers me a bit, since it carries with it the
> notion that it's subordinate to the main phase. But that may not be the
> case; it could just be that the phases have some partial overlap with no
> fixed relationship between them.
>
>> 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.
>> ****
>>
>> ** **
>>
>> *Von:[email-masked] [mailto:[email-masked]<[email-masked]>]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2013 14:52:47 +0000

Seth,

My feedback is below.

--

JG

James Gould

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

Date: Tuesday, April 9, 2013 10:31 AM

All of these options work, in that a registry would be able to express their current active phase(s). #1 is ambiguous, though, because there are multiple ways to express the same state. That is, there doesn't seem to be any semantic difference between these two expressions:
<launch:phase name="landrush">claims</launch:phase>
<launch:phase name="claims">landrush</launch:phase>
As a result, I think it's likely that registry operators will end up choosing different representations for the same server policy. Or that two registry operator may use the same representation with different meanings - one may decide the both phases equal to each other, while the other assigns some meaning to the "primary" phase over the "subphase".

The plan would to clarify the expected combination in the text of the draft, but not via the XML schema for option #1.  This hits the 90% case of the landrush happening at the start of the claims phase.

Really the only different between #1 and #2 is locking down the possible values of the overlap attribute and leaving the name attribute open for use in defining a true sub-phase.  The text can define the expected combination of phase and overlap value to cover the launch at the start of the claims period.  My recommendation would be <launch:phase overlap="landrush">claims</launch:phase>.

#3 is the clearest, because there's a single, canonical representation for each state of the server with respect to its currently active phases. I agree that might cause confusion as to what phase(s) should be sent back to the server, but #1 and #2 have the same problem - are clients required to send back the subphase? Or the "overlaps" attribute? Is it acceptable for a server to be more permissive and accept a subset of that information? The point of having the client specify the phase(s) is so that the server will error if the phase changes out from under them (as opposed instead of doing something unexpected). As such, it makes sense to me that if the client is going to pass any phase information (and take advantage of this feature), then they should be required to pass all phase information.

I have a different thought on the validation of the phase information.  I believe that the <launch:phase> value, which is required, should be validated against the active phase.  The sub-phase "name" value or the "overlap" value should be validated when passed.  The key here is to allow and not require the client to be explicit.  We are adding the "type" attribute to the <launch:create> element to enable the client to explicitly specify the desired type of object to create (application or registration).  I don't see any difference in the interface for a "landrush" or a standard "claims" phase create except it may result in the creation of an application.  The desired object type can be specified using the optional "type" attribute instead of overloading the <launch:phase> element.  If there is some inherent difference in the server logic during the "landrush" that must be reflected outside of the type of object to create, it can be passed by the client and validated by the server.

Another question with option #3 would be whether a matching list of <launch:phase> elements would be required for the other commands (info, update, delete) and if not which one of the set would be required.

Which option do you believe is best?  Do you believe we should tackle this at all in the EPP extension draft?  Overlapping phases is new with the TMCH model, so I feel that we should add something to at least define a consistent way of representing the possible overlapping of the claims and the landrush periods.

On Tue, Apr 9, 2013 at 9:47 AM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Seth,

         <launch:create

           …

         </launch:create>

         <launch:create

           …

         </launch:create>

         <launch:create

           …

         </launch:create>

--

JG

James Gould

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

JG

James F. Gould
Principal Engineer
Verisign

James,

Alex

Thanks,

--

JG

James Gould

12061 Bluemont Way

Reston, VA 20190

---

From: Seth Goldman <[email-masked]>
Date: Tue, 9 Apr 2013 11:34:15 -0400

I appreciate that you are working on defining the expected combinations of
phases/subphases, but it still doesn't feel right to me; the concepts just
don't map cleanly on to the actual launch phases. It also seems like you
are going down the path of embedding business logic into the technical
specification (which, admittedly, is not a new problem in EPP), instead of
leaving it open and flexible for future modification. I think having
multiple phase elements models the actual state without embedding any
business logic about the relationship between those phases, plus it leaves
the specification far more open for future (as yet unknown) modifications.
Who knows what phases we may come up with in the (far) future?

On Tue, Apr 9, 2013 at 10:52 AM, Gould, James <[email-masked]> wrote:

>  The plan would to clarify the expected combination in the text of the
> draft, but not via the XML schema for option #1.  This hits the 90% case of
> the landrush happening at the start of the claims phase.
>
>
>  Really the only different between #1 and #2 is locking down the possible
> values of the overlap attribute and leaving the name attribute open for use
> in defining a true sub-phase.  The text can define the expected combination
> of phase and overlap value to cover the launch at the start of the claims
> period.  My recommendation would be <launch:phase
> overlap="landrush">claims</launch:phase>.
>
>
>  #3 is the clearest, because there's a single, canonical representation
> for each state of the server with respect to its currently active phases. I
> going to pass *any* phase information (and take advantage of this
> feature), then they should be required to pass *all* phase information.
>
>
>  I have a different thought on the validation of the phase information.
>  I believe that the <launch:phase> value, which is required, should be
> validated against the active phase.  The sub-phase "name" value or the
> "overlap" value should be validated when passed.  The key here is to allow
> and not require the client to be explicit.  We are adding the "type"
> attribute to the <launch:create> element to enable the client to explicitly
> specify the desired type of object to create (application or registration).
>  I don't see any difference in the interface for a "landrush" or a standard
> "claims" phase create except it may result in the creation of an
> application.  The desired object type can be specified using the optional
> "type" attribute instead of overloading the <launch:phase> element.  If
> there is some inherent difference in the server logic during the "landrush"
> that must be reflected outside of the type of object to create, it can be
> passed by the client and validated by the server.
>
>  Another question with option #3 would be whether a matching list of
> <launch:phase> elements would be required for the other commands (info,
> update, delete) and if not which one of the set would be required.
>
>  Which option do you believe is best?  Do you believe we should tackle
> this at all in the EPP extension draft?  Overlapping phases is new with the
> TMCH model, so I feel that we should add something to at least define a
> consistent way of representing the possible overlapping of the claims and
> the landrush periods.
>
>
>>> 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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2013 15:51:32 +0000

So you are in support of option 3.  Do you feel that support for multiple phases should be added for all of the extended commands (check, info, create, update, and delete) to be consistent?

What do others think?

JG

James F. Gould
Principal Engineer
Verisign

On Apr 9, 2013, at 11:34 AM, "Seth Goldman" <[email-masked]<mailto:[email-masked]>> wrote:

I appreciate that you are working on defining the expected combinations of phases/subphases, but it still doesn't feel right to me; the concepts just don't map cleanly on to the actual launch phases. It also seems like you are going down the path of embedding business logic into the technical specification (which, admittedly, is not a new problem in EPP), instead of leaving it open and flexible for future modification. I think having multiple phase elements models the actual state without embedding any business logic about the relationship between those phases, plus it leaves the specification far more open for future (as yet unknown) modifications. Who knows what phases we may come up with in the (far) future?

On Tue, Apr 9, 2013 at 10:52 AM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Seth,

My feedback is below.

--

JG

<8A7A655D-9ED0-4D38-898D-E9E8B754666E[151].png>

James Gould

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

         <launch:create

           …

         </launch:create>

         <launch:create

           …

         </launch:create>

         <launch:create

           …

         </launch:create>

--

JG

<8A7A655D-9ED0-4D38-898D-E9E8B754666E[149].png>

James Gould

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

JG

James F. Gould
Principal Engineer
Verisign

James,

Alex

Thanks,

--

JG

James Gould

12061 Bluemont Way

Reston, VA 20190

---

From: James Mitchell <[email-masked]>
Date: Wed, 10 Apr 2013 02:27:18 +1000

Jim,

Comments prefixed with JM:

Regards,
James

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

James,

--

JG

James Gould

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

Jim

JM: We also will validate the phase value, e.g. reject a command with phase "landrush" during the active Sunrise phase. I am confused regarding your second sentence, isn't the notice always required for "claims"? Do you mean you will not require the extension when neither mark nor notice is required, even for commands that result in applications (e.g. old-school landrush without claims)?

         <launch:create

         <launch:create

JM: I support this change as it clarifies registrar intent/expectations.

However we seem to be on different pages. I only have one "phase" value in my system, be it "sunrise", "landrush", "non-tmch-sunrise". The launch extension however allows this information in two places, the phase element value, or the name attribute value. I would prefer if the launch extension provided only one place for the "phase" – noting that I believe the "claims" and "landrush" phase/sub-phase debate is off-track.

Since I have to use the name attribute value for "custom" phases, e.g. my "non-tmch-sunrise" phase, I will prefer that value over the phase element value. In pseudocode this will be { phase = phase.name present ? phase.name.value : phase.value }. I have no interest in writing code to check for valid combinations of phase and phase-name/sub-phase.

JM: Providing the extension twice, once with "claims" and another with "non-tmch-sunrise"? I have given this only a few seconds worth of thought..

Regards,
James

Alexander,

JG

James F. Gould
Principal Engineer
Verisign

James,

Alex

Thanks,

--

JG

James Gould

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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 11 Apr 2013 13:17:48 +0000

James my feedback is below.

--

JG

James Gould

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

Date: Tuesday, April 9, 2013 12:27 PM

Jim,

Regards,
James

James,

--

JG

James Gould

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

Jim

The notice is only required during claims if there is a matching mark for the domain name.  If the claims check response returns "0" or "false" for the "exists" attribute, then the launch extension is not required on create for that domain name.  We do not have a need for an explicit landrush phase at this point, but if we needed one the passing of the launch extension would be recommended but not required since there is no additional information required by the server from the client to satisfy the landrush create (assuming that a notice is not needed).  If the landrush is asynchronous then the launch extension would be included in the create response and the 1001 (pendingCreate) result code would be returned.

         <launch:create

         <launch:create

The intent of the "name" attribute was strictly to support some form of phase extensibility (sub-phase or new phase).  You are missing the "claims" phase since the "claims" phase represents a state of the TLD that has a different set of interface requirements for the client and the server.  It is up to you to implement the phase validation logic, but I recommend that you do to ensure that you're satisfying the intent of the client.

No, we can update the draft to remove the notice from the choice and make it optional, so there is no need in providing the extension twice.

Regards,
James

Alexander,

JG

James F. Gould
Principal Engineer
Verisign

James,

Alex

Thanks,

--

JG

James Gould

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