등록 데이터 정책

등록 데이터 정책

1. 소개
2. 적용 범위
3. 정의 및 해석
4. 정책 발효일
5. 데이터 보호 계약
6. 등록 데이터 수집
7. 레지스트라에서 레지스트리 운영자로 등록 데이터 이전
8. 데이터 에스크로 제공자로 등록 데이터 이전
9. 도메인 이름 등록 데이터 게시
10. 공개 요청
11. 로그 파일
12. 등록 데이터 보유

부속서 I

부속서 II

실행 기록

1. 등록 데이터 처리
2. 등록 데이터 이전
3. 에스크로 제공자로 등록 데이터 이전
4. 등록자 조직 게시
5. 적법한 공개에 대한 합리적 요청에 대응
6. 등록 데이터 보유
7. 계열 및 인증 비공개 또는 대리 서비스
8. 생성일
9. 업데이트 일자

배경 설명

등록 데이터 정책

1. 소개

   등록 데이터 정책("정책")은 각 ICANN 인증 레지스트라("레지스트라") 및 ICANN과 계약을 체결한 gTLD 레지스트리 운영자("레지스트리 운영자")에 대한 등록 데이터 처리 요구 사항을 설명하는 ICANN 합의 정책입니다.

2. 적용 범위

   2.1. 본 정책은 각 ICANN 인증 레지스트라 및 ICANN과 계약을 체결한 레지스트리 운영자에게 적용됩니다.

   2.2. 레지스트리 운영자와 레지스트라가 등록 데이터에 포함된 개인정보를 5항에 요구된 데이터 보호 계약에 명시된 이외의 목적으로 처리하는 것은 본 정책의 범위를 벗어납니다.

3. 정의 및 해석

   3.1. 이 문서에서 "~해야 한다", "~해서는 안 된다", "요구된다", "~하는 것을 권장한다", "~하지 않는 것을 권장한다", "~할 수 있다"와 같은 키워드는 BCP 14[RFC2119] [RFC8174]에서 설명된 대로 해석합니다.

   3.2. 데이터 주체의 "동의"는 데이터 주체가 진술 또는 명시적인 확인 조치를 통해 데이터 주체와 관련한 개인정보 처리에 동의한다는 의사를 자유롭고 구체적이며 정보에 근거하여 모호하지 않게 표현함을 의미합니다.

   3.3. "개인정보"는 식별되거나 식별될 수 있는 자연인("데이터 주체")와 관련된 정보를 의미합니다.

   3.4. "처리"는 수집, 기록, 조직, 구성, 저장, 조정 또는 변경, 검색, 협의, 사용, 전송/전파/기타 이용 가능한 수단을 통한 공개, 연계 또는 결합, 제한, 삭제, 폐기 등 자동화 여부에 상관없는 모든 수단을 통해 개인정보에 대해 수행되는 작업을 의미합니다.

   3.5. "게시", "게시하다", "게시됨"은 등록 데이터를 공개된 등록 데이터 디렉터리 서비스에 제공하는 것을 의미합니다.

   3.6. "등록 데이터"는 본 정책의 6항에 따라 등록명과 관련하여 자연인 또는 법인으로부터 수집하거나 레지스트라 또는 레지스트리 운영자가 생성하는 데이터 요소 값을 의미합니다.

   3.7. "적법한 공개에 대한 합리적 요청"("공개 요청")은 10항의 요구 사항에 따라 비공개 등록 데이터를 공개하도록 레지스트리 운영자 또는 레지스트라가 제출하는 요청을 의미합니다.

   3.8. 본 정책에 정의되지 않고 사용된 용어는 해당하는 레지스트리 계약 또는 레지스트라 인가 계약에 명시된 의미를 따릅니다.

   3.9. 레지스트리 운영자와 레지스트라가 본 정책의 조항에 함께 언급되는 경우 각 조항에서는 해당 레지스트리 계약 또는 레지스트라 인가 계약에 따라 각 레지스트리 운영자 및 각 레지스트라의 별도 요구 사항과 의무를 규정합니다.

4. 정책 발효일

   본 정책은 2025년 8월 21일에 발효됩니다. gTLD의 중간 등록 데이터 정책은 2025년 8월 20일까지 효력이 유지됩니다. 2024년 8월 21일~2025년 8월 20일 기간 동안 레지스트리 및 레지스트라는 gTLD 등록 데이터의 임시 명세서 또는 본 정책 전체 또는 두 정책의 요소에 부합하는 조치를 계속 구현할 수 있습니다.

5. 데이터 보호 계약

   ICANN, gTLD 레지스트리 운영자 및 인증 레지스트라는 관련 법률에서 요구하는 경우 상호 간에, 그리고 본 정책에 따라 고려되는 제3자 제공업체와 필요한 데이터 보호 계약을 체결해야 합니다. 약관에는 등록 데이터 처리의 법적 근거가 포함될 수 있습니다.

   관련 법률을 준수하기 위해 레지스트리 운영자 또는 레지스트라와 ICANN 간에 관련 계약을 체결해야 하는 경우 ICANN은 요청 시 지체 없이 본 정책에 따라 구현되는 레지스트리 운영자 또는 레지스트라와 데이터 보호 계약을 체결해야 합니다.

   레지스트리 운영자 또는 레지스트라는 관련 법률에 따라 계약을 체결해야 한다고 판단될 경우 본 정책에 따라 지체 없이 요청해야 합니다.

   데이터 보호 계약은 관련 법률에 규정된 대로 관련 데이터 보호 기관의 추가 지침에 따라 수시로 개정되고 갱신될 수 있습니다.

