요약

  • IETF 프라이빗 컨피그 후보 초안 개정판 10은 각 NETCONF 세션에 별도의 준비 공간을 부여합니다. 커밋은 항상revert-on-conflict모드의 암묵적 업데이트를 먼저 수행합니다. 충돌이 하나라도 있으면 작업이 중단되고, 조용히 승자를 지정하지 않습니다.
  • 그러나 명시적 결정은 여전히 파괴적입니다.prefer-candidate는 프라이빗 값을 유지하며 이 값이 나중에 현재 값을 덮어쓸 수 있습니다.prefer-running은 충돌하는 프라이빗 변경을 지웁니다. NACM 권한, 인증, 모드 공지는 어느 쪽이 해당 서비스에 정당했는지 설명하지 않습니다.
  • 따라서커밋 권한장(commit warrant)이 필요합니다: 브랜치 기반, 충돌 목록, 채택된 모드, 손실되는 값, 책임자, 허용 범위, 통제, 컨펌 커밋 조건과 롤백 대상. 이는 Daniel Kade의 제안이며 IETF의 요구 사항이 아닙니다.

프라이빗 브랜치는 한 문을 닫고 다른 문을 연다

RFC 6241의 공유 컨피그 후보는 완전한 구성을 만든 뒤 활성화할 수 있게 합니다. 이 편의에는 잘 알려진 위험이 따릅니다: 여러 세션이 같은 공간을 수정할 수 있습니다. 클라이언트가 자신의 변경을 검증하면서 다른 클라이언트가 남긴 변경을 함께 확정해버릴 수 있습니다. 잠금은 일부 사고를 막지만, 신중함을 대기열로 바꾸는 일이 빠릅니다. RFC 5717의 부분 잠금조차 커밋이 단일 클라이언트의 작업만 담는다는 것을 보장하지 않으며, 모델의 모든 의존성을 이해해야 한다고 가정합니다.

draft-ietf-netconf-privcand-10초안은 명확한 답을 제안합니다. 2026년 8월 24일에 발행되어 NETCONF 작업반의 최후 공개 검토(last call)에 들어가고 Proposed Standard 경로를 목표로 하지만, 여전히 활성 Internet-Draft이며 RFC가 아닙니다. 이 초안의 컨피그 후보는 세션 전용입니다. 관련 첫 호출 시 현재 구성의 사본으로 시작하며, 다른 NETCONF 구성 세션의 범위 밖에서 변경 사항을 유지합니다. 세션이 사라지면 컨피그 후보와 검증되지 않은 변경도 함께 사라집니다.

이 메커니즘은 브랜치 작성자가 타인의 작업을 실수로 커밋하는 일을 방지합니다. 또한 전체 datastore를 정지시키지 않고 병렬 준비를 가능하게 합니다. 상당한 진보입니다. 그러나 또 하나의 약속을 요구해서는 안 됩니다: 그 사이에 프로덕션이 변했을 때, 어느 구성안이 가장 좋은 권위를 갖는지 판단하는 일 말입니다.

프라이빗 브랜치는 "누가 이 변경을 준비했는가?"라는 질문에 답합니다. "어느 것이 우선해야 하는가?"라는 질문은 그 브랜치가 생성 시점의 세계와 더 이상 같지 않은 세계에 접촉할 때 시작됩니다.

충돌은 값만큼 출발점에 관한 문제다

update작업은 컨피그 후보의 오래된 기반을 현재 구성으로 교체한 뒤 클라이언트의 변경을 다시 적용합니다. 전체는 원자적입니다. 이 성질 덕분에 조정이 부분적으로만 성공한 중간 상태가 생기지 않습니다.

초안은 충돌을 클라이언트의 가능한 의도를 기준으로 정의합니다. 두 텍스트가 다르다는 것만으로는 충분하지 않습니다. 준비 구간 동안 현재 구성과 컨피그 후보가 같은 노드를 수정했고, 새로운 출발점이 있었다면 클라이언트가 다르게 행동했을 수 있는 상황이어야 합니다. 값, 존재 여부, 사용자가 정한 순서, presence 컨테이너, leaf-list, leaf, YANG 메타데이터가 대상이 될 수 있습니다. 서버는 특히 트랜잭션 식별자를 통해 추가 통제를 더할 수 있습니다.

대상 노드마다 내부적으로in conflict표시가 붙습니다. 초안은 표시 메커니즘을 자신의 범위 밖으로 둡니다. 자식의 표시가 자동으로 모든 조상으로 거슬러 올라가지는 않습니다. 충돌 위치는 클라이언트가 의도를 다시 검토할 수 있도록 XPath 경로와 값으로 전달되어야 합니다.

