Re: draft-tan-epp-launchphase-11
Francisco Obispo <[email protected]> Wed, 21 Aug 2013 11:25:07 -0700
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
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 protected]> wrote: > 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 protected]> wrote: > >> Hi John, >> >> I was able to identify a possible new section (section 5) of the RPM document: >> >> >> New Section 5: >> 5. Exemptions. >> >> <page3image2352.png> >> 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 protected]> 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 protected]> wrote: >>> >>>> 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 protected]> wrote: >>>> >>>>> 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. >>>>> >>>>> _______________________________________________ >>>>> provreg mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/provreg >>>> >>>> Francisco Obispo >>>> Director of Applications and Services - ISC >>>> email: [email protected] >>>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >>>> PGP KeyID = B38DB1BE >>>> >>>> >>>> >>>> _______________________________________________ >>>> provreg mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/provreg >> >> Francisco Obispo >> Director of Applications and Services - ISC >> email: [email protected] >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >> PGP KeyID = B38DB1BE >> >> >> > <page3image2352.png> Francisco Obispo Director of Applications and Services - ISC email: [email protected] Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg