요약

  • 2015년 5월, Alain Durand는 5년치 IANA 요청 통계를 도메인 이름, 번호 자원, 프로토콜 파라미터에 걸친 업무 지도로 정리했다. 그의 글은 이관 참여자들에게 패턴을 보여 주면서도, 이관을 결정한다는 주장은 하지 않았다.
  • 분류가 중요했다: 신규 gTLD가 이름 관련 요청을 바꿔 놓았고, IANA의 IPv4 풀이 고갈되고 반환된 블록이 재분배된 상황에서도 번호 자원 요청은 대체로 수평을 유지했으며, 프로토콜 파라미터 레지스트리가 가장 큰 레지스트리 집합을 이루되 그 범주 안에서는 PEN(Private Enterprise Number) 요청이 사용량을 주도했다.
  • 요청 건수는 무엇이 언제 도착했는지 보여 줄 수 있다. 그러나 그것만으로 요청이 얼마나 어려웠는지, 정확하게 처리되었는지, 얼마나 큰 운영 리스크를 담았는지, 그 요청이 시행하는 정책을 누가 정할 권한을 가졌는지는 입증할 수 없다.

익숙한 기관을 만난 새 동료

Alain Durand의 2015년 5월 글은 유용한 자기 고백으로 시작한다. 그는 20년 이상 IETF에서 활동했고, 워킹 그룹을 이끌고 RFC를 집필하며 기술 업무의 참여자로서 IANA 레지스트리를 사용해 왔다. 그러나 몇 달 전 ICANN에 합류한 뒤, 자신이 레지스트리를 외부 사용자로서는 잘 알지만 그 뒤의 서비스 운영은 잘 모른다는 사실을 깨달았다.

새 역할의 일부는 IANA 이관(IANA Stewardship Transition)을 지원하는 것이라고 그는 썼다. 그는 그에 대한 응답으로 자신이 접근할 수 있던 통계를 거슬러 올라가 5년치 사용 데이터를 모았다. 그 결과물은 새 헌법 제안도, 모든 IANA 결정에 대한 감사도, 하나의 지표로 업무를 순위 매길 수 있다는 주장도 아니었다. 이관 논의가 사람들에게 다스리라고 요청하던 서비스의 규모와 패턴을 이해하려는 시도였다.

이 구분이 글에 인간적 중심을 준다. Durand는 자신을 인터넷 공학의 신참으로 내세우지 않았다. 그는 할당을 요청하는 사람에게 레지스트리가 어떻게 보이는지 아는 것과, 기능 운영 주체가 수많은 레지스트리에 걸쳐 요청을 접수·검증·처리하는 방식을 아는 것 사이에 더 좁은 격차가 있다는 점을 짚었다. 그의 선택은 업무량을 서비스의 이름이나 특정 논쟁의 유명세로부터 추정하지 않고, 관찰 가능한 흔적에서 서비스를 학습하는 것이었다.

결과물은 작업 지도였다. 유지되는 레지스트리 수를 보이게 하고, 요청의 원인이 다른 세 커뮤니티를 분리하며, 단면이 아니라 시계열을 독자에게 제공했다. 이 지도가 유용했던 이유는 정확히 “IANA 업무”가 하나의 균질한 대기열이라고 가장하지 않았기 때문이다.

근거는 그의 글이 이관 제안을 바꾸거나, 그 거버넌스에 영향을 주거나, 이후의 서비스 수준 지표를 낳았다는 것을 보여 주지 않는다. 글의 명시된 목적은 더 소박했다. 독자가 기능의 범위를 이해하도록 돕는 것. 그것만으로 이 작업이 의미 있을 수 있다. 하나의 기술 사무실처럼 논의되는 서비스에 대해, 실제 요청 구성에 대한 시각은 사람들이 용량, 감독, 연속성에 대한 결정을 내리기 전에 대화를 바로잡을 수 있다.

한계도 똑같이 중요하다. 차트는 판단의 중립적 대체물이 아니다. 무엇을 요청으로 셀지, 범주를 어떻게 묶을지, 어떤 시계열에 별도 축을 줄지, 총량을 어떻게 조합할지에 대한 선택은 모두 독자가 무엇을 알아차리는지를 형성한다. Durand의 글은 그가 관찰한 것에 대한 명확한 기술을 준다. 동시에 그 관찰이 무엇을 입증할 수 있고 없는지 묻게 해 준다.

2,800개가 넘는 기록, 그러나 단일한 업무 종류는 아니다

Durand는 IANA 부서가 세 운영 커뮤니티를 위해 2,800개가 넘는 레지스트리를 유지한다고 기술했다. 그는 도메인 이름, 번호 자원, 그리고 IETF 레지스트리를 포함한 프로토콜 파라미터를 확인했다. 그의 설명에 따르면 많은 레지스트리는 본질적으로 텍스트 파일이었다. 이 단순한 서술은 업무를 실제보다 작아 보이게 할 수 있다. 레지스트리가 목록일 수 있어도, 운영상 의무는 목록에 대한 변경을 지배하는 규칙을 적용하고 정확한 기록을 보존하며 그 결과 할당을 의존하는 다른 이들이 사용할 수 있게 하는 것이다.

