Re: [Idngwg] Summary of IDNGWG meeting on 14 September 2017
Dear colleagues, Please find below the propose changes to guidelines 12 and 13 (a and b). To do this, I reviewed RFCs 3743 and 4290 to find the common language with RFC 7940. My action item was to draft a guideline or guidelines that could use common terminology so that it could be understood by users of all RFCs. Here is a summary of the terms used by the RFCs. RFC 3743, 4290 RFC 7940 Activation, Registration (used interchangeably) Activated Reserved label (in a bundle) Allocatable (as in for potential registration) Block (from registration) Block (from registration) It was difficult for me to use the words “disposition” and “allocatable” since they are very RFC7940 specific. So my approach was to start from a clean slate and come up with a guideline that addresses the following questions, which I believe are the objective of the guidelines on variant management: Who offers variant management? – the registry, defined by registry policy and idn tables. What determine the variant labels? – registry policy and idn tables. Who can activate a variant? – registrar at registrant’s request, or registry per local policy. What triggers activation of a variant? – registrant’s request, or registry policy. What type of variant is allowed to be activated? – per registry policy. Proposed guideline to replace 12, 13(a) and 13(b): TLD Registries may activate an IDN Variant Label, provided that i) such IDN Variant Label is requested by the same registrant or corresponding registrar as the Primary IDN Label, ii) such IDN Variant Label is registered to the registrant of the Primary IDN Label, and iii) such IDN Variant Label conforms with the registry policy. In exceptional cases, where a language and/or script have established conventions, a TLD Registry may automatically activate an IDN Variant Label at its discretion. In such cases, the TLD Registry must ensure that only the necessary IDN Variant Labels are automatically activated and the number of such labels remains as small as possible. Also, we should consider thinking about the implication with the restriction on variant activation required by many RAs. -Dennis From: <idngwg-bounces@icann.org> on behalf of Pitinan Kooarmornpatana <pitinan.koo@icann.org> Date: Wednesday, September 20, 2017 at 11:30 AM To: "idngwg@icann.org" <idngwg@icann.org> Subject: [EXTERNAL] Re: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear IDNGWG members, Please use this revised version of the summary as attached. Regards, Pitinan From: idngwg-bounces@icann.org [mailto:idngwg-bounces@icann.org] On Behalf Of Pitinan Kooarmornpatana Sent: Wednesday, September 20, 2017 8:15 PM To: idngwg@icann.org Subject: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear IDNGWG members, Please find attached the summary of the meeting of the IDNGWG held on 14 September 2017. Please let us know if you would like to suggest any edits or additions. Action Items S. No. Action Items Owner 1 Rephrase the 13(a) and (b) as discussed by the WG DT 2 Create the Implementation Notes Section in the document and move the text as discussed by WG PK The recording and this summary are also posted at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_IDN_IDN-2BImplementation-2BGuidelines&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=qAs-z5lsx1qg4ORlIggZJ8rKxoygReIR_xCeVaO37qo&m=aY1-dHxlABaLKNIJ2pNIlUESTXjTUFNREkhX7hp477w&s=tNlN7HnP7aFuSosGOfjXSkPM_n1uxI8GIZMLvbMRVr0&e=> Regards, Pitinan
Based on today’s input, this is a slightly revised version of the proposed guideline TLD Registries may activate an IDN Variant Label, provided that i) such IDN Variant Label is requested by the same registrant or corresponding registrar as the Primary IDN Label, ii) such IDN Variant Label is registered to the registrant of the Primary IDN Label, and iii) such IDN Variant Label conforms with the registry policy and IDN Tables. In exceptional cases, where a language and/or script have established conventions, a TLD Registry may automatically activate an IDN Variant Label at its discretion. In such cases, the TLD Registry must ensure that only the necessary IDN Variant Labels are automatically activated and the number of such labels remains as small as possible. -Dennis From: <idngwg-bounces@icann.org> on behalf of "idngwg@icann.org" <idngwg@icann.org> Reply-To: Dennis Tan Tanaka <dtantanaka@verisign.com> Date: Wednesday, September 20, 2017 at 5:08 PM To: Pitinan Kooarmornpatana <pitinan.koo@icann.org>, "idngwg@icann.org" <idngwg@icann.org> Subject: [EXTERNAL] Re: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear colleagues, Please find below the propose changes to guidelines 12 and 13 (a and b). To do this, I reviewed RFCs 3743 and 4290 to find the common language with RFC 7940. My action item was to draft a guideline or guidelines that could use common terminology so that it could be understood by users of all RFCs. Here is a summary of the terms used by the RFCs. RFC 3743, 4290 RFC 7940 Activation, Registration (used interchangeably) Activated Reserved label (in a bundle) Allocatable (as in for potential registration) Block (from registration) Block (from registration) It was difficult for me to use the words “disposition” and “allocatable” since they are very RFC7940 specific. So my approach was to start from a clean slate and come up with a guideline that addresses the following questions, which I believe are the objective of the guidelines on variant management: Who offers variant management? – the registry, defined by registry policy and idn tables. What determine the variant labels? – registry policy and idn tables. Who can activate a variant? – registrar at registrant’s request, or registry per local policy. What triggers activation of a variant? – registrant’s request, or registry policy. What type of variant is allowed to be activated? – per registry policy. Proposed guideline to replace 12, 13(a) and 13(b): TLD Registries may activate an IDN Variant Label, provided that i) such IDN Variant Label is requested by the same registrant or corresponding registrar as the Primary IDN Label, ii) such IDN Variant Label is registered to the registrant of the Primary IDN Label, and iii) such IDN Variant Label conforms with the registry policy. In exceptional cases, where a language and/or script have established conventions, a TLD Registry may automatically activate an IDN Variant Label at its discretion. In such cases, the TLD Registry must ensure that only the necessary IDN Variant Labels are automatically activated and the number of such labels remains as small as possible. Also, we should consider thinking about the implication with the restriction on variant activation required by many RAs. -Dennis From: <idngwg-bounces@icann.org> on behalf of Pitinan Kooarmornpatana <pitinan.koo@icann.org> Date: Wednesday, September 20, 2017 at 11:30 AM To: "idngwg@icann.org" <idngwg@icann.org> Subject: [EXTERNAL] Re: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear IDNGWG members, Please use this revised version of the summary as attached. Regards, Pitinan From: idngwg-bounces@icann.org [mailto:idngwg-bounces@icann.org] On Behalf Of Pitinan Kooarmornpatana Sent: Wednesday, September 20, 2017 8:15 PM To: idngwg@icann.org Subject: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear IDNGWG members, Please find attached the summary of the meeting of the IDNGWG held on 14 September 2017. Please let us know if you would like to suggest any edits or additions. Action Items S. No. Action Items Owner 1 Rephrase the 13(a) and (b) as discussed by the WG DT 2 Create the Implementation Notes Section in the document and move the text as discussed by WG PK The recording and this summary are also posted at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_IDN_IDN-2BImplementation-2BGuidelines&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=qAs-z5lsx1qg4ORlIggZJ8rKxoygReIR_xCeVaO37qo&m=aY1-dHxlABaLKNIJ2pNIlUESTXjTUFNREkhX7hp477w&s=tNlN7HnP7aFuSosGOfjXSkPM_n1uxI8GIZMLvbMRVr0&e=> Regards, Pitinan
Thanks Dennis. This change is noted and reflected in the new version of the document. Regards, Sarmad From: idngwg-bounces@icann.org [mailto:idngwg-bounces@icann.org] On Behalf Of Tan Tanaka, Dennis via Idngwg Sent: Thursday, September 21, 2017 9:13 PM To: Pitinan Kooarmornpatana <pitinan.koo@icann.org>; idngwg@icann.org Subject: Re: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Based on today’s input, this is a slightly revised version of the proposed guideline TLD Registries may activate an IDN Variant Label, provided that i) such IDN Variant Label is requested by the same registrant or corresponding registrar as the Primary IDN Label, ii) such IDN Variant Label is registered to the registrant of the Primary IDN Label, and iii) such IDN Variant Label conforms with the registry policy and IDN Tables. In exceptional cases, where a language and/or script have established conventions, a TLD Registry may automatically activate an IDN Variant Label at its discretion. In such cases, the TLD Registry must ensure that only the necessary IDN Variant Labels are automatically activated and the number of such labels remains as small as possible. -Dennis From: <idngwg-bounces@icann.org<mailto:idngwg-bounces@icann.org>> on behalf of "idngwg@icann.org<mailto:idngwg@icann.org>" <idngwg@icann.org<mailto:idngwg@icann.org>> Reply-To: Dennis Tan Tanaka <dtantanaka@verisign.com<mailto:dtantanaka@verisign.com>> Date: Wednesday, September 20, 2017 at 5:08 PM To: Pitinan Kooarmornpatana <pitinan.koo@icann.org<mailto:pitinan.koo@icann.org>>, "idngwg@icann.org<mailto:idngwg@icann.org>" <idngwg@icann.org<mailto:idngwg@icann.org>> Subject: [EXTERNAL] Re: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear colleagues, Please find below the propose changes to guidelines 12 and 13 (a and b). To do this, I reviewed RFCs 3743 and 4290 to find the common language with RFC 7940. My action item was to draft a guideline or guidelines that could use common terminology so that it could be understood by users of all RFCs. Here is a summary of the terms used by the RFCs. RFC 3743, 4290 RFC 7940 Activation, Registration (used interchangeably) Activated Reserved label (in a bundle) Allocatable (as in for potential registration) Block (from registration) Block (from registration) It was difficult for me to use the words “disposition” and “allocatable” since they are very RFC7940 specific. So my approach was to start from a clean slate and come up with a guideline that addresses the following questions, which I believe are the objective of the guidelines on variant management: Who offers variant management? – the registry, defined by registry policy and idn tables. What determine the variant labels? – registry policy and idn tables. Who can activate a variant? – registrar at registrant’s request, or registry per local policy. What triggers activation of a variant? – registrant’s request, or registry policy. What type of variant is allowed to be activated? – per registry policy. Proposed guideline to replace 12, 13(a) and 13(b): TLD Registries may activate an IDN Variant Label, provided that i) such IDN Variant Label is requested by the same registrant or corresponding registrar as the Primary IDN Label, ii) such IDN Variant Label is registered to the registrant of the Primary IDN Label, and iii) such IDN Variant Label conforms with the registry policy. In exceptional cases, where a language and/or script have established conventions, a TLD Registry may automatically activate an IDN Variant Label at its discretion. In such cases, the TLD Registry must ensure that only the necessary IDN Variant Labels are automatically activated and the number of such labels remains as small as possible. Also, we should consider thinking about the implication with the restriction on variant activation required by many RAs. -Dennis From: <idngwg-bounces@icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Pitinan Kooarmornpatana <pitinan.koo@icann.org<mailto:pitinan.koo@icann.org>> Date: Wednesday, September 20, 2017 at 11:30 AM To: "idngwg@icann.org<mailto:idngwg@icann.org>" <idngwg@icann.org<mailto:idngwg@icann.org>> Subject: [EXTERNAL] Re: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear IDNGWG members, Please use this revised version of the summary as attached. Regards, Pitinan From: idngwg-bounces@icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Pitinan Kooarmornpatana Sent: Wednesday, September 20, 2017 8:15 PM To: idngwg@icann.org<mailto:idngwg@icann.org> Subject: [Idngwg] Summary of IDNGWG meeting on 14 September 2017 Dear IDNGWG members, Please find attached the summary of the meeting of the IDNGWG held on 14 September 2017. Please let us know if you would like to suggest any edits or additions. Action Items S. No. Action Items Owner 1 Rephrase the 13(a) and (b) as discussed by the WG DT 2 Create the Implementation Notes Section in the document and move the text as discussed by WG PK The recording and this summary are also posted at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_IDN_IDN-2BImplementation-2BGuidelines&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=qAs-z5lsx1qg4ORlIggZJ8rKxoygReIR_xCeVaO37qo&m=aY1-dHxlABaLKNIJ2pNIlUESTXjTUFNREkhX7hp477w&s=tNlN7HnP7aFuSosGOfjXSkPM_n1uxI8GIZMLvbMRVr0&e=> Regards, Pitinan
participants (2)
-
Sarmad Hussain -
Tan Tanaka, Dennis