이전 정책

1. 레지스트라간 이전

   1. 보유자가 허가한 이전

      1. 레지스트라 요구 사항

         등록명 보유자는 레지스트라간 도메인 이름 등록을 이전할 수 있어야 합니다. 단, 인가 획득 레지스트라의 이전 프로세스가 본 정책의 최소 기준을 충족해야 하고 ICANN이나 레지스트리 정책에 따라 이전이 금지되지 않아야 합니다. 레지스트라간 도메인 이름 이전 프로세스는 혼동을 방지할 수 있도록 명확하고 간결해야 합니다. 또한 레지스트라는 레지스트라가 사용하는 구체적인 이전 프로세스에 관해 공개된 문서에 대해 등록명 보유자에게 알리고 그에 대한 액세스를 제공하기 위해 합당한 노력을 기울여야 합니다.

         1.1 이전 권한

         자격 상실 레지스트라 또는 해당 레지스트리(해당되는 경우)의 공개 Whois 서비스에 등록된 관리 담당자와 등록명 보유자는 인가 획득 레지스트라에 대한 이전 요청을 승인하거나 거부할 수 있는 유일한 당사자입니다. 분쟁 발생 시 등록명 보유자의 권한이 관리 담당자의 권한보다 우선합니다.

         레지스트라는 이전 요청의 진위를 확인하기 위한 목적으로 공식 기록상 레지스트라 또는 관련 레지스트리의 Whois 데이터를 사용할 수 있고 합의 정책에 따라 결정되는 다른 데이터 출처의 데이터를 사용할 수도 있습니다.

      2. 인가 획득 레지스트라 요구 사항

         등록명 보유자가 도메인 이름 등록을 다른 레지스트라에게 이전하도록 요청하는 각 사례에 대해 인가 획득 레지스트라는 다음과 같이 해야 합니다.

         2.1 등록명 보유자나 관리 담당자(이하 "이전 담당자")로부터 명시적인 허가를 얻습니다. 따라서 이전은 인가 획득 레지스트라가 이전 담당자로부터 이전 확인을 받은 경우에만 진행할 수 있습니다.

         2.1.1 허가는 반드시 유효한 표준 허가 양식(FOA)을 통해 이루어져야 합니다. ICANN 웹사이트에서 사용 가능한 FOA는 두 가지입니다. "레지스트라 이전에 대한 초기 허가"라고 표시된 FOA는 인가 획득 레지스트라가 이전 담당자로부터 레지스트라 이전에 대한 허가를 요청할 때 사용해야 합니다. "레지스트라 이전 요청 확인"이라고 표시된 FOA는 공식 기록상 레지스트라가 이전 담당자로부터 이전에 대한 확인을 요청할 때 사용해야 합니다.

         FOA는 영어로 작성되어야 하며 이전 요청과 관련하여 분쟁이 발생하는 경우 해당 분쟁도 영어로 진행되어야 합니다. 레지스트라는 다른 추가 언어로 이전 담당자와 통신할 수 있습니다. 하지만 이 경우 영어가 아닌 다른 언어로 번역된 FOA 버전의 정확성과 완전성에 대한 책임은 다른 언어를 사용하도록 선택한 레지스트라에게 있습니다.

         2.1.2 인가 획득 레지스트라가 본 허가를 획득하기 위해 물리적인 절차를 이용할 경우 FOA의 종이 사본으로 충분하나, 이전 담당자가 해당 사본에 서명해야 하고 문제의 도메인 이름에 대해 공식 기록상 레지스트라 Whois 출력의 물리적 사본도 포함되어야 합니다.

         2.1.2.1 인가 획득 레지스트라가 물리적인 허가 절차를 이용할 경우 인가 획득 레지스트라는 이전 담당자의 믿을 수 있는 신원 증명을 확보하고 이를 확보했음을 증명하는 적절한 기록을 유지할 책임이 있습니다. 또한 인가 획득 레지스트라는 요청을 하는 법인이 그러한 요청을 할 권한이 있음을 확인할 책임도 있습니다. 인정 가능한 물리적 신원 양식은 다음과 같습니다.

         1. 공증 진술서
         2. 유효한 운전 면허증
         3. 여권
         4. 정관
         5. 군인 신분증
         6. 주/정부 발행 신분증
         7. 출생 증명서

         2.1.3.1 인가 획득 레지스트라가 본 허가를 얻기 위해 전자적인 절차를 이용할 경우 인정 가능한 신원 양식은 다음과 같습니다.

         1. 인가 획득 레지스트라가 있는 지역의 국가 법률을 준수하는 전자 서명(관련 법률이 있는 경우).
         2. 이전 담당자 이메일 주소와 일치하는 이메일 주소를 가진 개인이나 법인의 동의.

         2.1.3.2 공식 기록상 레지스트라는 인가 획득 레지스트라가 위에 규정된 확인을 받지 못한 것으로 판단된다는 이유만으로 이전 요청을 거부할 수 없습니다.

         2.1.3.3 인가 획득 레지스트라가 확인을 받지 못한 경우 이전 진행이 허용되어서는 안 됩니다. 모든 경우에서 인가 획득 레지스트라가 이전 담당자에 의한 이전 요청을 받고 인증했다고 추정합니다.

         2.2 레지스트라 툴 키트에서 지정된 "이전" 명령의 전송을 통해 레지스트리 운영자의 데이터베이스를 새로운 레지스트라를 반영하도록 변경해 달라고 요청합니다.

         2.2.1 "이전" 명령의 전송은 인가 획득 레지스트라 측에서 공식 Whois 데이터베이스에 등록된 이전 담당자로부터 필수 허가를 얻었음을 나타내는 것으로 해석됩니다.

         2.2.2 인가 획득 레지스트라는 레지스트라간 도메인 이름 이전에 대한 등록명 보유자 요청을 검증할 책임이 있습니다. 하지만 공식 기록상 레지스트라는 본 정책의 섹션 I.A.3("공식 기록상 레지스트라의 의무")에 따라 인가 획득 레지스트라에게 도메인 이름을 이전하겠다는 등록명 보유자의 의도를 별도로 확인해야 합니다.

         2.2.3 "레지스트라 이전에 대한 초기 허가"라고 표시된 FOA는 다음과 같은 상황에서 만료됩니다.

         2.2.3.1 인가 획득 레지스트라가 FOA의 자동 갱신을 허용하지 않고 등록명 보유자가 자동 갱신을 명시적으로 선택하지 않은 상태에서 인가 획득 레지스트라가 FOA를 발행한 후 60일이 경과한 경우

         2.2.3.2 레지스트라간 이전이 완료되기 전에 도메인 이름이 만료되는 경우

         2.2.3.3 섹션 II.C.의 등록자 변경이 완료된 경우

         2.2.3.4 레지스트라간 이전이 완료된 경우

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

      3. 공식 기록상 레지스트라의 의무

         3.1 공식 기록상 레지스트라는 레지스트리로부터 보류 중인 이전에 대한 통지를 받으면 등록명 보유자에게 이전에 대해 통보하여 등록명 보유자의 의도를 확인해야 합니다. 공식 기록상 레지스트라는 이 정책에 규정된 기준에 따라 그러한 확인을 수행해야 합니다.

         3.2 공식 기록상 레지스트라가 사용하는 요청 양식의 성격이 충분히 행정적이고 유용한 정보를 제공하며 이전 담당자에게 이전 담당자의 의도 확인을 목적으로 해당 양식이 명확히 제공되도록 하기 위해 공식 기록상 레지스트라는 반드시 FOA를 사용해야 합니다.

         3.3 FOA는 영어로 작성되어야 하며 이전 요청과 관련하여 분쟁이 발생하는 경우 해당 분쟁도 영어로 진행되어야 합니다. 레지스트라는 다른 추가 언어로 이전 담당자와 통신할 수 있습니다. 하지만 이 경우 영어가 아닌 다른 언어로 번역된 FOA 버전의 정확성과 완전성에 대한 책임은 다른 언어를 사용하도록 선택한 레지스트라에게 있습니다. 또한 타 언어로 이루어지는 통신은 본 정책에 규정된 절차를 따라야 합니다. 여기에는 어떤 레지스트라도 이전 요청 시 이전 담당자의 동의를 얻기 위해 사용된 FOA에 추가 정보를 추가할 수 없다는 요구 사항이 포함되며 이에 국한되지 않습니다.

         등록명 보유자가 이전을 미리 승인하는 경우 공식 기록상 레지스트라는 미리 승인된 이전이 시작되었음을 등록명 보유자에게 알리는 수정된 FOA 버전을 보낼 수 있습니다.

         이 요구 사항이 공식 기록상 레지스트라가 별도의 연락을 통해 기존 고객에게 마케팅하는 것을 불가능하게 하는 것은 아닙니다.

         3.4 공식 기록상 레지스트라는 등록명 보유자에게 가능한 한 빨리 FOA를 전송해야 하며 레지스트리 운영자로부터 이전 요청을 받고 늦어도 24시간 내에 전송해야 합니다.

         3.5 공식 기록상 레지스트라가 이전 요청과 관련하여 레지스트리의 알림에 5일 내에 응답하지 못할 경우 기본적으로 이전이 "승인"됩니다.

         3.6 Whois에 등록된 이전 담당자가 공식 기록상 레지스트라에게 이전 요청을 확인하지 않고 공식 기록상 레지스트라가 이전 요청을 명시적으로 거부하지 않은 경우 기본적으로 공식 기록상 레지스트라는 이전 진행을 허용해야 합니다.

         3.7 아래 이유 중 하나로 이전 요청을 거부할 경우 공식 기록상 레지스트라는 등록명 보유자와 잠재적인 인가 획득 레지스트라에게 거부 사유를 밝혀야 합니다. 공식 기록상 레지스트라는 다음과 같은 특정한 경우에만 이전 요청을 거부할 수 있습니다.

         3.7.1 사기가 입증된 경우

         3.7.2 등록명 보유자
         또는 관리 담당자의 신원에 대해 합리적인 분쟁이 있는 경우.

         3.7.3 도메인 이름의 만료 일자가 경과했고 이전 등록 기간에 대해 지불이 이루어지지 않은 경우(신용 카드 지불 거절 포함) 또는 도메인 이름이 아직 만료되지 않았고 이전 또는 현재 등록 기간에 대해 지불이 이루어지지 않은 경우. 하지만 이 모든 경우에 공식 기록상 레지스트라는 이전 거부에 앞서 도메인 이름을 "레지스트라 홀드(HOLD)" 상태로 지정해야 합니다.

         3.7.4 권한 있는 이전 담당자가 이전에 대해 이의를 표명한 경우. 이의는 권한 있는 이전 담당자가 특정 요청 양식(종이 또는 전자 수단)을 사용하여 제기할 수 있으며 특정 이전 요청에 대한 거부이거나 레지스트라가 받은 모든 이전 요청에 대한 일시적 또는 무기한의 일반적인 이의일 수 있습니다. 모든 경우에 옵트인 및 권한 있는 이전 담당자의 요청에 따라 권한 있는 이전 담당자의 명시적인 사전 동의와 함께 이의를 제기해야 하며, 레지스트라는 5일 이내에 잠금을 해제하거나 잠금을 해제할 수 있는 합리적으로 액세스 가능한 방법을 권한 있는 이전 담당자에게 제공해야 합니다.

         3.7.5 이전 요청이 도메인 이름에 대한 레지스트리 Whois 기록에 표시된 생성 날짜로부터 60일 내에 이루어진 경우.

         3.7.6 이전된 지 60일(또는 더 짧은 기간을 추후 결정)이 안 된 도메인 이름인 경우(두 레지스트라가 합의하거나 분쟁 해결 절차에 따라 결정되어 다시 원래의 레지스트라에게 이전된 경우 제외). "이전됨"은 레지스트라간 이전이 본 정책의 절차에 따라 이루어졌음을 의미합니다.

         3.8 공식 기록상 레지스트라는 다음 상황에서 이전 요청을 거부해야 합니다.

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

         3.8.2 관할 법원의 법원 명령이 있는 경우.

         3.8.3 이전 분쟁 해결 정책에 따라 이전의 이전과 관련된 분쟁이 보류 중인 경우.

         3.8.4 레지스트라가 본 정책의 절차에 따라 등록자 변경 후 60일 레지스트라간 이전 잠금을 부과한 경우.

         3.8.5 레지스트라는 등록자 변경 후 60일 레지스트라간 이전 잠금을 부과했습니다. 그리고 등록명 보유자는 등록자 변경 요청 전에 60일 레지스트라간 이전 잠금을 옵트아웃하지 않았습니다.

         3.9 요청된 레지스트라 변경을 거부할 수 없는 경우는 다음을 포함하나 이에 국한되지 않습니다.

         3.9.1 보류 기간 또는 향후 등록 기간에 대한 미지불.

         3.9.2 등록명 보유자 또는 관리 담당자의 무응답.

         3.9.3 이전 요청을 하기 전에 등록명 보유자에게 도메인 이름 잠금을 해제할 합당한 기회와 잠금 해제 기능을 제공하지 않은 경우의 Registrar Lock(레지스트라 잠금) 상태에 있는 도메인 이름.

         3.9.4 초기 등록 후 처음 60일 동안, 레지스트라 이전 후 처음 60일 동안 또는 등록자 변경 후 60일 잠금 기간 동안 이외에 섹션 II.C.2에 따라 요구되는 도메인 이름 등록 기간 제한.

         3.9.5 문제의 도메인의 등록명 보유자가 등록에 대해 지불한 경우의 레지스트라와 비즈니스 파트너/계열사 간 일반적인 지급 불이행.

         3.10 공식 기록상 레지스트라는 이전 절차와는 별개로 등록명 보유자로부터 지불을 받기 위해 사용 가능한 다른 메커니즘을 보유합니다. 따라서 지불에 대한 분쟁이 발생할 경우 공식 기록상 레지스트라는 이전 절차를 등록명 보유자로부터 서비스에 대해 안전하게 지불 받기 위한 메커니즘으로 이용하면 안 됩니다. 이 요구 사항에 대한 예외는 다음과 같습니다.

         3.10.1 이전 등록 기간에 대한 미지불의 경우에 이전이 만료일 이후 요청된 경우 또는

         3.10.2 현재 등록 기간에 대한 미지불의 경우에 이전이 만료일 이전에 요청된 경우.

      4. 레지스트라 조정

         4.1 각 레지스트라는 FOA 및 그에 대한 이전 담당자의 응답을 포함하여 분쟁 해결 정책에 따라 관련 자료 보관과 증빙에 필요할 수 있는 서류 사본을 유지할 책임이 있습니다. 인가 획득 레지스트라는 계약의 표준 문서 보존 정책에 따라 이전 담당자로부터 수신한 FOA 사본을 반드시 유지해야 합니다. FOA와 함께 신뢰할 수 있는 신원 증명 자료 사본도 보관해야 합니다.

         4.2 인가 획득 레지스트라와 공식 기록상 레지스트라 모두 해당되는 레지스트라간 도메인 이름 거래 도중과 이후에 이전을 위해 사용되는 증거를 제공해야 합니다. 그러한 정보는 이전 거래의 당사자인 한쪽 레지스트라가 요청할 경우 반드시 상대쪽 레지스트라가 제공해야 합니다. 또한 ICANN, 레지스트리 운영자, 법원 또는 사안에 대한 관할권을 가진 당국 또는 제3자 분쟁 해결 패널도 요청 후 5일 내에 그러한 정보를 요구할 수 있습니다.

         4.3 인가 획득 레지스트라는 자격 상실 레지스트라의 요청에 따라 FOA의 서면 또는 전자 사본을 유지하고 생성해야 합니다. 공식 기록상 레지스트라가 FOA 사본을 요청한 경우 인가 획득 레지스트라는 공식 기록상 레지스트라의 요청(관련 증빙 서류 제공을 포함)을 5일 내에 이행해야 합니다. 지정된 기간 내에 이 서류를 제공하지 못하면 본 정책의 요구 사항에 따라 이전 불만이 접수될 경우 레지스트리 운영자 또는 분쟁 해결 패널이 이전을 취소할 수 있는 근거가 됩니다.

         4.4 공식 기록상 레지스트라 또는 인가 획득 레지스트라 중 한쪽에서 이전 요청이 본 정책에 따라 이행되지 않았다고 생각하는 경우 레지스트라는 본 정책의 섹션 I.C에 규정된 분쟁 해결 절차를 시작할 수 있습니다.

         4.5 레지스트라는 이전 요청을 돕기 위해 다른 레지스트라와 레지스트리만 사용할 수 있도록 고유의 개인 이메일 주소를 제공하고 유지관리해야 합니다.

         4.5.1 이 이메일 주소는 이전 요청과 본 정책에 규정된 절차와 관련된 문제에만 사용됩니다.

         4.5.2 이메일 주소는 이전 문제에 대응할 수 있는 사람이 메시지를 수신할 수 있도록 관리되어야 합니다.

         4.5.3 해당 이메일 주소로 수신된 메시지에는 7일을 초과하지 않도록 상업적으로 합당한 기간 내에 응답해야 합니다.

         4.6 이전 긴급 조치 담당자

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

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

         4.6.3 TEAC 통신 채널을 통해 보낸 메시지에는 자동 응답이 아니라 인가 획득 레지스트라의 담당자가 직접 응답해야 합니다. 응답하는 사람이나 팀은 이전에 관한 긴급한 문제를 조사하고 해결할 수 있는 능력과 권한이 있어야 합니다. 사고에 대한 최종 해결은 더 오래 걸릴 수 있으나 첫 요청 후 4시간 내에는 응답해야 합니다.

         4.6.4 자격 상실 레지스트라는 TEAC 통신에 응답하지 못할 경우 ICANN Compliance 및 레지스트리 운영자에 보고해야 합니다. TEAC 통신에 응답하지 못할 경우 본 정책의 섹션 I.A.6.4에 따라 이전이 취소될 수 있고 인가 비갱신 또는 종료를 포함하여 ICANN의 추가 조치를 초래할 수 있습니다.

         4.6.5 양 당사자는 TEAC 통신과 응답을 서면 또는 전자 형태로 보존해야 하고 요청 시 이 문서 사본을 ICANN 및 레지스트리 운영자와 공유해야 합니다. 이 문서는 레지스트리 인가 계약서(RAA)의 섹션 3.4에 따라 보존됩니다. TEAC 통신 채널 이용자는 레지스트라가 응답하지 않을 경우 ICANN에 보고해야 합니다. 또한 ICANN은 상황에 따라 적절한 방법으로 레지스트라 TEAC 통신 채널에 대한 주기적인 테스트를 수행하여 레지스트라가 실제로 TEAC 메시지에 응답하는지 확인할 수 있습니다.

      5. "ClientTransferProhibited" 상태 및 "AuthInfo" 코드에 대한 요구 사항

         5.1 ICANN 사양 또는 정책과 관련 법률 또는 규제에 따라 레지스트라는 아래 규정된 요구 사항을 준수해야 합니다.

         레지스트라는 등록 시 또는 등록명 보유자의 후속 요청 시 "ClientTransferProhibited" 상태로 도메인 이름을 설정할 수 있습니다. 단, 레지스트라는 등록 계약(등록명 보유자의 명시적 동의 획득)에 도메인 이름의 이전을 금지하는 약관을 포함해야 합니다. 또한, 등록명 보유자가 "ClientTransferProhibited" 상태를 제거할 수 있는 시설을 레지스트라가 제공하지 않은 경우 해당 레지스트라는 등록명 보유자의 첫 요청 후 5일 내에 "ClientTransferProhibited" 상태를 제거해야 합니다.

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

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

         5.4 공식 기록상 레지스트라는 단지 등록명 보유자와 레지스트라 간에 지불 관련 분쟁이 있다는 이유만으로 "ClientTransferProhibited" 상태를 제거하거나 "AuthInfo 코드"를 등록명 보유자에게 공개하는 것을 거부할 수 없습니다.

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

         5.6 "AuthInfo" 코드는 등록명 보유자를 확인하는 데만 사용해야 하며, 본 정책의 섹션 I.A.2 및 I.A.4에 설명된 것과 같이 이전 요청 허가 또는 확인을 위해서는 여전히 FOA를 사용해야 합니다.

      6. 레지스트리 요구 사항

         6.1 인가 획득 레지스트라의 "이전" 명령을 받으면 레지스트리 운영자는 두 레지스트라에 모두 전자적 통지를 전송합니다. 전자 우편 알림을 사용하는 레지스트리의 경우 각 레지스트라가 이전 진행을 돕기 위한 목적으로 설정한 고유 이메일 주소로 응답 알림을 발송할 수 있습니다.

         6.2 레지스트리 운영자는 레지스트리 운영자가 5일 내에 공식 기록상 레지스트라로부터 NACK 프로토콜 명령을 받지 않는 한 요청된 이전을 완료해야 합니다.

         6.3 레지스트리의 데이터베이스가 인가 획득 레지스트리로의 변경이 반영되어 업데이트되면 레지스트리 운영자는 두 레지스트라에 모두 전자적 통지를 전송합니다. 각 레지스트라가 이전 진행을 돕기 위한 목적으로 설정한 고유 이메일 주소 또는 당사자 간 합의한 기타 이메일 주소로 통지를 발송할 수 있습니다.

         6.4 레지스트리 운영자는 이전이 이루어진 후 레지스트리 운영자가 아래 기술된 통지 중 하나를 받는 경우 이전을 취소할 수 있습니다. 이 경우 이전이 취소되고 공식 기록상 레지스트라 필드가 원래의 상태로 돌아갑니다. 레지스트리 운영자는 통지 수령 후 5일 내에 이전을 취소해야 하지만 레지스트리 분쟁 결정이 있는 경우 예외로 합니다. 이 경우 레지스트리 운영자는 법원에 소송을 제기하지 않는 한 14일 내에 이전을 취소해야 합니다. 필요한 통지는 다음 중 하나입니다.

         6.4.1 공식 기록상 레지스트라와 인가 획득 레지스트라 간에 이전이 실수로 이루어졌거나 본 정책에 규정된 절차를 따르지 않고 이루어졌다는 합의를 밝힌 이메일, 서신, 팩스

         6.4.2 이전에 대해 관할권을 보유한 분쟁 해결 기관의 최종 결정

         6.4.3 이전에 대해 관할권을 보유한 법원의 명령

         6.4.4 이전에 앞서 인가 획득 레지스트라가 섹션A.4.6에 명시된 기간 내에 TEAC를 통한 메시지에 응답하지 않았다고 공식 기록상 레지스트라가 제공한 문서

      7. 등록 기록

         각 레지스트라는 해당 고객, 즉 등록명 보유자에게 초기 도메인 이름 등록 날짜를 기록하고 증명할 수 있는 자체 기록을 유지할 것을 요구해야 합니다.

      8. 등록 약관에 대한 영향

         레지스트리 운영자가 섹션 I.A에 따라 보유자가 허가한 이전을 완료하면 기존 등록이 1년 연장됩니다. 단, 어느 경우에도 등록의 만료되지 않은 총 기간이 10년을 초과할 수 없습니다.

   2. ICANN 승인 이전

      1. 특정 레지스트라 또는 그 자산을 다른 레지스트라가 인수하거나 (ii) 레지스트라가 인가를 받지 못했거나 레지스트리 운영자의 허가를 받지 못하여 해당 레지스트라가 후원하는 모든 등록의 후원이 이전되는 경우 아래 절차에 따라야 합니다.

         1.1 인가 획득 레지스트라는 레지스트리 TLD에 대해 ICANN의 인가를 받아야 하고 레지스트리 TLD에 대해 레지스트리 운영자와 유효한 레지스트리-레지스트라 계약을 맺어야 합니다.

         1.2 ICANN은 서면으로 레지스트리 운영자에게 해당 이전이 커뮤니티 이익을 증진할 것임을 증명해야 합니다(예: 레지스트라의 현재 또는 임박한 비즈니스 실패로 인한 안정성 위협에 이익이 됨).

      2. 이 두 조건을 충족하면 레지스트리 운영자는 50,000건 이하의 이름 등록과 관련된 이전에 대해 레지스트리 데이터베이스에서 필요한 1회성 변경을 무료로 진행합니다. 50,000건을 초과하는 이름 등록과 관련된 이전의 경우 레지스트리 운영자는 인가 획득 레지스트라에게 미화 50,000달러의 1회성 고정 수수료를 부과합니다.

   3. 이전 분쟁 해결 정책

      레지스트라간 이전에 관한 분쟁을 처리하는 절차는 이전 분쟁 해결 정책에 규정되어 있습니다. 소관 레지스트리 운영자와 ICANN 인가 레지스트라는 이 정책의 절차를 준수해야 합니다.