2,800이라는 수는 레지스트리 수의 산수이지, 똑같이 활동적인 서비스 수의 산수가 아니다. 그것은 카탈로그가 얼마나 넓었는지를 알려 준다. 그러나 특정 달에 요청을 받은 레지스트리가 몇 개인지, 변경이 얼마나 복잡했는지, 각각이 직원 시간을 얼마나 요구했는지, 한 기록의 오류가 하류에서 무엇을 의미할 수 있는지는 말해 주지 않는다. 모든 레지스트리를 동일한 단위로 다루면 근거 없이 목록을 업무량 추정으로 바꾸어 버린다.

세 커뮤니티 레이블 역시 세 개 부서 이상을 설명한다. 이들은 서로 다른 종류의 요청, 서로 다른 기술 어휘, 서로 다른 정책 환경을 모은다. 이름 관련 업무에는 최상위 도메인 기록 및 위임의 변경이 포함된다. 번호 자원에는 지역 레지스트리로의 IPv4, IPv6, 자율 시스템 번호 블록 할당이 포함된다. 프로토콜 파라미터에는 표준과 구현이 의존하는 방대한 값 카탈로그가 포함된다. 하나의 운영 주체가 세 가지 모두를 실행할 수 있어도, 그것이 하위 작업들을 서로 교환 가능하게 만들지는 않는다.

이것은 인력 배치와 거버넌스 모두에서 중요하다. 루틴한 연락처 변경 대기열은 절차가 표준화된 채 빠르게 늘어날 수 있다. 단일 위임 또는 재위임은 더 긴 검증 경로와 더 많은 당사자를 포함할 수 있다. 번호 자원 요청은 드물면서도 합의된 글로벌 정책의 정밀한 이행에 의존할 수 있다. 프로토콜 파라미터 요청은 기계적으로 단순하면서도 운영 주체가 레지스트리별 절차를 따르고, 전문가와 상의하거나 분쟁을 올바른 표준 기구에 회부하도록 요구할 수 있다.

단일한 카운트는 이 차이를 어느 쪽으로든 가릴 수 있다. 그래프에 더 많은 항목이 찍힌다고 하여 높은 빈도의 시계열을 가장 중요하게 만들 수 있다. 또한 기록의 결과나 복잡도가 큰 경우 드문 시계열을 무시할 만한 것으로 보이게 할 수도 있다. 어느 쪽 결론도 빈도만으로 나오지 않는다.

따라서 측정의 문제는 카운팅이 무용하다는 것이 아니다. 해석 전에 세어지는 단위를 명명해야 한다는 것이다. Durand의 글은 총량만 제시하는 대신 여러 단위를 보이게 했다. 독자는 IANA가 서로 다른 운영 커뮤니티에서 수요가 오는 서비스 집합을 조율하고 있음을 볼 수 있었다. 하나의 기능 이름이 하나의 업무량에 대응한다고 가정하는 것보다, 운영 주체를 이해하는 더 좋은 출발점이다.

이름 업무는 하나의 곡선으로 움직이지 않았다

Durand는 도메인 이름 요청을 넓은 범주로 나누었다. ccTLD에 대해서는 위임과 재위임을, 행정·기술 연락처 갱신이나 DS 레코드 갱신 같은 변경과 구분했다. 일반 도메인(gTLD) 시각도 위임·재위임을 네임 서버, 연락처, DS 데이터 같은 기록 변경과 구분했다.

이 분할은 독자에게 요청의 수와 요청의 의미를 구분하는 첫 방법을 준다. 연락처 기록의 변경은 위임 결정과 같은 운영 사건이 아니다. 시스템은 둘 다 요청으로 기록할 수 있지만, 서비스 관리자는 각각에 동일한 검증, 조율, 소요 시간 가정을 부여할 이유가 없다. Durand의 범주는 각 사건이 얼마나 걸렸고 몇 명이 관여했는지는 알려 주지 않는다. 그러나 서비스 자체가 서로 다른 종류의 업무를 인식하고 있음을 보여 준다.

그의 일반 도메인 그래프는 프로그램의 변화도 보이게 했다. 신규 gTLD의 도입과 함께 위임·재위임 요청의 양이 크게 늘었다. 이는 수요 곡선이 정책 및 시장 환경에 반응한 사례다. 이것은 운영 주체가 그 프로그램을 만들었다거나, 증가가 이름의 사회적 가치에 상응하는 확장을 나타낸다는 뜻이 아니다. 새로운 위임 도메인 계층이 관련 운영 서비스에 더 많은 요청을 만들었다는 뜻이다.

행정적 함의는 실용적이다. 조직이 과거 평균만으로 인력을 예측한다면, 새 프로그램은 그 기준선을 낡게 만들 수 있다. 5년치 그래프가 유용한 이유는 증가를 맥락 속에 놓아 주기 때문이다. 곡선이 단순히 일정한 비율로 올라간 것은 아니었다. 눈에 띄는 단계나 지속적 변화는 기존 패턴 안의 완만한 변동과는 다른 계획을 요구할 수 있다.

