Subject: [provreg] Launch Phase EPP Extension Version 02 Posted

From: "Gould, James" <[email-masked]>
Date: Fri, 10 Aug 2012 14:23:17 +0000

I've been working with Wil Tan and Gavin Brown on updating the Launch Phase EPP Extension Mapping to support the two models (ICANN and ARI/Neustar) along with the models that were previously defined in the Launch Phase EPP Extension Version 01.  You can find the draft at the URL http://www.ietf.org/id/draft-tan-epp-launchphase-02.txt.  This is a straw man draft to kick off the discussions as the tmch-tech list works out the model.  I've already posted a message on the tmch-tech list to start the discussions there.

--

JG

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

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

---

From: "Tran, Trung" <[email-masked]>
Date: Wed, 15 Aug 2012 16:10:25 -0400

Thanks James, Wil, and Gavin for putting the draft together.  I'm still reviewing the document, however I have a concern with the list of statuses (Section 2.3).  While having a defined list makes it easier for different parties to understand what each status means, it could be too restrictive.  It's conceivable to have statuses around the auction process for validated applications.  So should extension to status be allowed?

current list of statuses:
       <restriction base="token">
           <enumeration value="pending"/>
           <enumeration value="validated"/>
           <enumeration value="invalid"/>
           <enumeration value="allocated"/>
           <enumeration value="rejected"/>
         </restriction>

Trung

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Friday, August 10, 2012 10:23 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [provreg] Launch Phase EPP Extension Version 02 Posted

--

JG

James Gould

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

---

From: Gavin Brown <[email-masked]>
Date: Thu, 16 Aug 2012 10:38:43 +0100

Hi Trung,

On 15/08/2012 21:10, Tran, Trung wrote:
> Thanks James, Wil, and Gavin for putting the draft together.  I’m still
> reviewing the document, however I have a concern with the list of
> statuses (Section 2.3).  While having a defined list makes it easier for
> different parties to understand what each status means, it could be too
> restrictive.  It’s conceivable to have statuses around the auction
> process for validated applications.  So should extension to status be
> allowed?

If we make the status element arbitrary, then each server will have its
own set of codes that each client will have to learn via some out of
band channel such as documentation or a support ticket, and will have to
develop business logic for handling them. By keeping this element an
enumeration we're making it much easier for clients to support this
extension.

If there are other status codes that would be useful, let's try to
generate an exhaustive list before we throw the baby out with the bath
water and make the status code an arbitrary text element.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 16 Aug 2012 11:25:01 +0100

>From my perspective as a registrar, I'm in complete agreement with Gavin:
arbitrary registry-specific extensions and behaviour variations are hell for us,
and the less of that there is, the better for us.

It would be better, from a registrar's perspective, if we attempted to nail down
this kind of thing as well as possible now, and later, if it turns out that
further statuses are required, the list is revised (and possibly the version
number is bumped up). That allows registrar clients to key their behaviour to
things announced at connection time rather than being riddled with
registry-specific behaviour.

Extensibility is all well and good, but a well-defined set of states and state
transitions that *everybody* agrees upon is vastly more valuable.

K.

-- 
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: "Gould, James" <[email-masked]>
Date: Thu, 16 Aug 2012 12:03:08 +0000

I agree that we should predefine as many known statuses as possible in the draft as an enumerated list.  How about if we take the approach of the launch phases with the inclusion of a "custom" status and an optional name attribute that can be used for define a sub-status of one of the enumerated statuses or used to define a completely custom status?  We can expand the enumerated list now for auction statuses if those statuses are known.  Trung, do you have any specific statuses that should be added now?  Would this meet the needs of a predefined list of statuses with some form of extensibility?  

Jim

