- Iana-ipr - nro-apps-2.ripe.net

Meeting in ICANN 55
by German Valdez 07 Mar '16

07 Mar '16

Hi Here is a doodle poll in order to find a common time to meet during Marrakech http://doodle.com/poll/f493whdyy7b26epn This is based on Paul and Alan availability, hopefully we can find a time that work for the rest. Regards German

10 25

What's going into PTI?
by Greg Shatan 07 Mar '16

07 Mar '16

I'm curious to know the understanding of the RIRs and IETF about what is going into PTI. The ICANN Budget just posted for comment shows only the "naming functions" going into PTI, while the "numbers functions" and "protocol parameter functions" will remain within ICANN. Since IANA staff is cross-functional, this means that the IANA staff will be allocated in part to ICANN and in part to PTI based on what they do (e.g., employee A will be 30% PTI, 70% ICANN and employee B will be 50% PTI, 70% ICANN). As such, PTI would almost certainly have no full-time employees. Is this your understanding of the plan? Thanks! Greg

2 5

Notes from 29 Feb 2016
by Alan Barrett 03 Mar '16

03 Mar '16

Notes from the IANA-IPR meeting of 29 February 2016 1. Review of changes agreed during the previous call. 1.1. Tentative acceptance of non-controversial edits. Edits have been “accepted”. 1.2. Edits regarding right to sublicense rights to PTI. Text has been edited. No further action is required. 1.3. Edits regarding regitrant, administrative contact, tech contact. Text has been edited to say that the Trust should be the Registrant and Administrative Contact, and ICANN should be the Technical contact, for all IANA domain names. There was a discussion on whether the administrative contact should be ICANN or the Trust. Andrew suggested that the ARPA TLD was an existing example of a similar arrangement, where the IAB is the registrant and the administrative contact, and ICANN (as the IANA operator) is the technical contact. There was agreement that a similar arrangement made sense for the IANA domain names. The current draft document already specifies the Trust as both the registrant and administrative contat, and ICANN as the technical contact, and there is no need to change this. 1.4. Edits regarding multiple approvals. Text has been edited to require approval from both the registrant and technical contact. Andrew mentioned Mark Monitor as a possible service provider. Greg mentioned CSC Corporate Domains and Cloudflare as possible service providers. ACTION: Andrew and Greg to add comments to the document mentioning these possible providers of registry services that require multiple approvals. 1.5. Edits regarding number of members of IIGC. Text has been edited to say 3 members from each operational community. No further action is required. 1.6. Edits regarding exclusive licence being restricted to use in connection with the provision of the IANA functions. Andrew mentioned that comme questions had been raised in the IETF community. He suggested opening threads in the community mailing lists to discuss the issue of exclusive licences. Greg suggested that we could write a “primer” document to help people understand different types of licences and their implications. Lise suggested that we could do both. Andrew said that one person’s question about “Why are we granting them exclusive control?” seemed to show confusion between control of the marks versus exclusive licence to use the marks. Greg agreed to write a short document (a few paragraphs). ACTION: Greg to write a short document on the implications of an exclusive license. 1.7. Edits to mention IANA registries not managed by ICANN, and non-IANA registries managed by the ICANN IANA department. Text has not yet been edited. Andrew said that the ENUM registry is operated by RIPE NCC, does not call itself an IANA registry, but is discussed in the IANA Considerations section of RFC 4414. Andrew said thet the Timezone database not an IANA registry, is not controlled by the IETF, but is operated by IANA according to RFC 6557 specified by the IETF. The issue is that we don’t want to prevent people from continuing to operate ENUM and timezone database. Greg said that ENUM not using the IANA brand, so it is probably OK without a licence, but we should devote a sentence to it. Andrew said that ICANN/IANA has the ability to maintain IANA databases for SDOs other than the IETF. So far they don't, exactly, though some think the TZ database is such a case Nurani suggested that the RIPE NCC legal adviser should be involved, since the ENUM registry is operated by the RIPE NCC. Andrew suggested that the document might be ready for involvement from legal counsel in all three opertional communities. Greg agreed that legal counsel should comment on the term sheet, after a last look by this group Greg talked about balance between the Trust and the communities, and thinks the document strikes a good balance, but it needs more discussion 2. Update on discussion in operational communities. The draft “Principle Terms” draft document is in Google Docs at this URL: <https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i…>. It has been shared in numbers communitl “ianaxfer” mailing list, with not much feedback. It has been shared in a CWG call, with no feedback yet. It has been discussed in the IETF, and there was feedback on the exclusive license, as discussed under agenda item 1.6. It will be discussed in a CRISP call later on 29 Feb 2016. ACTION: All to encourage further discussion in community mailing lists. 3. Implications of the new name of PTI. Andrew asked whether we needed to be explicit that, whatever name is used for PTI, all services remain at iana.org. He mentioned that a new name for “PTI” is expected to be announced at ICANN 55 in Marrakesh, in March 2016. Greg wondered whether the name will include “IANA” or “Internet Assigned Numbers Authority”. Alan said that it would be bad if the name included IANA, but they lost the licence later. Greg said that the licence could be written to allow for this, and force them to change their name if they lose the licence. Andrew said that he was planning to send a message to ICANN about this issue. He did not have time to edit the message collaboratively before sending, btu would copy the members of this group. 4. Name of IIGC. Alan asked whether we could find a better name than IANA IPR Governance Council (IIGC), because the name Governance Council sounds pompous. Greg suggested “Community Representative Group”. 5. Next steps. All to inform their community of the document, and encourage discussion. Next meeting will be after the CCWG meeting on Friday 8 May 2016. German will try to choose some time slots during ICANN week and post a poll.

