Page History
...
Info |
---|
PROPOSED AGENDA Agenda Background Documents |
Info | ||
---|---|---|
| ||
TranscriptionWebEx Chat |
Tip | ||
---|---|---|
| ||
Dial outs: Kavouss Arasteh, Cheryl Langdon-Orr, Maureen Hilyard, Juan Manuel Rojas, Bram Fudzulani, Dessalegn Yehuala, Sala Tamanikaiwaimaro AttendanceApologies: Jonathan Agmon, Sanna Sahlman, Taylor Bentley, Liz Williams, Jorge CancioTentative apology/Joining late: Marita Moll, Greg Shatan, Kris Seeburn, Elsa Saade, Juan Manuel Rojas, Demi Getschko, Barrack Otieno, Bruna Martins dos Santos, Cristina Monti, Timothy Asiedu, Dave Kissoondoyal, Aslam Mohamed, Timothy Asiedu, Carlos Dionisio Aguirre, Thongchai Sangsiri |
Note |
---|
Notes/ Action Items Action Items: Include the input from the notes and chat in the spreadsheet and review for the next meeting. Notes: 1. SOI Updates: No updates. 2. Update from ICANN61 / Where we are now: Slide 4: Update from ICANN61: -- WT5 held a public session at ICANN61 -- Provided a brief background and summary of progress -- Presented the timeline the group is working towards to deliver an Initial Report in July -- Discussed future treatment of geographic terms contained within the 2012 Applicant Guidebook (AGB). -- Slides, transcript and video stream can be accessed via the ICANN61 Meeting Schedule page - https://61.schedule.icann.org/meetings/647704 -- Feedback from the session has been incorporated into the working document for the Work Track: - https://docs.google.com/spreadsheets/d/1FuPEq0y-cdSUQ1nvhWKhVnG8PLaC2RYXsCpQu91FDqo/edit#gid=358523414 -- Some members raised concerns about the format of the spreadsheet used to track deliberations. Suggestions for alternatives are welcome. Slide 5: Work Track 5 Work Plan: -- March-April: Begin Discussing Future Treatment of Terms in 2012 Applicant Guidebook. -- May: Discuss Future Treatment of Terms Not Included in 2012 Applicant Guidebook. -- June: Draft initial report. -- July: Publish Initial Report -- Not an end point, but a required step in the PDP to publish in the public forum. Initial focus is to reach this initial report stage in July. Slide 6: Where are we now? Drawing on the conversation during the ICANN61 session, the Work Track co-leaders submit the following proposals for consideration: -- 2-character country codes (ISO 3166): Maintain the status quo, reserving all 2 letter-letter ASCII combinations for existing and future country codes. -- 3-character country codes (ISO 3166): Maintain the status quo, i.e. not available, and defer broader questions about which entity/entities can apply for these strings and how they may be treated (for instance, as a gTLD, a ccTLD or something else). -- Long and short form of country and territory names (ISO 3166): Maintain the status quo, i.e. not available, and defer broader questions about which entity/entities can apply for these strings and how they may be treated (for instance, as a gTLD, a ccTLD or something else). Discussion: -- Gathering all input in a spreadsheet, but could consider converting it into a Word document. -- Separate item: The letter-number combination is not a geographic name and will be taken by Work Track 2; the actual two-character country codes would be reserved (letter-letter country code). -- The discussion centered on the point that a letter-number combination would not be referring to a geographic term so it would be out of scope of this Work Track. It would be considered by Work Track 2. -- When we defined the scope of Work Track 5 we explicitly included 3-character country codes, so how can we pass this on – what do we mean by “defer broader questions about which entity/entities can apply”? At ICANN61 whereby it was thought that this should sit outside of gTLD-land (outside of GNSO). That is where we find difficulties in routing anything further. We said we would not look at anything that is outside of the scope for the GNSO. Comments were to keep these as unavailable and to defer broader questions outside the GNSO scope. Important to note that even if some countries did not want this as a gTLD, and it is not a ccTLD, and Work Track 5 can only look at what is a gTLD or not. So the only solution is either we give support or non-objection, it would still be a gTLD, which would not be satisfactory for the participants who commented at ICANN61. 3. Geographic terms from the AGB (continued): Slide 8: Review of Existing Country and Territory Names: As a reminder, in the 2012 Application Guidebook, the following country and territory names were not available (see section 2.2.1.4.1):
Slide 9: Future Treatment – Country and Territory Names: We are now discussing future treatment of the following country and territory names:
Discussion: -- What do we mean by “name of the country” – do we mean in English? Answer: There are some language aspects included in the terms. Bullet 2 – “is a translation of a name appearing on the list...” Check in the AGB to see which items have a translation? ISO 3166 names it comes in two forms – English translation or French translation of the names. That is the language being used. Often they are actually transliterated. For the permutations language isn’t mentioned. What has been discussed is the possibility of having all languages. -- When we’ve talked about permutations: it is strangely written – transposition doesn’t apply to 3-letter codes, but doesn’t mention permutations. Perhaps still consider whether to have the permutations unavailable, or to have an objection process. There were a number of conversations in the spreadsheet on the relevance on the reserved status. -- Shortcomings on translations or specific terms should be covered on the spreadsheet in those items that are not covered in the applicant guidebook. -- On the last bullet – “name by which a country is commonly known...” ADD: “in any language”. But, how would we manage that? It could not be a definitive list. Start with any official language in the country or geography concerned by the relevant string. Depending on requests for expanding, you could go to UN languages, but this might be too little. Not fair to say all strings to be treated fairly in all languages. Where the AGB is not explicit we should take that over to the list of what isn’t in the guidebook. If we are saying these are reserved then it would be ideal to have a definitive list, but that may not be possible. “In any language” could be tens of thousands of strings reserved. Need to compile a rough list of what this could look like. A start could be recognizing the official language in the jurisdiction of the string concerned. Should we say, “all scripts” instead of “all languages”? Noting this for the list of what is not considered in the AGB. Re: it is the short- or long-form name association with a code that has been designated as “exceptionally reserved” by the ISO 3166 Maintenance Agency. (example: .eu) – does it fit into the same way forward? -- “Exceptionally reserved” there are no definitions of this in the standard. Probably shouldn’t include in a new version of the AGB. The whole standard is in a review period and it might be that the whole notion of reserved names will change. If you are doing a new AGB consider taking this whole notion of reserved and exceptionally reserved out of the AGB. Using undefined terms is not a good idea. -- Just accept the international standard as it is, but without including the notion of reserved and exceptionally reserved. But there are many geographicals that are not included in ISO 3166 at all. Bias toward a certain category of subdivisions and ignoring others. But, there could be other terms that protect, or they have an objection process. 4. Next Meeting: Wednesday, 18 April at 20:00 UTC. |