2. 등록자간 이전 ( 등록자 변경 )

   1. 정의

      1. 이 정책에서는 다음 용어를 사용합니다.

         1.1 "등록자 변경"은 다음 중 하나에 대한 자료 변경을 의미합니다.

         1.1.1 이전 등록자 이름

         1.1.2 이전 등록자 조직

         1.1.3 이전 등록자 이메일 주소

         1.1.4 이전 등록자 이메일 주소가 없는 경우 관리 담당자 이메일 주소

         1.2 "지정된 대리인"은 이전 등록자 또는 새 등록자가 해당 기관을 대신해서 등록자 변경을 승인하도록 명시적으로 허가한 개인이나 법인을 의미합니다.

         1.3 "자료 변경"이란 단순한 인쇄 오류 수정이 아닌 변경을 의미합니다. 다음과 같은 경우에 자료 변경으로 간주됩니다.

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

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

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

         1.4 "이전 등록자"는 등록자 변경이 시작된 시점의 등록명 보유자를 의미합니다.

         1.5 "새 등록자"는 이전 등록자가 도메인 이름 등록 이전을 제안하는 법인 또는 개인을 의미합니다.

   2. 등록자 변경의 가용성

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

      2. A 레지스트라는 다음 상황에서 등록자 변경 요청을 거부해야 합니다.

         2.1 만료 등록 복구 정책의 섹션 2.2.5에 따라, 도메인 이름 등록 계약이 만료되었고 등록명 보유자가 더 이상 도메인 이름을 갱신하거나 다른 레지스트라에 이전할 권리가 없는 경우

         2.2 이전 등록자와 신규 등록자가 등록자 변경을 아래 섹션 II.C에 따라 적절히 허가하지 않은 경우

         2.3 도메인 이름에 다음을 포함하나 이에 국한되지 않는 도메인 이름 관련 분쟁이 발생한 경우

         2.3.1 레지스트라가 통보를 받은 보류 중인 UDRP 처리 절차

         2.3.2 레지스트라가 통보를 받은 보류 중인 URS 처리 절차

         2.3.3 보류 중인 TDRP 처리 절차

         2.3.4 레지스트라가 통보를 받은 등록자 변경을 금지하는 관할 법원의 명령

      3. 다음 상황에서 레지스트리 운영자는 등록명 보유자의 세부 사항을 변경할 수 있으며 아래 섹션 II.C의 등록자 프로세스 변경이 적용되지 않습니다.

         3.1 등록 계약이 만료된 경우¹

         3.2 레지스트라에서는 등록 계약을 종료한 경우

         3.3 레지스트라 또는 레지스트리 운영자가 법원 명령에 따라 이전 등록자의 정보를 업데이트하는 경우

         3.4 레지스트라가 UDRP 결정 이행 중에 이전 등록자의 정보를 업데이트하는 경우

         3.5 레지스트라가 이전 등록자의 정보를 만료된 도메인 삭제 정책에 따라 업데이트하는 경우

         3.6 레지스트라가 남용 불만에 대한 대응으로 이전 등록자의 정보를 업데이트하는 경우

   3. 등록자 변경 프로세스

      1. 이전 등록자에서 새 등록자로 등록자 변경을 처리하려면 레지스트라는 다음을 모두 수행해야 합니다.

         1.1 도메인 이름이 섹션 II.B에 따라 등록자 변경에 적합한지 확인합니다.

         1.2 새 등록자 또는 새 등록자의 지정된 대리인으로부터 등록자 변경 요청에 대한 확인을 받습니다. 레지스트라는 반드시 보안 메커니즘을 사용하여² 새 등록자 및/또는 각각의 지정된 대리인이 등록자 변경에 명시적으로 동의했는지 확인해야 합니다. 확인 과정에서 레지스트라는 반드시 새 등록자에게 레지스트라와 등록 계약을 체결해야 한다고 알려야 합니다(등록 계약 자체에 대한 링크 제공 가능). 레지스트라는 또한 등록자 변경을 승인 또는 취소하는 방법에 관한 지침을 포함하고 새 등록자나 지정된 대리인(해당되는 경우)에게 레지스트라가 설정한 기간(최대 60일을 초과하지 않음) 내에 변경 요청이 확인되지 않으면 해당 요청이 진행되지 않음을 알려야 합니다.

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

         1.4 위 II.C.1.3의 설명에 따라 이전 등록자에게 통보 시 또는 통보 후 이전 등록자 또는 이전 등록자의 지정된 대리인에게서 등록자 변경 요청에 대한 확인을 받습니다. 레지스트라는 반드시 보안 메커니즘을 사용하여 이전 등록자 및/또는 각각의 지정된 대리인이 등록자 변경에 명시적으로 동의했는지 확인해야 합니다. 레지스트라는 확인을 받는 과정에서 이전 등록자나 지정된 대리인(해당되는 경우)에게 레지스트라가 설정한 기간(최대 60일을 초과하지 않음) 내에 등록자 변경 요청이 확인되지 않으면 해당 요청이 진행되지 않음을 알려야 합니다.³

         1.5 위에 설명한 확인을 받은 후 1일 내에 등록자 변경을 처리합니다.

         1.6 등록자 변경 완료 전 또는 완료 1일 내에 이전 등록자와 새 등록자에게 통보합니다. 통보는 다음 조건을 따라야 합니다.

         1.6.1 등록자 변경 수행 전 또는 1일 내에 새 등록자와 이전 등록자에게 모두 발송합니다.

         1.6.2 접수된 요청을 설명하고 해당 도메인을 나열합니다.

         1.6.3. 문의를 위한 연락처 정보를 포함합니다.

         1.6.4. 이전 등록자와 새 등록자에게 섹션 II.C.2에 설명된 60일 레지스트라간 이전 잠금에 대해 알리거나 이전 등록자가 이전에 섹션 II.C.2에 설명된 60일 레지스트라간 이전 잠금을 옵트아웃했음을 알립니다.

      2. 레지스트라는 등록자 변경 후 60일 레지스트라간 이전 잠금을 부과해야 합니다.⁴ 단, 레지스트라는 등록명 보유자가 등록자 변경 요청 전에 60일 레지스트라간 이전 잠금을 옵트아웃할 수 있도록 허용해야 합니다.

