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

Wed Feb 17 09:17:53 UTC 2016

On 17 Feb 2016 8:46 a.m., "Jonathan Robinson" <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 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/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
> https://www.nro.net/mailman/listinfo/iana-ipr
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> 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/d9f1df16/attachment.html>