6. 등록 데이터 수집

   6.1. 레지스트라는 다음 데이터 요소에 대한 (별표 표시된) 값을 수집하거나 생성해야 합니다.

   6.1.1. 도메인 이름

   6.1.2. 레지스트라 WHOIS 서버*

   6.1.3. 레지스트라 URL*

   6.1.4. 레지스트라*

   6.1.5. 레지스트라 IANA ID*

   6.1.6. 레지스트라 남용행위 신고연락처 이메일*

   6.1.7. 레지스트라 남용행위 신고연락처 전화번호*

   6.1.8. 도메인 상태*

   6.1.9. 등록명

   6.1.10. 등록자 주소

   6.1.11. 등록자 시/도

   6.1.12. 등록자 지역

   6.1.13. 등록자 우편번호

   6.1.14. 등록자 국가

   6.1.15. 등록자 전화

   6.1.16. 등록자 이메일

   6.1.17. 레지스트라 등록 만료일*

   "지역" 및 "우편번호" 값은 UPU 우편 주소 기재 표준 또는 해당 국가 또는 지역의 다른 관련 표준에 정의된 국가 또는 지역에 해당하는 경우에만 수집해야 합니다.

   "레지스트라 WHOIS 서버" 값은 레지스트라 인가 계약 또는 ICANN 합의 정책에 따라 필요한 경우에만 생성해야 합니다.

   6.2. 레지스트라는 등록명 보유자에게 다음 데이터 요소에 대한 값을 제공할 기회를 제공할 수 있습니다. 레지스트라가 값 수집을 제안하고 등록명 보유자가 값을 제공하도록 선택한 경우 레지스트라는 값을 수집해야 합니다.

   6.2.1. 등록자 전화 내선

   6.2.2. 등록자 팩스

   6.2.3. 등록자 팩스 내선

   6.2.4. 기술자 이름

   6.2.5. 기술자 전화

   6.2.6. 기술자 이메일

   6.3. 등록명 보유자가 기술 연락처를 제공하는 경우, 레지스트라는 등록 시 등록명 보유자에게 개인 연락처 정보를 제공하는 대신 기술 연락처를 알려주어야 하며, 등록명 보유자는 (a) 등록명 보유자(또는 대표)와 동일한 개인을 기술 연락처로 지정하거나, (b) 기술 연락처를 개인적으로 식별할 수 없는 연락처 정보(예: john.doe@example.org 대신 tech-assistance@example.org 이메일 주소)를 제공할 수 있습니다.

   6.4. 레지스트라는 리셀러 데이터 요소 값을 생성할 수 있습니다.

   6.5. 레지스트라는 등록명 보유자에게 다음 데이터 요소에 대한 값을 제공할 기회를 제공해야 합니다. 등록명 보유자가 제공한 경우 레지스트라는 다음 데이터 요소 값을 수집해야 합니다.

   6.5.1. 등록자 조직

   6.5.2. 이름 서버

   6.5.3. 이름 서버 IP 주소

   6.5.4. DNSSEC 요소

   6.6. 등록명 보유자가 등록자 조직 데이터 요소 값을 입력하는 경우 레지스트라는 등록명 보유자에게 다음 사항을 알려야 합니다.

   6.6.1. 등록명 보유자가 값을 게시하는 데 동의하는 경우 등록자 조직은 RDDS에 게시됩니다.

   6.6.2. 등록자 조직은 등록명 보유자로 간주됩니다.

   6.7. 레지스트라는 레지스트리-레지스트라 계약 및/또는 레지스트리 운영자 등록 정책의 요구에 따라 추가 데이터 요소를 수집할 수 있습니다.

   6.8. 레지스트라는 본 정책의 발효일 이전에 수집된 관리 담당자 데이터를 삭제할 수 있습니다. 관리 담당자 데이터를 삭제하기 전에 레지스트라는 6.1.9~6.1.16항에 요구된 등록명 보유자 데이터 요소 값이 수집되었는지 확인해야 합니다.

7. 레지스트라에서 레지스트리 운영자로 등록 데이터 이전

   7.1. 레지스트라는 다음 데이터 요소를 레지스트리 운영자에게 이전해야 합니다.

   7.1.1. 도메인 이름

   7.1.2. 레지스트라 URL

   7.1.3. 레지스트라

   7.1.4. 레지스트라 IANA ID

   7.1.5. 레지스트라 남용행위 신고연락처 이메일

   7.1.6. 레지스트라 남용행위 신고연락처 전화번호

   7.1.7. 도메인 상태

   7.2. 레지스트라는 다음 데이터 요소(수집되거나 생성된 경우)를 레지스트리 운영자에게 이전해야 합니다.

   7.2.1. 레지스트라 WHOIS 서버

   7.2.2. 이름 서버

   7.2.3. 이름 서버 IP 주소

   7.2.4. DNSSEC 요소

   7.3. 레지스트라는 적절한 법적 근거자 존재하고 데이터 처리 계약을 체결한 경우 다음 데이터 요소를 레지스트리 운영자에게 이전해야 합니다.

   7.3.1. 등록명

   7.3.2. 등록자 주소

   7.3.3. 등록자 시/도

   7.3.4. 등록자 국가

   7.3.5. 등록자 전화

   7.3.6. 등록자 이메일

   7.4. 레지스트라는 적절한 법적 근거자 존재하고 데이터 처리 계약을 체결한 경우 다음 데이터 요소(수집된 경우)를 레지스트리 운영자에게 이전해야 합니다.

   7.4.1. 등록자 조직

   7.4.2. 등록자 지역

   7.4.3. 등록자 우편번호

   7.4.4. 등록자 전화 내선

   7.4.5. 등록자 팩스

   7.4.6. 등록자 팩스 내선

   7.4.7. 기술자 이름

   7.4.8. 기술자 전화

   7.4.9. 기술자 이메일

   7.5. 레지스트라는 다음 데이터 요소(레지스트리 운영자가 지원하는 경우)를 레지스트리 운영자에게 이전할 수 있습니다.

   7.5.1. 레지스트라 등록 만료일

   7.5.2. 리셀러

