On 17 Feb 2016 8:46 a.m., "Jonathan Robinson" <jrobinson@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 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.
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/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i4...
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@nro.net https://www.nro.net/mailman/listinfo/iana-ipr
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship