[Gnso-newgtld-wg-wt2] Actions/Discussion Notes: Work Track 2 Sub Team Meeting 27 July

Julie Hedlund julie.hedlund at icann.org
Thu Jul 27 22:11:57 UTC 2017


Dear Sub Team Members,

 

Please see below the action items and discussion notes captured by staff from the meeting on 27 July.  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. 

 

Please also see the attached documents and the excerpts from the chat room below.

 

Best regards,

Julie

 

Julie Hedlund, Policy Director

 

 

Action Items/Discussion Notes 27 July

 

Top-Level Reserved Names: https://docs.google.com/spreadsheets/d/1x74w58a9UaTTVulCMmrI45iTiHao6Hf1s8eVeeh5-N0/edit#gid=0[docs.google.com]

Second-Level Reserved Names: https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8GCamL3NQ/edit#gid=2486987[docs.google.com]

 

1.  CC2 Comments: Registry Agreements:

 

2.1.1 on single vs multiple registry agreements

 

-- To collect ourselves I want to engage to see if everyone thinks we are on the same page.  This is where I think we are at -- what I felt was the majority opinion.

 

Summary:

 

-- Support for a model similar to what is currently in place: a single registry agreement with exemptions that allow for TLDs with different operational models.

 

-- Also support for different registry agreements for different TLD categories, centered around a common, core base set of contractual requirements.

 

-- The majority of responses has shown support for a single registry agreement that allows for different operational models.

 

Discussion:

 

-- What this doesn't say that there should be no presumption that the open registry model should be the default model.  that people don't have to explain why they don't want to be in the base agreement.  It should accommodate other business models.  1) There should be no presumption is everyone is an open model; 2) ICANN staff and Board should be open to listening about other models and incorporating other specifications.

 

-- I wonder if we can delve into the above statement.  The concern is that if we have thousands of applications how ICANN would enter into negotiations with every registry and not singling out any registry for different treatment.  There could be business models that truly are unique that should be differentiated.  If we are going to have flexibility we need to build in some guidelines.

 

-- How will ICANN do it I guess $185,000 for the fee should allow ICANN to engage in good faith negotiations.  I don't think it is disparate treatment to allow different models.

 

-- We all understand that it is very difficult to give specific treatment because of the Bylaws, but there must be some way for ICANN to be flexible for different types of business models.  

 

-- I think we should have some option in the application process for the models that we know about that we create specific provisions for the spplicant should pick which model applies.  We should brainstorm what type of business models that we can foresee.   [Action to Jeff Neuman and Paul McGrady]

 

-- Whenever we create some loophole or extra provisions people who would like to circumvent the protections for registrants they will us it.  To do things that you can't do with an open TLD.  Such as leasing domain names.

 

-- The current models that we are exploring -- such as Brand TLD or closed TLD -- there are specific provisions that you can't do that.  We are having them follow the same protections as for registries.  This is something that exists today.  We are exploring different avenues for other models as well.

 

>From the chat:

 

Jeff Neuman: Rather than use the word "exemptions" I would say "flexibility"

Jeff Neuman: Paul - Any examples of TLDs with different business models today that should have a different agreement

Alexander Schubert: So applicants can apply for eageneric term base gTLD, then keep it "closed" and (instead of allow registrations to happen) "lease" domains - without providing ANY protections to the "leasee"? Cause that what will happen.

Alexander Schubert: .... a generic term based ....

Jeff Neuman: @Paul - You make an assumption that the fees will be that high....decision has not been made yet.

Paul McGrady: Will still need an "other" option to open, closed, etc.

Paul McGrady: @Jeff - I'm making the high fees assumption because I've seen ICANN's financial statements...  They need the $.

Jeff Neuman: @Paul - lol

Paul McGrady: But there can be many more models out there.  Prior to the FIrst Round opening, I could have NEVER anticiapted the .sucks business model, but yet, here it is.

Alexander Schubert: .book owned by Amazon and then SLDs "leased" to authors would mean the "users" of the domains are completely unprotected!

Susan Payne: Alexander I don't think it's reasonable to raise hypotheticals using real examples of registry operators without making that absolutely clear. People may believe you are referring to an actual intended business model 

 

2. CC2 Comments: Reserved Names:

 

