요약

  • draft-ietf-netconf-yp-transport-capabilities-07은 오케스트레이터가 구현 시점 데이터 또는 실행 중인 서버에서 지원되는 YANG 알림 전송 방식, 인코딩, 보안 프로토콜을 발견할 수 있게 한다.
  • 이 기록은 기능 메뉴이다. 그 자체로 하나의 정확한 조합을 선택하거나, 로컬 정책에 따라 승인하거나, 수신자를 프로비저닝하거나, RFC 8639 구독을 수립하거나, 전달을 증명하지 않는다.
  • 구현 시점 주장과 런타임 주장은 출처와 최신성이 다르다. 자동화는 두 가지를 하나의 포괄적인 "지원됨" 플래그로 통합하지 않고 어느 쪽을 읽었는지 보존해야 한다.
  • 기능-구독 결정 영수증은 관찰된 기록, 선택된 조합, 정책 버전, 수신자, 요청, 결과 및 폴백을 결합해야 한다. 이는 IETF 요구 사항이 아니라 편집 제안이다.

한 행의 유혹적인 확실성

새 라우터에서 텔레메트리를 준비하는 컨트롤러를 상상해 보라. 디스커버리 응답에는 HTTPS 전송 항목이 들어 있다. 그 아래에는 XML과 JSON 인코딩, 그리고 TLS 1.2와 TLS 1.3 보안 식별자가 나열되어 있다. 컨트롤러는 제품 브로슈어에서 얻을 수 있는 것보다 훨씬 많은 것을 알게 된다. 나열하지 않은 장치에 UDP-notif를 제안하거나, XML과 JSON만 나열한 전송에서 CBOR을 제안하는 일을 피할 수 있다.

유혹은 하나의 녹색 배지를 저장하는 것이다.알림 가능.

그 배지는 통제 지점을 버린다. 컨트롤러는 어느 인코딩을 선택했는가? 정책은 어느 TLS 버전을 허용했는가? 정보는 제품 인스턴스 데이터 파일에서 얻은 것인가, 아니면 이 실행 중인 장치에서 얻은 것인가? 알림 수신자가 프로비저닝되고 도달 가능했는가? 인증된 주체에게 구독 생성 권한이 있었는가? 퍼블리셔가 요청을 수락했는가? 첫 알림이 도착했는가?

YANG Notification Transport Capabilities의 개정판 07은 2026년 8월 17일에 게시되었다. Datatracker는 9월 8일, 즉 8월 25일에 발표된 IETF Last Call에 따른 의견 마감일에 마지막으로 업데이트되었다. 9월 9일 연구 기준 시점에서 이 문서는 Proposed Standard를 목표로 하는 활성 Internet-Draft로서 IESG에 제출된 상태이며, 담당 에어리어 디렉터의 진행을 기다리고 있다. 이는 RFC나 최종 승인이 아니라 살아 있는 프로세스 상태이다.

이 초안은 디스커버리를 구조화한 점에서 공을 받을 만하다. 거버넌스 문제는 디스커버리가 성공한 뒤에 시작된다.

"지원됨"에는 두 개의 시계가 있다

이 설계는 RFC 9196의 시스템 기능 프레임워크를 확장한다. 해당 RFC는 의도적으로 기능 정보를 게시하는 두 가지 방식을 지원한다. 구현자는 장치가 가동되기 전에 YANG 인스턴스 데이터를 제공할 수 있고, 실행 중인 서버는 NETCONF 또는 RESTCONF를 통해 기능 데이터를 노출할 수 있다.

이 두 출처는 서로 교환 가능한 복사본이 아니다. 구현 시점 정보는 NMS 설계자가 제품군을 통합하는 데 도움을 주고 운영자가 구매 또는 배포 전에 시스템을 평가하는 데 도움을 준다. 런타임 정보는 실행 중인 서버를 설명하며 라이선싱 또는 하드웨어 제약을 반영할 수 있다. RFC 9196은 런타임 읽기를 이전 정보가 퍼블리셔가 실제로 구현한 것인지 확인하는 방법으로 명시적으로 식별한다. 또한 기능이 런타임에 변경되는 시스템은 기능 컨테이너에 대한 on-change 알림을 지원해야 한다고 명시한다.

따라서 조달 카탈로그는 특정 섀시에 대해 최신이 아니면서도 참일 수 있다. 런타임 읽기는 관찰 시점에는 최신이지만 실행 시점에는 오래되었을 수 있다. 라이선스는 바뀔 수 있고, 라인 카드는 사라질 수 있고, 소프트웨어 이미지는 교체될 수 있다. 두 출처를 동일한 부울로 평탄화하면 프레임워크가 보존하도록 설계된 구분이 지워진다.