________________________________________
From: [email-masked] [[email-masked]] on behalf of Keith Gaughan [[email-masked]]
Sent: Thursday, August 16, 2012 6:25 AM
To: [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

K.

--
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/provreg

---

From: Wil Tan <[email-masked]>
Date: Fri, 17 Aug 2012 01:09:57 +1000

On Thu, Aug 16, 2012 at 10:03 PM, Gould, James <[email-masked]> wrote:

> I agree that we should predefine as many known statuses as possible in the
> draft as an enumerated list.  How about if we take the approach of the
> launch phases with the inclusion of a "custom" status and an optional name
> attribute that can be used for define a sub-status of one of the enumerated
> statuses or used to define a completely custom status?  We can expand the
> enumerated list now for auction statuses if those statuses are known.
>  Trung, do you have any specific statuses that should be added now?  Would
> this meet the needs of a predefined list of statuses with some form of
> extensibility?
>
>
Just as a data point, these were the statuses that Cloud Registry used when
we last did our sunrise and land rush auctions. They were certainly
adequate for us. Also, while not technically elegant, I suspect we can
satisfy the majority of use cases by conveying fine-grained statuses with
<launch:status> textual content:

  <launch:status s="validated">auction in-progress</launch:status>

Trung, what are your thoughts?

.wil

---

From: Gavin Brown <[email-masked]>
Date: Thu, 16 Aug 2012 16:18:45 +0100

On 16/08/2012 16:09, Wil Tan wrote:
> On Thu, Aug 16, 2012 at 10:03 PM, Gould, James <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I agree that we should predefine as many known statuses as possible
>     in the draft as an enumerated list.  How about if we take the
>     approach of the launch phases with the inclusion of a "custom"
>     status and an optional name attribute that can be used for define a
>     sub-status of one of the enumerated statuses or used to define a
>     completely custom status?  We can expand the enumerated list now for
>     auction statuses if those statuses are known.  Trung, do you have
>     any specific statuses that should be added now?  Would this meet the
>     needs of a predefined list of statuses with some form of extensibility?
> 
> 
> Just as a data point, these were the statuses that Cloud Registry used
> when we last did our sunrise and land rush auctions. They were certainly
> satisfy the majority of use cases by conveying fine-grained statuses
> with <launch:status> textual content:
> 

Wouldn't this effectively be another free text element that servers will
overload with their own special meanings? If anything that appears
inside that element requires client processing, registrars will be in
the same situation as I previously described.

G.

---

From: Wil Tan <[email-masked]>
Date: Fri, 17 Aug 2012 01:35:26 +1000

> the same situation as I previously described.
Yes, that's why I said it's not elegant, but my (possibly wrong) assumption
was that the textual description won't be used by registrars for
automation. It would primarily be used for answering customer queries about
"I applied for this domain, do I have it yet and if not, why not?" The
enumerated "s" attribute values are what matters to the state machine, and
it's important to keep it simple.

I agree that we should try to capture statuses that registries might need,
rather than providing yet another extensibility point.

.wil

---

From: Gavin Brown <[email-masked]>
Date: Thu, 16 Aug 2012 16:40:44 +0100

On 16/08/2012 16:35, Wil Tan wrote:
> Yes, that's why I said it's not elegant, but my (possibly wrong)
> assumption was that the textual description won't be used by registrars
> for automation.

It seems more likely to me that registries would decide to overload this
field and then compel registrars to create business logic to handle it.

However, I don't think that his has happened with the <status> element
for domains, contacts, and hosts (unless someone wants to correct me),
so perhaps I am overstating the risks.

G.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 16 Aug 2012 16:57:39 +0100

On Thu, Aug 16, 2012 at 12:03:08PM +0000, Gould, James wrote:

> draft as an enumerated list.  How about if we take the approach of the launch
> phases with the inclusion of a "custom" status and an optional name attribute
> that can be used for define a sub-status of one of the enumerated statuses or
> used to define a completely custom status?  We can expand the enumerated list
> now for auction statuses if those statuses are known.  Trung, do you have any
> specific statuses that should be added now?  Would this meet the needs of a
> predefined list of statuses with some form of extensibility?  

The problem there is that it essentially makes the statuses freeform again, just
in a more awkward fashion. This kind of thing is harmful to interop. It's better
to have a well-defined set of statuses and a well-defined set of state
transitions that nobody is absolutely happy with but everyone at least agrees is
good enough than a mess of mutually slightly-incompatible riffs off of the same
theme.

I'd prefer to say YAGNI to this unless a strong case can be made to the
contrary.

K.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 16 Aug 2012 17:14:01 +0100

> so perhaps I am overstating the risks.

What's happened in those cases is that the registry operators create their own
extensions to fit the extra semantics they--being the beautiful and unique
snowflakes that they are--feel they absolutely can't possibly live without.

You're not at all overstating the risks. The thing that gets missed in this kind
of discussion is that when a registry has discretion over the implementation of
some element of EPP or a non-optional extension or object mapping, they
effectively multiply the amount of work that needs to be done to implement that
by the number of registrars integrated with them. The more that can be done so
that registrars don't have to implement dozens of subtly-incompatible variations
on the same spec.

K.

---

From: "Tran, Trung" <[email-masked]>
Date: Thu, 16 Aug 2012 18:12:35 -0400

I agree with the advantages of having enumerated list of statuses.  However I can’t believe that we know enough about each registry policy that would take into account all of the different status variations.  So someone will end up using custom EPP extension to capture these other statuses that were not defined in this draft.

Concerning auction related statuses, we have used auction pending, auction awarded, and auction rejected.  If there are other ways to capture this info besides status, please let me know.

Trung

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wil Tan
Sent: Thursday, August 16, 2012 11:35 AM
To: Gavin Brown
Cc: [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

On Fri, Aug 17, 2012 at 1:18 AM, Gavin Brown <[email-masked]<mailto:[email-masked]>> wrote:

On 16/08/2012 16:09, Wil Tan wrote:
> On Thu, Aug 16, 2012 at 10:03 PM, Gould, James <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

Yes, that's why I said it's not elegant, but my (possibly wrong) assumption was that the textual description won't be used by registrars for automation. It would primarily be used for answering customer queries about "I applied for this domain, do I have it yet and if not, why not?" The enumerated "s" attribute values are what matters to the state machine, and it's important to keep it simple.

I agree that we should try to capture statuses that registries might need, rather than providing yet another extensibility point.

.wil

---

From: "Gould, James" <[email-masked]>
Date: Thu, 16 Aug 2012 22:18:11 +0000

In reviewing the thread on the status element of the draft, these are the following options:

1. Keep the status element as a non-extensible enumerated list.  
2. Change the status element to use a enumerated list of status values as an attribute and allow for the element text to be free-form.  The free-form text could be returned to the registrant.  
3. Add an optional name attribute to the status element along with a "custom" status enumerated value to support sub-statuses or custom statuses similar to the approach taken in the draft with the phase element.  
4. Make the status element a token instead of a enumerated list.  I don't believe anyone really proposed this, but I left it in for completeness.  

I would like to have all of the possible known statuses defined in the draft, where if we did a good job in gathering them all, option #1 is the best.  If we don't do a good job of gathering them all then some form of extensibility like option #3 would be needed to enable adding the missing statuses without requiring the creation of a registry specific custom extension.  I believe option #2 is close to using the optional name attribute of option #3 as a sub-status with a slightly different intent of not using the value to drive client-side logic.  

Does anyone know of any concrete statuses that need to be added to help with options #1, #2, and #3?  I don't want the draft to make it too difficult for the clients to handle and I don't want it to be too restrictive to meet specific registry policies that would result in the creation of additional custom extensions.  I believe option #3 is a good compromise, but that's probably obvious since I was the one that originally proposed it.  

I would like to hear from the list if there are any additional options to consider and which option is preferred.  

Jim 

________________________________________
From: [email-masked] [[email-masked]] on behalf of Keith Gaughan [[email-masked]]
Sent: Thursday, August 16, 2012 12:14 PM
To: [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

K.

---

From: "Tran, Trung" <[email-masked]>
Date: Fri, 17 Aug 2012 14:21:02 -0400

Jim,
I agree with you and prefer option #3.  What are your thoughts on the auction related statuses that I sent out earlier?

Trung

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Thursday, August 16, 2012 6:18 PM
To: Keith Gaughan; [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

Jim 

On Thu, Aug 16, 2012 at 04:40:44PM +0100, Gavin Brown wrote:
> > assumption was that the textual description won't be used by 
> > registrars for automation.
>
> It seems more likely to me that registries would decide to overload 
> this field and then compel registrars to create business logic to handle it.
>

What's happened in those cases is that the registry operators create their own extensions to fit the extra semantics they--being the beautiful and unique snowflakes that they are--feel they absolutely can't possibly live without.

You're not at all overstating the risks. The thing that gets missed in this kind of discussion is that when a registry has discretion over the implementation of some element of EPP or a non-optional extension or object mapping, they effectively multiply the amount of work that needs to be done to implement that by the number of registrars integrated with them. The more that can be done so that registrars don't have to implement dozens of subtly-incompatible variations on the same spec.

K.

--
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/> 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 _______________________________________________
provreg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/provreg

---

From: "Gould, James" <[email-masked]>
Date: Fri, 17 Aug 2012 19:25:58 +0000

Tran,

We must have been typing at the same time yesterday, since I got your
e-mail with the auction statuses after sending my message.

I recommend adding the pendingAuction status and merging the "auction
awarded" status into the existing allocated status and the "auction
rejected" status into the existing rejected status.  The description of
the pendingAuction status could be "application pending based on results
of auction".  The state transition section could add the optional
pendingAuction status between the validated status and the rejected,
allocated statuses.  What do you think of this?

Are there any other additional known statuses that we should add?

--
  
JG

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

On 8/17/12 2:21 PM, "Tran, Trung" <[email-masked]> wrote:

>Jim,
>I agree with you and prefer option #3.  What are your thoughts on the
>auction related statuses that I sent out earlier?
>
>Trung
>
>2. Change the status element to use a enumerated list of status values as
>an attribute and allow for the element text to be free-form.  The
>free-form text could be returned to the registrant.
>3. Add an optional name attribute to the status element along with a
>"custom" status enumerated value to support sub-statuses or custom
>statuses similar to the approach taken in the draft with the phase
>element.  
>4. Make the status element a token instead of a enumerated list.  I don't
>believe anyone really proposed this, but I left it in for completeness.
>
>I would like to have all of the possible known statuses defined in the
>draft, where if we did a good job in gathering them all, option #1 is the
>best.  If we don't do a good job of gathering them all then some form of
>extensibility like option #3 would be needed to enable adding the missing
>statuses without requiring the creation of a registry specific custom
>extension.  I believe option #2 is close to using the optional name
>attribute of option #3 as a sub-status with a slightly different intent
>of not using the value to drive client-side logic.
>
>Does anyone know of any concrete statuses that need to be added to help
>with options #1, #2, and #3?  I don't want the draft to make it too
>difficult for the clients to handle and I don't want it to be too
>restrictive to meet specific registry policies that would result in the
>creation of additional custom extensions.  I believe option #3 is a good
>compromise, but that's probably obvious since I was the one that
>originally proposed it.
>
>What's happened in those cases is that the registry operators create
>their own extensions to fit the extra semantics they--being the beautiful
>and unique snowflakes that they are--feel they absolutely can't possibly
>live without.
>
>You're not at all overstating the risks. The thing that gets missed in
>this kind of discussion is that when a registry has discretion over the
>implementation of some element of EPP or a non-optional extension or
>object mapping, they effectively multiply the amount of work that needs
>to be done to implement that by the number of registrars integrated with
>them. The more that can be done so that registrars don't have to
>implement dozens of subtly-incompatible variations on the same spec.
>
>K.
>
>--
>Blacknight Internet Solutions Ltd. <http://blacknight.com/> 12A
>Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company
>No.: 370845 _______________________________________________
>provreg mailing list
>[email-masked]

---

From: "Tran, Trung" <[email-masked]>
Date: Fri, 17 Aug 2012 17:28:41 -0400

Jim,
Sounds good.  I think that will work.

There's no other status I can think of...at this time.

Trung

-----Original Message-----
From: Gould, James [mailto:[email-masked]] 
Sent: Friday, August 17, 2012 3:26 PM
To: Tran, Trung; Keith Gaughan; [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

Tran,

We must have been typing at the same time yesterday, since I got your e-mail with the auction statuses after sending my message.

I recommend adding the pendingAuction status and merging the "auction awarded" status into the existing allocated status and the "auction rejected" status into the existing rejected status.  The description of the pendingAuction status could be "application pending based on results of auction".  The state transition section could add the optional pendingAuction status between the validated status and the rejected, allocated statuses.  What do you think of this?

--
  
JG

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

On 8/17/12 2:21 PM, "Tran, Trung" <[email-masked]> wrote:

>2. Change the status element to use a enumerated list of status values 
>as an attribute and allow for the element text to be free-form.  The 
>4. Make the status element a token instead of a enumerated list.  I 
>don't believe anyone really proposed this, but I left it in for completeness.
>
>draft, where if we did a good job in gathering them all, option #1 is 
>the best.  If we don't do a good job of gathering them all then some 
>form of extensibility like option #3 would be needed to enable adding 
>the missing statuses without requiring the creation of a registry 
>specific custom extension.  I believe option #2 is close to using the 
>optional name attribute of option #3 as a sub-status with a slightly 
>different intent of not using the value to drive client-side logic.
>
>creation of additional custom extensions.  I believe option #3 is a 
>good compromise, but that's probably obvious since I was the one that 
>originally proposed it.
>
>I would like to hear from the list if there are any additional options 
>to consider and which option is preferred.
>
>Jim
>
>> However, I don't think that his has happened with the <status> 
>> element for domains, contacts, and hosts (unless someone wants to 
>> correct me), so perhaps I am overstating the risks.
>
>their own extensions to fit the extra semantics they--being the 
>beautiful and unique snowflakes that they are--feel they absolutely 
>can't possibly live without.
>
>to be done to implement that by the number of registrars integrated 
>with them. The more that can be done so that registrars don't have to

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 24 Aug 2012 12:50:39 +0200

On 10/08/12 16:23, Gould, James wrote:
> I've been working with Wil Tan and Gavin Brown on updating the Launch Phase EPP
> Extension Mapping to support the two models (ICANN and ARI/Neustar) along with
> the models that were previously defined in the Launch Phase EPP Extension
> Version 01.  You can find the draft at the URL
> http://www.ietf.org/id/draft-tan-epp-launchphase-02.txt.  This is a straw man
> draft to kick off the discussions as the tmch-tech list works out the model.
>   I've already posted a message on the tmch-tech list to start the discussions
> there.
>
> --
>
>

Hi James,

as I just commented on the eppsig draft: Unfortunately, I hadn't time yet to 
dive into the whole clearing house stuff, so my question could be naïve. Can you 
please elaborate about the need to support digital signatures in your extension, 
esp. how the lack of signatures would be a vector for misuse. And who is 
actually in possession of the private key and signs that part?

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Fri, 24 Aug 2012 13:02:38 +0000

Klaus,

The use of digital signatures and PKI is included in the ARI / Neustar Model for the Trademark Clearinghouse (TMCH) and discussed at the summit this week in Brussels.  The TMCH would be the holder of the private key and the registries, or anyone that needs to validate the signature, would have the corresponding public key.  Using PKI, the trademark holder / registrant would go to the TMCH to get a signed claim to use with one or more sunrise applications.  The TMCH, who has already validated the trademark information, would provide the information along with a digital signature around it to the trademark holder / registrant.  The trademark holder / registrant would give the signed claim to a registrar as part of a sunrise application.  The registrar would pass the signed claim in the launch phase extension of the domain create to the registry.  The registry can validate the signed claim using the public key of the TMCH and trust the information covered by the TMCH digital signature.  With this model, there is no direct dependency from the registries to the TMCH to validate the information, there is no need to replicate trademark information from the TMCH to the registries, and the trademark holder / registrant can securely pass the relavent trademark information to the registries in their sunrise applications. 

Please let me know if you have any additional feedback or questions in your review of the Launch Phase EPP Extension draft.

Thanks,

Jim  

________________________________________
From: [email-masked] [[email-masked]] on behalf of Klaus Malorny [[email-masked]]
Sent: Friday, August 24, 2012 6:50 AM
To: [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

Hi James,

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Fri, 24 Aug 2012 18:53:16 +0000

Trung,

How about allowing a string of human-readable text for the status similar
to RFC 5731 along with the use of the optional name attribute to define
the sub-status or full status when using a status value of "custom"?

Below is an example of the rejected status that was rejected due to losing
an auction.  

<launch:status s="rejected" name="rejectedAuction" lang="en">
Application rejected due to result of auction.
</launch:status>
>From the client perspective, the "rejected" status is what can be used to
drive logic with the optional use of a sub-status "rejectedAuction" to
provide more clarity.  The text "Application rejected due to result of
auction." is provided to describe the rationale for the status.

Below is an example of use of a custom status.

<launch:status s="custom" name="pendingServerSelection" lang="en">
Application pending a custom form of selection based on server policy.
</launch:status>

I believe that the server SHOULD NOT use the "custom" status, but is there
to support an unknown / custom status without encouraging the creation of
a new custom extension.

Any feedback is welcome.

--
  
JG

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