그러나 더 많은 요청을 보여 주는 차트는 그것이 얼마나 많은 추가 노동을 요구했는지 드러내지 않는다. 백 건의 균질한 요청이 열 건의 복잡한 요청보다 시간이 덜 걸릴 수 있다. 급증은 여러 독립 요청, 한 프로그램이 만든 일괄 변경, 처리 중인 절차적 백로그의 정산, 또는 카운트 규칙의 변경을 반영할 수 있다. 그래프는 더 많은 기록된 요청이라는 일차적 사실을 확립할 뿐이다. 운영 부담을 판단하려면 처리 시간, 검증 단계, 재작업, 에스컬레이션, 인력 같은 보조 근거가 필요하다.

추세와 예측 사이에도 차이가 있다. Durand의 5년 시각은 이미 일어난 패턴을 문서화했다. 신규 gTLD 증가는 과거의 예측 가능성에 조건이 있었음을 보였다. 미래의 요청량이 같은 경로를 반복할 것이라는 약속이 아니었다. 책임 있는 조직은 그 시계열로 무엇이 바뀌었는지 묻고, 새로운 수준이 지속되는지 검증할 수 있다. 이전 평균을 보증으로 다루어서는 안 된다.

유용한 기여는 이름 업무가 단일 선으로 남지 않았다는 점이다. 분리 덕분에 어느 종류의 수요가 변했는지 물을 수 있다. 그것은 이미 “IANA가 바빠졌는가?”보다 답하기 쉬운 질문이다. 비용, 품질, 제도적 권한에 대한 답은 아직 아니다.

안정적인 번호 요청이 안정적인 세계를 뜻하지는 않았다

번호 자원 섹션은 IPv4·IPv6 유니캐스트 블록과 자율 시스템 번호 블록에 대한 IANA 요청을 추적한다. Durand는 지역 인터넷 레지스트리(RIR)가 요청한 대형 IPv6 블록이 2010년 이전에 요청되었고 그 이후 그 시계열에는 추가 요청이 없었다고 보고했다. 그는 또한 2011년 IANA의 미할당 IPv4 유니캐스트 주소 풀 고갈을 기록하고, 몇몇 블록이 이후 ICANN에 반환되어 글로벌 정책에 따라 RIR에 재분배되었다고 언급했다.

이것들은 세 가지 서로 다른 사실이다. 대형 IPv6 블록에 대한 요청 패턴, 한 중앙 풀의 고갈 사건, 그리고 정책에 따라 재분배된 이후의 반환. 이들을 주소 수요가 사라졌다는 주장으로 합쳐서는 안 된다. IANA의 할당 요청은 인터넷 전반의 트래픽, 네트워크가 사용하는 주소 수, 지역 레지스트리의 지속적 업무와 같은 측정이 아니다. IANA 경계에서의 평평한 시계열은 하류의 모든 활동을 대표할 수 없다.

이 구분은 희소 자원 상황에서 특히 중요하다. 중앙 기능이 처리하는 요청 수가 안정적이거나 감소하더라도 풀은 고갈될 수 있다. 희소성은 분배 규칙에 대한 가용 재고에 대한 진술이고, 요청 차트는 특정 운영 주체를 통과한 관찰된 흐름에 대한 진술이다. 하나가 다른 하나에 정보를 줄 수 있지만, 같은 변수가 아니다.

몇몇 IPv4 블록의 반환은 운영 기록이 맥락으로부터 이익을 얻는 이유를 보여 준다. 단순 선 그래프는 고갈 이후의 새 요청을 보여 주고 독자가 평범한 예비 물량이 남아 있다고 가정하게 할 수 있다. Durand의 본문은 반환된 블록이 이후 글로벌 정책에 따라 재분배되었다고 설명한다. 블록이 풀에 다시 나타난 사실이 이전의 고갈을 지우거나 새롭고 제약 없는 공급을 만들지는 않았다. 적용되는 정책과 블록의 출처가 중요하다.

관리자에게, 안정적인 물량은 업무의 결과의 변화를 가릴 수 있다. 각 요청이 유한한 풀과 상호작용한다면, 재분배는 루틴한 파라미터 할당의 대량 시계열보다 더 큰 결과를 가질 수 있다. 정책 변경이 자격이나 시기를 바꾼다면, 각 사건의 해석이 변하면서도 요청 건수는 거의 움직이지 않을 수 있다. 물량 시계열은 운영 주체가 각 요청에 연관된 규칙과 상태에 대한 정보를 유지할 때에만 용량 계획에 유용하다.

2015년 성과 보고서는 또 하나의 구분을 더한다. 그 번호 자원 섹션은 올바른 정책 이행, 요청자에게 통지하기 전 레지스트리 갱신 여부, 필요한 확인(클리리피케이션) 회수, 정해진 기간 내 완료, 공개 투명성에 대한 지표를 기술했다. 보고서는 그 달에 완료된 번호 자원 요청이 없었다고 밝혔다. 따라서 성과 범주는 어떤 의무가 추적되고 있었는지를 알려 주고, 제로 완료 기록은 하부 활동을 확인하지 않고 그 달을 바쁘거나 한가한 시스템의 증거로 읽지 말라고 경고한다.

넓은 교훈은 번호 자원 선이 오도적이었다는 것이 아니다. Durand 자신이 그것을 안정적이라고 기술했다. 교훈은 요청 건수 수준의 안정성이 공급, 정책, 하류 사용, 각 거래에 붙은 결과에 무엇이 일어났는지 열어 둔다는 것이다. 좋은 분석은 이 구분을 보존한다.

