Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

for other places see: http://tinyurl.com/z2hgdgr

PROPOSED AGENDA: 

  1.  Review agenda
  2. Roll Call/SoIs
  3. Discussion on response to Dr. Crocker (Draft letter to be distributed by Steve Coates)
  4. Discussion regarding principles from 2007 Final Report (excerpt attached)
  5. Discussion on Subject 1: Should there in fact be new gTLDs?
  6. Discussion on Subject 2 (Time Permitting): TLD Types/Differentiation 
  7. AOB

 

Mp3

Transcript

AC Chat

Attendance

Apologies:  Richard Padilla (joining late), Amr Elsadr, Susan Payne

On audio only: none

Notes/Action items:

Principles:

 

1.  Decisionmaking: 

-- Document in the notes actions to be taken at a next meeting (noting that a first reading is normally the result of discussion so may note be documentable ahead of time)

-- Keep a decision log on all decisions that have been made and the results.

 

A. New generic gTLDs must be introduced in an orderly, timely, and predictable way.  Action: Will be addressed later as an overarching principle.

 

B. Some new generic TLDs should be IDNs subject to the approval of IDNs being available in the root.  Action: (Alan Greenberg) Not sure this is needed anymore as it is moot.  (Vanda Scartezini) or could just state that TLDs can be in both ASCII and IDN formats. (agreed)

 

