요약

  • 이의제기 기간은 결정이 공개된 시점부터 두 달로 고정되어 있지만, 결정 자체에 적용되는 기한은 문서상 '합리적인 기간'이라는 문구뿐이며 보편적인 숫자는 없다.
  • 항소 절차의 최상위 단계인 IAB는 IESG의 결정을 무효화해 이전 상태로 되돌릴 수 있으나, IESG에 유보된 결정을 대신 내릴 수는 없고, 검토한 조항이 등록을 명할 권한을 명시한 것도 아니다. 그런 명시가 없다는 결론은 두 조항을 함께 읽은 필자의 해석이며, 문서에 그렇게 적혀 있지는 않다.
  • 사슬에서 처음 이름 붙는 제도적 단계는 해당 전문가를 임명하고 재량으로 해임할 수 있는 기구다.

프로토콜 파라미터 레지스트리는 엔지니어링 합의가 번호로 굳어지는 자리다. 장비 유형 코드, 필드 값, 레지스트리 식별자 같은 것들이 여기서 확정된다. 이런 결정은 사무적으로 보이지만 저자와 근거와 불복 경로가 따로 있다. IANA가 운영하는 프로토콜 레지스트리에서는 그 경로가 꽤 상세하게 규정되어 있고, 바로 그 상세함 덕분에 비대칭이 눈에 띈다. 이의제기에는 단단한 기한이 있고, 결정에는 말로 된 공식 하나만 있다.

규칙을 정하는 문서는 2017년 6월에 나온 RFC 8126이다. 이 문서는 열 가지 등록 정책 범주를 둔다. Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, Specification Required, RFC Required, IETF Review, Standards Action, IESG Approval이 그것이다. 이 눈금의 양 끝은 그 자체로 중요하다. Private Use와 Experimental Use 값은 IANA가 아예 기록하지 않는다. 공개 레지스트리 밖에, 번호 체계 밖에, 항소 절차 밖에 존재하는 값이다.

가장 흥미로운 단계는 Specification Required다. 전문가 검토에 더해 영구적이고 공개적으로 열람 가능한 명세를 요구한다. 그 명세는 명확하고 기술적으로 건전해야 하며, 독립적인 구현이 서로 연동할 수 있을 만큼 충분해야 한다. RFC일 필요는 없다. 숫자로 잴 수 없는 문턱이고, 무엇이 충분한 문서인지를 둘러싼 다툼이 바로 여기서 생긴다.

전문가는 빈 공간에서 판단하지 않는다. 같은 RFC의 §§5.1–5.3에 따르면 전문가는 해당 레지스트리에 공개된 기준이 있으면 그 기준으로 요청을 평가하고, 없으면 문서의 완전성과 연동성, 충돌 여부로 평가하며, 설득력 있는 반대가 없는 한 요청을 받아들이는 쪽을 기본으로 삼는다. 거부 사유도 열거되어 있다. 자원의 희소성, 불명확한 문서, 해로운 구조적·운영적 영향, IETF 작업과의 해로운 충돌이다. 모두 공개된 기준에 따른 판단이지만, 판단인 것은 분명하다.

그다음이 권한의 구조다. §5.2.1은 그대로 이렇게 적는다. "The IESG may remove any designated expert that it appointed, at its discretion." 같은 절은 IETF 레지스트리의 전문가를 IESG가 임명하고 교체하며, 보통 지역 담당 이사의 추천을 따른다고 밝힌다. 판단을 다툴 수 있는 전문가는, 그 이의를 가장 먼저 심사할 기구가 임명한 사람이다.

불복 경로는 §10에 있다. 등록 결정에 대한 이의는 IESG로 간 뒤 IAB로 가고, 전문가 팀이 얽힌 분쟁에는 RFC 2026 §6.5.1의 절차가 적용된다. 사다리는 작업반 의장, 해당 지역 담당 이사, 전체 IESG, IAB 순이다. 각 단계는 사안을 검토하고 해결을 시도해야 하며, IAB는 절차 준수와 기술적 타당성에 관해 최종이다.

이제 기한이다. 여기서 문서들은 대칭을 잃는다. RFC 2026 §6.5.4는 이렇게 못 박는다. "All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged." 두 달은 결정이 공개된 시점에서 세는 상한이고, 발효 시점도 통지 수령 시점도 아니다. 반면 결정 자체에 대해 같은 절은 '합리적인 기간' 안에 결정하고 통보하라고 요구할 뿐이며, 보편적인 고정 기한은 없다고 명시한다. IANA 레지스트리 운영 원칙도 같은 논리를 확인한다. RFC 8720 §3.1은 예측 가능한 처리를 예상치 못한 단계가 없는 것으로 정의하며, 정해진 일수 안에 결정을 보장하는 것으로 정의하지 않는다. 겉보기 비대칭이 여기서 드러난다. 기다리는 쪽에는 달력이 없고, 다투는 쪽에는 마감이 있다. 그 격차가 의도된 초안인지는 이 리뷰에서 확인하지 않는다.