참고

소개 및 배경 설명: IRTP 파트 C 정책 개발 프로세스(PDP)는 기존 이전 정책의 개선 영역을 다루는 5개의 PDP 시리즈 중 세 번째입니다.

GNSO 평의회는 2012년 9월 22일 회의에서 다음 3가지 문제 해결을 위한 PDP 출범을 결정했습니다.

1. "제어 변경" 기능 및 관련 보안 문제(국가 코드 이름 공간에 gTLD 공간을 위한 모범 사례로 활용할 수 있는 적용 가능한 모델이 있는 경우 현재 이 기능의 달성 방식 조사를 포함). 여기에는 합법적인 이전 활동과 보안의 균형을 맞추기 위한 목표를 가지고 거부 사유 #8 및 #9에 설명된 잠금 절차에 대한 검토도 포함해야 합니다.
2. 사기성 이전을 막기 위한 시간 제한 허가 양식(FOA) 조항의 시행 여부. 예를 들어 인가 획득 레지스트라가 이전 담당자와 FOA를 주고받았으나 이름이 잠겨 있는 경우 레지스트라는 도메인 이름 상태 조정을 기다리며 FOA를 보류할 수 있고 이 시간 동안 등록자 또는 다른 등록 정보가 변경될 수 있습니다.
3. 레지스트리가 레지스트라에 대해 독자적인 ID가 아닌 IANA ID를 사용하도록 할 경우 프로세스 간소화 가능성.

