Re: draft-tan-epp-launchphase-11

Hi James,

Thanks for the feedback!

Our primary concern is time, we have to adhere to a strict schedule on launch and having multiple phases and sub-phases will not only confuse the registrars but also delay open delegation.

Below is the proposed schedule for our gTLD launch

If the image is not available please see the proposed launch schedule at https://www.registry.net.za/content.php?gen=1&contentid=93


Kind regards,

Mike

--

If you don't know where you are going, any road will get you there.

On 27 Aug 2013, at 9:38 PM, "Gould, James" <[email protected]> wrote:

> Mike,
> 
> Sorry about being late to the game on this thread, but do you envision
> supporting a custom sunrise as well as a custom claims period?  The draft
> already supports a custom sunrise with the ability to define your own
> signed mark and encoded signed mark.  The draft does support defining a
> custom claims period with the use of a custom phase name or sub-phase
> name.  Is there the need to define another handle for a custom claims
> phase via an optional chID attribute.  There is no registry of the custom
> claims service that maps to a phase name, sub-phase name, or chID, so the
> client needs to know this ahead of time.  If there is a custom claims
> phase that needs to support more than one claims service (TMCH and
> custom), then there would be the need for an additional property like
> chID; otherwise I believe you can use the custom phase name or sub-phase
> name as the key.  
> 
> -- 
> 
> JG
> 
> 
> 
> James Gould
> Principal Software Engineer
> [email protected]
> 
> 703-948-3271 (Office)
> 12061 Bluemont Way
> Reston, VA 20190
> VerisignInc.com
> 
> 
> 
> 
> 
> On 8/22/13 1:57 AM, "Mike O'Connell" <[email protected]> wrote:
> 
>> Hi Gavin,
>> 
>> Thanks John Hollifield for assisting with locating RPM proposal, I
>> struggled to find it yesterday as I wanted to include it in my original
>> email.
>> 
>>>> With ICANN allowing third-party clearing houses I would like to propose
>>>> an extension to the launchphase RFC to include an optional attribute
>>>> for
>>>> a clearinghouse ID (chID), this wouldn't break existing implementations
>>>> but would allow certain registries to utilise a localised
>>>> clearinghouse;
>>>> such as a company registration repository.
>>> 
>>> Can you conceive of a scenario where a registry might use two different
>>> clearinghouses during the same launch? That would be exceptional in my
>>> experience.
>> 
>> One scenario we envisage is with geoTLDs where companies wish to protect
>> their local identity but cannot (or will not) register with the TMCH. The
>> registry will offer the mandatory TMCH sunrise followed by a local
>> sunrise where these companies can claim their stake through formal
>> processes.
>> 
>>>> The attribute would be a simple indicator to assist in referencing the
>>>> correct clearinghouse. For example:
>>>> 
>>>> Launch:Check response
>>>> 
>>>>   S:     <launch:claimKey
>>>> chID="tmch">2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001</launch:
>>>> claimKey>
>>>> 
>>>> 
>>>> Launch:Create request
>>>> 
>>>>   C:     <launch:codeMark chID="tmch">...</launch:codeMark>
>>>> 
>>>> 
>>>>   and to possibly extend the (Signed)Mark schema with a chID
>>>> attribute/element
>>>> 
>>>> 
>>>> The other commands would reference the application by the application
>>>> ID
>>>> element so they wouldn't need the chID attribute. I would be happy to
>>>> do
>>>> the extensions to the RFC and submit to you for approval.
>>> 
>>> Assuming that there is a genuine problem, then this seems like a good
>>> solution. I would ask that the attribute be optional though.
>> 
>> Definitely optional, I wouldn't want to inadvertently break other
>> implementations
>> 
>>> I look forward to seeing your patch! You can fork the git repo from
>>> https://github.com/wil/EPP-Launch-Phase-Extension-Specification.
>> 
>> Thanks - will get started.
>> 
>> 
>> Kind regards,
>> 
>> Mike O'Connell
>> 
>> --
>> 
>> If you don't know where you are going, any road will get you there.
>> 
>> _______________________________________________
>> provreg mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/provreg
>

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