Skip to main content
Resources

gTLD의 중간 등록 데이터 정책

이 페이지는 다음과 같은 언어로 제공됩니다.

모든 번역 내용 및 문서의 영어 버전은 공식 버전이며, 영어 외 다른 언어의 번역 버전은 정보 제공용으로만 사용할 수 있습니다.

gTLD의 이 중간 등록 데이터 정책(중간 정책)은 일반 최상위 도메인(gTLD)의 데이터 보호 요구 사항과 관련하여 2019년 5월 15일 ICANN 이사회에서 채택한 GNSO(General Name Supporting Organization) 정책 권장 사항을 구현하는 합의 정책입니다. 이 중간 정책은 아래의 배경 절에서 설명한 대로 총 29개 중 EPDP(Expedited Policy Development Process) 팀의 권장 사항 중 하나를 구현합니다. gTLD의 후속 등록 데이터 정책(등록 데이터 정책)에서는 이사회 승인 권장 사항을 구현하고 2단계가 종료된 후에 이 중간 정책을 대체합니다.

이 중간 정책은 2019년 5월 20일에 발효됩니다. 이 중간 정책에 따라 2019년 5월 20일부터 gTLD 레지스트리 운영자 및 ICANN 공인 레지스트라(통칭 "계약 당사자")가 등록 데이터 정책 구현을 보류하며 임시로 gTLD 등록 데이터의 임시 규정과 일치하는 조치를 계속 구현합니다.

  1. 1단계
  2. 2019년 5월 20일부터 계약 당사자는 2018년 5월 17일에 ICANN 이사회에서 채택한 gTLD 등록 데이터의 임시 규정(임시 규정)에 부합하는 조치를 계속 구현해야 합니다.

  3. 2단계
  4. ICANN 조직에서 (a) 구현 검토 팀과 협의하여 등록 데이터 정책 문서 완성, (b) 등록 데이터 정책 문서의 게시 및 (c) 등록 데이터 정책 게시를 계약 당사자에게 공식적으로 통지하고 나면 계약 당사자가 임시 규정에 부합하는 조치를 지속적으로 구현하거나 등록 데이터 정책 문서와 일치하는 조치를 구현해야 합니다.

    이 단계에서 계약 당사자는 등록 데이터 정책 문서의 발효일에 대비하여 중간 정책이나 등록 데이터 정책 전체 또는 두 가지 요소를 모두 구현할 수 있습니다.

  5. 3단계
  6. 등록 데이터 정책의 발효일(EPDP 팀에서는 2020년 2월 29일을 권장함) 시점에 계약 당사자는 등록 데이터 정책을 준수해야 합니다.

실행 기록

ICANN 계약 준수에 따라 계약 당사자는 다음과 같이 해당 중간 정책을 준수할 의무가 있습니다.

1단계: ICANN 계약 준수에 따라 계약 당사자는 임시 규정에 부합하는 조치를 계속 구현할 의무가 있습니다.

2단계: ICANN 계약 준수에 따라 계약 당사자는 (a) 임시 규정에 부합하는 조치를 계속 구현하거나 (b) 등록 데이터 정책 문서에 부합하는 조치를 구현할 의무가 있습니다. 준수 문의에 대한 응답으로 계약 당사자는 해당 활동이 이 의무를 어떻게 충족시키는지를 입증해야 합니다. 임시 규정에서 등록 데이터 정책으로 전환하는 속도는 계약 당사자의 재량에 달려 있습니다.

3단계: ICANN 계약 준수에 따라 계약 당사자가 등록 데이터 정책을 준수할 의무가 있습니다. 이 단계에서 등록 데이터 정책이 작동하고 중간 정책이 더 이상 시행되지 않습니다.

계약 당사자는 세 개의 단계 전체에서 레지스트리 계약과 레지스트라 인증 계약의 변경되지 않은 부분을 계속해서 준수해야 합니다.

배경 설명

2018년 5월 17일 ICANN 이사회(ICANN 이사회)에서는 gTLD 등록 데이터의 임시 규정을 채택했습니다. 임시 사양은 유럽 연합의 GDPR(General Data Protection Regulation)을 준수하기 위해 레지스트라 인증 및 레지스트리 계약의 기존 요구 사항을 수정했습니다. 레지스트리 계약(RA) 및 레지스트리-레지스트라 계약(RAA)의 ICANN 내규와 합의 정책 및 중간 정책 규정에 따라 임시 규정은 2019년 5월 20일에 만료됩니다.

