RFC 9890: YANG 리비전 신원 경계 이해하기

요약

RFC 9890은 YANG 모듈 및 서브모듈 이름에 관한 RFC 6020의 등록 문구를 갱신합니다.
최초 버전 이름과 XML 네임스페이스는 고유하게 유지되며, 이후 리비전은 최초 이름과 네임스페이스를 재사용합니다.
IANA의 YANG 모듈 이름 레지스트리 절차가 이러한 이름의 할당에 대해 권위 있으며, 레지스트리 신원은 리비전을 인식하는 배포 인벤토리가 아닙니다.

RFC 6020은 레지스트리 내 모든 모듈·서브모듈 이름과 모든 XML 네임스페이스가 고유해야 한다고 명시했습니다. RFC 9890은 이 문구가 리비전에 대한 IANA의 실무와 맞지 않았음을 설명합니다. 갱신된 규칙에서 고유성은 최초 버전에 적용됩니다. 최초 모듈 또는 서브모듈 이름은 고유하게 유지되고, 최초 모듈의 XML 네임스페이스도 고유하게 유지됩니다. 이후 모든 리비전은 최초 이름과 동일한 XML 네임스페이스를 그대로 사용합니다.

이 연속성은 의도된 것입니다. 소비자는 각 리비전을 새로 등록된 신원으로 취급하지 않고도 모듈 계열을 인식할 수 있습니다. 그러나 이 경계는 운영상 중요합니다. 이름이나 네임스페이스로 레지스트리를 조회하면 어떤 신원이 등록되었는지는 답할 수 있지만, 리비전 메타데이터와 해당 모듈 아티팩트 없이는 어떤 리비전이 설치되었고 검증되었으며 복원하기에 안전한지는 답할 수 없습니다. 연속된 리비전들이 의미적으로 호환된다는 것도 입증하지 못합니다.

IANA는 자신의 절차가 YANG 모듈 이름 레지스트리에서 이름을 할당하는 데 권위 있기 때문에 RFC 9890을 추가 참조로 등재합니다. 고정된 IANA 스냅샷은 2026-09-05에 관찰된 레지스트리 상태의 증거이며, 구현 품질, 운영자 채택, 도구 호환성, 특정 리비전의 정확성에 대한 증거가 아닙니다.

Theo March 분석 — RFC 9890의 요구 사항이 아님:안정적인 이름을 완전한 배포 키로 다루면 신원 모호성이 생깁니다. 자동화에서 이 모호성은 인벤토리 드리프트로 이어질 수 있습니다. 기록은 올바른 모듈 계열을 가리키지만 검증과 배포에는 서로 다른 리비전이 사용된 경우입니다. 실질적 통제는 안정적인 이름과 네임스페이스와 함께 리비전 식별자, 원본 아티팩트 또는 다이제스트, 검증 결과, 롤백 대상을 함께 보존하는 것입니다.

검증 픽스처

최소 픽스처에는 다음이 포함되어야 합니다. 모듈 이름example-module; XML 네임스페이스urn:example:module; 최초 리비전2024-01-01; 이후 리비전2025-06-01; 레지스트리 조회 결과; 검증에 사용한 정확한 아티팩트; 롤백용으로 보존한 아티팩트. 두 리비전이 동일한 이름과 네임스페이스를 유지하는지 확인한 뒤, 인벤토리 기록이 리비전 날짜 또는 동등한 리비전 메타데이터로 두 리비전을 구분하는지 검증합니다. 두 번째 픽스처는 의도적으로 리비전 메타데이터를 생략해야 합니다. 기대 결과는 통제 검사 실패이며, 아티팩트가 동등하다는 추론이 아닙니다. 이는 본 브리핑에서 제안된 운영 테스트이며, RFC 9890이 만든 요구 사항이 아닙니다.

운영자 의사 결정 경로

권위 있는 레지스트리 절차를 통해 등록된 이름과 네임스페이스를 확인합니다.
검증에 사용된 정확한 리비전 메타데이터와 모듈 아티팩트를 조회하고 기록합니다.
활성화 전에 배포된 리비전과 검증된 리비전을 비교합니다.
리비전별 롤백 대상과 그 보존 사실에 대한 증거를 저장합니다.
리비전 신원이 없으면 승격이나 롤백을 일시 중지합니다. 안정적인 레지스트리 신원에서 호환성을 추론하지 않습니다.

이 증거 집합은 전 리비전에 걸쳐 전역 고유 이름을 가정한 도구가 얼마나 많은지를 측정하지 않습니다. 운영자 인시던트, 상호운용성 실패, 마이그레이션 비용도 확립하지 않습니다. RFC 9890은 연속된 리비전 간 의미적 호환성을 검증하지 않습니다. 고정된 IANA 스냅샷은 관찰 이후 변경될 수 있습니다. 벤더 지원과 배포 보급률은 소스 집합의 범위 밖입니다.