IRTP 파트 C 실무그룹은 2012년 6월 4일에 첫 보고서를 여론 수렴 포럼 개시와 함께 발표했으며(섹션 6에서 자세한 내용 참고) 2012년 10월 9일에 최종 보고서를 발표했습니다. ICANN 이사회는 2012년 12월 20일에 IRTP 파트 C 실무그룹의 권고안을 채택했습니다. 구현 검토 팀은 ICANN 직원과 함께 이전 정책 초안을 개발했습니다. 초안 정책은 여론 수렴 기간을 거쳤습니다.

모든 ICANN 인가 레지스트라는 2016년 11월 1일까지 정책을 준수해야 합니다.

자료 변경 : 섹션 II.A.1.3에서 자료 변경은 단순한 인쇄 오류 수정이 아닌 변경을 의미하는 것으로 정의됩니다. 레지스트라는 인쇄 오류 수정이 무엇인지 어느 정도 유연하게 결정할 수 있습니다. 인쇄 오류 수정의 예는 다음과 같습니다.

1. 등록자 이름 필드를 oJhn Smith에서 John Smith로 수정.
2. 등록자 이름 필드를 Jane Kgan에서 Jane Kang으로 수정.
3. 등록자 조직을 Example, Icn에서 Example, Inc로 수정.
4. 등록자 조직을 ExampleCorp에서 Example Corp로 수정.