이 마지막 표현이 메커니즘의 제도적 한계를 드러냅니다. 서버는 트리와 작업을 알지만 긴급 티켓, 유지보수 창, 서비스 위계, 예외를 승인한 책임자는 모릅니다. 어떤 노드는 국부적으로 보이면서 더 넓은 의존성을 지배할 수 있습니다. 정당하게 인증된 두 주체가 시간적으로 양립할 수 없지만 각각 타당한 목표를 추구할 수 있습니다.

충돌을 감지하는 것은 불일치를 보존할 뿐입니다. 그것을 해결할 권리를 가르지 않습니다.

세 가지 모드, 세 가지 책임

revert-on-conflict는 필수 모드이자 기본 모드입니다. 충돌이 하나라도 남아 있으면 병합 없이 업데이트가 실패합니다. 모든 커밋은 다른 업데이트를 위해 시스템 기본값이 선택되어 있더라도 이 암묵적 업데이트를 먼저 수행합니다. 실패 후 클라이언트는 자신의 작업을 수정하거나 포기하거나, 해결 모드를 지정한 업데이트를 의식적으로 시작해야 합니다. 이 거절은 가치가 있습니다. 결정을 아직 검토할 수 있는 순간을 만들기 때문입니다.

prefer-candidate에서 충돌하는 프라이빗 값은 브랜치에 남고, 충돌하지 않는 현재 변경은 병합됩니다. 이어지는 커밋이 현재 구성의 해당 값을 덮어씁니다. 잃어버리는 것은 브랜치 생성 후 프로덕션에서 나타난 의도입니다.

prefer-running에서 현재 값이 충돌하는 프라이빗 변경을 대체합니다. 프라이빗 작업의 나머지는 남지만, 브랜치는 더 이상 작성자의 계획 전체를 표현하지 않습니다. 잃어버리는 것은 준비된 의도의 일부입니다.

위치나 시간 순서만으로는 선택할 수 없습니다. "candidate"가 "업무상 더 최신"을 뜻하지 않습니다. "running"이 "미래를 위해 승인됨"을 뜻하지도 않습니다. 현재 값은 임시 긴급 조치일 수 있고, 프라이빗 브랜치는 오래전 승인된 마이그레이션일 수 있습니다. 그 반대도 가능합니다. datastore의 말은 기술적 상태를 설명할 뿐, 정당성의 서열을 설명하지 않습니다.

서버는 running이 수정된 뒤의 자동 업데이트에 다른 모드를 사용할 수도 있습니다. 비표준 선택은 공지되어야 하며, 모든 모드가 사용 가능하지 않은 경우 모드의 목록도 공지되어야 합니다. 공지는 행동을 관찰 가능하게 만듭니다. 그러나 정책의 이유, 유효 기간, 손실을 감수하는 서비스는 알려주지 않습니다.

진짜 위험은 시간적으로 뒤로 옮겨집니다. 최종 커밋은 깔끔하고 성공적일 수 있지만, 파괴적 결정은 더 일찍 자동 업데이트에 의해 내려졌을 수 있습니다. 커밋만 기록하는 로그는 활성화를 올바른 클라이언트에게 돌리되, 결과를 만들어낸 규칙은 무주장으로 남겨둡니다.

NETCONF는 RESTCONF가 압축하는 역사를 간직한다

NETCONF에서 클라이언트와 서버는 세션 전체에 대해 능력을 협상합니다. 클라이언트가 이를 지원하지 않는 서버에 요청하면, 서버는 하위 호환성을 위해 요청을 무시하거나 세션을 닫을 수 있으며, 초안은 새 구현에 대해 세션 닫기를 권장합니다. 따라서 클라이언트의 선호는 세션이 실제로 프라이빗이라는 증거가 아닙니다.

RESTCONF에는 같은 클라이언트 측 공지가 없습니다. 서버가 private-candidate 능력을 공개하면, 데이터 리소스에 대한 모든 쓰기는 요청별 컨피그 후보를 거치며 자동으로 커밋됩니다. 이 방식은 확장을 모르는 클라이언트가 기대하는 즉시성 의미를 보존합니다. 그러나 NETCONF 세션처럼 여러 작업을 아우르는 장기 브랜치를 만들지는 않습니다.

이 차이가 통제 방식을 결정합니다. NETCONF는 생성, 업데이트, 비교, 커밋 사이에 시간을 남겨두며, 권한장은 이 기간 동안 만료될 수 있습니다. RESTCONF는 이 단계들을 하나의 요청 안에 압축합니다. 수정과 활성화 사이에 놓인 승인은 같은 방식으로 유지되지 않습니다. 조직은 어휘의 유추가 아니라 실제 경계를 다스려야 합니다.

실행할 권리는 우선순위를 정할 권한이 아니다

RFC 8341은 NACM이 사용자와 콘텐츠에 따라 읽기, 쓰기, 실행을 제한하도록 합니다. 초안은update를 민감한 작업으로 규정하고 무단 접근의 영향을 경고합니다. 상호 인증, 안전한 전송, 접근 정책은 필수입니다.

