Summary

  • 10월 26일자 IANABIS 초안은 IETF 스트림 RFC 없이도 등록할 수 있는 모든 새 등록부에 Change Controller 칸을 만들도록 IANA에 지시한다. 선착순, 전문가 검토, 명세 필요, RFC 필요 절차가 포함된다. 해당 칸이 없는 기존 등록부에는 앞으로 빈 칸을 추가한다. 문서는 아직 Internet-Draft다.
  • 현행 RFC 8126도 변경 관리자를 밝히라고 권고했다. 현재 IANA의 JSONPath 함수 확장 등록부에는 전문가 Glyn Normington과 다섯 항목의 변경 관리자 IETF가 별도로 적혀 있다.

처음 배정한 사람은 영구 승인자가 아니다

새 프로토콜 값을 등록할 때는 절차가 눈에 잘 띈다. 번호가 비어 있는지, 문서가 조건을 충족하는지, 전문가 검토가 필요한지 확인한다. 하지만 등록부는 첫 배정에서 끝나지 않는다. 몇 년 뒤 설명을 바로잡거나 참고 문헌을 바꾸고 담당 연락처를 갱신해야 한다. 처음 글을 쓴 사람이 아직 일한다고 가정할 수 없다. 문의에 답하는 연락처가 변경을 승인할 권한을 가졌다고 볼 수도 없다. 기술 판단을 맡은 전문가는 또 다른 역할을 수행한다. 이 구분을 표 밖에 숨기면 권한은 오래된 메일함을 아는 사람에게 흘러간다.

현행 RFC 8126은 이미 변경 관리라는 문제를 다룬다. IETF 스트림 RFC에서 나온 등록부와 항목은 기본적으로 IESG를 통해 IETF가 변경을 관리한다. 그 경로 밖의 등록을 받는 등록부는 관리자를 명시하도록 권고한다. 새 선착순 등록부와 전문가 검토 등록부에는 별도 칸을 두는 편이 좋다고도 한다. 이번 초안은 새로운 권력자를 발명하지 않는다. 기존 권고를 IANA가 수행할 더 넓고 구체적인 지시로 옮긴다.

IANABIS -04 초안 11.2절은 IETF 스트림 RFC를 요구하지 않는 절차의 모든 새 등록부에 Change Controller 칸을 만들라고 한다. 선착순, 전문가 검토, 명세 필요, RFC 필요를 예로 든다. 2.5절에서는 IETF 스트림 항목의 칸에 통상 IESG보다 IETF를 적으라고 한다. IESG는 IETF를 대신해 일하기 때문이다. 원본 RFC가 명시적으로 IESG를 지정했다면 그 예외를 따른다. 기관의 권한과 이를 행사하는 기구를 같은 이름으로 뭉개지 않으려는 규칙이다.

빈 칸은 권한 위임장이 아니다

오래된 표에 대한 문구는 더 정직하다. 관리 칸이 없는 해당 기존 등록부에는 앞으로 빈 칸을 더한다. 과거 작성자나 현재 연락처를 자동으로 관리자로 승격시키지 않는다. 빠진 결정을 눈에 보이게 놓는 조치다. 초안에는 영향을 받는 등록부의 총수도, 그 칸을 언제 채울지에 관한 일정도 없다. 영향을 받는 표 목록과 각 관리자를 확정할 문서가 공개된다면 일의 규모를 판단할 수 있다.

이미 채워진 칸의 모습은 IANA JSONPath 등록부에서 볼 수 있다. Function Extensions는 Expert Review로 등록되며 전문가로 Glyn Normington이 표시된다. length, count, match, search, value 다섯 항목의 Change Controller는 IETF다. 같은 페이지에서 기술 검토자와 변경 권한자가 다른 자리에 있다. 이 표는 기존 사례이지 새 초안이 시행됐다는 증거가 아니다.

관리자 이름 자체가 바뀌는 경우도 있다. 초안 3.1.2절은 별도 규정이 없으면 등록 절차를 수정 절차로도 쓰도록 한다. RFC 없이 등록한 항목에서는 IANA가 연락처나 관리자 정보의 갱신을 확인하고 승인할 수 있으며, 필요하면 전문가나 영역 책임자의 조언을 구한다. 칸에 쓰인 이름과 그 이름을 바꿀 수 있는 절차가 맞물려야 한다. 이름표만 공개하고 누구나 이름표를 갈아 끼울 수 있게 두면 표는 장식품이 된다.

현재 적용되는 지침은 RFC 8126이다. IANABIS -04는 작업반의 Internet-Draft 단계다. 뒤따를 확정 문서, IESG 상태, IANA 표의 실제 수정 기록이 제안의 실행 여부를 보여줄 것이다.