Subject: Re: [provreg] [tmch-tech] Extensibility of status values et al., was: Launch Phase EPP Extension Version 04 Posted

From: "Gould, James" <[email-masked]>
Date: Tue, 11 Dec 2012 20:59:09 +0000

Klaus,

Thanks for your initial preliminary review.  My feedback is below.  I
highly recommend that you review the draft in full, since some of the
questions like the use of phases is addressed throughout the draft.  I've
copied the provreg list on this reply to get additional feedback from
those participants.

-- 

JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/11/12 6:37 AM, "Klaus Malorny" <[email-masked]> wrote:

>On 04/12/12 14:56, Gould, James wrote:
>> Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension
>> Mapping to support the current state of the ICANN TMCH Sunrise and
>>Claims
>> implementation model.  You can find the draft at the URL
>> http://tools.ietf.org/html/draft-tan-epp-launchphase-04.
> > [...]
>
>Hi,
>
>while I do not plan to review the draft in-depth before ICANN publishes
>its 
>updated functional specification, I had a look on it today regarding the
>status 
>values and discovered the custom/@name extensibility. While it was
>already added 
>to the -03 version, I wonder whether this is really the best approach to
>add 
>extensible status values, esp. as this could be seen as a blue print for
>other 
>future extensions and EPP itself, as standard EPP misses this desirable
>feature 
>at all. First, allowing the addition of a "name" to standard status
>values 
>(pending, validated, ...) breaks the previous characteristic of status
>values 
>that they are only binary (i.e. set or not). Second, the "custom" value
>creates 
>an asymmetry between standard and non-standard status values, as the
>"name" 
>attribute is suddenly the primary discriminator in the "custom" case and
>not a 
>subdiscriminator as in the other cases.

JG - Addition of the "name" attribute does not break the concept of the
binary characteristic of a status.  The "name" attribute represents a
sub-status when using a non-"custom" enumerated status value, which still
maintains the binary characteristic (i.e. set or not).  In the case of the
sub-status, the client is not required to key off of the sub-status "name"
value if they choose to, but can strictly key off of the parent enumerated
status.  The sub-status could provide more clarity to the client if a
higher level status does have more fine grained states.  You are correct
when using the "custom" enumerated status value, the "name" attribute
becomes the true custom name of the status.

>
>IMHO, it would be better to
>   - get rid of the @name attribute

This would be mean that the enumerated list in the draft is final, with no
built in form of extensibility.

>   - allow other status value names as well, either allowing any token,
>     a token with a prefix ("x-") or even Qnames

JG - The use of "any" might be too heavyweight for what we need here.  I'm
not sure if there is the need to define additional XSD's for the handling
of custom server statuses.  I don't know of the case where a server will
want to create their own custom status, but defining a new XSD that the
client has to deal with can quickly get out of hand.  Do you have an
example of what you mean by using the prefix or Qnames to handle say two
custom statuses like "foo" and "bar".  The current draft would represent
the "foo" and "bar" statuses as <launch:status s="custom" name="foo"/> and
<launch:status s="custom" name="bar"/>, respectively.  In this case there
is no added complexity for the server or the client, and the client can
decide what to display for the status.  I would most likely display the
name attribute ("foo" or "bar") as the status and not drive any
client-side logic based on the use of the custom status unless I choose
to.  

>   - allow more than one status value in the info response

JG - The statuses are discrete steps in the state machine of an
application, meaning that there is only one state per application at a
time.  Maybe it would be better to call them states instead of statuses?

>
>If the current way of implementing states is retained, it is questionable
>whether a "pendingAuction" state is really required. Wouldn't it be a
>special 
>case of the "validated" status and thus should be identified via the
>"name" 
>attribute? Does ICANN require an auction in case of application
>conflicts, so 
>that it is necessary to include this state? This does not mean that I
>mind the 
>information that an application is part of an auction, but is it the
>right way 
>to express this?

JG - Yes, the "pendingAuction" status could be reflected as a "validated"
sub-status, but there is nothing wrong with including a possible known
status that an application may have.  This does not mean that it is a
required status, but that it is a possible status.  The "pendingAuction"
status was added based on feedback from Trung Tran on the provreg list.

>
>My criticism of the status values applies similarly to the phase names.
>Why 
>isn't it simply a token? I can't see that any semantics is enforced by
>the EPP 
>extension (although the registry may do so) on the use of the predefined
>phases, 
>e.g. if the phase is "sunrise", then this or that data has to be supplied.

JG - The phases in the draft define interface dependencies, where for
"sunrise" phase there is the use of the Sunrise Create Form by the passing
of the trademark information and for the "claims1" and "claims2" phases,
there is the use of the Claims Create Form that passes the required claims
notice information on create.  There is an additional dependency on the
phase value for the use of the Claims Check Command, since the Claims
Check Command is only applicable during the "claims1" and "claims2"
phases.  Having the phase name be freeform will not provide any form of a
interface contract between the client and the server.  How would the
client know what phase to pass and what should be passed along with it?
How would the server know what the intention of the client is?  For
example, the set of domain names used for a Claims Check Command is
different for the "claims1" and "claims2" phases.  The claims notice
claims notice presented to the Registrant is also different between the
"claims1" and "claims2" phases, so the server would want to ensure that it
is responding correctly based on what is explicitly being requested by the
client.  Having a predefined set of phases with expected extension
requirements (protocol interface) I believe will make the contract
stronger and cleaner between the client and the server.  Some servers
might decide to create custom phases, and in doing so will need to
communicate their interface requirements out-of-band to the clients.
Sub-phases could meet the same basic interface requirements of the parent
phase similar to the discussion above on the use of sub-statuses.

