Notes from IANA IPR call, 15 Feb 2016, 21:00 UTC
Present:
- Alan Barrett (NRO) - Paul Wilson (NRO) - Nurani Nimpuno (CRISP) - Greg Shatan (CWG) - Jonathan Robinson (CWG) - Jari Arkko (IETF) - Andrew Sullivan (IAB) - German Valdez (Secretariat)
Apologies:
- Izumi Okutani (CRISP) - Lise Fuhr (CWG)
1. Mailing list read-only subscription by observers
German confirmed that the iana-ipr@nro.net mailing list is open for subscription from the public, but is moderated in such a way that posts are allowed only from the small group of members.
2. Draft document read-only access by observers
Greg confirmed that read-only access to the “Principle Terms” draft document in Google Docs was possible using this link: https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i4ad4/edit?usp=sharing
This link may be published.
Members of this small group have all received a different link via email, which allows editing and commenting.
3. Tentative acceptance of non-controversial edits
Jonathan confirmed that he and Lise had reviewed the document. All agreed that non-controversial edits may be tentatively “accepted” in the draft document in Google Docs. Acceptance of edits is not binding on any party.
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.
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 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).
It also seemed clear that ICANN should be both the administrative contact and the technical contact for the IANA domain names.
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.
Jonathan suggested that we could allow multiple registrars the opportunity to bid on such a service.
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.
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.
—