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

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

#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 protected]> wrote:

>  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****
>
> Principal Software Engineer****
>
> [email protected]****
>
>  ****
>
> 703-948-3271 (Office)****
>
> 12061 Bluemont Way****
>
> Reston, VA 20190****
>
> VerisignInc.com
>
>   From: Seth Goldman <[email protected]>
> Date: Tuesday, April 9, 2013 8:48 AM
> To: James Gould <[email protected]>
> Cc: Alexander Mayrhofer <[email protected]>, EPP Provreg <
> [email protected]>
> 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 protected]> 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 protected]
>>
>> On Apr 9, 2013, at 3:39 AM, "Alexander Mayrhofer" <
>> [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]<[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]****
>>
>>  ****
>>
>> 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 protected]
>> https://www.ietf.org/mailman/listinfo/provreg
>>
>>

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