레지스트리 서비스 평가 정책 - ICANN 
 레지스트리 서비스 평가 정책 
 RSEP 프로세스 웹 페이지 
 ( 2006 년 7 월 25 일 게시 , 2006 년 8 월 15 일 발효 ) 
 1 . 1 레지스트리 서비스 가 다음 과 같이 정의 되 었 습니다 . 
 다음 에 모두 해당 하 는 서비스 : ( i ) 다음 작업 에 있 어 필수 적 인 레지스트리 의 운영 : 레지스 트라 에게서 도메인 이름 및 이름 서버 등록 과 데이터 접수 , TLD 에 대한 영역 서버 와 관련 된 상태 정보 의 레지스 트라 에 프로비저닝 , TLD 영역 파일 의 배포 , 레지스트리 영역 서버 운영 , 레지스트리 계약 에 따라 요구 되 는 TLD 에서 의 도메인 이름 서버 등록 과 관련 된 연락처 및 기타 정보 배포 및 ( ii ) 상황 에 따라 레지스트리 운영 자 가 레지스트리 계약 발효 일자 를 기준 으로 제공 , 
 합의 정책 ( 위 정의 참고 ) 이 수립 되 어 레지스트리 운영 자 가 제공 해야 하 는 기타 제품 또는 서비스 , 
 레지스트리 운영 자 로 지정 되 었 기 때문 에 레지스트리 운영 자 만 제공 할 수 있 는 기타 제품 또는 서비스 , 
 위 ( A ) , ( B ) 또는 ( C ) 범위 내 에서 레지스트리 서비스 에 대한 중대 변경 사항 ( http : / / www . icann . org / minutes / resolutions - 08 nov 05 . htm 에 있 는 2005 년 11 월 8 일 ICANN 이사회 에서 지정 한 . NET 계약 의 정의 를 따름 ) 
 1 . 2 보안 - 제안 된 레지스트리 서비스 의 보안 영향 이란 ( A ) 레지스트리 데이터 의 무단 공개 , 변경 , 삽입 , 폐기 또는 ( B ) 적용 가능 한 모든 표준 에 따른 시스템 운영 을 통해 인터넷 정보 또는 리소스 에 대한 무단 액세스 또는 공개 를 말 합니다 . ( http : / / gnso . icann . org / issues / registry - services / final - rpt - registry - approval - 10 july 05 . htm # 5 에 있 는 GNSO 제안 의 정의 를 따름 ) . 
 1 . 3 안정 성 - 제안 된 레지스트리 서비스 의 안정 성 영향 이 란 다음 을 의미 합니다 . ( A ) 관련 표준 트랙 또는 IETF 가 후원 하 는 최상 현행 규정 RFC 와 같이 잘 수립 되 고 알려진 권위 기준 단체 가 인정 하 고 공표 한 관련 기준 에 따르 지 않 거나 ( B ) 처리 량 , 반응 시간 , 또는 관련 표준 트랙 또는 IETF 가 후원 하 는 최상 현행 규정 RFC 와 같이 잘 수립 되 고 알려진 권위 기준 단체 가 인정 하 고 공표 한 관련 기준 에 따라 운영 하 고 레지스트리 운영 자 의 위임 정보 또는 프로비저닝 서비스 에 의지 하 는 인터넷 서버 또는 최종 시스템 의 응답 일관 성 에 반대 로 작용 하 는 상황 을 만듭니다 . ( http : / / gnso . icann . org / issues / registry - services / final - rpt - registry - approval - 10 july 05 . htm # 5 에 있 는 GNSO 제안 의 정의 를 따름 ) . 
 1 . 4 레지스트리 서비스 기술 평가 패널 - 레지스트리 서비스 기술 평가 패널 은 인터넷 인프라 및 DNS ( " 레지스트리 서비스 기술 평가 패널 ") 에서 활용 되 는 복잡 한 시스템 및 표준 프로토콜 에 대한 디자인 , 관리 및 실행 분야 의 전문가 20 명 으로 구성 됩니다 . 레지스트리 서비스 기술 평가 패널 구성원 은 의장 이 지명 합니다 . 레지스트리 서비스 기술 평가 패널 의장 은 ICANN 과 당시 최상위 도메인 레지스트리 정책 을 담당 하 는 지원 기구 의 레지스트리 지지 그룹 이 모두 동의 하 는 사람 이 어야 합니다 . 레지스트리 서비스 기술 평가 패널 의 모든 구성원 과 의장 은 보안 및 안전 성 의 정의 에 따라 패널 보다 먼저 문제 를 고려 하 도록 요구 하 는 합의 를 진행 해야 합니다 . 레지스트리 서비스 기술 평가 패널 로 회부 되 는 각 사안 에 대해 의장 은 관련 문제 를 평가 할 레지스트리 서비스 기술 평가 패널 구성원 을 5 명 이하 로 지정 해야 하 는데 , 이 들 은 기존 의 경쟁 , 재무 또는 법 적 이해관계 의 상충 이 없 고 제기 된 특정 기술 문제 와 관련 한 책임 이 없 는 사람 이 어야 합니다 . ( http : / / gnso . icann . org / issues / registry - services / final - rpt - registry - approval - 10 july 05 . 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 에 서면 으로 통보 한 후 : 
 ICANN 은 15 일 이내 에 레지스트리 서비스 를 위해 ICANN 의 추가 고려 가 필요 한지 " 예비 결정 " 을 내려야 합니다 . 추가 고려 가 필요 한 경우 는 해당 레지스트리 서비스 가 다음 에 해당 하 는 경우 입니다 . ( i ) 심각 한 보안 또는 안전 성 문제 를 일으킬 수 있 는 경우 ( ii ) 심각 한 경쟁 문제 를 일으킬 수 있 는 경우 
 레지스트리 운영 자 는 제안 된 레지스트리 서비스 를 시행 할 수 있 음 을 ICANN 에 통보 하 는 시점 에 ICANN 이 정보 를 바탕 으로 예비 결정 을 내릴 수 있 도록 충분 한 정보 를 제공 해야 합니다 . 레지스트리 운영 자 가 제공 한 " 기밀 " 로 표기 된 정보 는 ICANN 도 기밀 로 취급 해야 합니다 . 레지스트리 운영 자 는 제안 된 레지스트리 서비스 의 목적 및 DNS 사용 자 에게 미치 는 영향 을 설명 하 기 위해 반드시 " 기밀 " 정보 를 지정 하 지 는 않 습니다 . 
 ICANN 은 " 예비 결정 " 을 위해 레지스트리 서비스 의 경쟁 , 보안 또는 안정 성 영향 에 관하 여 예비 결정 기간 동안 ( 기밀 계약 대상 단체 나 개인 으로부터 ) 전문가 조언 을 구할 수 있 습니다 . ICANN 에서 기밀 정보 를 이러 한 전문가 에게 공개 할 때 는 레지스트리 운영 자 에게 전문가 의 신원 과 공개 할 정보 를 알려야 합니다 . 보안 및 안정 성 영향 을 위해 ICANN 은 아래 2 . 4 ( F ) 에 설명 된 레지스트리 서비스 기술 평가 패널 로부터 전문가 를 고용 할 수 있 습니다 . 
 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 에서 참조 하 십시오 .