VELOCE에는 결정-포인터 영수증이 필요하다

요약

OPSAWG는 VELOCE를 채택하고 2026년 8월 25일 워킹 그룹 개정판 00을 발행했습니다. 공개 기록은 이를 WG 문서이자 Internet-Draft로 설명할 뿐, RFC, BCP 또는 최종 IETF 규칙이 아닙니다.
같은 날짜의 속성 기반 프로젝트 콜 요약은 저장소를 가리키는 IANA 포인터가 확정되었다고 밝히는 한편, 개정판 00은 의식적으로 IANA 조치가 없다고 선언합니다. 해시, 상태, 승인 필드를 갖춘 IANA 레지스트리를 구상하는 풀 리퀘스트 49는 연구 기준 시점에 여전히 열려 있고 병합되지 않았습니다.
프로젝트 콜의 결론은 메일링 리스트에서 확인된 워킹 그룹 합의 행위와 같은 것이 아닙니다. GitHub 병합은 WG, Area Director 또는 IESG 승인과 같은 것이 아닙니다. IANA 행은 승인된 산출물을 기록할 수 있지만, 그 규범적 의미를 승인하는 주체가 되지는 않습니다.
VELOCE는 이미 한 가지 익숙한 위험을 피합니다. RFC 참조는 이동하는 브랜치 헤드가 아니라 특정 태그 버전을 가리켜야 합니다. 남은 질문은 이후 승인된 모듈이 어떻게 관련 불변 대상이 되는지, IANA가 이를 어떻게 검증하는지, 구현자는 어떤 버전을 기준으로 적합성을 주장할 수 있는지입니다.
실용적 해법은 얇은 결정-포인터 영수증입니다. 합의, 승인 주체, 정확한 모듈 바이트, 레지스트리 요청과 상태 변경, 버전 선택 규칙, 복구 근거, 이후 운영 채택을 연결한 공개 기록입니다. 이는 새로운 거부권이나 모든 한정된 수정마다 대체 RFC를 요구하는 것이 아니라 추적 가능성을 더하는 것이어야 합니다.

하나의 날짜, 네 가지 상태

공개 이력은 평범하지만 중요한 구분에서 시작됩니다. OPSAWG 의장들은 6월 채택 콜을 충분한 지지 확인으로 마무리하고, 개별 제출물을 다른 변경 없이draft-ietf-opsawg-veloce-yang-00으로 재발행할 것을 요청했습니다.Datatracker 기록은 해당 개정판이 8월 25일 승인된 워킹 그룹 문서임을 보여줍니다. 이는 그룹이 문서의 보관권을 갖게 되었음을 확인해 줍니다. 이후 개정판에서 등장할 모든 설계 선택을 정해 주는 것은 아닙니다.

개정판 00은 YANG 모듈을 RFC에 삽입하지 않는 실험을 제안합니다. 대신 RFC가 특정 태그가 달린 저장소 버전으로 연결됩니다. 이 세부 사항이 중요합니다. main이라는 브랜치는 발행 후에도 움직일 수 있습니다. 지정된 태그나 커밋은 미래의 독자가 발행이 가리킨 바이트를 검색하고 검증할 수 있게 해 줍니다. 초안은 또한 채택된 모듈이 IETF 저장소에서 갱신되고 RFC 참조가 새 버전을 가리키도록 변경될 수 있음을 상정합니다. 명시된 목표는 워킹 그룹 참여와 IETF 대략적 합의를 유지하면서 모듈 유지보수를 가볍게 하는 것입니다.

이 목표는 실제 비용 문제에 대한 답입니다. 작고 보안 관련이거나 상호운용성을 바로잡는 모듈 개정이 단지 이전 문서 안에 모듈이 인쇄되었다는 이유만으로 항상 전체 대체 RFC를 요구할 필요는 없습니다. 그러나 본문을 RFC에서 분리하면, 이전 발행 객체가 암묵적으로 함께 묶어 둔 사실들—어떤 바이트가 승인되었는지, 누가 그를 승인했는지, 어디서 복구할 수 있는지, 어떤 개정판이 적합성 주장을 충족하는지—도 함께 분리됩니다.