8. 데이터 에스크로 제공자로 등록 데이터 이전

   8.1. 레지스트라는 다음 데이터 요소의 전자 사본을 ICANN이 지정한 형식으로 ICANN 승인 데이터 에스크로 에이전트에게 제출해야 합니다.

   8.1.1. 도메인 이름

   8.1.2. 레지스트라 등록 만료일

   8.1.3. 레지스트라 IANA ID

   8.1.4. 등록명

   8.1.5. 등록자 주소

   8.1.6. 등록자 시/도

   8.1.7. 등록자 지역

   8.1.8. 등록자 우편번호

   8.1.9. 등록자 국가

   8.1.10. 등록자 전화

   8.1.11. 등록자 이메일

   "지역" 및 "우편번호" 값은 해당 국가 또는 지역에서 사용할 수 없는 경우 이전할 필요가 없습니다.

   8.2. 레지스트라는 다음 데이터 요소를 수집하거나 생성하는 경우 전자 사본을 ICANN이 지정한 형식으로 ICANN 승인 데이터 에스크로 에이전트에게 제출해야 합니다.

   8.2.1. 등록자 조직

   8.3. 레지스트라는 아래 데이터 요소를 수집하거나 생성하는 경우 아래 설명된 데이터 요소의 전자 사본을 ICANN이 지정한 형식으로 ICANN 승인 데이터 에스크로 에이전트에게 제출해야 합니다.

   8.3.1. 리셀러

   8.3.2. 등록자 전화 내선

   8.3.3. 등록자 팩스

   8.3.4. 등록자 팩스 내선

   8.3.5. 기술자 이름

   8.3.6. 기술자 전화

   8.3.7. 기술자 이메일

   8.4. 레지스트리 운영자는 다음 데이터 요소의 전자 사본을 ICANN이 지정한 형식으로 ICANN 승인 데이터 에스크로 에이전트에게 제출해야 합니다.

   8.4.1. 도메인 이름

   8.4.2. 레지스트리 도메인 ID

   8.4.3. 레지스트라 URL

   8.4.4. 생성일

   8.4.5. 레지스트리 만료일

   8.4.6. 레지스트라

   8.4.7. 레지스트라 IANA ID

   8.4.8. 레지스트라 남용행위 신고연락처 이메일

   8.4.9. 레지스트라 남용행위 신고연락처 전화번호

   8.4.10. 도메인 상태

   8.5. 레지스트리 운영자는 다음 데이터 요소(레지스트라에서 이전되거나 레지스트리 운영자가 생성한 경우)의 전자 사본을 ICANN이 지정한 형식으로 ICANN 승인 데이터 에스크로 에이전트에게 제출해야 합니다.

   8.5.1. 레지스트라 WHOIS 서버

   8.5.2. 업데이트 일자

   8.5.3. 레지스트라 등록 만료일

   8.5.4. 리셀러

   8.5.5. 레지스트리 등록자 ID

   8.5.6. 등록명

   8.5.7. 등록자 조직

   8.5.8. 등록자 주소

   8.5.9. 등록자 시/도

   8.5.10. 등록자 지역

   8.5.11. 등록자 우편번호

   8.5.12. 등록자 국가

   8.5.13. 등록자 전화

   8.5.14. 등록자 전화 내선

   8.5.15. 등록자 팩스

   8.5.16. 등록자 팩스 내선

   8.5.17. 등록자 이메일

   8.5.18. 이름 서버

   8.5.19. DNSSEC 요소

   8.5.20. 이름 서버 IP 주소

   8.6. 레지스트리 운영자는 다음 데이터 요소(레지스트라에서 이전되거나 레지스트리 운영자가 생성한 경우)의 전자 사본을 ICANN이 지정한 형식으로 ICANN 승인 데이터 에스크로 에이전트에게 제출할 수 있습니다.

   8.6.1. 레지스트리 기술자 ID

   8.6.2. 기술자 이름

   8.6.3. 기술자 전화

   8.6.4. 기술자 이메일

