.COM, .NET 및 .JOBS의 Thick Whois 전환 정책
모든 번역 내용 및 문서의 영어 버전은 공식 버전이며, 영어 외 다른 언어의 번역 버전은 정보 제공용으로만 사용할 수 있습니다.
뉴스
2019년 11월 7일 ICANN 이사회는 계약 준수 시행을 연기하라는 결의안을 통과시켰습니다. ICANN 계약 준수는 다음 사항이 모두 완료되기 전까지 대량 WHOIS 전환 정책의 시행을 연기할 예정입니다.
- gTLD의 등록 데이터 정책 시행 검토 팀(IRT)은 검토를 마치고 신속한 정책 개발 과정(EPDP) 팀의 권장 사항(ICANN 이사회가 2019년 5월 15일에 채택) 시행을 위한 예상 일정을 세웁니다.
- ICANN 조직과 IRT는 GNSO 평의회에 기존 정책 및 절차(대량 WHOIS 전환 정책 포함)에 대한 EPDP 팀의 권장 사항에 따른 영향에 관한 필요한 정보를 제공하며,
- GNSO 평의회는 대량 WHOIS 전환 정책에 영향을 미치는 관련 정책 및 절차(추가 정책 작업, 지침 또는 향후에 결정될 기타 조치가 포함될 수 있음)의 업데이트에 따른 조치를 취할 것인지 여부를 결정합니다.
이 문서에서 "~해야 한다", "~해서는 안 된다", "요구된다", "~하는 것을 권장한다", "~하지 않는 것을 권장한다", "~할 수 있다"와 같은 키워드는 RFC 2119( http://www.ietf.org/rfc/rfc2119.txt)에서 설명된 대로 해석한다.
적용 범위:
이 정책은 .COM, .NET 및 .JOBS gTLD의 레지스트리 운영자와 .COM, .NET 또는 .JOBS gTLD에 도메인 이름 등록을 지원하는 모든 레지스트라에 적용하는 것을 권장한다.
정의:
- Thin (등록): 레지스트리 운영자가 기술적 정보(예: 이름 서버, 상태, 생성일)와 도메인 이름에 관련된 지원 레지스트라만 유지하고 제공하는 도메인 이름. 도메인 이름의 연락처 정보는 지원 레지스트라가 유지한다.
- Thick (등록): 지원 레지스트라가 레지스트리 운영자에게 관련 연락처 정보의 사본을 제공하는 도메인 이름. 레지스트리 운영자는 기술적 정보(예: 이름 서버, 상태, 생성일)와 도메인 이름에 관련된 지원 레지스트라를 유지한다. 도메인 이름의 연락처 정보는 지원 레지스트라가 유지한다.
- 기존 도메인이름: 2018년 5월 1일 전에 생성되거나 생성 대기 상태인 도메인 이름.
- 전환진행지표: Thin에서 Thick으로 전환의 진행을 측정할 수 있도록 레지스트리 운영자가 작성하여 레지스트라와 ICANN에 정기적으로 전달하는 지표. 최소한 레지스트라가 관리하는 도메인 총수, 연락처 객체가 첨부된 도메인 수와 비율이 포함된다.
정책 및 발효일:
3.1 늦어도 2018년 5월 1일부터모든신규도메인이름등록은 Thick으로제출되어야한다.
3.2 기존도메인이름의모든관련등록데이터는 2019년 2월 1일까지 Thin에서 Thick으로마이그레이션되어야한다.
다음 요구 사항은 레지스트리 운영자에게만 적용한다.
4.1 레지스트리운영자는레지스트라가기존도메인이름의등록데이터를마이그레이션(즉 Thin에서 Thick으로전환)할수있도록 2017년 8월 1일까지 EPP 메커니즘과대체대량전송메커니즘을구축해야한다.
4.2 2017년 5월 1일까지, 레지스트리운영자는해당레지스트라와 ICANN에섹션 4.1의요구사항을지원하는데필요한시스템변경이반영된문서를제공해야한다.
4.3 2017년 5월 1일까지, 레지스트리운영자는레지스트라가기존도메인이름의등록데이터마이그레이션(즉 Thin에서 Thick으로전환)을테스트할수있도록관련운영테스트환경(OT&E)에서 EPP 메커니즘과대체대량전송메커니즘을구축해야한다.
4.4 2017년 8월 1일까지, 레지스트리운영자는이조항에규정된대로 RFC5733에서지정된모든연락처명령을지원해야한다. EPP 연락처필드 <contact:id>, <contact:postalInfo type> 및 <contact:authInfo>는레지스트리운영자에의해요구된다. 레지스트리운영자는 "2014년 1월 9일에승인된기본레지스트리계약"("기본레지스트리계약")이나이후개정본의규정 4 섹션 1에규정된 WHOIS(포트 43을통해제공) 및웹기반디렉터리서비스요구사항과, 레지스트리등록데이터디렉터리서비스일관성있는라벨링및디스플레이정책을준수하는데필요한다른모든등록데이터요소를 2019년 2월 1일까지수락해야하지만요구해서는안된다.
4.5 2018년 5월 1일부터, 레지스트리운영자는이조항에규정된대로 EPP 도메인객체 <create> 명령을위한 Thick 등록데이터를요구해야한다. 레지스트리운영자는 "2014년 1월 9일에승인된기본레지스트리계약"("기본레지스트리계약")이나이후개정본의규정 4 섹션 1에규정된 WHOIS(포트 43을통해제공) 및웹기반디렉터리서비스요구사항과, 레지스트리등록데이터디렉터리서비스일관성있는라벨링및디스플레이정책을준수하는데필요한모든등록데이터요소를요구해야한다.
4.6 2017년 8월 1일과 2019년 2월 1일사이에, 레지스트리운영자는최소한각레지스트라에게매월다음달첫째날의 UTC 기준 23:59까지전환진행지표를제공하는것을권장한다.
4.7 2017년 8월 1일과 2019년 2월 1일사이에, 레지스트리운영자는최소한 ICANN에 매월다음달첫째날의 UTC 기준 23:59까지모든레지스트라를위한모든전환진행지표를제공하는것을권장한다.
4.8 레지스트리운영자는 2017년 8월 1일까지 "2014년 1월 9일에승인된기본레지스트리계약"("기본레지스트리계약")이나이후개정본의규정 4 섹션 1과함께레지스트리등록데이터디렉터리서비스일관성있는라벨링및디스플레이정책("CL&D 정책")의요구사항을실행할수있다.
4.9 레지스트리운영자는 "2014년 1월 9일에승인된기본레지스트리계약"("기본레지스트리계약")이나이후개정본의규정 4 섹션 1에규정된 WHOIS(포트 43을통해제공) 및웹기반디렉터리서비스요구사항과, 레지스트리등록데이터디렉터리서비스일관성있는라벨링및디스플레이정책을신규등록의경우 2018년 5월 1일까지, 기존도메인이름의경우 2019년 2월 1일까지준수해야한다.
4.10 2017년 8월 1일과 2019년 2월 1일사이에, 기존도메인이름에서다음 RDDS 출력필드의데이터가공유등록시스템(SRS)에존재하지않는경우레지스트리운영자는다음 RDDS 필드를 "자문: 레지스트리계약부수조항, 해당등록데이터디렉터리서비스(Whois)에대한 2013 레지스트라인가계약(RAA) 규정"의부수조항 1에규정된대로선택사항으로처리할수있다.
- 레지스트리 등록자/운영자/기술자 ID
- 등록자/운영자/기술자 이름
- 등록자/운영자/기술자 주소
- 등록자/운영자/기술자 시/도
- 등록자/운영자/기술자 국가
- 등록자/운영자/기술자 전화
- 등록자/운영자/기술자 이메일
4.11 "청구" 연락처는레지스트리계약에서달리요구되지않는한선택사항이다. 레지스트리정책에서필수사항, 선택사항또는미지원사항인지를정의할수있다. 지원되는경우청구연락처정보는 "자문: 레지스트리계약부수조항, 해당등록데이터디렉터리서비스(Whois)에대한 2013 레지스트라인가계약(RAA) 규정"(섹션 22)에규정된대로디스플레이되어야한다.
다음 요구 사항은 레지스트라에게만 적용한다.
5.1 2017년 8월 1일과 2019년 2월 1일사이에, 레지스트라는레지스트리운영자가 "2014년 1월 9일에승인된기본레지스트리계약"("기본레지스트리계약")이나이후개정본의규정 4 섹션 1에규정된 WHOIS(포트 43을통해제공) 및웹기반디렉터리서비스요구사항과, 레지스트리등록데이터디렉터리서비스일관성있는라벨링및디스플레이정책을준수하는데필요한, 레지스트라데이터베이스에서제공되는기존도메인이름의모든필수필드를관련레지스트리운영자에게마이그레이션해야한다.
5.2 레지스트라는레지스트리운영자가 "2014년 1월 9일에승인된기본레지스트리계약"("기본레지스트리계약")이나이후개정본의규정 4 섹션 1에규정된 WHOIS(포트 43을통해제공) 및웹기반디렉터리서비스요구사항과, 2017년 8월 1일에시작되는신규도메인이름등록생성에대한레지스트리등록데이터디렉터리서비스일관성있는라벨링및디스플레이정책을준수하는데필요한완전한 Thick 등록데이터를레지스트리운영자에게제공할수있다.
5.3 레지스트라는레지스트리운영자가 "2014년 1월 9일에승인된기본레지스트리계약"("기본레지스트리계약")이나이후개정본의규정 4 섹션 1에규정된 WHOIS(포트 43을통해제공) 및웹기반디렉터리서비스요구사항과, 2018년 5월 1일에시작되는신규도메인이름등록생성에대한레지스트리등록데이터디렉터리서비스일관성있는라벨링및디스플레이정책을준수하는데필요한완전한 Thick 등록데이터를레지스트리운영자에게제공해야한다.
실행 기록
현지 정보보호법과 이 정책에 포함된 요구 사항이 상충하는 경우 레지스트리 운영자와 레지스트라는 ICANN WHOIS와 정보보호법 상충의 처리 절차를 이용할 수 있다.
배경 설명
ICANN 이사회는 합의에 의하여 GNSO Thick WHOIS 작업 그룹의 정책 권장 사항을 채택하였다. 이 권장 사항은 모든 gTLD 레지스트리의 Thick WHOIS 사용에 관한 것으로 GNSO 회의가 권장 사항을 승인한 후 2014년 2월 7일에 채택되었다. 권장 사항 #1은 "2013 [레지스트라 인가 계약]의 규정 3에 설명된 모델에 따른 일관성 있는 라벨링 및 디스플레이를 포함한 Thick WHOIS 서비스의 제공이 모든 기존 및 향후 gTLD 레지스트리의 필수 사항이 되는 것을 권장한다."라고 되어 있다. ( ICANN 이사회 결의서 2014.02.07.08 - 2014.02.07.09 http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c 참조).
ICANN은 정책 권장 사항을 실행하기 위해 커뮤니티 구성원 팀(실행 검토 팀)과 함께 작업했다. 실행의 일환으로 권장 사항의 채택 전에, ICANN은 제안된 정책 권장 사항과 이 정책에 포함된 내용에 대한 커뮤니티의 의견을 구했다. (https://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en 참조).
나아가서 Thick Whois 정책 PDP WG의 최종 보고서 [PDF, 1.23 MB] 섹션 7.2에는 Thin에서 Thick Whois로 전환을 실행하기 위한 일정과 요구 사항에 관련된 '실행 지침'도 포함되었다. 여기서는 " WG는 권장사항의일부실행(예: 기존 Thin gTLD 레지스트리에서 Thick 모델로전환)으로인해다른권장사항의실행(예: 해당데이터의일관성있는라벨링및디스플레이)이불필요하게지연되지않는것을강조한다."라고 명시하고 있다.
결과적으로 ICANN 기구는 Thin Whois 등록에서 Thick으로 전환, Whois 데이터의 일관성 있는 라벨링 및 디스플레이의 병행 실행 경로에 대해 실행 검토 팀과 함께 작업했다. 더 자세한 내용은 https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en 참조.