IETF 126 이전에 저자들은 이 질문들을 공개적으로 던졌습니다.메일링 리스트 토론은 RFC가 Git 태그, IANA 항목 또는 다른 대상을 가리켜야 하는지, '최신' 포인터는 무엇을 의미하는지, 구현자는 어떤 버전을 사용해야 하는지, 갱신 이후 적합성이 어떻게 검증 가능하게 유지되는지를 묻습니다.IETF 126 회의록은 GitHub, IETF가 통제하는 환경, IANA 발행, 아카이빙과 복구에 대해 상반되는 견해를 보존하고 있습니다. 이 토론은 배정된 시간이 부족하여 리스트에서 계속되었습니다. 이는 진행 중인 설계 질문의 증거이지, 참여자가 부적절한 행동을 했다는 증거가 아닙니다.

8월 25일 프로젝트 콜 요약은 네 번째 상태를 추가합니다. 요약에 따르면 기여자는 저장소의 이슈와 풀 리퀘스트로 작업할 수 있고, 격주 콜에서 형성된 견해는 메일링 리스트에 요약될 것이며, 반대 의견은 병합 전 추가 토론으로 이어져야 하고, IANA 간접 지정 모델이 확정되었습니다. 이 요약은 유용한 출처 기록이지만, 그 자체의 형태가 중요합니다. 이는 프로젝트 콜에 대한 속성 기반 기록이지, 공개된 워킹 그룹 합의 콜이나 IESG 결정이 아닙니다. RFC 8874는 GitHub 작업에 특별한 지위를 부여하지 않으며, 워킹 그룹 합의 결정이 메일링 리스트에서 확인될 것을 요구합니다. 콜은 설계를 앞당길 수 있지만, 그 확인을 조용히 대체할 수는 없습니다.

이제 그 진술을 실제 워킹 그룹 초안과 나란히 놓아 봅시다. IANA 고려사항 섹션은 이 문서에 IANA 조치가 없다고 명시합니다.RFC 8126에 따르면, 명시적인 조치 없음 섹션은 그냥 지나치게 읽을 빈칸이 아닙니다. 이는 작성된 문서에서 IANA가 할 일이 없다는 의식적 결론을 기록합니다. 이후 개정판이 유효한 요청을 추가하는 것을 금지하지는 않습니다. 다만 콜 요약에서 설명된 포인터 아키텍처가 개정판 00 시점에는 아직 IANA 지시가 되지 않았음을 의미합니다.

제안된 레지스트리는 완성된 레지스트리가 아니다

이 격차는풀 리퀘스트 49에서 드러납니다. 기준 시점에 이는 열려 있고 병합되지 않았습니다. 조치 없음 섹션을 YANG File/Module References 레지스트리로 대체하자는 제안입니다. 제안된 필드에는 영구 및 제안 상태, 정확한 URL, SHA-256 값, 관리 책임 연락처, IESG 또는 기타 승인 경로가 포함됩니다. 이들은 유망한 분리 장치입니다. 해시는 바이트를 식별하고, 연락처는 관리 책임을 확립하며, 상태는 제안과 현재 기록을 구분하고, 승인 필드는 결정 경로를 이름 짓습니다.

그러나 제안된 필드는 현재의 공개 권한이 아닙니다. 기존IANA YANG 모듈 이름 레지스트리는 RFC Required 정책으로 관리되며, 이름, 파일, 네임스페이스, 접두어, 참조, 비고 같은 익숙한 모듈 정보를 노출합니다. 현재로서는 제안된 VELOCE 필드인 파일 해시, 승인 상태, 관리 연락처, 결정 영수증을 노출하지 않습니다. IANA가 이미 새 레지스트리를 만들었거나 그 정책을 채택했거나 VELOCE 버전을 가져왔다는 결론이 도출되어서는 안 됩니다.

이는 라벨에 대한 지나친 구애가 아닙니다. 네 가지 객체는 서로 다른 역할을 합니다. 저장소는 풀 리퀘스트를 받고 검토 이력을 유지할 수 있습니다. 병합된 변경은 관리자가 저장소 규칙을 적용했음을 나타낼 수 있습니다. 워킹 그룹은 문서 또는 한정된 변경에 대해 대략적 합의에 도달할 수 있습니다. Area Director나 IESG는 추가 승인 역할을 가질 수 있습니다. IANA는 정의된 등록 또는 발행 행위를 수행할 수 있습니다. 결과적인 레지스트리 행은 버전의 동일성을 보존할 수 있습니다. 어느 행위도 나머지를 자동으로 증명하지 않습니다.

