요약

  • 2018년 8월 12일, Abuse Contact Policy Update Draft 1은 직접 발급된inetnum,inet6num및aut-num레코드에abuse-c연락처를 의무화하는 것을 제안했으며, 이는 전용 IRT 기반 연락처 객체 사용이 권장되지만 선택 사항이던 기존 체계를 대체하는 것이었다.
  • 이 검증 절차는 연속된 두 통의 일반 텍스트 이메일로 URL과 코드를 발송하고, 연락처에 CAPTCHA로 보호된 인증을 완료할 영업일 이틀을, 이후 LIR에게 영구 무효화 전까지 3일을 더 부여했다. 또 다른 검증 실패는 정책 위반이 될 수 있고 자원 철회 관련 후속 조치로 이어질 수 있었다.
  • 레지스트리는 하나의 도달 가능한 역할(role) 메일함을 요구하고 객관적인 전달 가능성을 테스트할 수 있다. 그러나 그 기록을 사용해 필터링, 양식, 수동 처리, 조치나 대응을 지시할 수는 없다. AFRINIC은 어뷰즈 규제기관이나 공공기관이 아니라 사적 기술 기록 관리자이기 때문이다.

L3 — 5일짜리 검증 기계

이 메커니즘은 연속된 두 통의 일반 텍스트 이메일로 시작했다. 첫 번째 이메일은 검증 URL을 담았고, 두 번째는 고유 코드를 담았다. 제안된abuse-c메일함을 관리하는 사람은 영업일 이틀 안에 CAPTCHA로 보호된 양식을 열어 코드를 붙여넣고 인증 항목에 표시해야 했다. 그 체크박스는 단순히 해당 주소가 메일을 수신할 수 있다는 것만이 아니라, 메일함이 정기적으로 모니터링되고 있고 조치가 취해졌으며 어뷰즈 신고에 대한 응답이 이루어졌음을 확인하도록 요구했다. 코드가 사용되지 않으면 연락처는 잠시 무효가 되었고, AFRINIC 직원이 LIR(local Internet registry)을 통해 후속 조치를 취하게 되었다. 회원은 문제를 바로잡기 위해 추가 영업일 3일을 넘지 않는 기간을 받았다. 두 번째 기간이 끝날 때까지 실패하면 연락처는 영구적으로 무효가 되었다. 이후의 검증 실패는 정책 위반으로 처리될 수 있었고, 특히 자원 철회와 관련된 절차 하에서 더 철저한 후속 조치를 받을 수 있었다.

이 압축된 절차가 중요한 이유는, 어떤 추상화가 이를 가리기 전에 제도적 질문을 드러내기 때문이다. 5영업일 만에 공개 번호 자원 디렉터리의 한 필드가 “아직 검증되지 않음”에서 “영구 무효”로 이동할 수 있었다. 반복될 경우, 문제는 다시 부정확한 연락처 데이터에서 정책 위반, 그리고 자원 관련 절차의 그림자로 이동할 수 있었다. 따라서 핵심 쟁점은 어뷥즈 신고가 주목받을 가치가 있는지가 아니었다. 사적 레지스트리가 작동하는 주소에 대한 합리적인 관심을 갖는 것이, 그 주소 뒤에서 일어나는 일을 감독하고 회원의 레지스트리 관계를 위험에 빠뜨리는 것까지 정당화할 수 있는지였다.

이 제안은AFPUB-2018-GEN-001-DRAFT01로 식별된 Abuse Contact Policy Update Draft 1이었다. Jordi Palet Martinez가 2018년 8월 12일에 제출하여 AFRINIC 통합 정책 매뉴얼의 8.0절을 대체하려 했다. 이는 논의 중인 제안이지, 시행 중인 규칙이 아니었다. 이 지위가 핵심이다. 이 문서는 시도된 제도 설계를 기록할 뿐, 첫 초안이 채택되거나 구현되었거나 어떤 회원에게 적용되었다는 것을 증명하지 않는다.

출발점은 비어 있는 디렉터리가 아니었다. AFRINIC은 2011년에 개발되어 2012년 구현된 것으로 기술된 어뷰즈 연락처 체계를 이미 갖고 있었다. 어뷰즈 연락처 정보를 게시하기 위한 전용 IRT 기반 객체를 사용했고,inetnum,inet6num,aut-num같은 자원 레코드는 그 객체를 참조할 수 있었지만 참조는 선택 사항이었다. 회원들은 좋은 관행으로 이 정보를 게시하도록 권고받았다. 약점은 명백했다. 권고만으로는 직접 발급된 자원에 명확하고 최신이며 일관된 어뷥즈 데스크가 존재하지 않을 수 있었다. 신고자는 여러 레코드를 뒤지거나, 일반 행정 주소에 메일을 쓰거나, 책임 있는 운영자를 추측해야 할 수 있었다. 낡은 객체에만 보존된 메일함은 아예 메시지를 받지 못할 수도 있었다.