긴 레지스트리 꼬리와 이례적으로 활동적인 하나의 시계열

프로토콜 파라미터 섹션은 목록 규모와 요청 물량 사이의 또 다른 불일치를 조명한다. Durand는 ICANN이 IANA 기능 운영 주체로서 유지하는 레지스트리의 압도적 다수가 IETF가 정의하고 사용하는 프로토콜 파라미터라고 썼다. 그러나 사용 데이터 안에서 가장 많이 사용된 IETF 프로토콜 파라미터 레지스트리는 PEN(Private Enterprise Number) 레지스트리였다. PEN 값은 SNMP 관리 정보 베이스(MIB) 구성에서 흔히 사용된다.

많은 레지스트리가 있다고 해서 모든 레지스트리가 동등한 변경 흐름을 받는다는 뜻은 아니다. 긴 꼬리 서비스는 거의 건드리지 않는 많은 레지스트리와 반복 요청을 끌어당기는 소수의 레지스트리를 함께 담을 수 있다. 이는 인프라 운영의 흔한 과제다. 목록은 폭을, 활동 데이터는 집중을 기술한다. 둘 다 필요하다. 레지스트리 수만으로 만든 예산은 조용한 네임스페이스의 루틴 업무를 과대평가하고, 바쁜 네임스페이스의 폭발적 부하를 과소평가할 수 있다.

Durand는 독자가 이것을 보도록 하나의 의도된 그래프 선택을 했다. PEN 요청의 빈도가 같은 차트에서 나머지 시계열을 읽기 어렵게 만들었기 때문에, PEN 요청을 다른 IETF 요청과 분리했다. 이는 표현에 대한 선택이면서 어떤 비교가 가능한지에 대한 선택이기도 했다. 별도의 PEN 선이 없다면, 작은 요청 시계열은 그 옆에서 거의 평평하게 보였을 것이다. 분리한 뒤에는 집중된 레지스트리와 낮은 물량의 나머지 모두를 검사하기 쉬워졌다.

그 선택이 그래프를 완전한 복잡도 지표로 만들지는 않는다. 빈도에 대한 더 나은 시각을 준다. 그 글은 PEN 등록이 다른 프로토콜 파라미터 변경보다 쉬웠는지 어려웠는지, 어느 레지스트리가 전문가 상의를 요했는지, 요청이 얼마나 자주 정정되었는지, 각 유형이 얼마나 시간을 소모했는지 독자에게 알려 주지 않는다. 바쁜 레지스트리는 예측 가능하고 자동화하기 쉬울 수 있다. 드문 레지스트리는 신중한 검토를 요하고 호환되지 않는 구현의 더 큰 위험을 지닐 수 있다. 그 질문에 답할 기록은 요청 시계열 안이 아니라 그 옆에 놓일 것이다.

기술적 맥락은 범주 오류를 막는 데도 도움이 된다. 프로토콜 파라미터 레지스터는 하나의 운영 주체가 기록을 유지한다는 이유만으로 단일 정책 영역이 아니다. RFC 2860은 IETF 범위의 프로토콜에 대해 IANA가 RFC에 명시된 기준과 절차에 따라 파라미터를 할당·등록한다고 정한다. 기술적 의문이 있으면 IESG(Internet Engineering Steering Group)에 지침을 구한다. 운영 주체의 카운트는 요청이 도착했음을 보여 준다. 표준 문서와 관련 절차는 그 요청을 어떻게 다루어야 하는지 확립한다.

운영 주체의 이름이 전체 시스템을 대변할 때 이 경계는 놓치기 쉽다. 독자는 “IANA가 값을 할당했다”를 보고 IANA가 실체적 규칙을 골랐다고 추론할 수 있다. 합의는 IETF 범위의 파라미터에 대해 그 추론이 틀릴 수 있는 이유를 보여 준다. 레지스트리 운영 주체는 기록을 유지하고 지시를 적용하며, 관련 표준 과정이 적용 기준을, 그리고 명시된 경우 지침을 공급한다.

Durand의 IETF에서의 긴 참여는 그를 유일한 저자로 만들지 않으면서 그 구분에 개인적 차원을 준다. 그가 Johan Ihren과 공저한 RFC 3901은 혼합 IPv4·IPv6 전송 상황에서의 DNS 배치에 대한 운영 지침을 제공한다. 각 존이 적어도 하나의 IPv4 도달 가능한 권한 서버를 유지할 것을 권하는데, 이는 IPv6를 사용할 수 없는 클라이언트의 리졸루션 경로가 끊기는 것을 막기 위한 연속성 조치다. 그 권고는 IANA의 레지스트리 업무량 측정이 아니라 전환기에 걸친 프로토콜 운영에 관한 것이다. 그는 요청 총계가 표현할 수 없는 세부가 운영 연속성을 좌우한다는 기술적 관점을 질문에 가져왔던 것이다.