의심의 여지를 방지하기 위해 레지스트라는 어떤 등록자 이름이나 등록자 조직 변경이라도 자료 변경으로 간주할 수 있습니다.

보안 메커니즘 : GNSO의 권장 정책에서는 레지스트라가 등록자 변경을 처리하는 방법에 있어서 어느 정도의 유연성이 필요함을 인정하고 있습니다. 예를 들어 레지스트라는 레지스트라 계정 또는 공개 리소스(예: Whois) 내에서 알 수 없는 정보를 기반으로 "대역 외" 인증을 고려할 수 있습니다. 예를 들면 다음과 같습니다(이에 국한되지 않음).

1. 레지스트라가 지정한 방식으로 반환해야 하는 고유한 코드를 제공하는 것과 같은 도구 기반 인증 방법을 통해 긍정적인 응답을 요구하는 이메일 발송 또는
2. 등록명 보유자 전화번호로 전화를 걸거나 SMS를 보내 레지스트라가 지정한 방식으로 반환해야 하는 고유한 코드 제공 또는
3. 등록명 보유자 전화번호로 전화를 건 후 등록명 보유자에게 웹, 이메일 또는 우편 메일로 등록명 보유자에게 전송된 고유 코드를 제공하도록 요구

등록자 변경 후 레지스트라간 이전 잠금 레지스트라는 섹션 II.C.2에 설명된 60일 레지스트라간 이전 잠금에 대한 특정 EPP 상태 코드를 적용할 필요는 없습니다. 단, 레지스트라가 고객이전금지(clientTransferProhibited) EPP 상태 코드를 적용하고자 선택하면 이름도 잠금 설정하여 등록명 보유자가 섹션 I.A.5.1에 따라 잠금을 제거하는 것을 금지해야 합니다.

---

¹ 등록 계약 조건에 따라 도메인 이름이 만료된 후 등록 및 Whois 세부 정보가 변경된 경우 만료 등록 복구 정책의 보호 조항이 여전히 적용됩니다.

² 보안 메커니즘의 예는 본 정책의 본문 뒤에 나오는 시행 참고에서 찾을 수 있습니다.

³ 레지스트라는 이전 등록자의 확인을 받을 때 등록된 추가 연락처 정보를 사용할 수 있으며 공개된 Whois에 제한되지 않습니다.

⁴ 레지스트라는 섹션 II.C.2에 설명된 잠금 해제에 제한을 둘 수 있으나 필수 사항은 아닙니다. 예를 들어 레지스트라는 영업일 기준 5일이 경과한 후에만 잠금을 해제할 수 있고 잠금 해제는 이메일에 대한 이전 등록자의 긍정적인 응답을 통해 허가를 받도록 할 수 있습니다.