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

Klaus,

I again put my feedback below.

-- 

JG
 

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







On 12/12/12 5:05 AM, "Klaus Malorny" <[email protected]> wrote:

>On 11/12/12 21:59, Gould, James wrote:
>> Klaus,
>>
>
>Hi James,
>
>> 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.
>
>Yes, after Dec. 20th
>
>> I've
>> copied the provreg list on this reply to get additional feedback from
>> those participants.
>
>Yes, probably the better place. I removed TMCH from the recpient list.
>
>
>> 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.
>>
>
>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".

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?


>
>>
>>> >
>>> >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.
>
>This was meant in the combination with next item. Otherwise, you would be
>right.
>
>>
>>> >   - 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
>>
>
>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.

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

>
>> 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 someone could explain to me as a non-native English speaker the
>difference 
>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.


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

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.


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

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.  

>
>But we can postpone the discussion until I can read the draft in the
>context of 
>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.

>
>Regards,
>
>Klaus

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