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=m66c6d1badbe7d35024b26d0be2b874... 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=444...
Hi,
On Mon, Feb 15, 2016 at 08:04:03PM +0400, Alan Barrett wrote:
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.
I've done some investigation of this. Here's what I learned.
Network Solutions/Web.com definitely offers the sort of facility we want. It's called, somewhat unfortunately, Web Lock (which, of course, in any search also turns into "we block", so you get about 10 billion alternatives to this). It provides a lot of granularity of control for high-value web sites, and importantly you can interlink the notifications for various actions such that multiple approvals and so on are needed. This is quite expensive -- thousands of dollars a year. This service was the source of some controversy when it was introduced, because Network Solutions sent auto-enroll notices to a large number of customers. (IMO, this was maybe the best example in a long history of the registration business snatching defeat from the jaws of victory: this is obviously a high-value service for certain kinds of user, and failing to get good press on it was a shame.)
I _believed_ that MelbourneIT had a similar service, but if it does I am unable to find any evidence of it.
Dyn (which is my employer) _will_ do this, on a case by case basis. In that case, it's all handled manually by concierge staff. At the moment I don't have a break-out of the cost, because really we only do it on request for certain kinds of customer, and they're always people using our DNS services and so on (i.e. it's basically a white-glove service). I'm not sure this would satisfy people, since it's all contractual.
I have heard tantalising rumours that Gandi will do this, but again I've been unable to find the evidence on their web site.
Maybe others closer to the domain name registration biz will know. I suggest we point to the Web Lock service and ask in the document whether any reviewers know of other examples of this, so that it could be put to bid.
In any case, I think this approach is cleaner than leaving the registrant with ICANN and handling the whole thing contractually, because in the event there's a dispute it's the registrant that, ultimately, the registrar is going to obey. That's precisely the case we're trying to guard against with all this effort, so ICANN retaining the registration seems like the wrong answer.
Best regards,
A
Ok, I made the two updates I said I would -- the note about the registration and rules for the registrar, and also the observation that we must sort out the issue of non-IANA-operated IANA registries (like enum). I _think_ that's all I said I'd do before we can share this document round, right?
A
participants (2)
-
Alan Barrett
-
Andrew Sullivan