참고: 본 문서는 아래 링크에 명시되어 있는 이전 정책과 관련된 레지스트라 요구 사항을 요약합니다. 본 문서 내에 요약된 조항은 해당 정책에 명시된 조항을 재정의하거나 대체하지 않습니다. 해당 정책의 전문을 참조하여 레지스트라 요구 사항을 검토하고 이해하십시오.

전체 정책 위치: https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en

이 섹션에서는 다음 내용을 다룹니다.

등록자 변경(섹션 II)

정의:

• 등록자 변경 - 주요 변경 사항:

• 단순한 인쇄상 오타 정정이 아닌 것으로 보이는 등록명 보유자의 이름 또는 조직의 변경

• 주소 또는 전화번호 변경이 수반되는 등록명 보유자의 이름 또는 조직의 변경

• 등록명 보유자의 이메일 주소의 변경

등록자 변경의 가용성:

- 일반적으로 등록자는 등록/Whois 데이터를 업데이트하고 다른 등록자에게 자유롭게 이전하도록 허용되어야 합니다.

- 다음과 같은 경우 레지스트라는 등록자 변경 요청을 거부해야 합니다.

등록자 변경 프로세스

(1)     도메인 이름이 등록자 변경에 적합한지 확인합니다.

(2)     보안 메커니즘을 통해 신규 등록자(또는 지정된 대리인)이 등록자 변경에 명시적으로 동의한다는 사실을 확인합니다.

(3)     이전 등록자(또는 지정된 대리인)에게 도메인 이름을 다른 레지스트라에게 이전하는 것이 최종 목표인 경우 등록자 변경 전에 레지스트라간 이전을 요청하여 II.C.1.2에서 설명한 60일 잠금이 시작되지 않도록 하는 것이 좋음을 알립니다(레지스트라가 이전 등록자에게 옵트아웃할 수 있는 옵션을 제공하고 이전 등록자가 60일 잠금을 옵트아웃한 경우 제외).

(4)     보안 메커니즘을 통해 이전 등록자(또는 지정된 대리인)이 등록자 변경에 명시적으로 동의한다는 사실을 확인합니다.

(5)     확인을 받은 후 1일 이내에 등록자 변경을 처리합니다.

(6)     II.C.1.1.6에 따라 이전 등록자와 신규 등록자에게 통보합니다.

(7)     II.C.2에 따라 이름을 잠급니다(해당되는 경우).

다음 상황에서는 등록자 변경 프로세스(섹션 II.C.1.1)가 적용되지 않습니다.

레지스트라가 등록명 보유자에게 알림(섹션 II.C)

• 1.1.2 및 1.1.4 –

60일 레지스트라간 이전 잠금(II C 2)

• 레지스트라는 등록자 변경 후 60일 레지스트라간 이전 잠금을 부과해야 합니다.

• 레지스트라는 등록자 변경을 요청하기 전에 이전 등록자에게 잠금 “옵트아웃” 옵션을 제공할 수 있습니다.

• “옵트아웃” 옵션을 제공하고 이전 등록자가 잠금을 옵트아웃한 경우 레지스트라는 레지스트라 잠금을 부과하지 않을 수도 있습니다.

레지스트라간 이전(섹션 I.A.1-4) 

이전 권한(이전 담당자)

관리 담당자와 RNH(등록명 보유자)는 레지스트라간 이전 요청을 승인하거나 거부할 수 있습니다.  그러나 분쟁 발생 시 등록명 보유자의 권한이 관리 담당자의 권한보다 우선합니다.

인가 획득 레지스트라

• 이전 담당자로부터 내향적 이전 요청을 받는 경우, "레지스트라 이전에 대한 초기 허가"라는 표준 영어 버전의 템플릿 FOA를 보내 허가를 받아야 합니다.

• 레지스트라는 다음으로 넘어가기 전에 이전 담당자로부터 확인을 받아야 합니다.

• 인가 획득 FOA는 다음 조건 중 하나(섹션 I A)가 발생하면 만료됩니다.

• 레지스트리에 "이전" 요청을 제출하기 전에 위에 설명된 상황 중 하나에 따라 FOA가 만료된 경우 이전을 진행하려면 인가 획득 레지스트라가 새로운 FOA를 통해 이전 요청을 다시 허가해야 합니다.

자격 상실 레지스트라

• 레지스트리 운영자로부터 외향적 이전 요청을 받는 경우, 24시간 이내에 "레지스트라 이전 요청 확인"이라는 표준 영어 버전의 템플릿 FOA를 보내야 합니다.