The full list of CC2 comments on reserved names can be found here: https://docs.google.com/spreadsheets/d/1tcWZt1bdoYH7vJl2Yi9G0jah7QzyhqU99tXnl3qV0rc/edit#gid=1800862598 

 

2.2.1 -- Do you believe any changes are needed to the String Requirements at the top level as defined in section 2.2.1.3.2 of the AGB?

 

-- Suggested changes to String Requirements: Valideus, INTO, RySG, NORID, BRG and Jannik Skou

 

-- No changes are needed: Jannik Skou, Nominet, Afilias, and ALAC.

 

-- The GAC pointed to comments it made regarding CC2 section 3.4 on String Similarity.

 

Discussion:

 

-- 1 and 2 characters were not allowed in ASCII and 1-character IDNs were not allowed.  Respect the finding of the ccNSO CCWG on the use of country and territory names (UCTN) on 2-character strings.

 

-- Not suggesting that we would overturn the CCWG determination, but that was about 2 letters, not about letter and number.  Could have a recommendation guidance on letter + number combination.

 

-- We are trying to be uniform in terms of 2 characters; we have consistent rules of no 2-letter-letter combinations because those are reserved for country codes.  There is nothing technical that would stop a number-letter/letter-number combination, but there might be an issue with a number-number combination.

 

-- In 2009 they said 2-characters were not allowed.

 

-- Discussion on whether we should add any of the newer names, previously.

 

-- Most comments didn't get into every category we had.  We could put that in a similar type of matrix.

 

Question: Comment from NORID -- protection for CENTR, just the same as GNSO, ccNSO.  What do people think about that comment.  Should we start protecting APNIC, LACNIC, etc.?  Protecting regional names. 

 

Responses:

 

-- We should not be protecting them, but nothing to keep them from applying and then reserving them.

 

-- I don't see carving these out for them but also why we reserve the ones that we do.  We need to distinguish why a few names are worthy of this kind of protection and others aren't.  There is a balance that we have to find there.

 

-- IETF has given a technical reason for why they are reserved.  At one point ICANN did entertain the notion for dropping the ICANN names from the list.  Unless we know of a technical reason I agree that we shouldn't keep them reserved.

 

>From the chat:

 

Jeff Neuman: Correct, we can decide from a policy perspective to allow a two character letter/number or number/letter combination

Jeff Neuman: two numbers may be an issue technically as confusing with an ip address

Alexander Schubert: I think ALL two letter combinations should be protected - the Internet user gets otherwise consfused  why some two letter combinations are cc and some gTLD! "aa" for example can never be assigned to a nation - should still be protected!

Jeff Neuman: @Phil - There are certain compromises that need to be made

Jeff Neuman: HP can still get HPE

Jeff Neuman: which is how they refer to themselves

Cheryl Langdon-Orr (CLO): and what if the ISO list does allocate Hp?

Jeff Neuman: I strongly believe we should honor the one recommendation from the CCWG-UCTN

Alexander Schubert: I think the ccNSO will try to kill us all if a start grabbing the two letter namespace.

Cheryl Langdon-Orr (CLO): agreed Jeff

Susan Payne: quite Alexander!

Cheryl Langdon-Orr (CLO): yep indeed 

Alexander Schubert: Volkswagen!

Alexander Schubert: vw

Cheryl Langdon-Orr (CLO): for the record My personal opinion is almost the opposite Phil, letters and numbers combination 2 characters excepted of course as Jeff is articulating now

Michael Flemming: My personal opinion: Alcoholics Anonymous, American Airlines = AA

Jeff Neuman: Other than the ones reserved by the IETF of course

Paul McGrady: Was there a basis for reseving the others originally?  Can we find it in the history?  If not, no need to keep reserving them.  

Paul McGrady: @ Jeff RE: IETF, sounds good so long as there is a rationale.  Would love to know if the "ICANN names" have any basis.  

Cheryl Langdon-Orr (CLO): agree with the IETF list as they've got rationale to do so

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170727/3d329145/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CC2 Themes - Work Track 2 - Reserved Names.pdf
Type: application/pdf
Size: 98996 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170727/3d329145/CC2Themes-WorkTrack2-ReservedNames-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: string requirements.pdf
Type: application/pdf
Size: 121124 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170727/3d329145/stringrequirements-0001.pdf>
-------------- 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/20170727/3d329145/smime-0001.p7s>


More information about the Gnso-newgtld-wg-wt2 mailing list