그는 또한 DNS에서의 IPv6 주소 표현을 다룬 RFC 3363의 다섯 편집자·저자 가운데 이름을 올렸고, Ihren과 Pekka Savola와 함께 RFC 4472의 정보성 운영 논의를 공저했다. 이들은 협업 기록이지 단독 설계자의 증거가 아니다. 오랜 표준 참여자가 서비스 내부에서 레지스트리 운영이 어떻게 보이는지 이해하고 싶었을 가능성을 그럴듯하게 만든다. 그러나 IPv6 DNS의 전체 정책이나 공학 역사를 그에게 귀속시킬 근거는 되지 않는다.

마지막 그래프가 유용한 이유는 유일한 그래프가 아니기 때문이다

Durand의 마지막 차트는 5년에 걸친 세 커뮤니티의 요청을 결합했다. 그는 ccTLD와 gTLD 위임·재위임 선이 다른 시계열과 나란히 읽힐 수 있도록 오른쪽 보조 축을 사용했다고 밝혔다. 그는 신규 gTLD 도입이 관련 위임 물량을 크게 늘렸고, 번호 자원 요청은 평평했으며, 프로토콜 파라미터 요청은 2012년 중반 무렵의 정체 이후 상승하기 시작했다고 보고했다. 신규 gTLD를 예외로 하고, 그는 기간 전체의 총량을 예측 가능하다고 기술했다.

결합 차트는 중요한 질문에 답할 수 있다. 기록된 요청의 총량이 기능들에 걸쳐 어떻게 움직였는가? 그것은 관리자가 한 흐름의 급증이 모든 흐름의 동시 변화를 의미하지 않는다는 것을 인식하도록 돕고, 예외적 프로그램 증가를 더 긴 기준선 옆에 놓아 서로 관련 없는 단면 비교를 강요하지 않는다.

그러나 총량은 요약하면서 가릴 수도 있다. 어떤 시계열이 보조 축을 차지하면, 독자는 척도가 다름을 알아차려야 한다. 한 레지스트리가 다른 것보다 훨씬 많은 이벤트를 만들면, 집계는 그 고빈도 흐름을 대체로 반영할 수 있다. 낮은 빈도의 작업이 큰 결과를 지니면, 총량은 그것을 시각적으로 사라지게 할 수 있다. 산술은 옳아도 직관적 비교는 약해질 수 있다.

보조 축 자체는 결함이 아니다. 차트 설계가 추리의 일부를 수행한다는 점을 상기시킬 뿐이다. 잘 레이블된 차트는 두 척도를 보여 주면서 기저의 카운트가 운영적 중요성에서 직접 비교 가능하다고 가장하지 않을 수 있다. 덜 신중한 독자는 같은 세로 이동이 같은 양을 의미한다고 하듯 기울기나 높이를 비교할 수 있다. Durand는 별도 축을 명시적으로 표시해 독자가 올바르게 읽을 기회를 주었다. 함께 실린 본문도 총량에 혼자 말하게 하지 않고 각 커뮤니티의 주요 추세를 명명했다.

여기에는 더 넓은 측정 원칙이 있다. 집계는 분류를 대체하지 말고 분류 뒤에 와야 한다. 먼저 이벤트가 무엇인지 정의한다. 그다음 어떤 범주를 더할 수 있고, 어떤 것이 별도 척도를 요하고, 어떤 것이 다른 성과 지표를 요하는지 결정한다. 이 단계를 따르는 총량은 요약할 수 있다. 이를 지우는 총량은 매력적이면서 정보 없는 수가 될 위험이 있다.

Durand의 글에는 분류의 증거가 있지만, 이후 감사자가 원하는 모든 정의는 없다. 본문에 각 그래프의 상세 데이터 사전을 공개하지 않고, 접근 가능한 표로 매월 값을 보여 주지 않으며, 중복, 재개된 사건, 완료되지 못한 요청을 어떻게 다루었는지 문서화하지 않았다. 이 한계는 분석을 무효로 하지 않는다. 분석의 경계를 정한다. 독자는 그가 보고한 방향과 상대적 패턴을 배울 수 있으나, 본문만으로 정확한 통계 모형이나 정밀한 업무량 예산을 재구성해서는 안 된다.

전체 시계열이 예측 가능했다는 수치도 좁은 의미를 가진다. 요청 물량은 신규 gTLD 효과를 제외한 5년 기록에서 예측 가능했다. 그것은 직원 시간, 리스크, 지연, 정확성, 재정 수요, 고객 만족이 똑같이 예측 가능하다는 것을 확립하지 않는다. 예측은 언제나 명시된 변수의 예측이다. 이 글의 변수는 요청 물량이었다. 다른 결과로 확장하려면 다른 데이터가 필요하다.

물량과 성과가 같은 달에 만났다

유용한 비교가 그의 글 옆에 놓여 있다. IANA는 당시 ICANN의 기능 이행을 지배하던 계약에 따라 2015년 5월 C.4.4 성과 보고서를 발행했다. 그것은 루틴한 루트 존 변경이 정해진 시간 내 처리되었는지, 승인된 변경이 정확히 시행되었는지, 번호 자원 요청이 적시성, 프로세스 품질, 투명성 요건을 충족했는지 같은 지표를 보고했다.