• RNH가 이전을 미리 승인하는 경우, 레지스트라는 미리 승인된 이전이 시작되었음을 RNH에게 알리는 수정된 FOA 버전을 보낼 수 있습니다.

• 자격 상실 레지스트라가 이전 담당자로부터 확인을 받지 못하고 레지스트라가 이전 요청을 명시적으로 거부하지 않은 경우 5일이 지나면 기본적으로 레지스트라가 이전 진행을 허용해야 합니다. 이것이 기본 이전 "승인"입니다.

• 자격 상실 레지스트라는 다음 이유 중 하나에 따라 이전 요청을 거부(NACK)할 수 있습니다. (섹션 I.A.3.7)

• 3.8.1 레지스트라가 UDRP 처리 절차가 보류 중임을 통보받은 경우..

이전 긴급 조치 담당자

• 레지스트라는 이전과 관련한 긴급한 의사소통을 위해 이전 긴급 조치 담당자("TEAC")를 지정합니다. TEAC의 목표는 비상 시에 레지스트라 간에 양자가 이해할 수 있는 언어로 빠르게 실시간 연락을 주고받는 것입니다. 그다음, 기존(또는 향후) 이전 분쟁 또는 취소 절차 시작을 포함하여 해결을 위해 추가 조치가 취해질 수 있습니다.

• TEAC와의 의사소통은 ICANN 인가 레지스트라, gTLD 레지스트리 운영자 및 ICANN 직원만 할 수 있습니다. TEAC 연락처는 전화번호 또는 기타 실시간 통신 채널로 지정될 수 있습니다. 도메인에 대한 무단 손실이 추정되는 경우 TEAC와의 의사소통이 합당한 시간 내에 시기 적절하게 개시되어야 합니다.

• TEAC 통신 채널을 통해 보낸 메시지에는 자동 응답이 아니라 인가 획득 레지스트라의 담당자가 직접 응답해야 합니다. 사고에 대한 최종 해결은 더 오래 걸릴 수 있으나 첫 요청 후 4시간 내에는 응답해야 합니다.

• TEAC 의사소통에 응답하지 못할 경우 본 정책의 섹션 I.A.6.4에 따라 이전이 취소될 수 있고 ICANN의 추가 조치가 초래될 수 있습니다.

• 양 당사자는 TEAC와의 의사소통과 응답을 서면 또는 전자 형태로 보존해야 하고 요청 시 이 문서 사본을 ICANN 및 레지스트리 운영자와 공유해야 합니다.

"ClientTransferProhibited" 상태 및 "AuthInfo" 코드에 대한 요구 사항(섹션 I.A.5)

• 레지스트라가 등록 계약에 그러한 상태를 부과하는 약관을 포함하고 등록명 보유자의 동의를 얻은 경우, 레지스트라는 등록 시 또는 RNH의 후속 요청 시 도메인 이름에 "ClientTransferProhibited" 상태만 부과할 수 있습니다.

• 레지스트라는 등록명 보유자의 첫 요청 후 5일 내에 "ClientTransferProhibited" 상태를 제거하고 등록명 보유자에게 고유한 "AuthInfo" 코드를 제공해야 합니다. (등록명 보유자가 직접 고유한 “Authinfo” 코드를 생성하고 “ClientTransferProhibited” 상태를 제거할 수 있는 시설을 레지스트라가 제공하지 않은 경우).

• 레지스트라는 RNH의 "ClientTransferProhibited" 상태 제거 또는 해당 "AuthInfo 코드" 요청 획득 요청에 응하기 위해 RNH의 연락처 또는 네임 서버 정보의 일부를 변경하는 데 사용하는 방법보다 제한적인 어떠한 방법도 사용할 수 없습니다.

• 레지스트라가 생성한 "AuthInfo" 코드는 도메인별로 고유해야 합니다.

• "AuthInfo" 코드는 RNH를 확인하는 데에만 사용해야 합니다.

• 레지스트라는 지불 관련 분쟁이 있다는 이유만으로 "ClientTransferProhibited" 상태를 제거하거나 "AuthInfo 코드"를 공개하는 것을 거부할 수 없습니다.

ICANN에서 승인한 이전(섹션 I.B)

• 다음과 같은 경우 레지스트라는 주관하는 모든 등록을 다른 레지스트라에게 이전할 수 있습니다.

• 레지스트라는 다음 절차를 사용합니다.