Skip to main content
Resources

ICANN의 WHOIS와 개인정보보호법 상충시의 처리 절차 개정안

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

발효일 2017년 4월 18일

수정된 Whois 절차의 개정 지시판 보기

소개 및 배경 설명

0.1 2003년 12월 [1] GNSO의 WHOIS 제 2 특별 위원회는 gTLD 레지스트리/레지스트라가 현지 법률 때문에 WHOIS의 개인 데이터에 관한 ICANN 계약의 조항을 완전히 준수할 수 없는 경우, 이를 입증할 수 있는 절차를 개발하도록 권고했다.

0.2 2005년 11월 [2] GNSO는 해당 절차 수립에 관한 정책 개발 프로세스를 확정했다. 이 프로세스는 WHOIS 특별 위원회가 권장하고 GNSO 평의회가 승인한 '절차에 관한 개선안'을 따르고 있다. [3] 2006년 5월 ICANN 이사회[4]는 해당 정책을 채택하고 ICANN 직원에게 갈등 절차를 개발하고 이를 공개적으로 문서화하도록 지시했다.

0.3 2006년 12월 3일 ICANN 직원은 ICANN WHOIS와 개인정보보호법 상충의 처리 절차 초안[각주 삽입, http://gnso.icann.org/issues/whois-privacy/whois_national_laws_procedure.htm]을 발간했다. ICANN은 정부 자문 위원회(Governmental Advisory Committee, GAC)에 절차 초안에 대한 의견을 구했다. 개정된 초안은 아래의 1.4에 통합되었다.

0.4 2015년 10월 5일 WHOIS와 국가 법률의 충돌에 관한 수행 자문 그룹1은 이 절차 중에서 개선이 가능한 사항을 개괄한 보고서를 발표했다. 자문 그룹 보고서에 대한 여론은 2015년 10월 5일부터 11월 17일까지 수렴했다. 이에 대한 최종 보고서를 GNSO 평의회에 제출하여 2016년 5월 회의에서 검토를 받았다.

0.5 아래에 요약된 절차는 레지스트라/레지스트리[5]가 WHOIS를 통한 개인 데이터의 수집, 표시 및 배포에 관한 ICANN 계약 조항을 준수하는 것이 지역/국가 개인 정보 보호 법률 또는 규정에 의해 합법적으로 금지되어 있음을 표시하는 경우에 ICANN이 어떻게 대응해야 하는지에 대해 설명한다. 해당 절차는 ICANN 직원용으로 작성된 것이다. 해당 절차에는 영향을 받는 gTLD 레지스트리/레지스트라를 위해 취할 수 있는 조치가 포함되어 있으나 레지스트리/레지스트라 또는 제3자에게 새로운 의무를 부과하지는 않는다. ICANN의 목표는 다른 법적 의무와 WHOIS에 관한 ICANN 계약 요건이 상충할 수 있는 경우를 ICANN에 보고할 때 어떤 절차를 밟아야 하는지 레지스트리/레지스트라 및 다른 당사자에게 알려주는 것이다.

1단계:

  1. Whois 진행 통지

    1.1 레지스트라/레지스트리는, WHOIS("WHOIS 진행")를 통해 개인 식별 데이터를 수집, 표시 또는 배포하는 행위에 적용되는 레지스트라 인가 계약서("RAA") 또는 ICANN과의 기타 계약상의 조항에 대한 준수에 영향을 줄 수 있는 조사, 소송, 규제 절차나 기타 정부 또는 민사 소송에 대한 통지를 받는 즉시 가능한 한 빨리 ICANN 직원에게 다음 사항을 제공해야 한다.

    • 조치의 성격과 상태(예: 심리, 조사, 소송, 제재 위협 등)와 있을 수 있는 결과의 범위에 대한 요약 설명
    • 레지스트라/레지스트리 담당자가 문제 해결을 위해 연락할 수 있는 연락처 정보
    • 적절하다고 판단되는 경우, 책임이 있는 지방 정부 기관 또는 기타 청구인의 연락처 정보와 ICANN이 이 문제에 관해 해당 공무원 또는 청구인과 연락할 수 있도록 권한을 부여하는 레지스트라/레지스트리의 진술 관련 법률 때문에 레지스트라/레지스트리가 그러한 권한 부여를 할 수 없는 경우, 통지서에 이를 기록해야 한다.
    • 정부 또는 기타 청구인이 이를 제시한 경우 현지 정부 또는 기타 청구인이 조치 또는 조사의 근거로 하는 법 또는 규정에 관한 문서
    • ICANN에 대한 현지 법률 및 의무의 요구 사항을 충족하기 위해 기울인 노력에 대한 진술

    1.2 통지 요건을 충족하면 레지스트라/레지스트리가 조사에 참여하여 고문이 최선이라고 판단하는 방식 및 과정으로 법원 명령, 규정 또는 집행 기관에 응답할 수 있다.

    1.3 레지스트라/레지스트리는 WHOIS 진행의 특정 상황에 따라 당사자 간의 모든 통신 내용을 WHOIS 진행의 결과가 나올 때까지 기밀로 유지하도록 ICANN에 요청할 수 있다. ICANN은 일반적으로 그러한 요청이 ICANN 운영에 적용되는 기타 법적 책임과 투명성에 관한 기본 원칙에 따라 수용될 수 있는 한도 내에서 요청에 우호적으로 응한다.

    1.4 WHOIS 진행 절차를 밟는 레지스트라 또는 레지스트리는 해당 국가의 정부와 협력하여 레지스트라 또는 레지스트리가 국내 법규, 국제법 및 해당 국제 협약에 따라 운영되도록 보장해야 한다.

  2. 대체 트리거: 정부 기관의 서면 진술서

    1.5 Whois 진행이 없는 경우, 레지스트리 또는 레지스트라는 다음을 충족하는 정부 기관의 서면 진술서를 ICANN에 제출할 수 있다.

    • (a) 다음과 같은 사실을 명시
      • (i) 해당되는 특정 계약 당사자(레지스트라 또는 레지스트리)
      • (ii) 서비스/등록 계약 기관에 관한 해당 조건을 검토한 사실
      • (iii) 해당 ICANN 계약의 관련 조항
      • (iv) 자신이 분석한 해당 법률
    • (2) 기관이 발견한 국내법과 계약상 의무 사이의 불일치에 관한 확인 및 분석(이때 각 법률 및 의무의 구체적인 조항을 인용)
    • (3) 계약상 의무와 일치하지 않는 것으로 판명된 국내법을 집행할 합법적 권한이 해당 기관에 있음을 증명하고 그러한 시행을 위해 계약 당사자에 대한 관할권이 있음을 증명

2단계: 협의

2.1 협의 과정의 목적은 레지스트라/레지스트리가 계약상의 WHOIS 의무를 최대한 준수할 능력을 유지하는 방식으로 문제를 해결하는 것이 되어야 한다.

2.1.1 ICANN은 통지를 받고 이를 검토한 후 해당 상황에서 실행할 수 없는 경우가 아니면 레지스트라/레지스트리와 협의한다. 해당 상황에서 적절하다고 판단되는 경우 ICANN은 레지스트리/레지스트라와 함께 해당 지역/국가의 집행 기관 또는 기타 청구인과 협의한다.

2.1.2 ICANN은 ICANN 정부 자문 위원회(Governmental Advisory Committee)의 자문을 받아 해당 국가의 정부에 ICANN WHOIS 요구 사항을 부분 수정할 것을 요청할 수 있는 권한과 관련해 자문을 요청할 것이다.

2.2 WHOIS 진행이 아무런 변경도 필요 없이 종료되거나 레지스트리/레지스트라 관행에서 변경해야 할 사항이 ICANN의 견해 상 RAA 또는 기타 계약상 의무에서 벗어난 것으로 간주되지 않는 경우, ICANN 및 레지스트리/레지스트라는 추가 조치를 취할 필요가 없다.

2.3 자문 절차가 진행되기 전에 WHOIS 관련 계약상 의무 이행에 영향을 미치는 관행을 변경하라는 명령을 현지 법률 집행 기관 또는 법원으로부터 받은 경우, 레지스트리/레지스트라는 변경 사항과 함께 그러한 조치의 근거가 되는 법률/규정을 ICANN에 즉시 통보해야 한다.

2.4 레지스트리/레지스트라는 WHOIS 진행의 결과가 나올 때까지 당사자 간의 모든 통신 내용을 기밀로 유지하도록 ICANN에 요청할 수 있다. ICANN은 일반적으로 그러한 요청이 ICANN 운영에 적용되는 기타 법적 책임과 투명성에 관한 기본 원칙에 따라 수용될 수 있는 한도 내에서 요청에 우호적으로 응한다.

2.5 대체 트리거가 적용되는 경우, 협의 단계에는 모든 이해 당사자가 통지 단계에서 제출된 서면 진술서를 검토하고 진술서의 모든 측면에 대해 의견을 제시할 수 있는 공개 협의가 포함된다. 이 경우 ICANN은 본 절차의 2.1.2항에 따라 해당 국가의 GAC 담당자(있는 경우)와도 협의한다.

3단계: 총괄 고문의 분석 및 권고

3.1 WHOIS 진행 과정에서 ICANN 총괄 고문 사무국의 견해로 봤을 때 계약상의 WHOIS 의무 이행을 방해하는 변경(위에 설명한 협의 과정 이전, 도중 또는 이후 어느 때든 관계없음)이 필요할 경우, ICANN 직원은 의무 불이행을 이유로 레지스트리/레지스트라에게 취해지는 강제 조치를 잠정적으로 거부할 수 있다. 그 대신에 ICANN은 공개 보고서와 권고안을 작성한 후 이를 ICANN 이사회에 제출하여 판단을 받게 된다. 보고서가 공개되기 전에 레지스트리/레지스트라는 보고서에서 특정 정보(레지스트리/레지스트라와 ICANN 간의 통신 또는 기타 권한/기밀 정보 포함, 여기에 국한되는 것은 아님)를 수정하도록 요청할 수 있다. 총괄 고문은 ICANN에 대한 법률 조언과 관련된 공개 보고서, 또는 총괄 고문의 견해 상 ICANN에 대한 면책 특권이나 법적 책임 가능성으로 인해 제한되어야 할 ICANN 고문의 조언과 관련된 공개 보고서에서 그러한 조언 또는 정보를 수정할 수 있다. 공개 보고서에는 다음 내용이 포함될 수 있다.

  1. 갈등과 관련된 법률 또는 규정 요약
  2. 레지스트리 또는 레지스트라의 계약상 WHOIS 의무 중 완전한 준수가 방해를 받는 원인이 되는 일부 의무에 대한 명세
  3. 2단계에 해당되는 경우, 협의 과정 요약
  4. 문제를 어떻게 해결해야 하는지에 대한 권장 사항. 식별된 하나 이상의 WHOIS 계약 조항에서 특정 상충이 적용되는 레지스트라/레지스트리에 ICANN이 예외를 제공해야 하는지 여부를 포함할 수 있다. 권장 사항이 승인되거나 거부될 경우, 인터넷 고유 식별자 시스템의 운영 안정성, 신뢰성, 보안 또는 전 세계 상호 운용성에 미칠 것으로 예상되는 부정적인 영향을 비롯한 권장 사항의 자세한 근거가 보고서에 포함되어야 한다.

3.2 레지스트라/레지스트리에게는 이사회에 의견을 제시할 수 있는 합당한 기회가 제공된다. 레지스트라/레지스트리는 이사회의 결의가 있기 전에 ICANN이 그러한 보고서를 기밀로 유지하도록 요청할 수 있다. ICANN은 일반적으로 그러한 요청이 ICANN 운영에 적용되는 기타 법적 책임과 투명성에 관한 기본 원칙에 따라 수용될 수 있는 한도 내에서 요청에 우호적으로 응한다.

3.3 대체 트리거가 적용되는 경우, 본 절차의 2.1.2항에 따라 이사회는 통지 단계에서 제출된 서면 진술서에 접수된 모든 의견과 해당 국가의 GAC 대표(있는 경우)로부터 접수한 모든 의견을 참작한다.

4단계: 해결

4.1 이사회는 인터넷 고유 식별자 시스템의 운영 안정성, 신뢰성, 보안 또는 전 세계 상호 운용성에 미칠 것으로 예상되는 부정적 영향을 염두에 두고 가능한 한 빨리 총괄 고문 보고서에 포함된 권장 사항을 고려하고 적절한 조치를 취한다. 그러한 조치로 다음과 같은 예를 들 수 있다(이에 국한되지 않음).

  • 수정 여부와 상관없이 보고서의 권고 사항을 승인 또는 거부
  • 영향을 받은 레지스트라/레지스트리 또는 제3자에게 추가 정보 요청
  • 보고서에 대한 공개적인 의견 수렴 일정 계획 또는
  • 보고서를 특정 날짜까지 검토하고 의견을 제시하도록 GNSO에 회부

5단계: 공고

5.1 이 문제에 대한 이사회의 결의안은 일반적으로 총괄 고문의 보고서와 함께 공개되며 향후 연구를 위해 기타 관련 자료와 함께 ICANN 웹 사이트에 보관한다. 그러한 정보를 일반인에게 공개하기 전에 레지스트리/레지스트라는 공고에서 특정 정보(레지스트리/레지스트라와 ICANN 간의 통신 또는 기타 기밀 정보를 포함하되 이에 국한되지 않음)를 수정해 달라고 요청할 수 있다. 총괄 고문은 ICANN에 대한 법률 조언과 관련된 공개 보고서, 또는 총괄 고문의 견해 상 ICANN에 대한 면책 특권이나 법적 책임 가능성으로 인해 제한되어야 할 ICANN 고문의 조언과 관련된 공개 보고서에서 그러한 조언 또는 정보를 수정할 수 있다. 어떤 수정으로도 레지스트리/레지스트라가 취하는 조치의 성격을 대중에게 알리기 어렵게 된 경우, ICANN은 취해진 조치와 그러한 조치의 근거를 상황에 따라 실행 가능한 대로 대중에게 적절히 알리기 위해 노력할 것이다.

5.2 이사회가 별도로 결정하지 않는 한, 문제의 해결로 인해 레지스트리/레지스트라의 WHOIS 산출물에 있는 데이터 요소가 제거되거나 접근하기 어려워지면 ICANN은 결의안 및 ICANN이 해당 계약 조항을 완전히 준수하도록 강제하는 것에 관대한 태도를 보이는 이유에 관해 대중에게 적절한 통지를 한다.

6단계: 진행 중인 검토

6.1 ICANN은 모든 구성체와 함께 관련 레지스트리 또는 레지스트라로부터 상당한 양의 정보를 받아 매년 프로세스의 효율성을 검토한다.


[1] Whois 제 2 특별 위원회, 예비 보고서, 2004년 6월, http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html

[2] GNSO 평의회 회의록, 2005년 11월 28일, http://gnso.icann.org/meetings/minutes-gnso-28nov05.shtml

[3] 2005년 10월 25일 GNSO Whois 특별 위원회의 특별 위원회 최종 보고서, http://gnso.icann.org/issues/tf-final-rpt-25oct05.htm

[4] 이사회 회의록, 2006년 5월 10일, http://www.icann.org/minutes/minutes-10may06.htm

[5] 이 문서에서 사용된 '레지스트리'라는 용어에는 레지스트리 운영자 및 후원 기구가 포함된다.


1https://community.icann.org/display/WNLCI/WHOIS+and+national+law+conflicts+IAG+Home

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."