위임된 TLD 기록의 루틴 변경에 대해 보고서는 80퍼센트가 21일 내에 엔드투엔드로 처리될 것이라는 목표를 두었다. 5월 실적은 86.1퍼센트였고, 정확도는 100퍼센트 목표 대비 100퍼센트로 목록에 올랐다. 번호 자원 섹션은 여러 개의 별도 지표를 정의하면서, 보고 월에 완료된 번호 자원 요청이 없다고도 밝혔다.

이 지표들은 Durand의 5년 그래프와 다른 질문에 답한다. 그래프는 넓은 범주로 몇 개의 요청이 도착했는지 묻는다. 계약 보고서는 명시된 서비스 의무가 충족되었는지 묻는다. 어느 쪽도 다른 쪽을 대체하지 못한다. 서비스는 물량이 늘면서도 시간 목표를 충족할 수 있다. 서비스는 물량이 적으면서도 영향이 큰 사건에서 실패할 수 있다. 카운트만으로 결과가 정확했다는 것을 보여 줄 수 없고, 정확도 백분율만으로 얼마나 많은 업무가 도착했고 얼마나 복잡했는지를 보여 줄 수 없다.

보고서들은 분모에 주의가 필요한 이유도 보여 준다. 한 달에 완료된 번호 자원 요청이 없다면, 독자는 각 백분율이 어떻게 계산되었는지, 지표가 이전 기간의 요청에 관한 것인지 진행 중인 프로세스에 관한 것인지, 어떤 관측이 포함되었는지 알아야 한다. 목표 달성이라는 헤드라인은 완료된 업무의 카운트와 같지 않다. 공식 보고서가 활동 메모를 공급해 주므로 신중한 독자는 백분율을 물량의 측정으로 다루는 실수를 피할 수 있다.

어떤 근거도 Durand의 글이 C.4.4 보고서를 낳았거나 그가 그 지표를 설계했다는 것을 보여 주지 않는다. 계약 보고 체계는 같은 시기에 존재했고, 두 공개 기록은 서로 다른 차원을 측정하기 때문에 비교 가능하다. 그의 글은 넓은 사용 패턴을 더 잘 보이게 했다. 성과 보고서는 선정된 적시성, 정확성, 프로세스, 투명성 의무를 검사 가능하게 했다.

이 짝은 더 유용한 측정 패키지를 시사한다. 범주별 요청 건수, 도착과 완료 타임스탬프, 외부 결정을 기다린 시간, 확인 사이클 수, 정정과 정확성 기록, 백로그 연령, 고객이 체감하는 결과. 처음 둘은 흐름을 기술하는 데, 다음 세트는 프로세스 품질을 설명하는 데, 마지막은 서비스 성과를 그것에 의존하는 사람들과 시스템에 연결하는 데 도움을 준다. 어떤 단일 지표도 그 모든 질문을 대변할 수 없다.

카운트는 여전히 옳은 첫 수가 될 수 있다. 운영 주체가 어느 서비스가 어느 요청을 받는지 말할 수 없다면, 대기열을 합리적으로 예측하거나 변화를 진단할 수 없다. 그러나 서비스 보고서는 도착한 업무와 그에 무엇이 일어났는지를 함께 보여 줄 때 더 책임 가능해진다.

이관은 집단적이었고, 기능들은 서로 구별된 채 남았다

Durand는 자신의 분석이 이관에 적극적으로 관여하는 사람들이 IANA 기능의 범위를 이해하는 데 도움이 될 수 있다고 말했다. 시기가 중요하다. 그는 이관 제안이 아직 조립 중이던 2015년 5월에 발행했다. 그러나 시기는 영향력의 증거가 아니다. 검토한 공개 자료는 그의 차트가 최종 제안의 근거로 인용되었거나, 그가 그 아키텍처를 골랐거나, 그의 개인적 견해가 커뮤니티의 합의를 결정했다는 것을 보여 주지 않는다.

2016년 3월에 송부된 최종 ICG 제안은 기능 운영 주체와 직접적 관계를 지닌 세 운영 커뮤니티 — 도메인 이름, 번호 자원, 프로토콜 파라미터 — 를 기술한다. 세 기능에 대한 정책과 감독 책임이 그 분리된 커뮤니티들에 있었다고 기술한다. 이어서 서로 다른 배치들을 기록한다. 이름 기능에 대한 계약과 모니터링 구조, 번호 서비스에 대한 ICANN과 5개 RIR 간 협정, 프로토콜 파라미터에 대한 IETF 협정과 그 정립된 정책·감독의 지속.

이 구조는 카운트 범주가 왜 중요했는지를 강화한다. 같은 운영 주체가 각 커뮤니티의 요청을 처리할 수 있어도, 고객 관계, 정책의 원천, 책임 경로는 동일하지 않았다. 운영 주체의 이름 자체는 누가 어떤 규칙을 적용하기로 했는지에 대한 완전한 설명이 아니었다. 월간 그래프는 수요를 읽을 수 있게 할 수 있었지만, 레지스트리 파일을 운영하는 사람이나 조직에 통합된 정책 권한을 부여할 수는 없었다.

