요약

  • RFC 10016은 시스템이 공급하는 구성을 위한 읽기 전용<system>데이터스토어를 추가한다. 클라이언트는 이 데이터스토어를 직접 편집할 수 없지만, 그 노드를 참조하거나,<running>에서 허용되는 값을 재정의하거나, 시스템이 정의한 항목 아래에 구성 가능한 자식을 추가할 수 있다.
  • "Origin: system"은 값이 어디에서 왔는지를 말할 뿐이다. 이는 사람의 승인, 불변성 또는 성공적인 적용을 증명하지 않는다. 재정의를 제거하면 시스템 값이 다시 드러날 수 있고, 하드웨어·라이선스·소프트웨어 변경은 어떤 시스템 노드가 존재하는지를 바꿀 수 있다.

한 운영자가 장치를 "명시적 설정 없음" 상태로 되돌리기 위해 재정의(override)를 제거했다. 그 결과는 부재가 아니었다. 그 아래에 있던 시스템 제공 값이<intended>에 다시 나타났고, 이후 실제로 활성화되었다. 구성이 줄어든 것처럼 보이는 삭제가 오히려 더 많은 동작을 만들어낸 것이다.

이것은 프로토콜의 예외가 아니다.RFC 10016이 드러내도록 만든 우선순위 모델 그 자체다. 이 Standards Track 문서는 서버 자체가 공급하는 구성을 담는 기본(conventional) 데이터스토어인<system>을 추가하여 네트워크 관리 데이터스토어 아키텍처를 갱신한다. 이 데이터스토어는 NETCONF와 RESTCONF 클라이언트에게 읽기 전용이다. 그럼에도 그 내용은 유효 구성(effective configuration)에 참여할 수 있다.

거버넌스상의 실수는 "읽기 전용"을 "변하지 않음"으로, "시스템"을 "승인됨"으로 읽는 것이다. 읽기 전용은 접근 경계를 식별한다. 즉 클라이언트가<system>에 직접 쓸 수 없다는 뜻이다. 그러나 이는 소프트웨어 업그레이드, 라이선스 변경, 하드웨어 이벤트를 넘어 데이터를 고정하지 않는다. 허용되는 값이<running>에 의해 가려지는 것을 막지 않는다. 기반이 되는 값의 위험을 누가 수용했는지 확립하지 않는다. 그리고 그 값이<operational>에 도달했는지 여부도 보여주지 않는다.

이전까지 흐릿했던 출처를 위한 데이터스토어

RFC 8342는 이미 장치가 적용하려는 구성과 실제 사용 중인 구성 및 상태를 구분한다. 이는 기본(conventional), 동적(dynamic), 학습(learned), 시스템(system), 기본값(default) 출처를 인정한다. RFC 10016은 시스템 구성에 이름이 붙은 데이터스토어를 부여하고 그 의미를 정교화한다.<system>에 존재하는 구성은 현재 참조되거나 적용되고 있느냐에 관계없이 시스템 구성으로 간주된다.

이 계약 아래에서 시스템 구성은 클라이언트가 삭제할 수 없다. 클라이언트가 삭제할 수 있는 서버 제공 데이터는 이 문서의 정의 범위 밖이다. 준수하는 NMDA 서버는ietf-system-datastore아이덴티티를 구현하며, 그 스키마 관계는RFC 7950에서 정의된 YANG 위에 세워진다. 클라이언트는RFC 8525가 기술한 YANG 라이브러리 정보를 통해 지원 여부를 확인할 수 있다.

두 가지 중요한 수명 주기가 있다.항상 존재하는(always-present)시스템 구성은 특정 물리적 자원과 무관하게 장치가 켜질 때 생성된다. 루프백 인터페이스가 RFC의 예이다.조건부로 존재하는(conditionally present)구성은 조건이 충족될 때 나타난다. 카드가 삽입되거나, 자원이 존재하거나, 라이선스·기능이 활성화되는 경우다. 그 조건이 사라지면 시스템 노드도 사라질 수 있다.

<system>데이터스토어 자체는 재부팅을 넘어 유지되지 않는다. 서버는 현재 조건이 요구하는 것을 재구성한다. 따라서 "재부팅 전에 존재했다"와 "재부팅 후 같은 노드가 생성되었다"는 별개의 관찰이 필요하다.<running>의 백업은 다음<intended>트리를 만들 입력을 완전히 기록하지 않는다.

읽기 전용 출처, 쓰기 가능한 우선순위

