| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Link to Charter Questions: https://docs.google.com/document/d/1-f9Ml-z9LcxVs9WuX53kIkp29j0JLh6d/edit | ||||||||||||||||||||||||||||||
2 | Corresponding Charter Question | Notes | SubPro (exisiting TLDs might not be affected by these recommendations) | IDN Variant TLD Management Staff Paper | RZ-LGR Technical Utilization (TSG) | SAC052 | SAC060 | ||||||||||||||||||||||||
3 | None | No Charter Question is needed | Affirmation with Modification 25.1: With the change in italicized text, the Working Group affirms Principle B from the 2007 policy: “Internationalised domain name (IDNs) new generic top-level domains should continue to be an integral part of the New gTLD Program.” Principle B originally stated, “Some new generic top-level domains should be internationalised domain names (IDNs) subject to the approval of IDNs being available in the root.” | ||||||||||||||||||||||||||||
4 | Section A. Consistent definition and technical utilization of RZ-LGR a1 | No material inconsistency among the SubPro Rec 25.2, SubPro IG 26.10, Staff Paper Rec 1, and TSG Recs 1 and Rec 2, although TSG Rec 2 provides more detailed recommendation in the implementation perspective. GAP: Question in the staff paper may need to be addressed, especially for the current/exisiting TLDs. Future TLDs should be in compliance with RZ-LGR, and the SubPro IRT may cover the staff paper question for future TLDs. | Recommendation 25.2: Compliance with Root Zone Label Generation Rules (RZ-LGR, RZ-LGR-2, and any future RZ-LGR rules sets) must be required for the generation of TLDs and variants labels, including the determination of whether the label is blocked or allocatable. IDN TLDs must comply with IDNA2008 (RFCs 5890-5895) or its successor(s). To the extent possible, and consistent with Implementation Guidance 26.10, algorithmic checking of TLDs should be utilized. == Implementation Guidance 26.10: The application submission system should do all feasible algorithmic checking of TLDs, including against RZ-LGRs and ASCII string requirements, to better ensure that only valid ASCII and IDN TLDs can be submitted. A proposed TLD might be algorithmically found to be valid, algorithmically found to be invalid, or verifying its validity may not be possible using algorithmic checking. Only in the latter case, when a proposed TLD doesn’t fit all the conditions for automatic checking, a manual review should occur to validate or invalidate the TLD. | Recommendation 1. Root Zone Label Generation Rules (RZ-LGR) the only source for valid TLDs and their variant labels. All TLDs and their variant labels must be defined by the RZ-LGR. All TLDs and their variant labels must be defined by the RZ-LGR. TLDs and their variant labels in the scripts not integrated in the RZ-LGR are undefined and, therefore, cannot be applied for or allocated. Any script that has no variant labels under the RZ-LGR has, by definition, no variants under this recommendation. == [Question for GNSO's Consideration] Question 1: Update policies and procedures to ensure that the definition of variant TLDs depends exclusively on the RZ-LGR. | Recommendation 1. All TLD labels, IDN and ASCII labels, must be processed using the RZ-LGR. Lowercase alphabetic ASCII labels are, as a practical matter, a subset of the Latin script labels defined by RZ-LGR; therefore, these ASCII Labels must be subject to RZ-LGR processing to determine their cross-script variant labels, e.g. with Armenian, Cyrillic, Greek, and other applicable scripts. Consequently, GNSO and ccNSO should incorporate the use of RZ-LGR into their TLD application processes accordingly and in a consistent manner. == Recommendation 2. For the scripts and writing systems which have been integrated into the RZ-LGR, the RZ-LGR must be the only source for processing the following cases: 2.1. Validate an applied-for TLD label and determine its variant labels with corresponding dispositions 2.2. Calculate variant labels, and corresponding disposition values, for each one of the already allocated or delegated TLD labels 2.3. Calculate variant labels, and corresponding disposition values, for each one of the reserved TLD labels | ||||||||||||||||||||||||||
5 | Section A. Consistent definition and technical utilization of RZ-LGR a4 | There is inconsistency between SubPro IG 25.3 and TSG Rec 5. TSG Rec 5 recommends putting such applications "on hold", whereas SubPro IG 25.3 recommends processing such application up to but not including contracting. The exact timing of when to put an application on hold is different. | Implementation Guidance 25.3: If a script is not yet integrated into the RZ-LGR, applicants should be able to apply for a string in that script, and it should be processed up to but not including contracting. Applicants under such circumstances should be warned of the possibility that the applied-for string may never be delegated and they will be responsible for any additional evaluation costs. | Recommendation 5. For an applied-for TLD label whose script is not yet supported by the applicable version of the RZ-LGR, the application should not proceed until the relevant script is integrated into the RZ-LGR. It is implied that the application should remain on-hold (or other appropriate status) until the relevant script is integrated into the RZ-LGR. This approach will ensure that any applied-for TLD label and its applicable variants, if any, are algorithmically validated using the RZ-LGR. | |||||||||||||||||||||||||||
6 | Section A. Consistent definition and technical utilization of RZ-LGR a7 | No material inconsistency between SubPro Rec 25.4 and SAC052 Rec 1, although SubPro Rec 25.4 provides more details. GAP: However, possibly due to the lack of relevant expertise, SubPro did not make a specific recommendation to cover this aspect of the TSG's Appendix B: "In the event that certain range of code points or entire scripts are permitted to be used for single character TLD applications based on certain criteria, it may be useful that those code points are appropriately tagged by the relevant Generation Panel in the RZ-LGR for a consistent analysis and to ease their identification and algorithmic calculation." In its rationale of Rec 25.4, SubPro agrees that it is appropriate to limit single-character gTLDs to only certain scripts and languages and welcomes the identification of the limited set of scripts and languages and potentially a specific list of allowable single-character gTLDs (e.g., during implementation). | Recommendation 25.4: Single character gTLDs may be allowed for limited script/language combinations where a character is an ideograph (or ideogram) and do not introduce confusion risks that rise above commonplace similarities, consistent with SSAC and Joint ccNSO-GNSO IDN Workgroup (JIG) reports. | [Not a formal recommendation] Appendix B: Note on Single Character TLDs Historically, single character TLDs have not been allowed due to their confusability potential. The SG advises GNSO and ccNSO to review SSAC’s SAC052 on the delegation of single character IDN TLDs. In the event that certain range of code points or entire scripts are permitted to be used for single character TLD applications based on certain criteria, it may be useful that those code points are appropriately tagged by the relevant Generation Panel in the RZ-LGR for a consistent analysis and to ease their identification and algorithmic calculation. | Recommendation 1: Given the potential for user confusion and the currently unfinished work on string similarity and IDN variants, the SSAC recommends a very conservative approach to the delegation of single-character IDN top-level domains. | ||||||||||||||||||||||||||
7 | Section B. "Same entity" at the top-level b1, b2, b4 | No material inconsistency between the SubPro Rec 25.5 and Staff Paper Recs 2 and 7. In the rationale of Rec 25.5, SubPro agrees that "variant TLDs must be operated by the same registry operator". This is consistent with the rationale for Staff Paper Recs 2 and 7. | Recommendation 25.5: IDN gTLDs identified as variant TLDs of already existing or applied for gTLDs will be allowed only if labels are allocated to the same entity and, when delegated, only if they have the same back-end registry service provider. This policy must be captured in relevant Registry Agreements. | Recommendation 2. IDN variant TLDs {t1, t1v1, …} allocated to the same entity. For IDN variant TLDs that arise from an application and the RZ-LGR, all allocatable IDN variant TLD labels in the set must be allocated to the same entity or withheld for possible allocation only to that entity. In other words, for a top-level label t1 allocated to Entity X, its allocatable variant label t1v1 must only be allocated to Entity X or else withheld for possible allocation only to Entity X. == Recommendation 7. Same registry service provider for IDN variant TLDs. For feasible and consistent implementation of these requirements, the same back-end registry service provider, if applicable, must be employed for operating all the activated IDN variant TLDs by the registry operator. | |||||||||||||||||||||||||||
8 | Section C. "Same entity" at the second-level c1, c3 | No material inconsistency between SubPro Rec 25.6 and Staff Paper Rec 3. GAP: Questions in the Staff Paper may need to be addressed. | Recommendation 25.6: A given second-level label under any allocated variant TLD must only be allocated to the same entity/registrant, or else withheld for possible allocation only to that entity (e.g., s1 under {t1, t1v1, …}, e.g., s1.t1 and s1.t1v1). | Recommendation 3. Same second level label under IDN variant TLDs s1.{t1, t1v1, …} registered to the same entity. For each allocated IDN variant TLD, a given second level label beneath the TLD must only be allocated to the same entity/registrant, or else withheld for possible allocation only to that entity. In other words, s1 under {t1, t1v1, …}, e.g., s1.t1 and s1.t1v1, must be allocated to Entity Y or else withheld for possible allocation only to Entity Y. == [Questions for GNSO's Consideration] Question 2: Update policies and procedures to incorporate the “same entity” rule for a given label beneath two variant TLDs. Question 3: Update policies and procedures to use ROID for the definition of “same entity”. In case ROID is not an option finalized, then define an alternate functional definition for “same entity”. | |||||||||||||||||||||||||||
9 | Section C. "Same entity" at the second-level c2 | No material inconsistency between SubPro Rec 25.7 and Staff Paper Rec 4; the point "same entity at the second-level = registrant" is included in the rationale of both recommendation. GAP: It seems to be missing the case of second-level variants under a singleton TLD. For completeness, this group should be added for consideration as a charter question. | Recommendation 25.7: For second-level variant labels that arise from a registration based on a second-level IDN table, all allocatable variant labels in the set must only be allocated to the same entity or withheld for possible allocation only to that entity (e.g., all allocatable second-level labels {s1, s1v1, …} under all allocated variant TLD labels {t1, t1v1, …}). | Recommendation 4. Second-level variant labels under IDN variant TLDs {s1, s1v1, …}.{t1, t1v1, …} registered to the same entity. According to the IDN Implementation Guidelines, for second-level IDN variant labels that arise from a registration based on a second-level IDN table, all allocatable IDN variant labels in the set must only be allocated to the same entity or withheld for possible allocation only to that entity. This implies that all allocatable second-level labels {s1, s1v1, …} under all allocated variant TLD labels {t1, t1v1, …} must be allocated to Entity Z or else withheld for possible allocation only to Entity Z. == [Question for GNSO's Consideration] Question 3: Update policies and procedures to use ROID for the definition of “same entity”. In case ROID is not an option finalized, then define an alternate functional definition for “same entity”. | |||||||||||||||||||||||||||
10 | Section C. "Same entity" at the second-level c4, c5, c6 | GAP | No corresponding SubPro recommendation | Recommendation 5. Second-level IDN tables offered under IDN variant TLDs harmonized. Second-level IDN tables applicable for an IDN variant TLD set must be mutually coherent but not necessarily identical. For two second-level variant labels s1 and s1v1 under any TLD t1 generated using the applicable IDN table for t1, these must also be variant labels under TLD t1v1 if generated by the applicable IDN table for t1v1. This also implies that the complete set of second-level variant labels may not all be valid under all variant TLDs. For example, for the second level label s1v2, the domain name s1v2.t1 may be valid, but due to difference in IDN tables for variant TLDs, s1v2.t1v1 may not be valid. == [Question for GNSO's Consideration] Question 13: Update policies and procedures for filing IDN tables using the LGR format specified in RFC 7940 as per IDN Guidelines 4.0. Question 15: Update policies and procedures to require harmonized IDN tables across IDN variant TLDs to produce a consistent set of second-level variant labels. Also, require second level variant labels to be allocated to the same registrant under all variant TLDs | |||||||||||||||||||||||||||
11 | Section C. "Same entity" at the second-level c4 | No material inconsistency between SubPro Rec 25.8 and Staff Paper Rec 6. | Recommendation 25.8: Second-level labels derived from Recommendation 25.6 or Recommendation 25.7 are not required to act, behave, or be perceived as identical. | Recommendation 6. Second-level variant label allocatable or activated under IDN variant TLDs not necessarily same. The set of allocatable or activated second-level variant labels may not be identical across the activated IDN variant TLDs. For two variant labels s1 and s1v1 which are allocatable under the active IDN variant TLDs t1 and t1v1, the label s1.t1 may be allocated or activated but s1.t1v1 may not be allocated or activated. Similarly, if s1v1.t1 is allocated or activated, s1v1.t1v1 may not be allocated or activated. | |||||||||||||||||||||||||||
12 | H. Adjustments in string simlarity processes h4 | GAP | No corresponding SubPro recommendation | [Question for GNSO's Consideration] Question 23: Review string similarity procedure to address decorated two-character Latin labels. The ccTLD labels in the root depend on an external registry (ISO 3166) that allocates alphabetic codes to countries. In order to ensure that no conflicts with future assignments by ISO can happen, ICANN has traditionally also maintained a restriction against the use of two-letter TLDs that do not correspond to ISO 3166 entries. This restriction should be maintained for all Latin script letters. No variants should be generated for ccTLDs even if the Latin letters are included in the RZ-LGR, because the basis for the ccTLD labels lies in the external source (the ISO 3166 code); therefore, only that code should be allocated. For reasons of conservatism, however, the lack of “decorated” ISO 3166 two-character codes should not be regarded as a reason to permit such registrations. | |||||||||||||||||||||||||||
13 | Section A. Consistent definition and technical utilization of RZ-LGR a9, a10 Section D. Adjustments in registry agreement, registry service, registry transition process, and other processes/procedures related to the domain name lifecycle E. Adjustments to objection process, string similarity review, string contention resolution, reserved strings, and other policies and procedures F. Adjustments in registration dispute resolution procedures and trademark protection mechanisms | GAP: Staff paper points out the impact to many aspects of the ICANN policies and procedures due to the implementation of IDN variant TLD management recommendations. Specific questions are asked for the GNSO to consider to develop appropriate recommendations. Please see more details in Column D. In the rationale of SubPro Rec 25.5, it is mentioned that "To the extent that the TLD were to change hands at any point after delegation, the variant TLDs must remain linked contractually, which should be considered a persistent requirement (e.g., this would impact gTLD registry transition procedures, including EBERO)." However, there are no specific SubPro recommendations on these aspects. In addition, some limited discussion took place in SubPro regarding how an applicant would be able to seek to obtain allocatable variant TLDs, for both existing gTLDs and new gTLDs. As these deliberations arose late in the PDP's life cycle, the group elected to only recommend the “same entity” principle for variant TLDs but refrained from providing recommendations on how variant TLDs can be obtained. In its Rec 25.5, SubPro recommended capturing the "same entity" policy in relevant Registry Agreements, but did not propose how to do so. | No corresponding SubPro recommendation | Recommendation 8. Update existing policies and associated procedures to accommodate the recommendations for IDN variant TLDs. Existing policies and associated procedures must be adjusted to ensure that the recommendations above remain true under the functioning of gTLD and ccTLD policy and procedures. == [Questions for GNSO's Consideration] Question 8: Update policies and procedures for string review to ensure that every candidate label for allocation is allocatable. (Section H.) Question 9: Update domain transfer and update process to reflect inter-TLD linkages due to variants and the need to enforce the “same entity” rule (e.g. that s1.t1 and s1.v1t1 may have the same contact ROID after a <domainUpdate>). (Section F.) Question 10: Update policies and procedures to allow the lists of reserved names and the strings for inappropriate delegation to reflect any variants. (Section G.) Question 12: Update policies and procedures to incorporate variant label states and transitions between them. (Section K.) Question 16: Those TLDs using EPP may need to create an enhancement (either a protocol modification, a standard message, or a standard extension) that permits expressing response messages for unavailability of an unallocated label due to variants. Work with the technical community to make this enhancement. (Section F.) Question 17: If applicable, for the registry agreement propose changes for Registry Transition Process or Change of Control ensuring “same entity” rule is maintained. (Section F.) Question 18: Update EBERO provisions to ensure all names in an IDL set remain under unified control during EBERO. (Section F.) Question 19: Update registry agreement documents to ensure the label under variants TLDs (e.g. s1.t1, s1.t1v1, s1v1.t1 and s1v1.t1v1) follow the “same entity” rule. (Section F.) Quesiton 20: Update UDRP for UDRP application in the face of “same entity” restrictions. (Section J.) Question 21: Possibly recommend updates to TMCH mechanism to include second level labels and their variants s1, s1v1 under TLD labels and their variants t1, t1v1 and broader calculation of variant labels. (Section J.) Question 22: Update the string similarity guidelines for TLDs and their variant labels. (Section H.) | Recommendation 10: In the current design of rights protection related to the TMCH process there is a risk of homographic attacks. The roles of the involved parties, specifically registrars, registries and TMCH, related to matching must be made clear. == Recommendation 12: The matching algorithm for TMCH should be improved. == Recommendation 13: The TMCH must add support for IDN variant TLDs. Particularly during the Trademark Claims service a name registered under a TLD that has variant TLDs should trigger trademark holder notifications for the registration of the name in the TLD and all its allocated variant TLDs. | ||||||||||||||||||||||||||
14 | Overarching | GAP | No corresponding SubPro recommendation | Recommendation 9. All other existing TLD policies and procedures apply to IDN variant TLDs, unless otherwise identified. Unless adjusted due to recommendation 9 above or other reasons identified and agreed by the community, because each IDN variant TLD is also another TLD, all existing TLD policies and procedures for allocation and delegation remain applicable for IDN variant TLDs as well. | |||||||||||||||||||||||||||
15 | Section A. Consistent definition and technical utilization of RZ-LGR a2 | GAP | No corresponding SubPro recommendation | Recommendation 3. GNSO and ccNSO should work collaboratively and consider their respective policy, procedure and/or contract changes to address any existing possible deviations from the calculation of the RZ-LGR in two specific areas: 3.1. Delegated TLDs: These are cases that have occurred under special circumstances in which labels generally deemed as the same (i.e. variant TLDs under RZ-LGR) were previously delegated as independent TLDs, albeit with special considerations (e.g. synchronized TLDs). Any such variations should be considered for alignment with RZ-LGR. 3.2. Self-identified “variant” TLDs: Historically IDN TLD applications, for gTLDs and ccTLDs, have asked the applicant to identify and list any variant labels (based on their own calculations) corresponding to the applied-for string. These self-identified “variant” labels may or may not conform to the RZ-LGR once implemented. The self-identified “variant” labels which are also variant labels based on RZ-LGR will need to be assigned a variant disposition based on RZLGR calculation. Further, self-identified “variant” labels that are not variant labels based on the RZ-LGR definition should not be considered as variant TLD labels and it needs to be determined on how to address such labels previously identified by the applicants. GNSO and ccNSO must consider a resolution of such outstanding cases that conforms to the LGR Procedure and RZ-LGR calculations. | |||||||||||||||||||||||||||
16 | Section A. Consistent definition and technical utilization of RZ-LGR a3 | Determining valid or invalid applied-for labels should be part of the overall TLD label evaluation process. As such, there should be a process that encompasses all cases in which the applied-for label is subject to an observation/rejection and a process for the applicant to put a remedy to such objection. Therefore, this specific case can be part of the (assuming existing) procedure. SubPro's recommendation 32.1 may supercede the TSG Recommendation 4 and SSAC060 Recommendation 2. | [Regarding the remedy element] Recommendation 32.1: The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that appear to be inconsistent with the Applicant Guidebook. The new substantive challenge/appeal mechanism is not a substitute or replacement for the accountability mechanisms in the ICANN Bylaws that may be invoked to determine whether ICANN staff or Board violated the Bylaws by making or not making a certain decision. Implementation of this mechanism must not conflict with, be inconsistent with, or impinge access to accountability mechanisms under the ICANN Bylaws. The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and formal objections decisions: (Specifically, likely the DNS Stability aspect of evaluation/challenge procedures) | Recommendation 4 below describes the cases in which an applied-for label, whose script is supported by the RZ-LGR, is determined to be “invalid”. The SG defers to the GNSO and ccNSO to determine the process to deal with these cases (e.g. suspend or reject the applied-for TLD) as this is considered a matter of policy or procedure. While there may be merits for either choice, the SG provides items 4.1 to 4.4 as technical input for community’s consideration, to help address SSAC’s SAC060 recommendation: "ICANN must maintain a secure, stable, and objective process to resolve cases in which some members of the community (e.g., an applicant for a TLD) do not agree with the result of the LGR calculations." Recommendation 4. For an applied-for TLD label whose script(s) are supported by the applicable version of the RZ-LGR, the RZ-LGR will calculate either of two values: “valid” or “invalid”. Consequently, an applied-for TLD that is determined “valid” may proceed with the subsequent evaluation process, whereas an applied-for TLD that is determined “invalid” must not proceed, because it did not pass the validation by RZ-LGR. While policy needs to determine how an “invalid” label should be dealt with (Recommendation 2 in SAC060), the following technical input should be considered by the relevant policy development process: 4.1 Conformance with IDNA2008. An applied-for label must be in Normalization Form C7 and must conform to IDNA2008. 4.2. Conformance with LGR Procedure. Policy or procedure must not override the results of the RZ-LGR. That is, policy or procedure alone cannot turn an “invalid” label into a “valid” label, or vice-versa. Doing so would invalidate the entire RZLGR. Any change to the RZ-LGR (e.g. repertoire, variant rules or WLEs) must be undertaken using the process stipulated in the LGR Procedure. 4.3. Script LGR can be updated, if justified, using the LGR Procedure. In general, GPs make design choices8 based on current knowledge and available information. These choices determine the code point repertoire and its context rules, the whole-label evaluation rules and variant sets. If and when there is new information available, the LGR Procedure defines the process to update the RZLGR9. 4.4. Re-validation of applied-for label is possible. The applied-for TLD label may be re-validated when a new RZ-LGR version becomes available. | Recommendation 2: ICANN must maintain a secure, stable, and objective process to resolve cases where some members of the community (e.g. an applicant for a TLD) do not agree with the result of the LGR calculations. The spirit of such a process should be to balance (1) the desire/need from certain communities to change certain LGR rules (e.g., additional code points, variant rules, etc.) with (2) the risk that changing the LGR rules without proper review could introduce instability. The SSAC proposes the following straw man process to ICANN for consideration: • If an applicant or a community disagrees with the LGR calculation, they can appeal to ICANN to reconvene the relevant generation panel to update the LGR. Such an appeal should not focus on the given string, but rather on the LGR as a whole, for a script or a set of scripts. • Once ICANN receives the request, it should reconvene the relevant label generation panel. The label generation panel should conduct its review by following its regular process outlined in the LGR document to consider the specific case (see Section B 2.1.1 of the Root LGR Procedure). Such a process must also undergo integration panel checking and public comment, as per the process already defined. | ||||||||||||||||||||||||||
17 | Section A. Consistent definition and technical utilization of RZ-LGR a5 | GAP | No corresponding SubPro recommendation | [Not a formal recommendation] Appendix C. Limiting the IDN Variant Domain Names with the Delegation of IDN Variant TLDs | Recommendation 6. SSAC advises in SAC060 that too many variant labels should not be delegated. The SG considers that the matter on limiting the number of allocatable variant labels to be a policy matter. Refer to Appendix C of IDN Variant TLD Implementation: Appendices11 for some suggested approaches. | Recommendation 14: ICANN should ensure that the number of strings that are activated is conservative. A variant TLD application must be accepted only if the TLD applicant clearly demonstrates the necessity for activating the string. Variants that are not necessary, but are desired, must not be allocated and activated. | |||||||||||||||||||||||||
18 | Section A. Consistent definition and technical utilization of RZ-LGR a6 | GAP | No corresponding SubPro recommendation | Recommendation 7. It is expected that the RZ-LGR be revised throughout its lifecycle, either as a result of a new script LGR being integrated or a revision of an existing script LGR being adopted. There may be cases where a script LGR does not support an existing TLD (See Recommendation 12 for additional context). In such cases, it is possible that the existing TLD(s) may need to be grandfathered. GNSO and ccNSO should consider reviewing their policies and procedures to deal with the grandfathering process of existing TLDs as a result of changes of the RZ-LGR. | |||||||||||||||||||||||||||
19 | G. Process to update the IDN Implementation Guidelines g1, g1a | See Charter Q L1 | Not applicable | Not applicable | Not applicable | Not applicable | Not applicable | ||||||||||||||||||||||||
20 | |||||||||||||||||||||||||||||||
21 | |||||||||||||||||||||||||||||||
22 | |||||||||||||||||||||||||||||||
23 | |||||||||||||||||||||||||||||||
24 | |||||||||||||||||||||||||||||||
25 | |||||||||||||||||||||||||||||||
26 | |||||||||||||||||||||||||||||||
27 | |||||||||||||||||||||||||||||||
28 | |||||||||||||||||||||||||||||||
29 | |||||||||||||||||||||||||||||||
30 | |||||||||||||||||||||||||||||||
31 | |||||||||||||||||||||||||||||||
32 | |||||||||||||||||||||||||||||||
33 | |||||||||||||||||||||||||||||||
34 | |||||||||||||||||||||||||||||||
35 | |||||||||||||||||||||||||||||||
36 | |||||||||||||||||||||||||||||||
37 | |||||||||||||||||||||||||||||||
38 | |||||||||||||||||||||||||||||||
39 | |||||||||||||||||||||||||||||||
40 | |||||||||||||||||||||||||||||||
41 | |||||||||||||||||||||||||||||||
42 | |||||||||||||||||||||||||||||||
43 | |||||||||||||||||||||||||||||||
44 | |||||||||||||||||||||||||||||||
45 | |||||||||||||||||||||||||||||||
46 | |||||||||||||||||||||||||||||||
47 | |||||||||||||||||||||||||||||||
48 | |||||||||||||||||||||||||||||||
49 | |||||||||||||||||||||||||||||||
50 | |||||||||||||||||||||||||||||||
51 | |||||||||||||||||||||||||||||||
52 | |||||||||||||||||||||||||||||||
53 | |||||||||||||||||||||||||||||||
54 | |||||||||||||||||||||||||||||||
55 | |||||||||||||||||||||||||||||||
56 | |||||||||||||||||||||||||||||||
57 | |||||||||||||||||||||||||||||||
58 | |||||||||||||||||||||||||||||||
59 | |||||||||||||||||||||||||||||||
60 | |||||||||||||||||||||||||||||||
61 | |||||||||||||||||||||||||||||||
62 | |||||||||||||||||||||||||||||||
63 | |||||||||||||||||||||||||||||||
64 | |||||||||||||||||||||||||||||||
65 | |||||||||||||||||||||||||||||||
66 | |||||||||||||||||||||||||||||||
67 | |||||||||||||||||||||||||||||||
68 | |||||||||||||||||||||||||||||||
69 | |||||||||||||||||||||||||||||||
70 | |||||||||||||||||||||||||||||||
71 | |||||||||||||||||||||||||||||||
72 | |||||||||||||||||||||||||||||||
73 | |||||||||||||||||||||||||||||||
74 | |||||||||||||||||||||||||||||||
75 | |||||||||||||||||||||||||||||||
76 | |||||||||||||||||||||||||||||||
77 | |||||||||||||||||||||||||||||||
78 | |||||||||||||||||||||||||||||||
79 | |||||||||||||||||||||||||||||||
80 | |||||||||||||||||||||||||||||||
81 | |||||||||||||||||||||||||||||||
82 | |||||||||||||||||||||||||||||||
83 | |||||||||||||||||||||||||||||||
84 | |||||||||||||||||||||||||||||||
85 | |||||||||||||||||||||||||||||||
86 | |||||||||||||||||||||||||||||||
87 | |||||||||||||||||||||||||||||||
88 | |||||||||||||||||||||||||||||||
89 | |||||||||||||||||||||||||||||||
90 | |||||||||||||||||||||||||||||||
91 | |||||||||||||||||||||||||||||||
92 | |||||||||||||||||||||||||||||||
93 | |||||||||||||||||||||||||||||||
94 | |||||||||||||||||||||||||||||||
95 | |||||||||||||||||||||||||||||||
96 | |||||||||||||||||||||||||||||||
97 | |||||||||||||||||||||||||||||||
98 | |||||||||||||||||||||||||||||||
99 | |||||||||||||||||||||||||||||||
100 | |||||||||||||||||||||||||||||||