이사회는 2016년 3월 10일 ICG 제안을 수용했다. 그 집단적 결정은 기록 속에서 집단적으로 남아야 한다. Durand 자신의 서술은 자신을 그 과정을 지원하는 기술 스태프 역할에 놓는다. 그것은 그를 선출된 커뮤니티 대표들 사이에 놓거나, 최종 제안의 저자로 만들지 않는다. 그의 공개 글은 업무 이해에 대한 기여의 증거이지, 거버넌스에 대한 저작권의 증명이 아니다.

이 구분이 그의 업무의 가치를 보존한다. 운영 분석이 왜 중요했는지 보이기 위해 개인의 영향력을 과장할 필요는 없다. 이관에는 계약, 책임성, 연속성, 정당성이 관여한다. 그것을 책임 있게 설계하려면 사람들은 서비스가 무엇을 하고 어떻게 작동하는지 알아야 한다. 물량에 대한 증거는 그 그림에 들어가는 입력 중 하나다. 응답 시간, 정확성, 정책 문서, 고객 경험, 보안 통제, 재정, 비상 계획도 그렇다.

요청 차트는 헌법 문서가 아니다. 어느 커뮤니티가 정책을 정할 권리를 가졌는지, 요청에 분쟁이 있을 때 어떤 절차가 적용되는지 답할 수 없다. 그러나 기능이 어떻게 운영되는지를 무시하는 거버넌스 설계 역시 불완전하다. 규칙이 관련 데이터를 볼 수 없는 사람들에게 책임을 배정하면, 그들은 정상 활동과 경고 신호를 구분하지 못할 수 있다. 운영 주체가 모든 데이터와 그 정의를 통제하면, 고객은 해석에 도전할 근거를 잃을 수 있다.

따라서 증거와 권한 사이의 유용한 관계는 대체가 아니라 분리다. 증거는 어떤 정의 집합 아래 무엇이 일어났는지를 의사 결정자에게 알려 준다. 권한은 누가 증거를 해석하고, 규칙을 정하고, 시정을 요구할 수 있는지를 결정한다. 내구성 있는 감독 체계는 둘 다 필요로 하며, 그 사이에 보이는 경로가 있어야 한다.

공개 기록이 Durand에 대해 말할 수 있는 것

근거는 작지만 명확한 순서를 확립한다. Durand는 2015년 3월 ICANN에 합류했다. 그는 IETF 업무를 통해 오랫동안 IANA 레지스트리를 사용해 왔지만 그 내부 운영은 가깝게 몰랐다고 썼다. 그의 역할은 이관 과정 지원에 관여했다. 그는 5년치 가용 사용 데이터를 모아, 발표를 커뮤니티와 요청 유형으로 나누고, 가독성을 위해 PEN 활동을 분리하고, 집계 추세를 요약했다.

그 순서는 업무 결정과 공개 결과를 기술한다. 그가 쓴 것 이상의 사적 동기를 드러내지 않는다. 누가 프로젝트를 배정했는지, 다른 직원이 기저 데이터를 조립했는지, 차트가 어떻게 검토되었는지, 데이터 수집이 완전했는지, 그 글이 예산이나 제안을 바꾸었는지 알려 주지 않는다. 신중한 프로필은 그 빈틈을 상상의 장면으로 채울 필요가 없다.

그의 기술적 기록은 이 작업이 그 배경에 왜 부합하는지 설명해 준다. 그와 연관된 RFC들은 공동 집필되고 공학 과정을 거쳐 검토된 운영 지침을 포함해 IPv6와 DNS에 관한 업무를 보여 준다. 그 문서들은 상호운용성, 연속성, 프로토콜 배치의 실용적 결과에 관한 것이다. 2015년 사용 연구는 관련되면서도 구별되는 관심사를 가졌다. 하나의 기록 보존 서비스가 서로 다른 기술 커뮤니티에 걸쳐 어떻게 사용되고 있었는가.

근거는 이 전기가 얼마나 넓어질 수 있는지도 한정한다. 이 글은 그의 경력의 모든 고용주나 프로젝트를 재구성하지 않는다. 여기서 가용한 자료는 초점이 맞은 초상을 지지한다. 조직 안으로 옮겨간 기술 참여자가, 공개 레지스트리에 대한 친숙함이 운영에 대한 지식과 같지 않다는 것을 알아차리고, 통계를 사용해 그 차이를 이해했다. 그것이 이야기인 이유는 관찰 가능한 결정과 공개된 결과에 연결될 수 있기 때문이다.

결과는 새로운 서비스 모델도, 검증된 업무량 예측도 아니었다. 운영 주체의 미래 감독이 공개적으로 논의되던 시점에 요청 패턴에 대한 더 명확한 기술이었다. 독자는 어느 패턴이 변했고 어느 것이 대체로 안정적이었는지 볼 수 있었다. 그리고 그 업무가 하나의 거대한 대기열이 아니라는 것도 볼 수 있었다. 이것들은 기능을 누가 다스려야 하는지를 정하지 않더라도 의미 있는 조직적 산출이다.

따라서 “Durand는 무엇을 이루었는가?”라는 질문은 그를 단독 설계자로 만들지 않고 답할 수 있다. 그는 IANA 운영의 한 단면을 더 논의하기 쉽게 만들었다. 그는 대화를 “IANA 기능”이라는 추상에서 식별 가능한 서비스 흐름 쪽으로 옮기는 데 도움을 주었다. 주장의 규모가 증거의 규모에 맞는다.

