Subject: [provreg] draft-tan-epp-launchphase-11

From: Mike O'Connell <[email-masked]>
Date: Wed, 21 Aug 2013 09:31:18 +0200

Hello Wil,

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.

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.

Any thoughts/comments?

Kind regards,

Mike O'Connell

--

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

---

From: Gavin Brown <[email-masked]>
Date: Wed, 21 Aug 2013 13:50:16 +0100

Hi Mike,

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

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

I look forward to seeing your patch! You can fork the git repo from
https://github.com/wil/EPP-Launch-Phase-Extension-Specification.

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: Francisco Obispo <[email-masked]>
Date: Wed, 21 Aug 2013 09:21:03 -0700

Hi Mike,

Can you please share the announcement?

I could not find any references to ICANN allowing multiple TMCHs on the newTLD page.

Thanks

On Aug 21, 2013, at 12:31 AM, Mike O'Connell <[email-masked]> wrote:

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

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 21 Aug 2013 10:51:12 -0700

Hi John, 

I was able to identify a possible new section (section 5) of the RPM document:

New Section 5:
5. Exemptions.

5.1 Registry Operator MAY apply with ICANN for exemptions to include additional registration programs that would qualify as Qualified Registry Launch Programs under these Requirements prior to or after entering into the Agreement. Such applications could, for example, provide for authorization to implement programs set forth in Registry Operator’s application for the TLD and programs unique to geographic or community gTLDs.

5.2 To facilitate the protection of verified legal rights, Registry Operator may request an exemption from these TMCH Requirements to permit Registry Operator to implement a single secondary (i.e. in addition to the Trademark Clearinghouse) verified legal rights mechanism providing protections for verified legal rights that meet or exceed the validation standards of the Trademark Clearinghouse.

5.3 Notwithstanding this Section 5, Registry Operator must comply with these Requirements, unless ICANN grants to Registry Operator a written exemption.

I'm not positive that ICANN will let pass 5.2, but in any case, if it does, the approach that you're proposing will require some sort of arbitrary payload to be transferred, because I don't see how we can guarantee that it will match the current spec.

If that's the case, then the approach of having some sort of entity within the extension that is capable of holding a SMD, an encodedSignedMark, or anything else, will most likely be needed.

Right now, the elements appear attached to the <lp:create> element:

     <!--
     Child elements for the create command
     -->
     <complexType name="createType">
       <sequence>
         <element name="phase" type="launch:phaseType"/>
         <choice minOccurs="0">
           <element name="codeMark" type="launch:codeMarkType"
             maxOccurs="unbounded"/>
           <element ref="smd:abstractSignedMark"
            maxOccurs="unbounded"/>
           <element ref="smd:encodedSignedMark"
            maxOccurs="unbounded"/>
         </choice>
         <element name="notice" minOccurs="0"
          type="launch:createNoticeType"/>
       </sequence>
       <attribute name="type" type="launch:objectType"/>
     </complexType>

That way, the extension is not bound to the specific types listed in the above schema definition.

On Aug 21, 2013, at 10:24 AM, John Hollifield <[email-masked]> wrote:

> Hi Francisco
> 
> My understanding is that this proposed change (along with others) is part of a memorandum on revisions to the RPM document which is currently in public consultation.
> 
> The latest RPM as well as the memorandum can be found at
> 
> http://www.icann.org/en/news/public-comment/rpm-requirements-06aug13-en.htm
> 
> Regards
> 
> John
> Nominet
> 
> Sent from my iPhone
> 
> On 21 Aug 2013, at 17:21, "Francisco Obispo" <[email-masked]> wrote:
> 
>> Hi Mike,
>> 

Francisco Obispo

---

From: John Hollifield <[email-masked]>
Date: Wed, 21 Aug 2013 17:59:03 +0000

Hi Francisco

>the approach that you're proposing

Just to be clear these are not my proposals, I was just pointing you to the documents.

Regards

John
Nominet

Sent from my iPhone

On 21 Aug 2013, at 18:51, "Francisco Obispo" <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

New Section 5:
5. Exemptions.

     <!--

On Aug 21, 2013, at 10:24 AM, John Hollifield <[email-masked]<mailto:[email-masked]>> wrote:

Hi Francisco

Regards

John
Nominet

Sent from my iPhone

On 21 Aug 2013, at 17:21, "Francisco Obispo" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mike,

Thanks

On Aug 21, 2013, at 12:31 AM, Mike O'Connell <[email-masked]<mailto:[email-masked]>> wrote:

Hello Wil,

Launch:Check response

Launch:Create request

Any thoughts/comments?

Kind regards,

Mike O'Connell

--

_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo
Director of Applications and Services - ISC
email: [email-masked]<mailto:[email-masked]>
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo
Director of Applications and Services - ISC
email: [email-masked]<mailto:[email-masked]>
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 21 Aug 2013 11:25:07 -0700

Ah Apologies John,

I was aware of that. Thanks for showing me the reference.

Francisco

On Aug 21, 2013, at 10:59 AM, John Hollifield <[email-masked]> wrote:

> On 21 Aug 2013, at 18:51, "Francisco Obispo" <[email-masked]> wrote:
> 
>> Hi John, 
>> 

Francisco Obispo

---

From: Mike O'Connell <[email-masked]>
Date: Thu, 22 Aug 2013 07:57:00 +0200

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.

> clearinghouses during the same launch? That would be exceptional in my

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.

> solution. I would ask that the attribute be optional though.

Definitely optional, I wouldn't want to inadvertently break other implementations

> https://github.com/wil/EPP-Launch-Phase-Extension-Specification.

Thanks - will get started.

Kind regards,

Mike O'Connell

--

---

From: John Hollifield <[email-masked]>
Date: Wed, 21 Aug 2013 17:24:59 +0000

Hi Francisco

Regards

John
Nominet

Sent from my iPhone

Hi Mike,

Thanks

Hello Wil,

Launch:Check response

Launch:Create request

Any thoughts/comments?

Kind regards,

Mike O'Connell

--

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Tue, 27 Aug 2013 19:38:45 +0000

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-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 8/22/13 1:57 AM, "Mike O'Connell" <[email-masked]> 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.
>
>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.
>
>>>    S:     <launch:claimKey
>>>chID="tmch">2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001</launch:
>>>claimKey>
>>> 
>>> 
>>> Launch:Create request
>>>

---

From: Mike O'Connell <[email-masked]>
Date: Wed, 28 Aug 2013 10:11:19 +0200

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

--