맨 위 단계가 최고 권한은 아니다. RFC 2026 §6.5.2는 IAB가 IESG의 결정을 무효화해 이전 상태로 되돌리거나 조치를 권고할 수 있게 하면서, IESG에 유보된 결정을 내리는 것은 금지한다. 이를 §6.5.1의 사다리와 함께 읽으면 필자의 결론이 나온다. 검토한 사다리에서 확인되는 가장 강한 결과는 취소이지 명령이 아니다. 검토한 조항은 IAB에 등록을 명할 권한을 명시적으로 부여하지 않는다. 권고, 취소 후 재심사, 또는 사안에 따라 나중에 등록에 이르는 경로는 열려 있다. 더 나아간 구제는 §6.5.3에 따라 Internet Society 이사진에게 향하고, 기술적 본안이 아니라 절차 자체의 적절성을 다룬다.

문서가 풀지 않는 질문이 남는다. §5.2.1은 IESG가 자신이 임명한 전문가를 재량으로 해임할 수 있게 하고, §10은 등록 결정에 대한 이의를 우선 같은 IESG로 보낸다. 두 조항은 나란히 서 있고, 검토한 조항 어디에도 임명하는 역할과 1심 심사 역할의 분리가 선언되어 있지 않다. 사슬에서 처음 이름 붙는 제도적 단계는 그 전문가를 임명하는 기구다. §10의 경로는 전체 IESG에 이르기 전에 작업반 의장과 해당 지역 담당 이사를 거치며, 특정 이의를 누가 심리하는지, 같은 사람들이 관여하는지는 여기서 확인하지 않는다. 이것은 고발이 아니라 구조에 대한 서술이다. 재심의 가능성은 있지만, 임명한 쪽과 재심하는 쪽 사이의 제도적 거리는 선언되어 있지 않다.

현행 규범은 멈춰 있지도 않다. 2026년 3월에 나온 RFC 9907은 RFC 8126을 명시적으로 갱신하고 RFC 8407을 폐기한다. §§4.30.3과 5.3은 권위 있는 레지스트리의 변경을 IANA가 유지하는 해당 YANG 모듈의 관리와 연결하고, 새 값은 모듈에 직접 넣지 말고 레지스트리에 두라고 요구한다. 오류 기록도 내용이 있다. 정오표 검색에서 기술 정오표 6522는 2021년 4월 8일 기각되었다. 전문가 검토 아래 §4.6을 충족하는 수단으로 특정 Internet-Draft 버전을 명시적으로 허용하자는 제안이었는데, 검증자는 이를 오류 수정이 아니라 공동체 논의와 합의가 필요한 정책 제안으로 보았다. 이 기각은 경계를 확정한다. 문서 요건의 문턱은 편집상 오타가 아니라 정책의 문제다.

대체 문서도 준비 중이다. draft-ietf-ianabis-rfc8126bis-05는 2026년 11월 2일 공개되었고, 초록은 RFC 8126을 폐기한다고 말하지만 머리말은 "if approved"라는 조건을 붙이며 상태 표시는 이 문서가 초안임을 분명히 한다. 이 리뷰에서는 미완의 개정 상태로 읽고, 발효된 규칙으로 다루지 않는다.

레지스트리를 하나의 정책으로 보는 관행을 깨는 실무적 세부도 있다. 2026년 7월 13일 개정으로 표시된 IANA의 RFC 저자 안내는 한 레지스트리 안에서도 범위에 따라 등록 절차가 다를 수 있으므로 레지스트리 이름만으로 적용 정책을 특정할 수 없다고 경고한다. 요청은 정확한 레지스트리와 필요한 필드를 밝혀야 하고, 참조 RFC가 레지스트리 화면에 보이지 않는 필드를 담은 서식을 요구할 수도 있다. Expert Review나 Specification Required의 경우 IANA는 IETF Last Call 기간에 전문가에게 검토를 요청하고 작업반을 참조에 넣는다.

이 리뷰의 경계는 분명히 밝혀야 한다. 실제 등록 요청, 거부, 제기된 이의, 그 처리 결과는 어느 것도 검토하지 않았다. 여기 적힌 내용은 공개된 틀에 관한 것이지, 특정 요청이 어떻게 처리되었는지에 관한 것이 아니다. 어떤 레지스트리에 어느 정책이 적용되는지도 확정하지 않았다. IESG 내부의 이의 처리와 공개되지 않은 과거 이의 기록은 확보하지 못했다. 정오표 6522의 기각은 Internet-Draft가 실무에서 한 번도 받아들여진 적이 없다는 뜻이 아니다. §4.6은 Internet-Draft를 허용 형식으로 열거하지 않는다. IANA 이름 기능 관련 문서를 확보하려던 세 차례 시도는 제공자 측에서 멈췄고, 계약서와 Customer Standing Committee 정관, Naming Function Review 보고서는 여전히 읽지 못한 상태다. 이것은 이 검토의 접근 한계이지 그 문서들의 내용에 대한 판단이 아니다.

그래서 등록을 신청하는 사람에게 무엇이 남는가. 달력은 신청자에게만 있다. 결정이 내려지고 공개되었다면, 이의를 제기할 두 달이 있고, 본안 답변을 받을 기한은 없다. 검토한 조항에서 확인되는 가장 강한 결과는 이전 상태의 회복이다. 그리고 사슬에서 처음 이름 붙는 제도적 단계는 그 전문가를 고르고 해임할 수 있는 기구다.