Draft 1은 훨씬 강한 디렉터리 규칙을 제안했다. AFRINIC이 직접 할당한 모든 번호 자원은 해당inetnum,inet6num또는aut-num WHOIS항목에abuse-c연락처를 포함해야 했다. 적어도 하나의 연결된 어뷥즈 메일함이 유효하고, 모니터링되고, 적극적으로 관리되어야 했다. 하위 객체는 반드시 별도의 데스크가 필요하지 않았다. 상위 연락처를 상속하거나 자체 연락처를 게시할 수 있었다. 이 주소는 WHOIS, 애플리케이션 인터페이스 및 이후 등장할 어떤 접근 기법을 통해서도 제한 없이 이용 가능해야 했다. 이 수준에서 제안은 공개 레지스트리 데이터의 실질적 결함을 다루었다. 공통 필드는 연락 지점을 명확히 만들고, 상속은 중복을 줄이며, 객관적 검사는 실제 사고가 실패의 대가를 치르기 전에 죽은 역할 계정을 드러낼 수 있다.

검증 일정은 이 필드를 정적 선언이 아니라 반복되는 상호작용으로 만들었다. AFRINIC은 레코드가 생성되거나 업데이트될 때, 적어도 3개월마다 한 번, 그리고 AFRINIC이 판단하기에 적당하다고 보는 때마다 이를 검사하게 되었다. 제안의 예시는 URL과 코드가 짝을 이루는 메시지를 사용했지만, 일부 테스트는 도메인, 제목, 메시지 본문을 달리할 수 있었다. 이 변형은 알려진 검증 메시지만 인식하고 일반 어뷥즈 신고는 폐기하는 유사 체계를 방지하려는 것이었다. 따라서 이 설계는 좁게 화이트리스트된 탐지 이상을 테스트하려 했다.

검증을 수행하는 사람은 메일함에 대한 통제권과 절차 및 정책에 대한 이해를 보여야 했다. 수신 신고에 대한 첫 자동 확인 응답은 허용되었지만, 그 이후 메시지는 어느 시점에 수동 개입을 요구해야 했다. 메일을 필터링할 수 없었다. 신고자가 이메일을 떠나 웹 양식으로 제기하도록 강제될 수 없었다. 검증을 완료하는 사람은 정기적인 모니터링, 조치, 응답을 확인하는 것도 기대되었다. 이 추가 사항들은 각각 증거 대상을 이동시켰다. 코드의 성공적 반환은 누군가 두 통의 메시지를 수신하고 양식을 조작할 수 있음을 증명한다. 그러나 이후의 신고가 정확한지, 티켓에 충분한 증거가 있는지, 신고된 고객이 책임이 있는지, 특정 구제가 정당한지, 발신자가 실질적 회신을 받을 자격이 있는지는 증명하지 않는다.

8.2절부터 8.7절까지가 합쳐져 이 경계를 넘는 일을 만들었다. 게시 규칙은 의무 필드를 공급했다. 이용 가능성과 처리 요구사항은 신고가 도달하는 경로를 규정했다. 검증 조항은 주기와 인증을 정했다. 시한 조항은 지연을 임시 무효, 이어서 영구 무효로 변환했다. 에스컬레이션 조항은 AFRINIC의 중개를 도입했다. 미준수 문구는 반복되는 실패를 위반과 철회에 이를 수 있는 절차와 연결했다. 이들은 서로 바꿔 쓸 수 없는 세부 사항이었다. 행동적·징벌적 계층을 제거해도 디렉터리는 여전히 더 유용해진다. 그러나 연락처 필드를 제거하면, 아무리 강한 집행 언어도 신고자에게 어디에 써야 하는지 알려주지 못한다.

같은 날 게시된 직원 평가는 기관이 이 텍스트를 어떻게 이해했는지 확인해 준다. 직원들은 Draft 1을 직접 발급된inetnum,inet6num,aut-num객체에abuse-c를 의무화하되 하위 레코드에는 선택권을 남기는 것으로 읽었다. 검사는 생성 시와 적어도 분기마다 발생한다고 이해했으며, 검증 실패를 통상적 조치의 대상이 되는 정책 위반으로 취급했다. 직원들은 개발·테스트·배포에 최소 한 달 반 정도가 필요하다고 추산했다. 이 평가에는 법률 자문의 의견이 기록되어 있지 않았다. 그 부재만으로 제안의 유효성이 결정되지는 않지만, 설계 기록에서는 유의미하다. 연락처 결함을 철회 관련 절차까지 에스컬레이션할 수 있는 메커니즘이 강제적 관할권에 대한 기록된 법적 분석 없이 운영적으로 평가된 것이다.

Draft 1을 위한 가장 강한 사례는 왜곡 없이 진술될 자격이 있다. 어뷥즈 신고는 시간에 민감하다. 특히 주소 공간이 고객과 리셀러의 여러 층을 거칠 때 올바른 데스크를 찾는 비용은 허구가 아니다. 보안팀, 네트워크 운영자, 인시던트 대응자, 영향을 받은 사용자는 인력 이동에도 살아남는 역할 주소의 이점을 누린다. 레지스트리 전반의 일관된 필드는 잘못 전달된 신고를 줄일 수 있다. 주기적 테스트는 도메인 변경이나 인력 이탈 후 조용히 죽은 메일함을 식별할 수 있다. 상속은 네트워크가 하나의 유능한 중앙 팀을 사용할 수 있게 한다. 자동 확인 응답은 사람이 나중에 증거를 평가하는 동안 수신을 확인할 수 있다. 테스트 변형은 검증 탐지만 통과하도록 시스템을 조작하는 행위를 억제할 수 있다. 도달 불가능한 운영 연락처를 게시하는 레지스트리는 열악한 디렉터리를 유지하는 것이다.