9. 도메인 이름 등록 데이터 게시

   9.1. RDDS 게시 요구 사항

   9.1.1. RDDS 쿼리에 대한 응답으로 레지스트라 및 레지스트리 운영자는 다음 데이터 요소를 게시해야 합니다.

   9.1.1.1. 도메인 이름

   9.1.1.2. 레지스트라 URL

   9.1.1.3. 생성일

   9.1.1.4. 레지스트리 만료일(예외: 레지스트라가 게시 가능)

   9.1.1.5. 레지스트라 등록 만료일(예외: 레지스트리 운영자가 게시 가능)

   9.1.1.6. 레지스트라

   9.1.1.7. 레지스트라 IANA ID

   9.1.1.8. 레지스트라 남용행위 신고연락처 이메일

   9.1.1.9. 레지스트라 남용행위 신고연락처 전화번호

   9.1.1.10. 도메인 상태

   9.1.1.11. RDDS 최종 업데이트

   9.1.2. RDDS 쿼리에 대한 응답으로 레지스트라 및 레지스트리 운영자는 다음 데이터 요소(수집, 이전 또는 생성된 경우)를 게시해야 합니다.

   9.1.2.1. 레지스트라 WHOIS 서버

   9.1.2.2. 업데이트 일자

   9.1.2.3. 이름 서버

   9.1.2.4. DNSSEC 요소

   9.1.3. RDDS 쿼리에 대한 응답으로 9.2항의 요구 사항에 따라 (a) 레지스트라는 다음 데이터 요소(수집되거나 생성된 경우)를 게시해야 하고, (b) 레지스트리는 다음 데이터 요소(레지스트라에서 이전되거나 레지스트리 운영자가 생성한 경우)를 게시해야 합니다.

   9.1.3.1. 레지스트리 도메인 ID

   9.1.3.2. 레지스트리 등록자 ID

   9.1.3.3. 등록자 조직

   9.1.3.4. 등록자 우편번호

   9.1.3.5. 레지스트리 기술자 ID

   9.1.3.6. 기술자 이름

   9.1.3.7. 기술자 전화

   9.1.3.8. 기술자 이메일

   9.1.4. RDDS 쿼리에 대한 응답으로 (a) 레지스트라는 등록자 지역 데이터 요소(수집된 경우)를 게시해야 하고, (b) 레지스트리 운영자는 등록자 지역 데이터 요소(레지스트라에서 이전된 경우)를 게시해야 합니다.

   9.1.5. RDDS 쿼리에 대한 응답으로 (a) 레지스트라는 등록자 국가 데이터 요소를 게시해야 하고, (b) 레지스트리 운영자는 등록자 국가 데이터 요소(레지스트라에서 이전된 경우)를 게시해야 합니다.

   9.1.6. RDDS 쿼리에 대한 응답으로 9.2항의 요구 사항에 따라 (a) 레지스트라는 다음 데이터 요소를 게시해야 하고, (b) 레지스트리는 다음 데이터 요소(레지스트라에서 이전된 경우)를 게시해야 합니다.

   9.1.6.1. 등록명

   9.1.6.2. 등록자 주소

   9.1.6.3. 등록자 시/도

   9.1.6.4. 등록자 전화

   9.1.6.5. 등록자 이메일

   9.1.7. RDDS 쿼리에 대한 응답으로 레지스트라 및 레지스트리 운영자는 리셀러 데이터 요소를 게시할 수 있습니다.

   9.1.8. RDDS 쿼리에 대한 응답으로 레지스트라는 이름 서버 IP 주소 데이터 요소를 게시할 수 있습니다.

   9.1.9. RDDS 쿼리에 대한 응답으로 레지스트리 운영자는 다음 중 필요한 조치를 취할 수 있습니다.

   9.1.9.1. 레지스트리 계약에 따라 도메인 내 글루 레코드(RFC8499의 정의에 따름)를 게시해야 하는 경우 이름 서버 IP 주소 데이터 요소를 게시해야 합니다.

   9.1.9.2. 레지스트리 계약에 요구되지 않은 경우 이름 서버 IP 주소 데이터 요소를 게시할 수 있습니다.

   9.1.10. RDDS 쿼리에 대한 응답으로 9.2항의 요구 사항에 따라 레지스트라 및 레지스트리 운영자는 다음 데이터 요소를 게시할 수 있습니다.

   9.1.10.1. 등록자 전화 내선

   9.1.10.2. 등록자 팩스

   9.1.10.3. 등록자 팩스 내선

   9.2. 등록 데이터 게시를 위한 수정 요구 사항

   9.2.1. 레지스트리 운영자 및 레지스트라: (a) 관련 법률을 준수하기 위해 등록 데이터에 포함된 개인정보를 수정해야 하는 경우 9.2항의 요구 사항을 RDDS에 적용해야 하고, (b) (i) 상업적으로 합당한 목적이 있거나 (ii) 이 항의 요구 사항 적용을 기술적으로 제한할 수 없는 경우 9.2항의 요구 사항을 적용할 수 있습니다. 9.2항의 요구 사항을 적용할지 여부를 결정할 때 레지스트리 운영자 및 레지스트라는 등록 데이터가 법인에 관한 것인지 개인정보를 포함하는지 여부와 등록명 보유자 또는 관련 연락처의 지리적 위치를 고려할 수 있지만 의무 사항은 아닙니다.

   9.2.2. 9.2항의 목적상 수정은 다음 조건을 충족하는 것으로 정의됩니다. 레지스트리 운영자 및 레지스트라는 (a) RDDS 출력에 데이터 요소의 값을 포함해서는 안 되며, (b) 값이 수정되었음을 나타내야 합니다.

   9.2.2.1. 레지스트리 운영자 또는 레지스트라는 9.2.1항의 요구 사항을 적용할 때 다음 항에 요약된 예외 규정에 따라 다음 데이터 요소에 대한 값을 수정해야 합니다.

   9.2.2.1.1. 레지스트리 도메인 ID

   9.2.2.1.2. 레지스트리 등록자 ID

   9.2.2.1.3. 등록명

   9.2.2.1.4. 등록자 주소

   9.2.2.1.5. 등록자 우편번호

   9.2.2.1.6. 등록자 전화

   9.2.2.1.7. 등록자 전화 내선

   9.2.2.1.8. 등록자 팩스

   9.2.2.1.9. 등록자 팩스 내선

   9.2.2.1.10. 레지스트리 기술자 ID

   9.2.2.1.11. 기술자 이름

   9.2.2.1.12. 기술자 전화

   9.2.2.2. 레지스트리 운영자는 9.2.1항의 요구 사항을 적용할 때 다음 데이터 요소에 대한 값을 수정해야 합니다.

   9.2.2.2.1. 등록자 이메일

   9.2.2.2.2. 기술자 이메일

   9.2.2.3. 레지스트리 운영자는 9.2.1항의 요구 사항을 적용할 때 등록자 조직 값을 수정할 수 있습니다.

   9.2.2.4. 레지스트라 또는 레지스트리 운영자는 9.2.1항의 요구 사항을 적용할 때 등록자 시/도 값을 수정할 수 있습니다.

   9.2.3. 레지스트라는 9.2.1항의 요구 사항을 적용할 때 다음 데이터 요소에 대해, 레지스트라는 이메일 값에 대한 관련 연락처와의 이메일 통신을 원활하게 하기 위해 이메일 주소 또는 웹 양식 링크를 게시하되, 연락처 이메일 주소 또는 연락처가 식별되지 않도록 해야 합니다.

   9.2.3.1. 등록자 이메일

   9.2.3.2. 기술자 이메일

   9.2.4. 레지스트라는 9.2.2.1.1~9.2.2.1.9항, 9.2.2.4항 및 9.2.3.1항에 열거된 데이터 요소의 값에 9.2.1항의 요구 사항을 적용할 때, 등록명 보유자에게 데이터 요소 값 게시에 동의할 수 있는 기회를 제공해야 합니다. 레지스트라는 등록명 보유자가 동의한 경우에 데이터 요소의 값을 게시해야 합니다.

   9.2.5. 계열 또는 인증 비공개 또는 대리 서비스를 사용하는 등록명의 경우, 레지스트라 및 레지스트리 운영자는 비공개 또는 대리 서비스의 전체 등록 데이터를 게시해야 하며, 기존 비공개 또는 대리 가명 이메일을 포함할 수도 있습니다.

   9.2.6. 등록명 보유자가 등록자 조직 데이터 요소 값 게시에 동의하는 경우, 레지스트라는 값을 게시해야 합니다. 등록명 보유자가 게시에 동의하지 않는 경우, 레지스트라는 등록자 조직 값을 수정할 수 있습니다.