자동화 기록은 출처, 모듈 개정판, 장치 및 소프트웨어 빌드, 검색 방법, 관찰 시간, 최신성 규칙을 명시해야 한다. 이러한 좌표 없는 "지원됨"은 거짓이 아니다. 기계가 그에 따라 행동할 때 비용이 커지는 방식으로 불완전할 뿐이다.

모델은 행위 앞에서 멈춘다

이 초안은 구독 기능을transport-capabilities컨테이너로 확장한다. 각transport-capability항목은 전송 프로토콜을 키로 하며 보안 프로토콜과 인코딩 형식 목록을 포함한다. 예제에서는 HTTPS를 XML과 JSON, 그리고 TLS 1.2와 1.3과 함께 묶는다. 두 번째 항목은 UDP-notif를 JSON과 CBOR, 그리고 DTLS 1.2와 1.3과 함께 묶는다.

이것은 디스커버리에 딱 맞는 규모이다. 클라이언트에게 실행 가능한 선택이 존재할 수 있는 위치를 알려준다. 선택의 기록은 아니다.

동시에 결함을 발명하지 않아야 한다. 별도의 leaf-list 자체는 서버가 모든 데카르트 조합을 거짓으로 광고한다는 증거가 아니다. 안전한 운영 주장은 더 좁다: 집합 멤버십은 컨트롤러가 사용하려는 정확한 조합에 대한 충분한 증거가 아니다. 컨트롤러는 여러 독립 배지에서 성공적인 조합을 추론하기보다 그 조합을 선택하고 시도하고 기록해야 한다.

이 구분은 RFC 8639에 의해 강화된다. 동적 구독은 구독자가 요청을 보냈다고 해서 존재하는 것이 아니다. 퍼블리셔가establish-subscription을 수락할 때에만 비로소 생성된다. 퍼블리셔는 여러 이유로 요청을 거부할 수 있으며 성공 가능성이 더 높은 매개변수에 대한 구조화된 힌트를 반환할 수 있다. 기능 디스커버리는 맹목적인 협상을 줄여준다; 그 상태 전환을 대체하지는 못한다.

수락조차 마지막 증명이 아니다. 수락은 퍼블리셔의 상태 머신에서의 생성을 확인할 뿐이다. 수신자 엔드포인트가 도달 가능하게 유지되었는지, 알림이 계속 도착했는지는 보여주지 않는다. 운영 관점에는 최소 다섯 가지 상태가 필요하다: 발견됨, 선택됨, 정책 승인됨, 수락됨, 전달 중.

프로비저닝된 관리 경로는 가정이지 결과가 아니다

이 초안은 배포 가정을 명확히 밝힌다. 오케스트레이터와 장치 사이에 관리 네트워크가 존재하고, 관리 연결과 장치의 관리 엔드포인트가 프로비저닝되어 있다. 이로써 오케스트레이터는 메뉴를 검색할 수 있다.

그러나 알림이 전송될 목적지를 프로비저닝하지는 않는다. 또한 하나의 인증된 관리 주체가 하나의 수신자에 대해 구독을 생성할 수 있는지 여부도 결정하지 않는다. 인증은 관리 인터페이스에 있는 사람이 누구인지 답한다. 인가와 로컬 정책은 그 주체가 어떤 보안 프로필과 목적지를 사용해 무엇을 일으킬 수 있는지 답한다.

자동화가 조직의 경계를 넘을 때 이것이 가장 중요하다. 중앙 컨트롤러가 장치를 읽을 수 있고, 보안 팀이 허용되는 프로토콜 프로필을 소유할 수 있으며, 텔레메트리 플랫폼이 수신자를 소유하고, 네트워크 팀이 도달 가능성을 소유할 수 있다. 단 하나의 녹색 디스커버리 응답은 이 기관 중 어느 곳에도 독점적으로 속하지 않는다. 인계 지점이 보이지 않으면 각 팀은 다른 팀이 결정적인 단계를 승인했다고 가정할 수 있다.

이 초안은 새 데이터 노드가 읽기 전용이며 보안에 민감하지 않다고 명시한다. 보안되고 상호 인증된 NETCONF 또는 RESTCONF 접근을 기대하며 액세스 제어는 NACM을 가리킨다. 메뉴의 기밀성을 과장할 필요는 없다. 거버넌스 리스크는 다르다: 비밀이 아닌 사실도 무단 지시로 사용될 수 있다. "TLS 1.2 지원됨"을 읽는 것은 규제 대상 수신자에 대해 이를 승인하는 행위와 같은 행위가 아니다.

