Skip to main content
Resources

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

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

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

RSEP 프로세스 웹페이지

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

1. 정의

1.1 레지스트리서비스가 다음과 같이 정의되었습니다.

  1. 다음에 모두 해당하는 서비스: (i) 다음 작업에 있어 필수적인 레지스트리의 운영: 레지스트라에게서 도메인 이름 및 이름 서버 등록과 데이터 접수, TLD에 대한 영역 서버와 관련된 상태 정보의 레지스트라에 프로비저닝, TLD 영역 파일의 배포, 레지스트리 영역 서버 운영, 레지스트리 계약에 따라 요구되는 TLD에서의 도메인 이름 서버 등록과 관련된 연락처 및 기타 정보 배포 및 (ii) 상황에 따라 레지스트리 운영자가 레지스트리 계약 발효 일자를 기준으로 제공,
  2. 합의 정책(위 정의 참고)이 수립되어 레지스트리 운영자가 제공해야 하는 기타 제품 또는 서비스,
  3. 레지스트리 운영자로 지정되었기 때문에 레지스트리 운영자만 제공할 수 있는 기타 제품 또는 서비스,
  4. 위 (A), (B) 또는 (C) 범위 내에서 레지스트리 서비스에 대한 중대 변경 사항 (http://www.icann.org/minutes/resolutions-08nov05.htm에 있는 2005년 11월 8일 ICANN 이사회에서 지정한 .NET 계약의 정의를 따름)

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 레지스트리 서비스를 도입할 수 있습니다(RSEP 실행 정보 소개 참조).

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

2.4항에서 설명된 바와 같이 gTLD 레지스트리 운영자 또는 후원 조직은 ICANN과 협의하여 서비스 변경에 대한 승인 여부를 ICANN과 레지스트리 운영자의 계약을 기반으로 결정합니다(RSEP 실행 정보 소개 참조).

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

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

gTLD 레지스트리 운영자 또는 후원 조직은 변경에 관한 충분한 정보를 ICANN에 제공하여 ICANN이 이를 위해 승인 프로세스가 필요할지 평가할 수 있도록 해야 합니다. 정보는 외부 사용자에게 표시되는 변경 사항에 대한 기술적인 설명과 외부 사용자에 대한 영향 평가를 포함해야 합니다. 레지스트리 운영자 또는 후원 조직이 외부나 커뮤니티의 피드백을 받은 경우 해당 피드백의 프로세스와 결과에 대한 상세한 내용을 포함해야 합니다. 정보 프로세스의 이 단계는 ICANN 직원이 기밀 사항으로 간주합니다(RSEP 실행 정보 1단계 및 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 이사회로 전달됩니다(RSEP 실행 정보 5단계 참조).

2.5 경쟁문제

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

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

회부한 후 ICANN은 더 이상 책임이 없고 레지스트리 운영자는 더 이상 레지스트리 서비스와 관련된 경쟁 문제에 대해 ICANN에 대한 의무가 없습니다. 회부할 경우 레지스트리 운영자는 회부된 정부 경쟁 기관이 사전에 승인하지 않는 이상 회부 이후 45일 동안 레지스트리 서비스를 배포하지 않습니다(RSEP 실행 정보 4-6단계 참조).

2.6 보안및안정성문제

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

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

제안된 레지스트리 서비스에 대한 평가 시, 레지스트리 서비스 기술 평가 패널은 보안 및 안정성에 대한 제안된 레지스트리 서비스 영향의 가능성 및 구체성을 보고합니다. 제안된 레지스트리 서비스가 보안 및 안정성에 대해 중대한 부정적 영향으로 인한 합리적인 위험을 만드는 경우도 포함됩니다(RSEP 실행 정보 4-6단계 참조).

2.7 ICANN 이사회결정

접수된 레지스트리 서비스 기술 평가 패널 보고서는 (레지스트리 운영자와 상담 후 기밀 유지를 위한 개정을 거쳐) 공개 의견 수렴을 위해 게시되며 ICANN 이사회는 접수 후 30일 이내에 결정을 내려야 합니다. 제안된 레지스트리 서비스가 보안 및 안정성에 대해 중대한 부정적 영향으로 인한 합리적인 위험을 만든다고 ICANN 이사회에서 합리적으로 판단한 경우, 레지스트리 운영자는 제안된 레지스트리 서비스를 제공하지 않습니다.

레지스트리 서비스 기술 평가 패널 보고서의 개정된 버전은 보고서를 게시할 때 레지스트리 운영자에게 제공됩니다. 레지스트리 운영자는 레지스트리 서비스 기술 평가 패널의 보고에 응답하거나 레지스트리 서비스의 보안 및 안정성에 대한 영향 가능성(RSEP 실행 정보 5단계 참조)과 관련된 추가 정보 또는 분석을 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."