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

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

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

등록자 변경(섹션 II)

정의:

  • 등록자 변경 - 주요 변경 사항:
    1. 이전 등록자 이름
    2. 이전 등록자 조직
    3. 이전 등록자 이메일 주소
    4. 관리 담당자 이메일 주소(이전 등록자 이메일 주소가 없는 경우)
  • 단순한 인쇄상 오타 정정이 아닌 것으로 보이는 등록명 보유자의 이름 또는 조직의 변경
  • 주소 또는 전화번호 변경이 수반되는 등록명 보유자의 이름 또는 조직의 변경
  • 등록명 보유자의 이메일 주소의 변경
    1. 이전 등록자 - 변경이 시작된 시점의 RNH(등록명 보유자)
    2. 신규 등록자 - 이전 등록자가 도메인 이름 등록 이전을 제안하는 법인 또는 개인
    3. 주요 변경 - 인쇄상 오타를 정정하는 것이 아닌 다음과 같은 변경을 의미

등록자 변경의 가용성:

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

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

    1. 만료 등록 복구 정책(ERRP)에 따라 등록 계약이 만료되었고 등록자가 더 이상 도메인 이름을 갱신하거나 다른 레지스트라에 이전할 권리가 없는 경우
    2. 이전 등록자와 신규 등록자가 등록자 변경을 적절히 허가하지 않은 경우
    3. 도메인 이름(예: URS, UDRP, TDRP, 법원 명령)이 분쟁 중인 경우

등록자 변경 프로세스

(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)가 적용되지 않습니다.

    1. 등록 계약이 만료된 경우
    2. 레지스트라가 등록 계약을 종료하는 경우
    3. 레지스트라 또는 레지스트리가 법원 명령에 따라 이전 등록자의 정보를 업데이트하는 경우
    4. UDRP 결정 실행에 따른 업데이트의 경우
    5. 만료된 도메인 삭제 정책에 따른 업데이트의 경우
    6. 남용 불만에 대응하여 업데이트하는 경우

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

  • 1.1.2 및 1.1.4 –
    • 신규 등록자에게 레지스트라와 등록 계약을 체결해야 한다고 알립니다.
    • 등록자 변경을 승인 또는 취소하는 방법에 관한 지침을 포함하고 이전 등록자나 신규 등록자(해당되는 경우)에게 레지스트라가 설정한 기간(최대 60일을 초과하지 않음) 이내에 변경 요청이 확인되지 않으면 해당 요청이 진행되지 않음을 알립니다.  
  • 1.1.6 -     
    • 1.1.6.1 – 등록자 변경 전 또는 1일 이내에 신규 등록자와 이전 등록자에게 모두 발송합니다.
    • 1.1.6.2 - 접수된 요청을 설명하고 해당 도메인을 나열합니다.
    • 1.1.6.3 - 문의를 위한 연락처 정보를 포함합니다.
    • 1.1.6.4 – 신규 등록자 및 이전 등록자에게 60일 잠금(해당하는 경우)을 알리거나, 이전 등록자에게 그가 이전에 60일 잠금을 옵트아웃했음을 알립니다.

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

  • 레지스트라는 등록자 변경 후 60일 레지스트라간 이전 잠금을 부과해야 합니다.
  • 레지스트라는 등록자 변경을 요청하기 전에 이전 등록자에게 잠금 “옵트아웃” 옵션을 제공할 수 있습니다.
  • “옵트아웃” 옵션을 제공하고 이전 등록자가 잠금을 옵트아웃한 경우 레지스트라는 레지스트라 잠금을 부과하지 않을 수도 있습니다.

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

이전 권한(이전 담당자)

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

인가 획득 레지스트라

    • 레지스트라는 FOA에서 추가 언어로 의사소통할 수 있습니다. 하지만 번역의 정확성과 완전성에 대한 책임은 레지스트라에게 있습니다.
  • 레지스트라는 다음으로 넘어가기 전에 이전 담당자로부터 확인을 받아야 합니다.
  • 인가 획득 FOA는 다음 조건 중 하나(섹션 I A)가 발생하면 만료됩니다.
    1. 2.2.3.1 인가 획득 레지스트라가 FOA의 자동 갱신을 허용하지 않고 등록명 보유자가 자동 갱신을 명시적으로 선택하지 않은 상태에서 인가 획득 레지스트라가 FOA를 발행한 후 60일이 경과한 경우
    2. 2.2.3.2 레지스트라간 이전이 완료되기 전에 도메인 이름이 만료되는 경우
    3. 2.2.3.3 섹션 II.C.의 등록자 변경이 완료된 경우
    4. 2.2.3.4 레지스트라간 이전이 완료된 경우
  • 레지스트리에 "이전" 요청을 제출하기 전에 위에 설명된 상황 중 하나에 따라 FOA가 만료된 경우 이전을 진행하려면 인가 획득 레지스트라가 새로운 FOA를 통해 이전 요청을 다시 허가해야 합니다.

