Koreangp

Download

koreangp@icann.org

June 2018

2 participants
2 discussions

[lgr] FW: CANN News Alert -- ICANN Board to Hold Four Public Sessions - Including One on IDN Variant TLD Implementation
by Sarmad Hussain June 11, 2018

June 11, 2018

Dear Generation Panel Members, As per the news below, ICANN Board will hold a public session on IDN Variant TLD Implementation Recommendations on 22 June 2018. As a background, the work following the board resolution in 2010 (see under IDN Variant TLD Implementation here <https://www.icann.org/resources/pages/idn-relevant-board-resolutions-2017-1…> ) led to the development of the Integrated Issues Report <https://www.icann.org/resources/pages/idn-relevant-board-resolutions-2017-1…> (IIR) by the community and ICANN org. IIR identified two gaps in implementing IDN variant TLDs: (i) There was no definition of IDN Variant TLDs (ii) There was no management mechanism for IDN Variant TLDs To address the first item, LGR Procedure was developed and was adopted by the ICANN Board in 2013, which has led to the development of RZ-LGR. Now, through the RZ-LGR, there is a clear definition of IDN Variant TLDs. With its availability, the RZ-LGR Study group has been formed to address the technical aspects of using the RZ-LGR for this purpose. However, RZ-LGR only addresses part of the issue, as identified by IIR. To address the second item, ICANN org has also been looking into the challenges of variant management mechanism to implement IDN Variant TLDs based on current IDN (g and cc) TLD procedures. This particular presentation to the ICANN Board focuses on that part of the work. Naturally, defining variant labels is a pre-requisite of managing them. So our focus has remained the RZ-LGR definition. With the RZ-LGR now available and remaining script communities well underway to finalize their LGR proposals, it is a good time to start the conversation about their management mechanism. Regards, Sarmad <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org_&d=DwMFaQ…> [icann.org] News Alert <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_ann…> https://www.icann.org/news/announcement-2018-06-07-en [icann.org] _____ ICANN Board to Hold Four Public Sessions and Board Meeting During Panama Workshop 7 June 2018 LOS ANGELES – 7 June 2018 – The ICANN Board will be holding four public sessions and a public Board meeting during its upcoming workshop in Panama City, Panama, which will be taking place from 22-24 June 2018, ahead of ICANN62. The agenda of the sessions is provided below. Date Time (UTC) Session 22 June 18:15 – 19:15 IDN Variant TLD Implementation Recommendations 23 June 14:00 – 15:00 Public Board Meeting 23 June 18:00 – 18:15 Board FY18 Priorities – Status of Deliverables 23 June 18:15 – 18:45 Long-Term and Short-Term Options for Streamlining the Reviews 23 June 22:00 – 23:00 Internet Governance Strategic Discussion Progress The sessions will be in English only. The format for each will be a listen-only session via Adobe Connect. Adobe Connect Link: https://participate.icann.org/opencommunity/ Participant Code: 5542211258 Additional access numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.myrcplus.com_cnums…> &ppc=5542211258&num=1-605-475-5606 [myrcplus.com] For more information about the Panama workshop and other upcoming ICANN Board meetings, please go to https://www.icann.org/resources/pages/2018-board-meetings [icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> . About ICANN ICANN's mission is to help ensure a stable, secure and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation with a community of participants from all over the world. _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

Fw: Possible OBF question -- I18n
by Yoshiro YONEYA June 7, 2018

June 7, 2018

FYI Threads can be obtained from IETF mail archive. <https://www.ietf.org/mail-archive/web/ietf/current/msg108021.html> Begin forwarded message: Date: Wed, 30 May 2018 15:55:24 -0400 From: John C Klensin <john-ietf(a)jck.com> To: ietf(a)ietf.org Subject: Possible OBF question -- I18n Hi. I want to share a question and possible an idea and see if it gets any traction before Thursday's BOF application cutoff. Many people seem to think that what has come to be called "internationalization" ("i18n") of the Internet is important, both to serving existing users for whom English may not be a comfortable language or Lain script a comfortable writing system and to making the Internet accessible to much larger populations ("the next billion"). Some of the issues are related to identifiers, with examples including IDNA, IRIs, PRECIS, and the recent work on non-ASCII identifiers in certificates. Others are more connected to actual protocol design, such as the SMTPUTF8 work in the EAI WG. Still others are related to content, language selection ins various applications, and so on. I think there is general recognition that the problems are difficult. Human languages have evolved, and evolved differently, over more centuries than anyone can count, making extrapolations from one language or writing system to another difficult and error-prone. Conventions that evolved to permit use of typewriters (with mechanically-limited numbers of keys) with writing systems with more than that many characters haunt contemporary comparison and matching issues. Even changes as recent as the divergence of American from British English, French as spoken and written in France from French as used in Quebec, and efforts to simplify the representations of a few thousand commonly-used Chinese characters can pose serious problems for computer system designers and implementers who just want do do something quick, obvious, and straightforward but still correct (or at least acceptable enough to not be culturally insulting). At the same time, the IETF has a problem with expertise, real energy, and support for internationalization work. The last WGs directly focused on the issues have essentially run out of steam, with a very small number of participants able and willing to do late-stage analysis and reviews. Other WGs whose work has involved important I18n issues have recognized that they don't have the needed expertise and had some trouble recruiting it or, when we are less lucky, have not recognized the problem. The latter poses a special challenge because, if the work is specialized, there may be little or no review of the I18n impact during IETF Last Call unless someone happens to notice, a sitaution that might pose a real threat to interoperability when the protocols are actually used. In addition, pressing problems do show up about which decisions need to be made if the IETF is going to fulfill its responsibilities in this area and, because of concerns about reviews (and probably more), it seems impossible to process work that is necessarily standards track without a WG and impossible to create a WG given the absence of manifestations of broad interest and knowledge and the history, mentioned above, of WGs running out of steam. It also probably doesn't help that several of the acknowledged experts and critically interested parties have little or no reliable support for attending IETF meetings so, if a group is to be judged by counting the number of people in the room for a discussion, it is easy to conclude that there is less interest than might actually exist. Some of us have been waiting for the IESG and/or IAB to sort the situation out and tell us what to do. That hasn't happened, possibly because flying pigs are in short supply but more likely because they understand the problems and don't have any solutions either. The IAB's concluding almost a year ago that its I18n Program was unsustainable and closing it was probably a benchmark, especially when one notices that no substitute has emerged, but, even had that not happened, an IAB Program can't process standards track documents under our current rules (or any rules I see anyone rushing to propose). So I'm wondering whether there is sufficient interest to hold a BOF to discuss how to deal with this situation. I don't want to get into the many substantive issues that have been hanging around, but rather to address the question of how, if there were drafts, what the review and approval process should be in an IETF where there will probably never be a huge number of experts around with time on their hands. Could we devise something Directorate-like or even Area-like? Could that group be counted on for substantive/ technical reviews to the extent to which, even if no other reviews addressed the substantive subject matter and no one on the IESG had special expertise, they could be approved anyway? Should we be reaching out to other groups with general internationalization expertise (not just, or a focus on, character coding) to see if we would work out joint review efforts or even if we could comfortably export the topic? Or have we actually come to the conclusion that the IETF had best stop claiming any responsibility or authority in this area and that we are willing to let whatever emerges fill the vacuum? If this sounds useful and you have anything to contribute, especially procedural or "where do we find the experts" advice, please speak up within the next 24-48 hours. IMO, if we should give give up, I think it would be better to do that as the result of a formal discussion than as a decision of a handful of people meeting more or less in private and without an explicit opportunity for community input. john p.s. before someone asks, I'm thinking actual BOF because don't think there is any point in this unless it has someone from the IESG willing to take at least some responsibility, produces minutes, has meetecho coverage, etc. I don't think dancing around with Bar BOFs, non-bar Bar BOFs, informal meetings, etc., meet those criteria. I don't thing a presentation in an area meeting or two would do it either -- we've tried that with no success and, more important, I'm seeing an increasing number of WGs being created with i18n implications or necessary involvement that are not in the ART area.

2 4