>Just my two cents,
>Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 12 Dec 2012 11:05:54 +0100

> Klaus,

Hi James,

> questions like the use of phases is addressed throughout the draft.

Yes, after Dec. 20th

> I've

Yes, probably the better place. I removed TMCH from the recpient list.

> becomes the true custom name of the status.

I see this differently. We consider, for example, to have a special state "in 
review" for registries that require additional manual review for some special 
domain names. In this state, certain changes to the application (e.g. 
registrant/admin contact changes) shall not be possible, while others shall 
still be (e.g. name server changes). One could consider this as a sub-status of 
the "pending" status, but with your definition of the non-relevance of the 
"name" value for the standard status values, this is not possible -- the 
registrar cannot predict the behaviour of the registry solely from the (primary) 
status. The only choice with the current draft would then be to use a "custom" 
state.

The suggestion to have multiple states (see below) would give us the choice to 
set the "pending" status, augmented by a second status telling the registrar, 
"in review, locked".

> built in form of extensibility.

This was meant in the combination with next item. Otherwise, you would be right.

>> >   - allow more than one status value in the info response

One can argue that for the deployment scope of the extension, the chosen 
solution is acceptable. But I don't see this solution as a general mechanism 
that should be adopted by other EPP extensions. This was my primary concern. I 
just tried to make a proposal for the latter one.

> time.  Maybe it would be better to call them states instead of statuses?

If someone could explain to me as a non-native English speaker the difference 
between state and status ;-)

> status was added based on feedback from Trung Tran on the provreg list.

Sure, I know that this is optional (by the way, why are there two transitions 
from "invalid" to "rejected" in Figure 1?). The question is simply whether this 
has any relevance to the EPP interaction between the registrar and registry. If 
not, it would have to be considered as a sub-status as you described above.

> phase similar to the discussion above on the use of sub-statuses.

I am always reluctant to cast registry policies into a protocol. Is it the duty 
of the protocol? In the case of this extension: Is it the duty of the extension 
to define the semantics of a "sunrise", "landrush" etc. phases? And if so, why 
is the relation of the phases to the use of <codeMark>, <signedMark>, 
<encodedSignedMark> and <notice> rather vague? Doesn't need a registrar 
out-of-band information about the (standard) phases anyway to access the 
registry correctly?

But we can postpone the discussion until I can read the draft in the context of 
ICANN's announced functional specification.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Wed, 12 Dec 2012 14:22:14 +0000

Klaus,

I again put my feedback below.

-- 

JG

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

>set the "pending" status, augmented by a second status telling the

Yes, as currently defined the status really reflect states that are
primarily information to the client and that don't define any additional
interface information like in the case of your "in review, locked" status.
 It might make sense to split them into state and status.  The rfc 5731
statuses could be applied to the domain application to define the
restrictions at the command level (i.e. serverUpdateProhibited,
serverDeleteProhibited).  I'm trying to think of how you would reflect
more fined grained statuses for domain applications
(serverUpdateContactProhibited, serverUpdateNsProhibited,
serverUpdateDnssecProhibited) to provide this detail to the client.  Do
you believe splitting them makes sense?  What would be useful to the
client to cover this use case as well as additional use cases?

>just tried to make a proposal for the latter one.

Got it.  I agree that this should not become a standard mechanism for
extension.  

>between state and status ;-)

This might be my warped definition of a state and status, but I'll give it
a shot.  An object can follow states of a state machine similar to the
diagram in the draft.  States could have some defined behavior
differences, like updates are allowed during the pending state but not in
the other states.  The states in the draft are primarily informational as
I describe above.  Statuses can be applied to an object that does not
truly define it's state in the state machine; although there has been a
mix of usage of statuses and states in the RFC's.  Multiple statuses can
be set on the object to explicitly define restrictions or enhancements
like the use of the prohibited statuses in the RFC's.  Maybe the term
status is too generic.

>not, it would have to be considered as a sub-status as you described

It is not relevant to the interface but for providing additional
information to the client.  It could have been handled by a sub-status,
but the thought was to capture the discrete states that we're aware of.

>out-of-band information about the (standard) phases anyway to access the

I don't believe this the draft is casting registry policy into a protocol
in any way, since we have a known set of launch phases that needs to pass
specific data between the clients and the servers.  There are registry
policy decisions that can be made, but the protocol interface should be
known for each of the phases by the client and the server. There are known
protocol interface elements like the passing of the <notice> on create
during the "claims1" and "claims2" launch phases or the passing of the
<codeMark>, <signedMark>, or <encodedSignedMark> during the sunrise launch
phase.  Servers can decide to support going beyond these by say allowing
the passing of the <codeMark>, <signedMark>, or <encodedSignedMark> in
other phases, but the extension meets the  known model requirements and is
flexible enough to support additional models.  If the extension does not
cover some of the semantics of the known launch phases, it will result in
a custom interface and integration on a per TLD basis, which is not good
for any of us.  

>ICANN's announced functional specification.

I encourage you and others to fully review and post comment on the draft
ahead of ICANN's announced functional specification.  I'm hoping that
ICANN is going to review the draft as well in creating their functional
specification to ensure that the draft meets it and if not post what
changes need to be made.  It will take time to incorporate feedback from
the community in this draft to have something useful for implementers to
implement to, so the earlier the comments the better.