이 구분은 각 기관을 보호합니다. IANA에게 논쟁 중인 모듈이 실질적으로 준비되었는지를 판단하게 하면 기록자를 승인자로 바꾸는 셈입니다. 병합을 합의의 증명으로 대하면 저장소에 없는 헌법적 무게를 부여하는 셈입니다. 태그된 릴리스를 배포의 증명으로 대하면 반복 가능한 바이트와 운영자의 사용 결정을 혼동하는 셈입니다. 올바른 설계는 각 행위가 다른 행위를 흉내 내지 않기 때문에 정확히 드러나게 합니다.

이 상황을 어두운 관점에서 읽는 것에 반하는 유용한 반증도 이미 있습니다. 개정판 00은 브랜치 헤드를 가리키지 않습니다. 대략적 합의 절차를 명시적으로 유지합니다. 열려 있는 풀 리퀘스트는 IANA에 무한한 재량을 부여하는 대신 해시와 명명된 승인 경로로 제약하려 합니다. 그리고 초기 워킹 그룹 개정판이 미해결 토론보다 늦어지는 것은 적절할 수 있습니다. VELOCE는 승인된 RFC, BCP 또는 내일 레지스트리를 만들라는 명령이 아닙니다. 통제 장치가 명시된 방향을 따라잡아야 하는 제안입니다.

포인터를 통제 가능하게 만드는 영수증

빠진 산출물은 두 번째 표준화 과정보다 작습니다. 이후의 각 모듈 변경에 대해 VELOCE는 다음 요소를 담은 하나의 연결된 결정-포인터 영수증을 발행할 수 있습니다.

변경 클래스와 주장된 규범적 효과;
관할 워킹 그룹과 문서의 현재 권한 상태;
메일링 리스트 합의 콜, 시작과 종료 날짜, 주요 반대 의견, 의장의 처리 결과;
등록을 요청하는 정확한 초안 또는 승인 텍스트;
저장소 URL, 불변 커밋, 태그, 콘텐츠 SHA-256;
저자, 검토자, 병합자, 승인 권한을 가진 주체의 별도 이름과 타임스탬프;
IANA 정책, 요청자, 요청 시각, 가져온 바이트, 검증 결과;
이전 및 새 레지스트리 행의 동일성, 효력 발생 시각, 대체 연결;
발행 시점 버전, 최신 승인 버전, 구현이 테스트된 버전;
호환성과 테스트 근거, 그리고 명시된 한계;
미러와 백업 위치, 최신 성공 동기화, 복구 훈련; 그리고
실제 구현 또는 운영자 채택에 대한 별도 기록.

영수증은 콜이 건설적이었다는 이유만으로 그것이 합의라고 선언해서는 안 됩니다. 이후의 공식 확인을 연결해야 합니다. 또한 IANA 거래를 실질적 판단으로 격상시켜서도 안 됩니다. 승인 주체가 후보가 현재 기록이 될 수 있는지를 결정하고, IANA는 합의된 정책 아래 요청되고 승인된 산출물을 확인하고 기록합니다. 레지스트리는 그때 증거를 담는 포인터이지, 미니 입법부가 아닙니다.

이것이 Lu Heng의Note 63에 담긴 유용한 교훈입니다. 이 노트는 VELOCE나 IANA에 대한 증거가 아닙니다. 설계의 관점을 제공합니다. 보관권, 기록, 출처 추적은 그 권한을 가져가지 않으면서 결정을 감사 가능하게 만들 수 있습니다. 단지 '최신'이라고 말하는 포인터는 기록과 판단을 뒤섞일 위험이 있습니다. 불변 동일성과 결정 이력을 함께 담는 포인터는 그 경계를 보존합니다.

같은 원칙이 적합성에도 적용됩니다. RFC 9907은 오늘날의 발행 기준선을 제공합니다. 규범적 YANG 문은 규범적 RFC 본문처럼 취급되고, 신규 또는 갱신 모듈은 IETF XML 및 YANG 모듈 이름 레지스트리를 통해 등록됩니다. VELOCE는 결국 다른 유지보수 체계를 정의할 수 있지만, 기준 시점에 그 BCP를 대체하지는 않았습니다. 따라서 구현자가 '최신 저장소 버전', '최신 IANA 행', 'RFC가 인용한 버전', '테스트로 인증된 버전'이 서로 바꿔 쓸 수 있는지 추측하게 두어서는 안 됩니다. 때로는 일치할 수 있습니다. 영수증은 일치하지 않을 때를 밝혀야 합니다.