The call for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues will take place on Thursday, 15 December 2016 at 20:00 UTC.
12:00 PST, 15:00 EST, 20:00 London, 21:00 CET
For other times: http://tinyurl.com/gr2c26q
PROPOSED AGENDA:
1. Welcome
2. Updated SOI
3. Reserved Names at the Second Level
4. AOB
In advance of the meeting I would like to share a Google sheet that we will use to discuss the second level reserved names during the meeting. Please review, make any comments about the material and we will discuss during the meeting.
https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8GCamL3NQ/edit#gid=2486987
Dial outs: Phil Buckingham, Cheryl Langdon-Orr, Michael Flemming
Apologies:
On audio only:
Slides:
Notes/Actions:
ACTION: Look at the new language of the registry agreement once it comes out and how that language may affect some reservations.
Reserved Names at the Second Level – See the Google Doc at: https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8GCamL3NQ/edit#gid=2486987.
From the chat:
Jeff Neuman: Remember the default...if we get no comments otherwise, the assumption is that whatever is applicable today will be applicable in the future. So speak up if you have an issue :)
ICANN/IANA Names -- All Levels and 2nd & 3rd levels; Example reserved at all levels, ASCII only.
-- Not adoped/not protected at the second level
-- Doesn't seem to be support to change policy to reserve at the second level.
-- Move in the direction of the AGB to not reserve at the second level.
-- Before the AGB was final, ICANN had itself, IANA, and some others proposed to be protected, but if it wasn't going to protect other organizations it wasn't going to protect its own.
-- The rationale was that if someone could pretent to be ICANN/IANA etc.
-- Example has been reserved for a long time. Don't need to spend a lot of time on it.
From the chat:
Rubens Kuhl: I think IANA still deserves such reservation. It's a "household name" of sorts. As in the IANA label only, not all the IANA labels. Example and ROOT-SERVERS are also worth keeping reserved, IMHO. ICANN is not worthy reserving. ;-) Example was also mentioned as an IANA label.
Annebeth Lange, ccNSO: To reserve anything at second level, there should be a very good reason why. Why ICANN and IANA and not other international organisations?
Jeff Neuman: @Annabeth - that is why ICANN took its name off the list
Rubens Kuhl: IANA is not an organization, PTI is. IANA is similar to INTERNIC, a long-recalled name with a meaning.
Annebeth Lange, ccNSO: Exactly :-) That is true, Rubens. You have a point.
Rubens Kuhl: It's also of note that we could move such names to being "LRO material", as in someone which is not RIPE applies for .RIPE, RIPE could file an LRO.
Greg Shatan: The iana.org domain name is used for emails instructing changes to the Root Zone, and for the website on which critical information is displayed. PTI also owns iana.com and iana.net.
Jeff Neuman: @Rubens I know IP attorneys that could make similar arguments :) If a registry wants to reserve other versions of "example" it may do so on its own. But I see no reason why it should be protected by ICANN in all TLDs
Trang Nguyen: There was a reserved names working group. The final report is posted at https://gnso.icann.org/en/drafts/rn-wg-fr19mar07.pdf and may provide some background info.
Symbols -- not allow them except for hyphens.
From the chat:
Jeff Neuman: the 2009 "recommendation" is the result of the final report from the reserved names working group.
Rubens Kuhl: ICANN disallowed even the hyphen.
Jeff Neuman: @Rubens - only when the hyphen is in the 3rd and 4th position
Greg Shatan: This probably requires an IETF RFC, I'm guessing. Symbols, that is.
Single and two-character IDNs
-- Leave as is (no reservations).
-- May be noteworthy to make mention of what is possible.
From the chat:
Annebeth Lange, ccNSO: Just a heads up for the Standardized Framework for Release of Two-Character ASCII Labels to avoid confusion with corresponding country codes, published yesterday. And a comment to IDNs - there have been instances where a 2-letter IDN is to similar to a 2-letter ASCII, so that it could not be accepted. It was on first level, but still it might appear on second level as well.
Single letters and digits -- accepted at 2nd and 3rd level
-- No reservations. Suggest leaving as is.
Any combination of two letters, digits
-- There is now a measurement to allow for the release for these characters if registries folllow certain policy and implementation requirements to avoid confusion.
-- Could change policy to note the implementation guidelines.
-- This provision is to avoid risk of confusion with the country codes. Could warrant something in the policy acknowledging which combinations raise that concern (letter-letter, number-number).
From the chat:
Susan Payne: Having said which, am I right in thinking that we are holding over the "country code" issue to discuss in the wider context of geo names? EP, EC, EU, AU, UN
Annebeth Lange, ccNSO: As for geo-names, I think that should be kept at first level. GAC has been discussing 2-letter codes from ISO-list 3166 at second level, but I do not think they have - at least so far - been anxious about other geonames at second level.
Tagged Names
-- IDN guidelines are the default; an exception can be granted. Right now IDN guidelines would be ceilings.
-- Currently the policy to implement the AGB reserves the hyphen in the 3rd and 4th location.
-- This isn't the only way the IDN guidelines can be implemented.
-- Suggesting not changing.
From the chat:
Rubens Kuhl: I'll note that a registry might be allowed to not follow ICANN IDN Guidelines to the letter, by making an RSEP request that ICANN approves. So the guidelines are not the ultimate restrictions to it
Jeff Neuman: The third and 4th hyphens could in theory be used for other types of IETF protocols..but to my knowledge they have not been
NIC, WHOIS, WWW -- 2nd & 3rd ASCII (now includes RDDS); IDN
-- This is a pain point for IDN registires -- forced to use ASCII only for the NIC label (could not use non-ASCII script) for the registry operation, but this has already changed.
-- Talking about two different things -- reservation of the name versus use of the name. Not sure if there would be a change in the reservation policy.
-- Not trying to translate them is what is important, but could consider saying that any translation could be used by the registry.
-- For purposes of blocking a name do not try to translate it. Could change to using either NIC or a translation of NIC...(language that is not as strong).
From the chat:
Alexander Schubert: Jeff is right! (about there being two different things).
