[Gnso-newgtld-wg-wt2] Actions/Discussion Notes: Work Track 2 SubTeam Meeting 15 December

Thu Dec 15 21:10:22 UTC 2016

Dear Sub Team Members,

Please see below the action items and discussion notes captured by staff from the meeting on 15 December.  These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the chat room or the recording.   See the chat room and recording on the meetings pages at: https://community.icann.org/display/NGSPP/Work+Track+2+Meetings.  See also the attached slides that are referenced below and posted on the wiki.

Best regards,

Julie

Julie Hedlund, Policy Director

Action Items/Discussion Notes 15 December

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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20161215/c2ad952e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20161215/c2ad952e/smime-0001.p7s>