Re: draft-tan-epp-launchphase-11

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