자격 상실 레지스트라

  • 레지스트리 운영자로부터 외향적 이전 요청을 받는 경우, 24시간 이내에 "레지스트라 이전 요청 확인"이라는 표준 영어 버전의 템플릿 FOA를 보내야 합니다.
    • 레지스트라는 FOA에서 추가 언어로 의사소통할 수 있습니다. 하지만 번역의 정확성과 완전성에 대한 책임은 레지스트라에게 있습니다.
  • RNH가 이전을 미리 승인하는 경우, 레지스트라는 미리 승인된 이전이 시작되었음을 RNH에게 알리는 수정된 FOA 버전을 보낼 수 있습니다.
  • 자격 상실 레지스트라가 이전 담당자로부터 확인을 받지 못하고 레지스트라가 이전 요청을 명시적으로 거부하지 않은 경우 5일이 지나면 기본적으로 레지스트라가 이전 진행을 허용해야 합니다. 이것이 기본 이전 "승인"입니다.
  • 자격 상실 레지스트라는 다음 이유 중 하나에 따라 이전 요청을 거부(NACK)할 수 있습니다. (섹션 I.A.3.7)
    1. 3.7.1 사기가 입증된 경우.
    2. 3.7.2 RNH 또는 관리 담당자의 신원에 관한 합리적인 분쟁이 있는 경우.
    3. 3.7.3 도메인 이름의 만료 일자가 경과했고 이전 등록 기간에 대해 지불이 이루어지지 않은 경우(신용 카드 지불 거절 포함) 또는 도메인 이름이 아직 만료되지 않았고 이전 또는 현재 등록 기간에 대해 지불이 이루어지지 않은 경우. 하지만 이 모든 경우에 공식 기록상 레지스트라는 이전 거부에 앞서 도메인 이름을 "레지스트라 홀드(HOLD)" 상태로 지정해야 합니다.
    4. 3.7.4 권한 있는 이전 담당자가 이전에 대해 이의를 표명한 경우.
    5. 3.7.5 이전 요청이 도메인 이름에 대한 레지스트리 WHOIS 기록에 표시된 생성 날짜로부터 60일 이내에 이루어진 경우.
    6. 3.7.6 도메인 이름이 자격 상실 레지스트라로 이전된 지 60일 이내인 경우.
  • 3.8.1 레지스트라가 UDRP 처리 절차가 보류 중임을 통보받은 경우..
    1. 3.8.2 관할 법원의 법원 명령이 있는 경우.
    2. 3.8.3 이전 분쟁 해결 정책에 따라 이전의 이전과 관련된 분쟁이 보류 중인 경우.
    3. 3.8.4 레지스트라가 통보를 받은 URS가 처리 중이거나 URS가 중지된 경우.
    4. 3.8.5 레지스트라가 등록자 변경 후 60일 레지스트라간 이전 잠금을 부과했고, RNH가 등록자 변경 요청 전에 60일 레지스트라간 이전 잠금을 옵트아웃하지 않은 경우.
    5. 자격 상실 레지스트라는 다음 상황 중 하나에 해당하는 경우 이전 요청을 거부(NACK)해야 합니다. (섹션 I.A.3.8)

이전 긴급 조치 담당자

  • 레지스트라는 이전과 관련한 긴급한 의사소통을 위해 이전 긴급 조치 담당자("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)

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

(i) 해당 레지스트라 또는 그 자산을 다른 레지스트라가 인수하는 경우

(ii) 레지스트라와 ICANN의 RAA 또는 레지스트리와의 RRA가 종료된 경우

  • 레지스트라는 다음 절차를 사용합니다.
    • 인가 획득 레지스트라는 레지스트리 TLD에 대해 ICANN의 인가를 받아야 하고 레지스트리 TLD에 대해 레지스트리 운영자와 유효한 레지스트리-레지스트라 계약을 맺어야 합니다.
    • ICANN은 서면으로 레지스트리 운영자에게 해당 이전이 커뮤니티 이익을 증진할 것임을 증명해야 합니다(예: 레지스트라의 현재 또는 임박한 비즈니스 실패로 인한 안정성 위협에 이익이 됨).
  • 이 두 조건을 충족하면 다음과 같이 진행됩니다.
    1. 레지스트리 운영자는 50,000건 이하의 이름 등록과 관련된 이전에 대해 레지스트리 데이터베이스에서 필요한 1회성 변경을 무료로 진행합니다.
    2. 50,000건을 초과하는 이름 등록과 관련된 이전의 경우 레지스트리 운영자는 인가 획득 레지스트라에게 미화 50,000달러의 1회성 고정 수수료를 부과합니다.



  • No labels