Skip to main content
Resources

레지스트리 서비스 평가 정책

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

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

(2006년 7월 25일 게시, 2006년 8월 15일 발효)

1. 용어 정의

1.1 레지스트리 서비스란 다음과 같이 정의됩니다.

  1. 다음에 모두 해당하는 서비스: (i) 다음 작업에 있어 필수적인 레지스트리의 운영: 레지스트라에게서 도메인 이름 및 이름 서버 등록과 데이터 접수, TLD에 대한 영역 서버와 관련된 상태 정보의 레지스트라에 프로비저닝, TLD 영역 파일의 배포, 레지스트리 영역 서버 운영, 레지스트리 계약에 따라 요구되는 TLD에서의 도메인 이름 서버 등록과 관련된 연락처 및 기타 정보 배포 및 (ii) 상황에 따라 레지스트리 운영자가 레지스트리 계약 발효 일자를 기준으로 제공,

  2. 합의 정책(위 정의 참고)이 수립되어 레지스트리 운영자가 제공해야 하는 기타 제품 또는 서비스,

  3. 레지스트리 운영자로 지정되었기 때문에 레지스트리 운영자만 제공할 수 있는 기타 제품 또는 서비스,

  4. 위 (A), (B) 또는 (C) 범위 내에서 레지스트리 서비스에 대한 중대 변경 사항 (ICANN 이사회가 2005년 11월 8일에 지정한 .NET 계약의 정의를 따름 -http://www.icann.org/minutes/resolutions-08nov05.htm).

1.2 보안 - 제안하는 등록기구 서비스가 보안에 미치는 영향은 다음을 의미합니다. (A) 등록기구 데이터의 무단 공개, 변경, 삽입 또는 폐기 또는 (B) 정보 무단 액세스, 정보 또는 모든 적용 기준과 일치하는 시스템 운영으로 인터넷 리소스 공개 (http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5에 있는 GNSO 제안의 정의를 따름).

1.3 안전성 - 제안하는 등록기구 서비스가 안정성에 미치는 영향은 다음을 의미합니다. (A) 등록기구 서비스는 관련 표준 트랙 또는 IETF가 후원하는 최상 현행 규정 RFC와 같이 잘 수립되고 알려진 권위 기준 단체가 인정하고 공표한 관련 기준에 따르지 않거나 (B) 처리량, 반응 시간, 인터넷 서버 또는 관련 표준 트랙 또는 IETF가 후원하는 최상 현행 규정 RFC와 같이 잘 수립되고 알려진 권위 기준 단체가 인정하고 공표한 관련 기준에 따라 운영하고 등록기구 운영자의 위임 정보 또는 프로비저닝에 의지하는 최종 시스템 일관성에 반대로 작용하는 상황을 만듭니다. (http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5에 있는 GNSO 제안의 정의를 따름).

1.4 레지스트리 서비스 기술 평가 패널 - 레지스트리 서비스 기술 평가 패널은 인터넷 인프라 및 DNS에서 사용되는 복합 시스템 및 표준 프로토콜에 대한 총 20명의 설계, 관리, 구현 전문가로 구성됩니다("레지스트리 서비스 기술 평가 패널"). 레지스트리 서비스 기술 평가 패널 구성원은 의장이 지명합니다. 레지스트리 서비스 기술 평가 패널 의장은 ICANN과 당시 최상위 도메인 레지스트리 정책을 담당하는 지원 기구의 레지스트리 지지그룹이 모두 동의하는 사람이어야 합니다. 레지스트리 서비스 기술 평가 패널의 모든 구성원과 의장은 보안 및 안전성의 정의에 따라 패널보다 먼저 문제를 고려하도록 요구하는 합의를 진행해야 합니다. 레지스트리 서비스 기술 평가 패널로 회부되는 각 사안에 대해 의장은 관련 문제를 평가할 레지스트리 서비스 기술 평가 패널 구성원을 5명 이하로 지정해야 하는데, 이들은 기존의 경쟁, 재무 또는 법적 이해관계의 상충이 없고 제기된 특정 기술 문제와 관련한 책임이 없는 사람이어야 합니다. (http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5에 있는 GNSO 제안의 정의를 따름).

2. 제안된 레지스트리 서비스에 대한 고려 프로세스

2.1 레지스트리 운영자 또는 후원 조직이 새로운 레지스트리 서비스를 고려

레지스트리 운영자 또는 후원 조직은 언제든지 기존 TLD 레지스트리 서비스의 아키텍처 또는 운영을 변경하거나 새로운 TLD 레지스트리 서비스 도입을 결정할 수 있습니다(시행 노트 1단계 참고).

2.2 변경을 위해 ICANN 검토가 필요한지 확인

2.4항의 설명에 따라 ICANN과 상담하는 gTLD 레지스트리 운영자 또는 후원 조직은 서비스 변경을 위해 ICANN과 레지스트리 운영자 사이의 계약에 따른 승인이 필요한지 결정해야 합니다(시행 노트 1단계 참고).

2.3 제안된 변경 사항에 대해 ICANN에 알림

정책은 새로운 레지스트리 서비스의 지지자가 새로운 레지스트리 서비스에 대한 요청을 제출하기 전에 ICANN과 협력할 것을 권장합니다. 레지스트리 서비스 평가 정책과 승인 프로세스의 목적은 gTLD 레지스트리 운영자가 제3자에 영향을 줄 수 있는 변경 사항을 미리 ICANN과 상의하도록 독려하는 환경을 조성하는 것입니다.

gTLD 레지스트리 운영자 또는 후원 조직은 변경에 관한 충분한 정보를 ICANN에 제공하여 ICANN이 이를 위해 승인 프로세스가 필요할지 평가할 수 있도록 해야 합니다. 정보는 외부 사용자에게 표시되는 변경 사항에 대한 기술적인 설명과 외부 사용자에 대한 영향 평가를 포함해야 합니다. 레지스트리 운영자 또는 후원 조직이 외부나 커뮤니티의 피드백을 받은 경우 해당 피드백의 프로세스와 결과에 대한 상세한 내용을 포함해야 합니다. 이 단계에서 ICANN 직원은 정보를 기밀로 취급해야 합니다(시행 노트 2단계 참고).

2.4 예비 결정 기간

레지스트리 운영자가 전술한 문단의 범위 내에서 레지스트리 서비스를 변경할 수 있음을 ICANN에 서면으로 통보한 후:

  1. ICANN은 15일 이내에 레지스트리 서비스를 위해 ICANN의 추가 고려가 필요한지 "예비 결정"을 내려야 합니다. 추가 고려가 필요한 경우는 해당 레지스트리 서비스가 다음에 해당하는 경우입니다. (i) 심각한 보안 또는 안전성 문제를 일으킬 수 있는 경우 (ii) 심각한 경쟁 문제를 일으킬 수 있는 경우

  2. 레지스트리 운영자는 제안된 레지스트리 서비스를 시행할 수 있음을 ICANN에 통보하는 시점에 ICANN이 정보를 바탕으로 예비 결정을 내릴 수 있도록 충분한 정보를 제공해야 합니다. 레지스트리 운영자가 제공한 "기밀"로 표기된 정보는 ICANN도 기밀로 취급해야 합니다. 레지스트리 운영자는 제안된 레지스트리 서비스의 목적과 DNS 사용자에 대한 영향을 설명하는 데 필요한 "기밀" 정보를 지정하지 않습니다.

  3. ICANN은 "예비 결정"을 위해 레지스트리 서비스의 경쟁, 보안 또는 안정성 영향에 관하여 예비 결정 기간 동안 (기밀 계약 대상 단체나 개인으로부터) 전문가 조언을 구할 수 있습니다. ICANN에서 기밀 정보를 이러한 전문가에게 공개할 때는 레지스트리 운영자에게 전문가의 신원과 공개할 정보를 알려야 합니다. 보안 또는 안정성 영향을 파악하기 위해 ICANN은 아래 2.4(F)에 기술된 레지스트리 서비스 기술 평가 패널의 전문가를 차출할 수 있습니다.

  4. 15일의 "예비 결정" 기간 동안 ICANN에서 제안된 레지스트리 서비스가 중대한 보안 또는 안정성(1.3항 및 1.4항의 정의에 따름) 또는 경쟁 문제를 야기하지 않는다고 판단할 경우 레지스트리 운영자는 이를 자유롭게 배포할 수 있습니다.

    제안된 서비스 시행을 위해 중대한 레지스트리 계약 변경이 필요한 경우 예비 결정이 ICANN 이사회에 회부됩니다(시행 노트 3~5단계 참고).

2.5 경쟁 문제

15일의 예비 결정 기간 내에 ICANN에서 해당 레지스트리 서비스가 중대한 경쟁 문제를 야기한다고 결정할 경우 ICANN은 결정 5일 내 또는 15일의 예비 결정 기간이 지난 후 2일 내(둘 중 이른 날짜)에 이 문제를 적절한 정부 경쟁 감시 기관이나 사안에 대한 관할권을 가진 기구에 회부하고 레지스트리 운영자에도 통보해야 합니다.

이처럼 회부할 경우 그에 대한 통신을 제출하는 날짜에 ICANN 웹 사이트에도 게시됩니다.

회부한 후 ICANN은 더 이상 책임이 없고 레지스트리 운영자는 더 이상 레지스트리 서비스와 관련된 경쟁 문제에 대해 ICANN에 대한 의무가 없습니다. 회부될 경우 레지스트리 운영자는 회부 후 45일이 경과할 때까지 레지스트리 서비스를 배포할 수 없습니다. 단, 회부된 정부 경쟁 감시 기관에서 조기 승인하는 경우는 제외입니다(시행 노트 5단계 참고).

2.6 보안 및 안정성 문제

15일의 예비 결정 기간 내에 ICANN에서 해당 레지스트리 서비스가 중대한 안정성 또는 보안 문제(1.3항 및 1.4항의 정의 참고)를 야기한다고 결정할 경우 ICANN은 결정 5일 내 또는 15일의 예비 결정 기간이 지난 후 2일 내(둘 중 이른 날짜)에 제안서를 레지스트리 서비스 기술 평가 패널(1.5항의 정의 참고)로 회부하고 동시에 제안서에 대한 공개 의견을 수렴해야 합니다.

레지스트리 서비스 기술 평가 패널은 회부 후 45일 이내에 제안된 레지스트리 서비스의 보안 또는 안정성(1.2항 및 1.3항의 정의 참고) 영향에 대한 서면 보고서를 준비할 시간이 있습니다. 이 보고서는 공개 의견 요약과 함께 ICANN 이사회로 전달됩니다. 보고서는 레지스트리 서비스 기술 평가 패널이 활용한 분석, 근거, 정보에 대한 상세한 설명을 비롯하여 ICANN 직원이 회부할 때 포함된 구체적인 질문에 대한 응답과 함께 패널의 의견을 발표해야 합니다. ICANN에서 레지스트리 서비스 기술 평가 패널로 회부하면 레지스트리 운영자는 레지스트리 서비스의 보안 또는 안정성 영향에 관한 추가 정보나 분석을 제출할 수 있습니다.

제안된 레지스트리 서비스 평가가 끝나면 레지스트리 서비스 기술 평가 패널은 레지스트리 서비스가 보안 또는 안정성에 주는 영향의 정도와 가능성에 대해 보고해야 합니다. 제안된 레지스트리 서비스가 보안이나 안정성에 유의미한 부정적인 영향을 줄 가능성이 실재하는지 여부도 포함해야 합니다(시행 노트 5~7단계 참고).

2.7 ICANN 이사회 결정

접수된 레지스트리 서비스 기술 평가 패널 보고서는 (레지스트리 운영자와 상담 후 기밀 유지를 위한 개정을 거쳐) 공개 의견 수렴을 위해 게시되며 ICANN 이사회는 접수 후 30일 이내에 결정을 내려야 합니다. ICANN 이사회가 제안된 레지스트리 서비스가 안정성 또는 보안에 유의미한 부정적 영향을 줄 수 있다고 결정할 경우 레지스트리 운영자는 제안된 레지스트리 서비스를 제공할 수 없습니다.

레지스트리 서비스 기술 평가 패널 보고서의 개정된 버전은 보고서를 게시할 때 레지스트리 운영자에게 제공됩니다. 레지스트리 운영자는 레지스트리 서비스 기술 평가 패널의 보고서에 응답하거나 ICANN 이사회에 레지스트리 서비스의 보안 또는 안정성 영향 가능성에 관한 추가 정보나 분석을 제출할 수 있습니다.

3. 재심의

제안된 새로운 레지스트리 서비스에 대한 ICANN의 결정으로 영향을 받는 gTLD 레지스트리 운영자 또는 레지스트리 후원 조직은 ICANN 조례에 따라 기존 재심의 프로세스를 이용할 수 있습니다.

재심의 프로세스에 대한 정보의 공식 출처는 ICANN 조례입니다(4조: 2항http://www.icann.org/general/bylaws.htm#IV 참고). 재심의는 ICANN 정책에 반하는 직원의 행동 또는 중요 정보를 고려하지 않고 이루어진 ICANN 이사회의 행동에 적용됩니다. 과거 재심의 프로세스에 대한 정보는 http://www.icann.org/committees/reconsideration 에서 참고할 수 있습니다.

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