10. 공개 요청

    10.1. 레지스트라 및 레지스트리 운영자는 공개 요청 제출 메커니즘 및 프로세스가 자세히 설명되어 있는 페이지에 직접 연결하는 링크를 홈페이지(도메인 이름 서비스가 제공되는 공개 웹페이지)에 게시해야 합니다. 메커니즘 및 프로세스에는 (a) 필요한 요청 형식 및 내용, (b) 요청자에게 응답하는 방법 및 (c) 예상 응답 일정이 지정되어 있어야 합니다.

    10.2. 레지스트라 및 레지스트리 운영자의 필요한 요청 형식 및 내용에는 최소한 다음이 포함되어야 합니다.

    10.2.1. 다음을 포함한 요청자의 신원

    10.2.1.1. 요청자의 연락처 정보

    10.2.1.2. 법인 또는 개인의 성격/유형

    10.2.1.3. 해당하는 경우에 요청자를 대리할 수 있는 권한을 입증하는 위임장 또는 유사한 진술서

    10.2.2. 요청자가 요청한 데이터 요소 값 목록

    10.2.3. 요청자의 법적 권리와 요청의 구체적인 이론적 근거 및 기준에 대한 정보

    10.2.4. 신의에 따라 요청하고 있다는 확인

    10.2.5. 요청에 대한 응답으로 수신된 데이터 요소 값을 합법적으로 처리하는 데 대한 요청자의 동의

    10.3. 레지스트라 및 레지스트리 운영자는 관련 필수 형식을 충족하는 공개 요청에 응답해야 합니다.

    10.4. 레지스트라 및 레지스트리 운영자는 각 요청에 대한 구체적인 이론적 근거와 기준을 고려하여 공과에 따라 형식을 충족하는 각 공개 요청을 고려해야 합니다.

    10.5. 레지스트라 및 레지스트리 운영자는 관련 필수 형식을 충족하는 공개 요청을 받은 후 2 영업일 이내에 지체 없이 수신 사실을 인정해야 하며, 예외적인 상황을 제외하고 인증 후 30일 이내에 지체 없이 응답해야 합니다.

    10.6. 공개 요청에 대한 응답으로 다음 중 필요한 조치를 취합니다.

    10.6.1. 요청된 데이터를 제공합니다.

    10.6.2. 레지스트리 운영자 또는 레지스트라는 결정 사유를 요청자가 객관적으로 이해하는 데 충분하고 명확인 설명을 포함하여 거부에 대한 구체적인 이유를 식별하여 요청된 데이터의 전체 또는 일부를 제공할 수 없는 이유에 대한 이론적 근거를 제시합니다. 여기에는 데이터 주체의 기본적인 권리 및 자유가 요청자의 정당한 이익(해당하는 경우)과 어떻게 비교 평가되었는지에 대한 분석과 설명이 포함됩니다.

    10.7. 레지스트리 운영자 또는 레지스트라는 부당한 요청/요청자 문제를 해결하기 위해 시정 조치를 취할 수 있습니다. 시정 조치에는 반복적이거나 불완전한 요청 거부, 부당한 요청자에 대해 기본적으로 추가 정보 요구, 기타 적절하다고 판단되는 조치가 포함될 수 있습니다. 수행된 시정 조치를 요청자에게 전달해야 합니다.

