[CWG-Stewardship] FW: [Iana-ipr] Notes from 15 Feb 2016

Wed Feb 17 17:14:09 UTC 2016

Please see below for one comment in response to a question directed to me.

Thanks,

Jonathan

From: Seun Ojedeji [mailto:seun.ojedeji at gmail.com] 
Sent: 17 February 2016 09:18
To: Jonathan Robinson <jrobinson at afilias.info>
Cc: cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] FW: [Iana-ipr] Notes from 15 Feb 2016

On 17 Feb 2016 8:46 a.m., "Jonathan Robinson" <jrobinson at afilias.info <mailto:jrobinson at afilias.info> > wrote:
>
> 4.  Discussion of items that have been flagged in the document
>
> 4.1.  Sublicensing rights
>
> It was agreed that the document should explicitly give ICANN the right to sublicense rights to PTI.
>
SO: Makes logical sense.

>
> 4.2.  Registrar, registrant and admin contact for IANA domain names
>
> There was discussion on ICANN’s expressed desire for "operational control over the IANA.ORG <http://IANA.ORG>  domain”, and how to provide that.  ICANN position, as stated in August 2015, is published at <https://www.icann.org/news/announcement-2015-08-15-en>.
>
> It was agreed that the registrant of the IANA domain names must be the same as the owner of the IPR (to be the IETF Trust).
>
SO: +1

> It also seemed clear that ICANN should be both the administrative contact and the technical contact for the IANA domain names.
>
SO: Makes sense, so long as any change approval process would ensure authorisation from both the admin contact and IETF trust (contact)

> Andrew suggested that some registrars provide services in which multiple approvals would be required for any operational change.  He suggested that using such a registrar could provide ICANN with the assurance that they would have sufficient operational control.
>
SO: This is good to know and its also an enlightenment to me as I never knew of a multiple approval option.

> Jonathan suggested that we could allow multiple registrars the opportunity to bid on such a service.
>
SO: Okay this seem like an overkill to me,  are we still referring to just domain names here? Are we doing this because of the approval requirement? From what I understand as explained above, it seem there are known registries that provides such service by default. Is it not as simple as transferring the domain to that Registrar. Why go through bidding just to host domain name.

JR: My recollection is that I said that I thought more than one registrar could provide the specific service as described. Not that I necessarily advocated for putting it out to bid.

> ACTION: Andrew to edit the document to outline the requirements for multiple approvals for any action by the registrar.
>
>
> 4.3.  Size of IIGC
>
> The draft (seciton 2b) says "the RIRs, the IETF and the names community will each select [five (5)] representatives (the “IANA IPR Reps”) to serve on an IANA IPR Governance Council (“IIGC”).”
>
> There was general agreement that this should be changed to three (3) representatives from each of the three operational communities.
>
SO: I think 5 may have been much easier number in the interest of representation et all. For instance RIR has 5 regions, also the CWG has 5 chartering organisations.

Thanks for the update.

Regards
>
> 4.4.  Exclusive license
>
> There was a long discussion on the implications of an exclusive license to ICANN.
>
> The IETF and the RIRs need to refer to the name IANA, and they might occasionally use the logo.  Greg said that descriptive or nominative use of the name was allowed without a licence, but use of the logo might need a licence.
>
> Alan was concerned that granting an exclusive licence to ICANN would prevent the granting of a licence for another party to use the logo.  Greg explained that exclusivity was restricted to a field of use, so granting an exclusive licence to ICANN for provideint the IANA services would not prevent granting a licence to another party to sue the logo for some legitimate reason.
>
> Greg also clarified that granting an exclusive licence to ICANN would prevent the IETF Trust from claiming to provide the AINA services, but would not interfere with the IETF Trust’s ability to use the marks in a descriptive way.
>
> ACTION: Greg to edit the document to clarify that the exclusive licence would be for a specified field of use.
>
> Andrew noted that there is an IANA registry that is not managed by ICANN (the ENUM registry managed by the RIPE NCC), and there is a non-IANA registry that is managed by the ICANN IANA department (the timezone database).  Licencing would need to accommodate these and similar cases.
>
> ACTION: Andrew to edit the document to mention the cases of IANA registries not managed by ICANN, and non-IANA registries managed by the ICANN IANA department.
>
>
> 4.5.  Ability for IETF Trust to use the marks
>
> This issue had been discussed under the previous agenda item.
>
>
> 4.6.  Quality of service
>
> Greg clarified that the text in section 3b requiring “consistent quality at least equal to the quality of services offered by ICANN immediately prior to the transition” was a standard formulation.  There does not seem to be a need to add more detailed quality rules to the document.
>
>
> 4.7.  Request to engage a new IANA service provider
>
> The draft (section 3g) say "the Trust may request that the relevant operational community or communities begin the process to engage a new IANA service provider.”  Jari had expressed a concern that a decision to engage a new IANA service provider shoudl come fomr the operational communities, not from the IETF Trust.
>
> Andrew said that there was a tension between the Trust’s need to perform quality control, and the need for the Trust to follwo the community’s wishes.  Greg said that the term “request” had been chosen deliberately in an attempt to balance these two goals.  Greg also said that this phrase should not be read in isolation, but in the context of the entire section 3g, which lists several escalation steps.
>
> There was general agreement that the affected operational communities should make the decision about engaging a new IANA service provider, and that this part of the “Principle Terms” draft should be brought to the communities’ attention during discussion.
>
>
> 4.8.  Other issues
>
> No other issies were discussed.
>
>
> 5.  Next steps
>
> The draft "Principle Terms” document should be discussed in the operational communities.  This link to the document may be used:
> <https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i4ad4/edit?usp=sharing>
>
> The next meeting will be in two weeks, on Monday 29 February at a time to be determined.  This will be shortly before the ICSANN 55 meeting in Marrakesh.
>
> —
>
>
> _______________________________________________
> Iana-ipr mailing list
> Iana-ipr at nro.net <mailto:Iana-ipr at nro.net> 
> https://www.nro.net/mailman/listinfo/iana-ipr <https://www.nro.net/mailman/listinfo/iana-ipr> 
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org> 
> https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://mm.icann.org/mailman/listinfo/cwg-stewardship> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20160217/ca318909/attachment.html>