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

Wed Feb 17 17:31:04 UTC 2016

Thanks for the clarification Jonathan.

Regards
On 17 Feb 2016 6:14 p.m., "Jonathan Robinson" <jrobinson at afilias.info>
wrote:

> 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>
> 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.
>
> 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
> > 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/b1ae383b/attachment-0001.html>