C. The reasons for introducing new TLDs include that there is demand from potential applicants for new TLDs in ASCII and IDN formats.  In addition the introduction of new TLD application process has the potential to promote competition in the provision of registry services, to add to consumer choice, market differentiation and geographical and service-provider diversity.  Action: Park until we get feedback on the overall issues.  Possible suggested new wording (Robert Burlingame (Pillsbury): "For C, perhaps "One of the reasons for introducing new top-level domains is that there is demand from potential applicants for new top-level domains in both ASCII and IDN formats.  Furthermore, the introduction of new top-level domains has the potential to promote:  competition in the provision of registry services; consumer choice; market differentiation; and geographical and service-provider diversity."

 

D. A set of technical criteria must be used for assessing a new TLD registry applicant to minimzie the risk of harming the operational stability, security, and globak interoperability of the Internet.  Action: Make sure that the principles sync with the new Bylaws.

 

E. A set of capability criteria for a new gTLD registry applican must be used to provide an assurance that an applicant has the capability to meet its obligations under the terms of ICANN's registry agreement.  Action: ( (Jeff Neuman) Clarify that the capability criteria are operational and financial?  (Alan Greenberg) Leave as is for now, recognizing that we'll probably need to add sub-paragraphs to provide additional detail.

 

F.  A set of operational criteria must be set out in contractual conditions in the registry agreement to ensure compliance with ICANN poicies.  Action: None.  Still applies.

 

G. The string evaluation process must not infringe on the applicant's freedom of expression rights that are protected under internationally recognized principles of law.  Notes: (Ayden Ferdeline) Why only the "applicant's" freedom of expression?  (Carlton Samuels) Say more about the string evaluation process?  (Greg Shatan) Put this into the recommendations, rather than principles?  Kavouss: Change the "protected" to "provided";in front of "internationally recognized" or (Steve Coates): "that are recognized under international principles of law." (Robin Gross) Objection to moving from principles to recommendations.

 

(Jeff Neuman) Question: Should be there be a way or method in the recommendations to add things that are based on new circumstances or not anticipated? (Steve Coates) Consider implications to "rolling procedures."

 

Recommendations:

 

1.  Steve Coates (Twitter): Agree with Greg.  Recommendation 1 should not be negotiatiable.  

 

Robert Burlingame (Pillsbury): I agree that "should" would be better than "must" in the Recommendations. 

Kurt Pritz: It is ok that a recommendation include the word "must." "Recommendation" means Policy Recommendations that were later approved by the ICANN Board.

 

Jeff Neuman: In addition to high-level principles there were things we wanted to be sure were included ("must").

 

Alan Greenberg & Greg Shatan: They may start as recommendations, but once approved by the Board they are policy.  (Greg Shatan) The taxonomy may be out of date/pre-go-live set up.  (Jeff Neuman) Should we list these as policies?  (Kavouss Arasteh) If you change to "policy" that may solve a lot of issues.  Be very careful not to use "must" if we don't mean "must" -- minimize the use of must.  (Kurt Pritz) Use "must" and "shall" in the definition adopted by ICANN (https://www.ietf.org/rfc/rfc2119.txt).

 

2.  Jeff Neuman: On this one there may be inherent questions -- what does "Reserve" mean?  There was a subgroup in 2006-7 that worked on this definition, "what is a Reserved Name?"   "Strings" here point to top-level domains.  Move forward subject to definiting the terms? 

3. Jeff Neuman: This was used to create some of the objection criteria for the 2012 round.  This will be discussed in one of the tracks, although not necessarily a rights-protection mechanism since this refers to strings at the top level.  Robin Gross: Freedom of Expression concerns were left out of the implemention of Recommendation 3 (which only focused on trademark protection).@Rob 

4.  Jeff Neuman: Would think this is non-contentious.  Alan Greenberg: Change the nomenclature to "concepts" and then if there should be a taxonomy work through it later.

5.  Jeff Neuman: Define "Reserved Word" and provide more context, as suggested by Kavouss. 

6.   Jeff Neuman: The group that deals with this work track should look at how this was defined.  Work with it initially as a concept. 

7.  Jeff Neuman: I am not sure the evaluation looked at the purpose that the applicant set out, just whether a registry could run as a registry.  We will probably come back to this.  Alan Greenberg: I am not sure it makes any sense.  Steve Coates: Agree on the language of "purpose" tied to "technical".  Kavouss Arasteh: How is this demonstration made?  Rubens Kuhl: Currently they demonstrate passing a pre-delegation test: https://newgtlds.icann.org/en/applicants/pdt.   Jeff Neuman: Not done during the application process.   May need to consider if we decide to accredit registry providers whether we do think a demonstration needs to be approved, in track 1 (process) track 5 (technical criteria/demonstration). 

8. Jeff Neuman: Never asked to demonstrate financial capabilities, but ICANN received statements and financial information.  Rubens Kuhl: Only looked an financial with the angle of a commercial registry.  We might choose to let financial be only a due diligence requirement for contract signing but not an application evaluation criteria.   Jeff Neuman:  Look at that in the relevant track. 

9.   Jeff Neuman:  Look at the ICANN Implementation Report, but for this one gets some comments in from the actual evaluators.   Robin Gross: Do better on recommendation 9.  Too much was changed after the fact and it wasn't fair.  Rudi Vansnick: Agreed.  Kavouss Arasteh: To whom is this addressed?  What is the relation to "objective and measurable criteria" and "pre-published application process?  Reword or say what we mean.  Jeff Neuman: Agree that we can word this better that there should be criteria set out in advance so applicants know how they will be measured.  Alan Greenberg: There may well be things that are non-objective but we should try to put in these that are non-discriminatory.  Kavouss: Are we asking ICANN to do this?  Rubens Kuhl: Add "non-discriminatory"  Jeff: That is a good addition.  Or except as otherwise set forth here?  Greg Shatan: Or "Where possible"?

10. Jeff: This is one where there have been comments that there should be different base contracts?  But the concept is that the applicant should know what contractual terms would apply to them.  Reword that there is not only one base contract?  We should talk about base contract(s) -- track 2 -- whether there should be a process to institute changes before a contract is signed.  Steve Coates: Could use improvement with additoinal clauses, and application of new clauses. 

11.  Replaced with 20.

12. Jeff: We need to build in some what to have changes.  Applicants need to know what dispute processes might be used against them.  Robin Gross: GAC objections impact recommendation 12, not understanding what a government might object to.

  

5.  (Kavouss) May need to define what we mean by a "Reserved Word" particularly for people who aren't familiar with the final report.


Reference Documents:

Principles and Recommendations Excerpt

...