11. 로그 파일

    11.1. 레지스트라는 9.2.3항의 요구 사항을 적용할 때:

    11.1.1. 요청자의 통신이 등록명 보유자 이메일 주소로 전달되었음을 확인하는 로그 파일을 유지해야 합니다. 로그 파일에는 메시지의 출처, 수신자, 내용 또는 개인정보가 포함되지 않아야 합니다.

    11.1.2. 요청자의 통신이 기술자 이메일 주소로 전달되었음을 확인하는 로그 파일을 유지할 수 있습니다. 로그 파일에는 메시지의 출처, 수신자, 내용 또는 개인정보가 포함되지 않아야 합니다.

    11.1.3. 등록명 보유자 이메일에 대한 통신 전달 관련 로그 파일을 요청 시 규정 준수 목적으로 ICANN 조직에 제공해야 합니다. 본 조항의 어떠한 내용도 레지스트라가 레지스트라의 연락 절차 남용을 방지하기 위해 합리적이고 적절한 조치를 취하는 것을 방지하는 것으로 해석되어서는 안 됩니다.

    11.2. 레지스트리 운영자 및 레지스트라는 표준 비즈니스 기록 관행에 따라 공개 요청에 대한 요청, 승인 및 응답 기록을 유지해야 합니다. 이러한 로그는 ICANN 조직의 감사 목적 등(이에 제한되지 않음) 필요시 생성될 수 있습니다.

12. 등록 데이터 보유

    레지스트라는 이전 분쟁 해결 정책의 목적상 필요한 데이터 요소를 레지스트라의 등록 주관 또는 등록자 간(등록자 변경) 등록 이전 후 최소 15개월 동안 보관해야 합니다.

부속서 I

WHOIS(포트 43을 통해 제공) 및 웹 기반 Whois 디렉터리 서비스를 이행할 때 다음을 준수해야 합니다.

1. 값 데이터가 수집, 생성 또는 이전되지 않은 데이터 요소의 경우 (a) 필드의 값 섹션(즉, 콜론 오른쪽)에 정보가 없는 키(즉, 콜론 왼쪽의 문자열)가 표시되거나, (b) 키 또는 값이 표시되지 않아야 합니다.
2. 값 데이터가 있고 본 정책 9.2.2항의 요구 사항이 적용되는 데이터 요소의 경우 값 섹션(즉, 콜론의 오른쪽)을 "REDACTED" 문자열로 대체해야 합니다.

참고: 본 부속서 I은 WHOIS(포트 43을 통해 제공) 또는 웹 기반 Whois 디렉터리 서비스를 제공하는 각 레지스트라 및 레지스트리 운영자에게 적용됩니다.

부속서 II

생성일이 본 정책의 발효일 이전인 기존 도메인 이름 등록의 경우:

1. 레지스트라는 등록자 조직 데이터 요소에 대한 값을 입력한 등록명 보유자에게 연락하여 (a) 값이 올바른지 검토 및 확인하도록 요청하고, (b) 등록자 조직 값 게시에 동의하는지 여부를 확인해야 합니다.
2. 등록명 보유자가 등록자 조직 값을 확인하거나 정정하고 게시에 동의하면, 레지스트라는 (a) 등록명 보유자에게 등록자 조직 값이 본 정책의 발효일까지 비개인정보로 처리된 후 게시될 것이라고 알리고 (b) 본 정책의 발효일까지 9.1.3항에 설명된 대로 등록자 조직 값을 게시해야 합니다.
3. 등록명 보유자가 등록자 조직 값 게시를 거부하거나 쿼리에 응답하지 않는 경우, 레지스트라는 9.2.6항에 설명된 대로 등록자 조직 값을 수정(9.2.2항의 정의에 따름)하거나 본 정책의 발효일 이전에 수집된 등록자 조직 값을 삭제할 수 있습니다. 등록자 조직 값을 삭제하기 전에 레지스트라는 6.1.9항에 요구된 등록명 보유자 데이터 요소 값이 수집되었는지 확인해야 합니다.

실행 기록