1 0

Agenda for 29 Feb
by Alan Barrett 29 Feb '16

29 Feb '16

Please suggest agenda items for the next call on 29 Feb 2016. I see the following items in the notes from the previous meeting on 15 Feb: * Announcement to operational communities that they may view the draft in Google Docs at <https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i…>. * Tentative acceptance of non-controversial edits * Edit the document to explicitly give ICANN the right to sublicense rights to PTI. * Edit the document to say that the IETF Trust will be registrant and admin contact, and ICANN will be tech contact. (Do we need to re-open that discussion, making ICANN only the tech contact and the Trust both registrar and admin contact?) * Edit the document to outline the requirements for multiple approvals for any change. * Edit the document to say that the IANA IPR Governance Council (“IIGC”) will have 3 representatives from each operational community. * Edit the document to clarify that exclusive licences will be restricted to use of the IPR in connection with provision of the IANA functions. * Edit the document to mention the cases of IANA registries not managed by ICANN, and non-IANA registries managed by the ICANN IANA department. Alan Barrett

3 4

Webex Details - IPR Teleconference Monday February 29th 6:00 AM UTC
by German Valdez 26 Feb '16

26 Feb '16

IPR Teleconference February 29th 2016 Monday, February 29, 2016 6:00 am | UTC| 1 hr Join WebEx meeting https://ripencc.webex.com/ripencc/j.php?MTID=mc3c2a1785025884e9dde0e15a6366… Meeting number: 708 019 002 Meeting password: iproc Join by phone 0800-051-3810 Call-in toll-free number (UK) +44-203-478-5289 Call-in toll number (UK) Access code: 708 019 002 Global call-in numbers | Toll-free calling restrictions https://ripencc.webex.com/ripencc/globalcallin.php?serviceType=MC&ED=447800…

1 0

Notes from 15 Feb 2016
by Alan Barrett 26 Feb '16

26 Feb '16

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(a)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/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i…> 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/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i…> 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. —

2 5

Doodle for next meeting time
by Andrew Sullivan 26 Feb '16

26 Feb '16

Hi, I put up a doodle for the next meeting time, on 29 Feb only, as agreed. http://doodle.com/poll/xvyp5emm9qa7tk2k Because for some reason doodle supports time zones but doesn't seem to have UTC as a possibility, I had to fill this in using a time zone, so I used my own. As a result, it goes from midnight UTC on the 29th to midnight US Eastern time on the 30th, because I have such a short attention span that I forgot what I was doing half way through. This is what an espresso machine in your house brings. I've filled it for myself, but note that the entries are sort of guesses. I'm travelling that day (I will go to Toronto and then drive down to Niagara to see my parents before flying to the ICANN meeting). Best regards, A -- Andrew Sullivan ajs(a)anvilwalrusden.com

6 10

Agenda for 15 Feb 2016
by Alan Barrett 15 Feb '16

15 Feb '16