클라이언트는 세 가지 방식으로 시스템 노드와 상호작용할 수 있다.<running>에 만드는 구성에서 시스템 노드를 참조할 수 있다. 서버가 재정의를 허용하는 경우, 일치하는<running>리프가<system>의 값보다 우선한다. 클라이언트는 시스템이 정의한 목록 항목 아래에 구성 가능한 자식을 추가하는 것도 허용받을 수 있으며, 항목 자체가 시스템에 기원을 두고 있어도 그렇다.

병합 규칙은 단순하지만 그 운영적 결과는 놓치기 쉽다. 두 입력이<intended>를 형성할 때<running>이 대응하는<system>노드를 이긴다. 어느 입력이든 변환(템플릿 확장이나 비활성 구성의 제거 등)이 필요하다면, 각 데이터스토어는 병합 전에 독립적으로 변환되어야 한다. 변환되지 않은 원본의 스크린샷은 최종 승자를 증명할 수 없다.

이제 삭제를 생각해보자. 시스템이 값 A를 공급한다. 운영자가<running>에 값 B를 쓰면 B가 이긴다. 이후 운영자가 B를 제거한다. 이 연산은 A를 삭제한 것이 아니다. 클라이언트는<system>에서 A를 삭제할 수 없다. A는<intended>에 다시 나타나고, 성공적인 적용 후 사용에 들어갈 수 있다. 이 제거를 "설정 초기화"라고 레이블하는 워크플로는 중요한 폴백 값을 감추게 된다.

역방향 전이도 똑같이 중요하다. 조건부로 존재하는 시스템 노드는 하드웨어가 제거되거나 라이선스가 변경되면 사라질 수 있다. 관련 구성은<running>과<intended>에 남아 있을 수 있지만, 참조된 자원이 없기 때문에<operational>에는 나타나지 않을 수 있다. 의도는 사라지지 않았지만 현실은 사라진 것이다.

출처(origin)는 출처일 뿐, 동의가 아니다

RFC 7952가 origin 주석에 사용되는 메타데이터 메커니즘을 제공한다. RFC 10016은<system>에서 흘러 들어오는 구성은<running>에서 명시적으로 구성되거나 재정의되지 않는 한 originsystem을 보고한다고 명확히 한다.<running>에 기원을 둔 구성은 NMDA 규칙에 따라 intended origin을 보고한다.

이 주석은 "이 노드를 어떤 출처가 공급했는가?"에 답한다. "이 유효 값을 누가 승인했는가?"에는 답하지 않는다. 제조사, 플랫폼 이미지, 장치 자원, 라이선스 하위 시스템 또는 로컬 시스템 프로세스가 노드를 공급할 수 있으며, 그때 이름이 있는 사람이 현재의 위험 결정을 내린 것은 아니다. 반대로 클라이언트의 재정의는 사람이 아니라 자동화된 컨트롤러의 결과일 수 있다.

출처를 승인으로 취급하면 두 가지 허위 주장이 생긴다. 첫째는 시스템이 공급했기 때문에 시스템 기원 값이 신뢰할 수 있다는 주장이다. 둘째는<running>에 나타나기 때문에 클라이언트 기원 재정의가 의도적인 것이라는 주장이다. 출처는 책임성에 필요하지만, 변경 권한, 정책 검토, 비즈니스 의도와 결합되어야 한다.

intended는 여전히 applied를 의미하지 않는다

<system>이 변경될 때마다 RFC 10016은 서버가<intended>를 즉시 갱신하고 검증하도록 요구한다. 또한 시스템 변경 후에도<running>이 유효한 구성 트리로 남아 있어야 한다고 말하면서, 그를 달성하는 메커니즘은 범위 밖으로 둔다. 이들은 데이터 처리에 관한 유용한 보장이지, 값이 하드웨어나 포워딩 동작에 도달했다는 증거가 아니다.

RFC 10016은 의도적으로<operational>을 변경하지 않는다. RFC 8342에 따르면, 누락된 자원, 전파 지연, 잔존 구성이 intended와 applied 상태를 분리해 둘 수 있다. 따라서 관련 체인은<system>과<running>이 독립적으로 변환되어<intended>로 병합되고, 이후 조건적으로<operational>에 적용되는 것이다. 모든 화살표마다 고유한 실패 모드가 있다.

