Re: Launch Phase EPP Extension Version 02 Posted

On Thu, Aug 16, 2012 at 10:03 PM, Gould, James <[email protected]> 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


> On Thu, Aug 16, 2012 at 10:38:43AM +0100, Gavin Brown wrote:
> > 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.
>
> 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
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
>

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