요약

  • RFC 9907은 2026년 3월에 발표된 Best Current Practice 216으로, RFC 8407을 폐기하고 RFC 8126을 갱신합니다. IANA 관리 모듈을 포함하여 YANG 데이터 모델을 담은 사양의 저자와 검토자를 위한 지침을 제공합니다.
  • 그 메커니즘은 편집적이면서도 운영적입니다. 코드 구성 요소 구분자, 고유한 이름, 완전한 헤더, 리비전과 RFC의 추적 가능성, 명시적 데이터스토어 의미론, 유용한 예제, 보안 분석, 레지스트리 절차는 사양을 일관되게 해석하기 쉽게 만듭니다.
  • 이는 와이어 프로토콜 변경이 아니며 상호 운용 가능한 구현을 보장하지도 않습니다. NETCONF와 RESTCONF의 상호 운용성과 사용성을 높이기 위한 프로세스 규율입니다.

YANG 데이터 모델은 관리 정보와 그 관계에 대한 개념적 기술입니다. 개별 모듈은 그 모델을 YANG으로 구현한 하나의 사례이며, 두 용어를 서로 바꿔 쓰듯 다뤄서는 안 됩니다. 검토자가 추출된 코드, 임포트, 리비전, 예제, 그 주변 산문을 살펴볼 때 이 구분이 중요합니다.

RFC 9907은 규범적 YANG 모듈과 서브모듈을 코드 구성 요소로 취급합니다. 이들은CODE BEGINS와CODE ENDS태그로 둘러싸여야 합니다. 공개되는 모듈 이름은 고유해야 합니다. 규범적 IETF 모듈은ietf-로 시작하고, 예제는example-을 사용해야 합니다. 이는 작은 통제 장치지만 검토상 이익은 큽니다. 권위 있는 구성 요소를 식별하고 규범적 자료와 예시 자료 사이의 우발적 충돌을 줄여줍니다.

모듈 헤더는 사양의 일부이지 장식이 아닙니다. 현재 IETF Trust 저작권 문구를 담고 YANG Parameters 레지스트리를 식별해야 합니다. 임포트된 모듈 외부의 참고 문헌은reference문에 들어갑니다. 공개된 각 리비전에는 그 모듈을 담은 문서를 식별하는 reference가 포함된 리비전 문이 필요합니다. 이 추적 가능성은 생성되거나 추출된 모듈을 고아가 된 스니펫이 아니라 감사 가능한 산출물로 만듭니다.

검토는 구문을 넘어 의미론까지 따라가야 합니다. YANG 1.1은 언어 규칙을 제공하고, Network Management Datastore Architecture는 NMDA 용어와 운영 상태(operational state) 맥락을 제공합니다. 저자는 무엇이 어느 데이터스토어에 속하는지, 구성(config)과 상태가 어떻게 관련되는지, 어떤 노드가 어떤 수명 주기적 또는 운영적 의미를 갖는지 명시해야 합니다. 깨끗한 파싱으로는 생략된 권한 경계를 해결할 수 없습니다.

예제는 검토 보조 자료이지 규범적 모듈이 아닙니다. 구현 요구 사항으로 제시되지 않으면서 의도된 구조를 명확히 해야 합니다. 문서는 또한 보안 결과, 특히 모델링된 데이터와 액션이 만드는 관리 노출을 설명해야 합니다. 마지막으로, IANA 관리 모듈에는 명시적인 레지스트리 절차가 필요합니다. 정책 권위는 레지스트리 프로세스에 있으며, 생성된 모듈 텍스트에 대한 임시 편집은 그 절차의 대체가 될 수 없습니다.

공개 전 검토 체크리스트

  1. 모든 규범적 모듈과 서브모듈이CODE BEGINS와CODE ENDS로 경계 지어져 있는가?
  2. 공개된 이름이 고유하며,ietf-가 규범적 IETF 모듈에 예약되고example-이 예제에 사용되는가?
  3. 각 모듈 헤더에 현재 Trust 문구가 있고 YANG Parameters 레지스트리를 식별하는가?
  4. 임포트된 모듈 외부의 참고 문헌이reference문에 있는가?
  5. 모든 리비전이 해당 RFC 또는 기타 담당 문서를 식별하는가?
  6. 산문이 데이터 모델과 그것을 구현하는 각 모듈을 구분하는가?
  7. NMDA 데이터스토어, 구성, 운영 상태, 수명 주기, 권한이 명시적인가?
  8. 예제가 명확히 비규범적이며 보안 영향이 분석되어 있는가?
  9. IANA 관리 모듈의 경우, 레지스트리 절차가 생성된 텍스트에 대한 편집이 아니라 명시적이고 권위 있는가?
  10. 검토자가 추출된 각 코드 구성 요소를 그것을 담은 문서로 역추적할 수 있는가?

운영자 수용 판단 경로

검토 기록이 열 개의 질문에 모두 답할 때만 모델을 수용하십시오. 구분자, 이름, 헤더, 리비전 참조, 의미론적 경계, 예제 라벨, 보안 분석 또는 레지스트리 절차 중 하나라도 없으면 사양 수정을 위해 반려하십시오. 답변이 완전하다면, 문서를 모든 구현이 상호 운용될 것이라는 약속이 아니라 검토 준비가 된 근거로 수용하십시오. NMDA 또는 레지스트리 권위에 관해 해결되지 않은 질문은 공개 전에 상급으로 올리십시오. 모호성은 소비자가 그것을 둘러싸고 운영상의 가정을 만들고 나면 되돌리기가 훨씬 어려워집니다.

출처