그러나 이들은 프로토콜상으로는 허가받았지만 그 시점의 권한 범위를 벗어난 주체의 경우를 해결하지 못합니다. 자동화 계정은 인터페이스 하위 트리를 쓸 수 있으면서도 인시던트 팀의 조치를 취소할 권한은 없을 수 있습니다. 관리자는 실행 권한을 가지면서 자신의 브랜치가 공유 서비스에 닿는다는 사실을 모를 수 있습니다. 영속적 권한은 "이 작업을 호출할 수 있는가?"에 답하고, 변경 권한은 "지금, 이 다른 의도에 맞서, 이 값을 강제할 수 있는가?"에 답합니다.

RFC 9144의 확장 비교는 한 조각의 증거를 제공합니다. 서버가 새 참조점을 지원하면 클라이언트는 컨피그 후보를 running, 자신의 생성 시점, 마지막update와 비교할 수 있습니다. 격차와 맥락의 변화가 더 잘 보입니다. 그러나 diff는 노드의 업무상 중요성, 의존성의 완전성, 권한의 유효성을 평가하지 않습니다.

커밋 권한장 만들기

결여된 통제는 프로토콜 밖에 둘 수 있습니다. 여기서 제안하는커밋 권한장은 단일 충돌 조정에 묶인 짧은 문서로, 만료를 전제로 합니다.

장치, datastore, 세션 또는 요청, 인증된 주체, 자동화 소유자를 식별합니다. 생성 시점, 마지막 업데이트 시점, 안정적인 running 참조를 기록합니다. 정확한 델타와 보고된 모든 충돌을 첨부하며, 로컬 정책이 노드별 표시가 드러내지 않는 부모나 서비스를 알 때는 이를 보강합니다.

공지된 기본값, 사용 가능한 모드, 작업이 자동인지 명시적인지, 적용된 모드를 기록합니다. 그다음 손실을 명명합니다:prefer-candidate에서 덮어써질 running 값,prefer-running에서 삭제되는 프라이빗 변경, 또는revert-on-conflict에서 여전히 열려 있는 충돌입니다.

NACM 정책 버전도 문서에 들어가며, 승인의 대체물이 되지 않습니다. 사람 또는 자동화된 책임자가 이유, 범위, 창, 영향 한도, 만료를 지정합니다. 비교 결과, 구성 검증, 서비스를 대표하는 통제가 결정을 뒷받침합니다.

마지막으로 권한장은 컨펌 커밋, 그 지연 시간, 존재하는 경우 영속 식별자, 기대되는 건강 신호, 정확한 복귀 대상을 명시합니다. 종결 시 결과와 새 현재 구성의 지문을 보존합니다. 어떤 전제가 바뀌면—running이 더 최신이 되고, 정책이 바뀌고, 관찰자가 사라지고, 창이 만료되면—권한장은 무효가 됩니다.

이 등록부는 NETCONF 작업도 아니고 IETF의 의무도 아닙니다. 프로토콜이 운반하지 않으려는 부분—타당한 한 의도를 다른 의도보다 우선시한 이유—을 보존하기 위한 Daniel Kade의 제안입니다.

돌아올 수 있다고 해서 첫 결정이 정당해지지는 않는다

컨펌 커밋은 여전히 훌륭한 방어입니다. 프라이빗 컨피그 후보를 사용하는 컨펌 커밋 동안 클라이언트 세션이 끊기면, 초안은 running의 즉시 복구와 제안된 변경의 폐기를 규정합니다. 복귀 능력은 연결성 장애나 통제 상실을 한계 지습니다.

그러나 그것은 초기 선택을 소급하여 정당화하지 않습니다. 결정은 되돌릴 수 있으면서도 권한 밖에서 내려질 수 있습니다. 반대로 정당한 긴급 개입이 신뢰할 만한 롤백을 갖지 못할 수 있으며, 이 경우 롤백 부재는 실행을 중단해야 하고 가상의 다른 권위를 만들어서는 안 됩니다.

discard-changes조차 정확한 표현을 요구합니다. 컨피그 후보는 자신의 생성 시점 또는 마지막 업데이트 시점 중 더 최신 쪽으로 돌아갑니다. 이 시점은 현재 running과 일치하지 않을 수 있습니다. 폐기 후 "프로덕션으로 돌아갔다"고 말하면 새 격차를 가릴 수 있습니다.

격리는 작업의 출처를 보호합니다. 충돌은 불일치의 가시성을 보호합니다. 컨펌 커밋은 복귀 경로를 보호합니다. 결정에 붙은 권한장만이 세션이 사라진 뒤에도, 한 의도가 왜 정당하게 우선권을 얻었는지 설명할 수 있습니다.

출처