1. 등록 데이터 처리:

   1. 본 정책의 어떠한 내용도 레지스트리 운영자 또는 레지스트라가 본 정책의 범위를 벗어난 다른 목적으로 데이터를 처리하는 것을 금지하지 않습니다. 예:
      1. 도메인 이름 등록에 대한 결제를 처리하기 위한 목적으로 신용카드 정보 수집
      2. 연락처를 만들기 위해 다음과 같은 추가 데이터 요소 수집 또는 생성: <contact:id>, <contact:authInfo> 또는 기술 연락처 시/도(<contact:city>) 및 국가(<contact:cc>)
      3. 레지스트라는 추가 연락처 데이터를 수집하는 경우 RDDS에 관련 연락처 데이터를 게시할 수 있습니다. 예를 들어 레지스트라는 6.2항에 따라 등록명 보유자로부터 기술 연락처 데이터를 수집하고 9.2.2.1.10~9.2.2.1.12항에 나열된 데이터 요소 값을 수정하는 경우 관련 연락처에게 데이터 요소 값 게시에 동의할 수 있는 기회를 제공할 수 있습니다. 레지스트라는 동의된 관련 연락처에 대한 데이터 요소 값을 게시할 수 있습니다.

2. 등록 데이터 이전

   1. 본 정책의 어떠한 내용도 레지스트라 또는 레지스트리 운영자가 데이터 에스크로 에이전트에게 추가 데이터 요소를 이전(예: 레지스트리 계약에 정의된 레지스트리 서비스를 제공하기 위해)하는 것을 방지하지 않습니다.
   2. 본 정책의 어떠한 내용도 관련 법률에서 법적 근거를 요구하는 경우 레지스트리 운영자가 레지스트라에게 추가 데이터 요소 값을 이전하도록 요구(법적 근거가 있는 경우)하는 것을 방지하지 않습니다.
   3. 7항에 따라 레지스트라에서 레지스트리 운영자로 데이터를 이전하기 위해 법적 근거가 필요한 경우 법적 근거에 대한 결정은 이전 당사자가 내립니다. 법적 근거의 존재 여부는 ICANN 조직의 결정 사항이 아니며 시행 대상이 아닙니다. 레지스트리 운영자 및 레지스트라가 법적 근거의 존재를 확인하고 데이터 이전을 포함하는 데이터 보호 계약을 체결한 경우, ICANN 조직은 7항에 따라 이전 요구 사항을 시행할 수 있습니다.
   4. 레지스트리 운영자 및 레지스트라는 관련 법률에서 요구되지 않는 경우 레지스트라에서 레지스트리 운영자로의 이전을 포함하여 개인정보 처리를 위한 법적 근거를 확인할 필요가 없습니다.

3. 에스크로 제공자로 등록 데이터 이전

   명확한 설명을 위해 관련 레지스트리 계약에 따라 레지스트리 운영자는 모든 승인된 레지스트리 서비스를 제공하기 위해 필요한 모든 데이터 요소를 에스크로해야 합니다.

4. 등록자 조직 게시

   1. 등록자 이름은 등록자 조직의 연락처로 간주됩니다.
   2. 레지스트라는 등록자 조직 값 게시에 대한 등록명 보유자의 동의를 얻고 등록명 보유자에게 6.6.1 및 6.6.2항의 요구 사항을 알리기 위해 자체 프로세스를 사용할 수 있습니다. 예를 들어 공개 또는 고지 사항을 제공하거나, 등록자 조직 값 확인 및 게시 동의를 요청하거나, 안내 팝업창을 표시하거나, 옵트인 요구 사항을 제공하거나, 레지스트라가 확인란을 선택하여 데이터 요소 게시에 동의할 때까지 등록자 조직을 회색으로 비활성화할 수 있습니다. 이러한 예는 전체 목록이 아닙니다.

5. 적법한 공개에 대한 합리적 요청에 대응

   공개 요청에 대한 레지스트라 또는 레지스트리 운영자의 응답 시간을 평가할 때, ICANN 조직은 수신된 요청 횟수, 관리 중인 도메인 이름 수, 평균 응답 시간, 거부된 요청 수를 고려할 수 있습니다.

6. 등록 데이터 보유

   1. 본 정책의 어떠한 내용도 데이터 보유 책임 면책 요청(해당하는 경우)을 포함하여 법률, 법적 절차 또는 기타 적절한 법적 근거에 따라 요구되는 경우 레지스트라 및 레지스트리 운영자가 보유 기간을 설정하는 것을 금지하지 않습니다.
   2. 레지스트라는 더 긴 보유 기간을 설정하기 위해 면책을 요구할 필요가 없습니다. ICANN 조직의 데이터 보유 면책 절차에서는 레지스트라가 더 짧은 데이터 보유 기간을 요청할 수 있도록 허용합니다.
   3. 명확한 설명을 위해 12항의 데이터 보유 요구 사항은 등록 데이터(본 정책의 정의에 따름)에만 적용되며 ICANN 규정 준수를 비롯하여 요청자가 이전 분쟁 해결 정책(TDRP) 이외의 목적으로 보유 데이터 요소의 공개를 요청하는 것을 방지하지 않습니다.

7. 계열 및 인증 비공개 또는 대리 서비스

   계열관계는 레지스트라 인증 계약 1.3항의 정의에 따르며 레지스트라 인증 계약 1.7항에 자세히 설명되어 있습니다. 인증 비공개 또는 대리 서비스 제공자(사용 가능한 경우)는 비공개 및 대리 서비스 인증 정책의 발효일부터 이 요구 사항의 적용을 받습니다.

8. 생성일

   본 정책의 목적상 "생성일"은 도메인 객체가 레지스트리 데이터베이스에 생성된 시점을 나타냅니다.

