Re: Custom phases with claims

James,

My feedback is below.

--

JG

[cid:A9AFE7A3-373A-4E10-A8E0-34ACE123DC68]

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

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

From: James Mitchell <[email protected]<mailto:[email protected]>>
Date: Thursday, May 16, 2013 1:23 AM
To: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: [provreg] Custom phases with claims

Jim,

You have long been a proponent for having clients provide "claims" and "landrush" in the phase element (to my disagreement). Since you require clients specify both, how would you represent a "custom" phase that requires claims processing given the "name" attribute cannot be used to specify the sub-phase?

The passing of the "claims" and the "landrush" in the phase element together in the draft is to cover a common use case of the overlapping "claims" phase with a "landrush".  Since SHOULD is used, this is recommended and is not a requirement.  I'm assuming that a custom phase during the "claims" phase does not overlap with "landrush", so therefore since "name" is freeform you can define your custom phase during claims to be a sub-phase of "claims".  Based on the TMCH model the required phases include "sunrise" followed by "claims", so if you have additional granularity of phases, then you can utilize the sub-phase feature of the draft to reflect it.  It might help if you can provide a specific example of what you're attempting to accomplish.


My preference is to remove "claims" as a phase as it provides _zero_ value to the protocol, and retire the need to provide sub-phase information during claims. Claims information may be provided with other phases (landrush, open) without explicitly providing a "claims" phase value, and servers have to code for missing claims information regardless (e.g. It is possible to provide "sunrise" with claims information, and "claims"  with mark information).

Your belief if that the "claims" phase provides no value from a protocol perspective, but I disagree since I view a TLD as running through a state machine of phases, where "claims" is one of those states or phases.  The "claims" phase defines specific  server behavior and interface requirements that is reflected with the use of the "claims" phase.  This includes support for the claims check and the requirement to pass the claims notice on the create.  The draft fully supports passing claims information and mark information using the Mixed Create Form based on your prior feedback.  Removing of the "claims" phase value as well as the enumerated list of phases will make it difficult for the clients considering the variety of definitions of phases and the variety of server behavior based on a set of freeform phase names.  Having a standard set of phase names, with predefined meanings, with expected server behavior, and with extensibility by the ability to define custom phases and sub-phases provides for a good mix of consistency and flexibility.


I also dislike the use of the term "custom" - registries will operate sunrises differently; those different sunrises are by definition custom. IMO the schema-level restriction on phase values provides no value to the protocol itself. I would like to see the phase enumeration removed, replaced instead with unrestricted "token" strings. The mapping document can reserve the existing values (sunrise, landrush, open) as having special meaning if you feel it is necessary.

Can you describe the interface / protocol differences that would be needed to cover these different "custom" sunrises?  If you're referring to different eligibility requirements, that is policy and not protocol that is best left out of the protocol.



Regards,
James

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