알림은 체인을 닫지 않으면서 도움이 될 수 있다. 시스템 구성의 변경은RFC 8639와RFC 8641같은 YANG 구독과 datastore-update 메커니즘을 통해 보고될 수 있다. 알림은 퍼블리셔가 구독 범위 안에서 이벤트를 발행했음을 증명한다. 그 자체로 모든 소비자가 그것을 처리했거나, 정책을 재계산했거나, 결과 운영 트리를 검증했음을 증명하지는 않는다.

또한<system>을<factory-default>와 혼동해서는 안 된다.RFC 8808은 공장 기본 설정을 위한 데이터스토어와 공장 초기화 연산을 정의한다. RFC 10016의<system>은 현재 조건 아래에서 현재 시스템이 제공하는 것을 기술한다. 일부 값이 서로 닮더라도, 두 데이터스토어는 아키텍처에서 다른 역할을 수행한다.

출처·우선순위 영수증

출처·우선순위 영수증(origin-and-precedence receipt)은 유효 구성에 책임성을 부여할 수 있다. 모든 실질적 노드에 대해 시스템 경로, 값 지문, origin, 존재 조건을 기록한다. 조건은 관련된 하드웨어, 라이선스, 기능, 부팅, 소프트웨어 또는 자원 시점(epoch)을 명명하여 "시스템 값"이 시대를 초과한 것으로 취급되지 않게 한다.

다음 절은 변경 가능성과 우선순위를 기록한다. 시스템 노드가 불변인지 재정의 가능한지, 어떤<running>노드가 참조하거나 가리는지, 어떤 구성 가능한 자식이 추가되었는지, 각 출처에 어떤 변환이 실행되었는지,<intended>로의 병합에서 어느 값이 이겼는지. 그리고 변경이 승인되기 전에 재정의를 제거했을 때의 결과를 기록한다.

활성화 절은<intended>를<operational>과 비교한다. 적용 시각, 자원 존재 여부, 지연, 실패, 잔존 상태, 그 값이 유효하다고 말하는 데 사용된 정확한 증거를 기록한다. 참조는 유효하면서 그 대상은 비활성일 수 있다. 유효한 intended 트리가 현재 존재하지 않는 자원을 여전히 기술할 수 있다.

권한 절은 시스템 공급자, 구성 클라이언트, 운영 승인자, 위험 소유자를 명명한다. 소프트웨어 업그레이드, 라이선스 전환, 하드웨어 삽입 또는 정책 커밋 같은 원인 변경을, 그 결과인 유효 값을 수용한 결정과 연결한다. 민감한 세부사항은 보호된 채로 남을 수 있고, 영수증은 해시와 범위가 지정된 참조를 유지할 수 있다.

이 영수증은 Daniel Kade의 편집적 거버넌스 제안이며, RFC 10016이 부과하는 새로운 요구사항이 아니다. 그 목적은 보이는 출처, 이기는 값, 승인된 결정, 적용된 결과 사이의 차이를 보존하는 것이다.

보안은 읽기 접근에서 시작한다

읽기 전용이 무해하다는 뜻은 아니다. RFC 10016은<system>에 하드웨어 식별자, 보안 정책, 중요 자원이 포함될 수 있다고 경고한다. 민감한 노드와 하위 트리에 대한 접근은 통제되어야 하며, 구현은 이를 읽으려는 시도를 기록할 것을 강력히 권고받는다.RFC 8341은 NETCONF와 RESTCONF 사용자를 제약하기 위한 Network Configuration Access Control Model을 제공한다.

재정의 경로는 별개의 위험이다. 공격자나 실수한 클라이언트가 민감한 시스템 값을 가리는<running>리프를 쓸 수 있으며, 그러면<system>자체는 전혀 바뀌지 않았음에도 정책 우회나 가용성 실패가 만들어진다. 따라서<system>에 대한 쓰기만 모니터링하면, 클라이언트가 사용할 수 없는 유일한 경로를 감시하면서 실제로 우선순위를 바꾸는 경로를 놓치게 된다.

좁은 결론이 유용한 결론이다. RFC 10016은 시스템 구성을 검사 가능하게 만들고 NMDA 클라이언트에 그에 대해 추론할 표준 방법을 제공한다. 그러나 시스템의 선택을 운영자의 의도로 인증하지 않고, 그 선택을 영원히 고정하지 않으며, 적용을 증명하지 않는다. 가시성은 통제의 시작이다. 영수증은 그 값을 우선순위를 따라 그리고 운영까지 따라가야 한다.

출처