9. 업데이트 일자

   레지스트라의 경우 본 정책의 목적상 "업데이트 일자"는 7항에 나열된 데이터 요소에 대해 레지스트라 데이터베이스 또는 레지스트리 데이터베이스에서 수행된 최신 업데이트를 의미합니다.

배경 설명

2018년 5월 17일 ICANN 이사회에서는 gTLD 등록 데이터의 임시 규정을 채택했습니다. 임시 규정은 유럽 연합의 GDPR(General Data Protection Regulation)을 준수하고, WHOIS 서비스의 지속적인 가용성을 최대한 보장하고 기타 gTLD 등록 데이터 처리를 보장하며, WHOIS의 단편화를 방지하기 위해 레지스트라 인증 및 레지스트리 계약의 기존 요구 사항을 수정했습니다. 레지스트리 계약(RA) 및 레지스트리-레지스트라 계약(RAA)의 ICANN 내규와 합의 정책 및 중간 정책 규정에 따라 임시 규정은 2018년 5월 25일 발효일로부터 최대 1년 동안 효력이 유지될 수 있습니다.

2018년 7월 19일에 일반최상위도메인이름지원기구(GNSO) 평의회에서 2단계로 개발될 신속한 정책 개발 과정(EPDP)을 시작하고, gTLD 등록 데이터 팀을 위한 임시 규정에 EPDP를 인가했습니다. 1단계 작업 중에 EPDP 팀은 gTLD 등록 데이터의 임시 규정이 현 상태 그대로 또는 수정된 ICANN 합의 정책이 되어야 하는지를 결정하는 업무를 맡았습니다. 또한 헌장에서는 그 결과가 GDPR을 준수해야 하며 다른 관련 개인 정보 보호 및 데이터 보호법을 고려해야 한다고 지시합니다. EPDP 팀 헌장의 2단계는 시스템에서 비공개 gTLD 등록 데이터의 표준화된 액세스/공개를 평가하고, 임시 규정 부속서에 언급된 문제를 해결하고, 1단계에서 연기된 기타 문제를 해결하는 데 목적이 있습니다.

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

2019년 2월 20일에 EPDP 팀은 최종 보고서를 게시했습니다. 이 보고서는 2019년 3월 4일에 GNSO 평의회에서 채택되었습니다. ICANN 조직에서는 2019년 3월 4일 최종 보고서에서 공개 의견 수렴 기간을 시작했습니다. 공개 의견 수렴 절차는 gTLD 등록 데이터를 위한 임시 규정에 대한 GNSO EPDP의 최종 정책 권고안에 관한 위원회의 조치에 앞서 커뮤니티 의견을 듣기 위한 것입니다. 공개 의견에 관한 요약 및 분석 보고서는 2019년 4월 23일에 게시되었습니다. 이사회에서는 2019년 5월 15일 몇 가지 예외를 제외하고 권고안을 채택하기로 결정했습니다.

이행 계획에 따라 작업을 시작하기 위해 합의 정책 이행 팀이 구성되었습니다. ICANN 조직에서 개발하고 GNSO 평의회에서 채택된 합의 정책 이행 프레임워크(CPIF)에 따라 합의 정책 이행 팀과 함께 작업하기 위해 PDP 실무 그룹의 회원과 관심 있는 커뮤니티 회원들로 구성된 실행검토팀(IRT)이 구성되었습니다.

이사회 결의안에 앞서 이행 팀은 3단계 정책 이행 개념을 마련했습니다.

• 1단계: 2019년 5월 25일에 만료되는 gTLD 등록 데이터를 위한 임시 규정에 부합하는 조치를 계속 구현합니다. 이는 권고안에 따라 영구 정책이 준비되어 게시될 때까지 적용될 임시 등록 데이터 정책입니다.
• 2단계: 이 단계는 ICANN 조직에서 등록 데이터 정책을 합의 정책으로 게시하고 계약 당사자에게 공식적으로 통지한 이후에 시작됩니다. 이 단계에서 계약 당사자는 등록 데이터 정책의 발효일에 대비하여 중간 정책, 등록 데이터 정책 또는 두 가지 요소를 모두 구현할 수 있습니다.
• 3단계: 계약 당사자는 등록 데이터 정책을 준수해야 합니다.

2019년 5월 17일에 ICANN 조직은 위원회의 2019년 5월 15일 결의안에 따라 gTLD의 중간 등록 데이터 정책을 게시했습니다. 2019년 5월 20일에 발효되는 중간 정책에 따라 계약 당사자는 2019년 5월 25일에 만료된 gTLD 등록 데이터의 임시 규정에 부합하는 조치를 계속 구현해야 합니다.

EPDP 팀은 2단계 작업을 완료하고 네 가지 권고안으로 구성된 최종 보고서를 EPDP 2단계 우선순위 2 권고안이라는 이름으로 게시했습니다. 2021년 6월 21일에 이사회는 권고한 19-22를 채택하고 이 권고안의 이행을 등록 데이터 정책 이행 작업 범위에 추가했습니다.

2022년 2월 24일에 이사회는 중요 데이터 손실에 대한 이사회의 우려를 해결하기 위해 조직 필드의 데이터 삭제에 관한 EPDP 권고안 12에 대한 GNSO 평의회의 보완 권고안을 채택했습니다.