검증과 구현은 필요하지만 경계가 있는 증거이다

Datatracker는 9월 8일 YANG 검증에 대해 오류 0건, 경고 0건을 보고했다. 또한 현재 보안 검토는 준비 완료, 전송 검토는 거의 준비 완료, IANA 조치 필요, 전문가 검토 완료로 기록했다. 이는 유용하고 구체적인 프로세스 사실이다. 어느 하나도 프로덕션 결과가 아니다.

개정판 07에는 구현 상태 섹션이 있으며, Huawei가 VRP의 YANG-Push 퍼블리셔용으로, Cisco가 IOS XR용으로 이 문서를 구현했다고 밝힌다. 같은 섹션은 게시 전에 해당 섹션을 제거하라고 RFC 편집자에게 지시한다. 이 진술은 모델이 어딘가에서 실행 코드에 도달했음을 보여줄 뿐이다. 공개된 개정판별 상호 운용성 매트릭스, 배포 점유율, 테스트된 조합 목록, 전달 성공률을 제공하지 않는다.

실행 코드 우선주의는 이름 이상을 요구한다. 이 메커니즘에 대한 설득력 있는 증거는 두 구현이 기능 출처를 내보내고, 컨트롤러가 동일한 정확한 조합을 선택하며, 정책이 이를 수락하고,establish-subscription이 기록된 이유와 함께 성공 또는 실패하며, 알림이 명명된 수신자에 도달하는 모습을 보여줄 것이다. 폴백이 조용히 약해지는 방식이 아니라 명시적이라면 실패 증거도 가치가 있다.

이 초안의dtls12식별자는 그러한 조용한 약화에 대한 유용한 경고를 제공한다: 그 설명은 DTLS 1.2를 폐기 상태로 규정하고 활성화를 권장하지 않는다고 말한다. 그 진술은 지역적이고 정확하다. 예제가 나열하는 TLS 1.2를 금지하지 않으며, 기존의 모든 DTLS 1.2 사용이 미명시된 규칙을 위반한다는 것을 증명하지도 않는다. 정책은 "1.2" 키워드 검색이 아니라 실제 식별자와 적용 가능한 표준을 소비해야 한다.

메뉴를 결정과 결합하라

빠져 있는 제도적 대상은기능-구독 결정 영수증이다. YANG 모듈을 변경하거나 제한된 경로를 통해 전송될 필요가 없다. 자동화가 관찰에서 행동으로 넘어갈 때 운영자 측에서 생성되는 기록이면 충분하다.

영수증은 장치, 제품군, 모듈 개정판, 소프트웨어 빌드를 식별한다. 출처가 구현 시점 파일인지 라이브 NETCONF/RESTCONF 읽기인지, 어디서 왔는지, 언제 관찰되었는지, 정책이 언제 오래된 것으로 간주하는지 명시한다. 정확히 광고된 전송 항목과 선택된 전송, 인코딩, 보안 조합을 보존한다.

그다음 행동 주체, 수신자 식별자와 엔드포인트, 로컬 정책 버전, 구독 매개변수, 시도 시간을 기록한다. 결과는 단순한 통과/실패가 아니다: 수락됨, 거부됨, 시간 초과, 이후 종료됨, 수락됐으나 첫 전달 없음은 서로 다른 결과이다. 구조화된 오류 힌트, 폴백, 강등을 승인한 권한이 함께 남는다.

그러한 영수증은 프로토콜 의미를 전혀 바꾸지 않는다. 개별적으로 참인 일련의 주장이 하나의 거짓 결론이 되는 것을 막는다. "제품 문서가 나열했다." "라이브 서버가 반환했다." "정책이 허용했다." "퍼블리셔가 수락했다." "수신자가 데이터를 얻었다." 각각은 각자의 시계에서 증명될 수 있다.

The Policy Mirror는 결정적 가치가 실제로 어디에 기록되는지 묻는다. 여기서 지원은 기능 트리에 기록되고; 권한은 NACM과 조직 정책에 있을 수 있으며; 존재는 구독 상태 머신이 기록하고; 유용성은 수신자에서만 나타난다.Running-Code Primacy는 이들의 실행 증거가 만나기를 요구한다.Reality, Not Advocacy는 결론을 비례하게 유지한다: 이 초안은 배포를 약속했다는 고발을 받지 않는다. 자동화에게 더 나은 메뉴를 준다. 운영자는 자신들이 주문한 것에 대한 영수증을 보관해야 한다.

출처