2018년 7월 19일에 GNSO 위원회는 EPDP를 시작하고 gTLD를 등록 데이터 팀을 위한 임시 규정에 EPDP를 인가했습니다. 참여에 관심을 표한 모든 GNSO 이해 관계자 그룹, 구성체 및 ICANN 자문 위원회는 EPDP 팀을 대표합니다. 단, 헌장에 따라 그룹당 회원 수는 제한됩니다.

이 헌장에서는 EPDP에 gTLD 등록 데이터의 임시 규정이 현상태 그대로 또는 수정된 ICANN 합의 정책이되어야 하는지를 결정하도록 요청합니다. 또한 헌장에서는 그 결과가 GDPR을 준수해야 하며 다른 관련 개인 정보 보호 및 데이터 보호법을 고려해야 한다고 지시합니다. EPDP 팀의 헌장에 따라 EPDP 팀이 정책 권고를 완료하고 게이팅 질문에 관해 토론한 후 비공개 등록 데이터에 대한 표준화된 액세스 모델에 관해서도 논의해야 합니다.

2018년 11월 21일에 EPDP 팀은 공개 의견을 위해 초기 보고서를 게시했습니다. 초기 보고서에는 EPDP 팀의 예비 권고와 공개 의견 수렴을 위한 질문이 포함되어 있습니다. 또한 EPDP 팀은 다음을 검토하고 권고했습니다. (i) 임시 규정에 설명된 목적의 타당성, 정당성 및 법적 근거, (ii) 임시 규정에 설명된 각 (x)레지스트라의 등록 데이터 수집 및 (y) 임시 규정에 설명된 대로 레지스트라에서 레지스트리로 데이터를 이전하는 정당성, 필요성 및 범위 (iii) 레지스트라와 레지스트리의 등록 데이터 공개.

초기 보고서에서는 다음과 같이 대중이 고려할 예비 권고안 및 질문도 제공합니다. (i) 레지스트라 및 레지스트리에서 에스크로 제공 업체 및 ICANN으로 데이터 이전, (ii) 레지스트리에서 긴급 백엔드 레지스트리 운영자(EBERO)로 데이터 이전, (iii) 등록 데이터에 합리적으로 액세스하기 위한 정의 및 체계 (iv) GDPR, 즉 책임 있는 당사자의 각 역할과 책임, (v) ICANN 합의 정책에 적용 가능한 업데이트, (vi) GNSO의 향후 작업을 통해 관련 합의 정책이 해당 법률과 일관성있게 재평가되는지 확인해야 합니다.

EPDP 팀은 각각의 데이터 처리 단계와 목적 및 법적 근거를 문서로 작성합니다. 이 기본 작업은 GDPR 호환 솔루션을 개발하는 데 필요하며 보고서 부록에 나와 있습니다.

초기 보고서 발간 후, EPDP 팀은 다음을 수행합니다. (i) 법적 문제에 관한 지침을 찾으며, (ii) 초기 보고서의 공표에 대한 응답으로 받은 공개 의견을 신중히 검토하고, (iii) 팀 구성원이 대표하는 커뮤니티 그룹과 함께 진행중인 작업을 검토하고, (iv) 최종 보고서 작성을 위해 심의합니다. GNSO 실무 그룹 가이드라인에서 요구하는 대로 본 최종 보고서에 포함된 권고 사항에 대한 합의 요청은 EPDP 팀 위원장이 다음과 같이 설명합니다. https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001436.html.

GNSO 위원회에서는 2019년 3월 4일 최종 보고서를 채택했습니다. ICANN 조직에서는 2019년 3월 4일 최종 보고서에서 공개 의견 수렴 기간을 시작했습니다. 공개 의견에 관한 요약 및 분석 보고서는 2019년 4월 23일에 게시되었습니다. 이사회에서는 2019년 5월 15일 몇 가지 예외를 제외하고 권고안을 채택하기로 결정했습니다.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."