지도는 위임장이 아니다

“커뮤니티가 얼마나 사용하는가”라는 표현은 그의 연구에 대한 자신의 설명에 나온다. 사용은 유용한 렌즈다. 서비스는 조직도가 아니라 실제 수요에 맞춰 크기가 정해져야 하기 때문이다. 그러나 사용은 인프라 기능의 전체 공공적 가치를 정의하지 않는다. 어떤 기록이 드물게 바뀌는 것은 정확히 많은 시스템이 의존할 수 있는 합의된 네임스페이스를 조율하기 때문일 수 있다. 낮은 이벤트 수가 높은 연속성 의무와 함께 올 수 있다.

또한 사용이 운영 주체가 누구의 규칙을 따라야 하는지를 결정할 수 없다. 레지스트리는 별도의 기술 커뮤니티가 개발한 정책 아래 요청을 받을 수 있다. 운영 주체의 업무는 필수적이면서도 그 재량은 경계를 지닌다. 값을 할당하고, 표준을 정하고, 위임을 승인하고, 정책을 변경하는 권한은 다른 곳에 있을 수 있다. RFC 2860은 프로토콜 파라미터에 관한 IETF 경계를 명시한다. 이관 제안은 세 범주 모두에 대해 분리된 정책·감독 커뮤니티를 기록한다.

반대의 오류도 가능하다. 운영 주체가 정책을 만들지 않는다고 해서, 사람들이 이행의 중요성을 과소평가할 수 있다. 정확히 유지된 레지스트리는 서면 규칙이 네트워크 운영자가 사용할 수 있게 되는 지점일 수 있다. 지연이나 부정확한 항목은 구현, 네이밍, 라우팅, 조율에 영향을 줄 수 있다. 정책 소유와 운영 책임은 구별되지만 어느 쪽도 하찮지 않다.

따라서 진지한 평가는 다음 질문들을 따로따로 묻는다.

  • 카운트되는 요청이나 변경은 어떤 종류인가?
  • 수용을 지배하는 규칙은 무엇이며, 누가 그것을 정했는가?
  • 처리에 얼마나 걸렸으며, 그 중 얼마나 운영 주체의 통제 아래 있었는가?
  • 결과 기록은 정확하고 공개적으로 이용 가능했는가?
  • 어떤 시스템이나 사용자가 그 결과에 의존했는가?
  • 어느 기구가 불일치를 검토하거나 정정을 요구할 수 있는가?
  • 한 운영 주체가 실패하면, 연속성에 필요한 이력·데이터·전문성을 잃지 않고 다른 주체가 이어받을 수 있는가?

사용 차트는 주로 첫 번째 질문에 답하고, 그 뒤를 잇는 이차적 운영 질문에 대한 부분적 기준선을 제공한다. 전체 목록에 답하지는 못한다. 범위를 이해하려던 글에 대한 비판이 아니다. 더 큰 결론의 증거로 쓰기보다 그것이 묻는 질문을 위해 읽어야 할 이유다.

공개 보고 체계는 여전히 이 차원들을 분리해 둘 필요를 반영한다. 현재의 IANA 성과 지표는 네이밍 SLA, 번호 자원 SLA, IETF 프로토콜 할당 통계, 루트 존 유지 관리자 성과, 기타 기록에 별도의 표면을 제공한다. 그 보고 분류는 Durand의 2015년 차트의 단순한 연속이 아니며, 그의 연구가 그것을 낳았다는 근거도 없다. 다만 성과 회계가 단일한 보편적 IANA 점수가 아니라 서비스 관계와 지표로 조직되어 있음을 보여 준다.

따라서 가용 기록 속에서 Durand의 가장 내구적인 기여는 헌법적이라기보다 인식적이다. 그는 데이터가 무엇을 드러낼 수 있는지 독자에게 보였다. 서로 다른 서비스 흐름, 눈에 보이는 프로그램 주도 변화, 안정적인 번호 요청 패턴, 집중된 요청 시계열을 지닌 긴 레지스트리 카탈로그. 신중한 독자는 추가 증거 없이는 데이터가 무엇을 드러낼 수 없는지도 볼 수 있다.

운영 주체에게 그 경계는 실용적이다. 이사회가 상승하는 요청 시계열을 본다면, 인력이나 프로세스나 통제를 바꿔야 하는지 물어야 한다. 커뮤니티가 안정적인 시계열을 본다면, 정책이 확정되었거나 결과가 작다고 가정해서는 안 된다. 이관 제안이 기능들에 걸쳐 같은 운영 주체를 가리킨다면, 각 기능에 붙은 별도의 고객, 규칙, 검토 권리를 그대로 보존해야 한다.

카운트는 운영을 읽을 수 있게 만들 수 있다. 그것만으로 그 운영을 정당하게 만들 수는 없다. Durand의 글은 지도로 읽을 때 가장 강하다. 규칙을 누가 정하는지, 서비스가 얼마나 잘 수행되었는지, 증거가 문제를 가리킬 때 누가 행동할 수 있는지를 묻기 전에, 업무가 어디에 도착했고 그 패턴이 어떻게 변했는지 볼 수 있는 방법으로.

출처