그러나 그 선량한 사례는 의무 연락처를 지지할 뿐, 나머지 기계를 지지하지 않는다. 객관적 전달 가능성은 한계가 명확한 질문을 한다. 메시지가 지정된 역할 주소에 도달할 수 있는가? Draft 1은 다른 질문들을 물었다. 운영자가 레지스트리가 선호하는 입력 채널을 허용하는가? 필터링 태세가 수용 가능하다고 판단되는가? 사람이 수동으로 개입하는가? 운영자가 “조치”를 취하는가, 그리고 그 단어는 무엇을 요구하는가? 모든 신고가 중복이든, 악성이든, 자동 생성이든, 형식이 잘못되었든, 근거가 없든 응답을 받아야 하는가? 이들은 운영 대응 체계의 설계와 적절성에 대한 결정이다. 레지스트리 레코드의 정확성으로부터 추론할 수 없다.

정확한 문구 자체도, 제안된 의무가 이메일 주소를 최신 상태로 유지하는 것뿐이라는 편리한 변명을 거부한다. 필터링 금지는 주소 형식 규칙이 아니다. 웹 양식 요구 금지는 전달 테스트가 아니다. 수동 개입은 인력과 절차에 대한 처방이다. 조치가 취해지고 신고에 응답이 이루어진다는 보증은 트리아지의 실질에까지 미친다. “AFRINIC이 판단하기에 적당하다고 보는 때”의 검증은 예측 가능한 유지보수 일정을 넘어서는 무제한 재량을 도입한다. 중개는 레지스트리 직원을 신고자와 운영자 사이에 놓인다. 철회 관련 후속 조치는 레지스트리의 서비스에 대한 실질적 통제력을 압박 수단으로 만든다. 5일 시계는 이 조각들을 묶어, 연락처 필드를 통해 행동을 가시화하고 실패에 제도적 결과를 붙였다.

8월 12일 이후의 수명 주기는 이러한 쟁점들이 인식되었음을 확인해 주지만, 이를 Draft 1에 소급 적용해서는 안 된다. Draft 2는 2018년 11월 20일에 등장했다. 그해 말 AFRINIC-29에서 참가자들은 검증된 연락처, MyAFRINIC에 대한 제한, 투표에 미치는 영향, 처벌, 그리고 AFRINIC이 “인터넷 경찰” 역할을 맡는지 여부를 두고 논쟁했다. 공동 의장들은 합의가 없음을 기록하고 제안을 재검토로 되돌렸다. AFRINIC의 2018년 연차 보고서는 이후 의무적abuse-c, 검증, 그리고 포털·투표 접근에 영향을 주는 제한을 포함한 징벌적 조치를 기술했다. 이 기록들은 Draft 2가 존재한 이후 단계의 맥락이며, 8월 12일 문서의 원문이나 법적 효과가 아니다.

마찬가지로 Draft 7을 Draft 1에 접어서는 안 된다. 버전 등록부는 7개의 초안을 기록하며, 7번째는 2021년 5월 17일에 제출되었다. 증거 기준 시점의 현재 자료는 그 이후 버전을 비준된 것으로 기술한다. Draft 7에 붙은 어떤 문구, 절차, 항소, 이후 지위도 그 자체의 역사에 속한다. 그것은 Draft 1을 소급적으로 시행 가능하게 만들거나, 첫 텍스트에 결여된 법적 권한을 공급하거나, 원래의 5일 메커니즘이 실제 철회를 초래했음을 증명할 수 없다. 분석 대상은 첫 제안과 그것이 처음 그으려던 제도적 경계 그 자체다.

Draft 1을 그 자체의 조건으로 읽으면, 같은 조항 안에 두 설계가 공존하고 있었다. 하나는 레지스트리 품질 개선이었다. 하나의 역할 연락처를 쉽게 찾게 하고, 메시지가 도달할 수 있도록 하고, 레코드가 수정이 필요할 때를 보여주는 것. 다른 하나는 행동 컴플라이언스 체계였다. 운영자의 접수 구조를 지정하고, 조치에 대한 보증을 요구하고, 탄력적 일정으로 운영자를 재검토하고, 불만을 중재하며, 실패를 자원 민감 절차와 연결하는 것. 첫 설계는 “신고를 어디로 보낼 수 있는가?”에 답한다. 두 번째 설계는 “네트워크가 수용 가능하게 행동했는가?”에 답하기 시작한다. 번호 레지스트리에는 첫 질문에 답할 기록이 있다. 두 번째 질문에 답할 사실도 공공 권한도 없다.