Here’s a proposed agenda for today’s call. Right at the end, I also posted the WEBEX details. Alan Barrett Proposed agenda for IANA IPR call, 15 Feb 2016 1. Mailing list read-only subscription by observers Review action item from the previous meeting: German Valdez to investigate the technical feasibility of allowing open read-only subscription, and to implement it if it is easy. This has been done. 2. Draft document read-only access by observers Review action item from the previous meeting: Greg Shatan to adjust the permissions and/or create new links as appropriate to allow this group to edit the document while allowing the public to read the document. Is there a URL that we can publish on the mailing list? 3. Tentative acceptance of non-controversial edits Confirm that Jonathan and Lise have reviewed the document. Confirm that non-controversial edits may be tentatively accepted, noting that acceptance is not binding on any parties. 4. Discussion of items that have been flagged in the document 4.1. Sublicensing rights We agreed that the licence should be to ICANN. Do we have to explicitly grant ICANN the right to sublicense? 4.2. Registrar, registrant and admin contact for IANA domain names The draft doesn’t mention the registrant for the IANA domain names. Should it be the IETF Trust? The draft specifies the IETF Trust as the administrative contact. There’s an open issue about whether ICANN should be the admin contact, to satisfy concerns about stability. There’s an open question about whether a registrar other than GoDaddy is needed, to provide a suitable level of control over which parties can make which changes. This issue is touched on by sections 1b and 3d of the draft. 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”).” Comments have suggested that the 5 representatives per community shouod be reduced to 3 or 2. 4.4. Exclusive license The draft (section 3a) offers an exclusive license to ICANN. We discussed this at the meeting on 8 February 2oa6, but perhaps more discussion is needed on how the IETF Trust and the three communities will be able to use the marks if there’s an exclusive license ot ICANN. 4.5. Ability for IETF Trust to use the marks The draft (section 3a) says "provided that the Trust will not have the right to use, display or reproduce the IANA marks”. There’s a quetion about why this is desirable. 4.6. Quality of service The draft (section 3b) says “consistent quality at least equal to the quality of services offered by ICANN immediately prior to the transition”. Is this sufficiently clear, especially to readers several years in the future? 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.” There’s a comment that the Trust could inform that communities that there’s an issue with IPR, but the decision about whether a new IANA operator is needed shouls come from the communities. 4.8. Other issues 5. Next steps WEBEX details: IPR February 2016 2nd Teleconference Monday, February 15, 2016 9:00 pm | Greenwich Time (Reykjavik, GMT) | 1 hr Join WebEx meeting https://ripencc.webex.com/ripencc/j.php?MTID=m66c6d1badbe7d35024b26d0be2b87… Meeting number: 708 074 468 Meeting password: ianaipr Join by phone 0800-051-3810 Call-in toll-free number (UK) +44-203-478-5289 Call-in toll number (UK) Access code: 708 074 468 Global call-in numbers | Toll-free calling restrictions https://ripencc.webex.com/ripencc/globalcallin.php?serviceType=MC&ED=444439…

2 2

Link for viewing the Principal Terms document for IANA IPR
by Greg Shatan 15 Feb '16

15 Feb '16

This link will allow the user to view the "Principal Terms" document for IANA IPR https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i… Greg

1 0

ICANN Statement Regarding IANA Intellectual Property Rights (IPR)
by Nurani Nimpuno 15 Feb '16

15 Feb '16

As ICANN’s statement on the IPRs came up during our call now, below is the statement from August 2015. Nurani https://www.icann.org/news/announcement-2015-08-15-en ICANN Statement Regarding IANA Intellectual Property Rights (IPR) ICANN supports the IANA Stewardship Transition Group (ICG) proposal and the underlying proposals from the Community Working Group (CWG), the Consolidated RIR IANA Stewardship Proposal (CRISP) team and the Planning for the IANA/NTIA Transition (IANAPLAN) working group. The ICANN Board is focused on how to implement the Intellectual Property Rights (IPR) component of the proposal. The Board believes that for stability and pragmatic operational reasons, the IANAFunctions Operator must have operational control over the IANA.ORG domain. During the transition, ICANN is prepared to transfer full ownership of the IANA-related trademarks to a neutral third party mutually agreed among the operational communities with the understanding that ICANN, as the current IANA Functions Operator, will be granted license to those trademarks and ICANNwill maintain operational control of the IANA.ORG domain for as long as ICANN remains the IANAFunctions Operator. If the transfer during the transition affects the timeline, we advise delay until after the transition. In that event ICANN is ready to hold the IPR as interim measure but commits to transfer it within 120 days after the neutral third party is identified by the operational communities. We believe this is neutral and in the public interest. We look forward to hearing from anyone in the community.

1 0