RFC 1303: 모듈 지원은 승인이 아니었다

요약

RFC 1303은 SNMP 에이전트 구현자가 지원하는 MIB 그룹과 그 변형을 서술할 수 있는 방법을 제공하여, 관리 스테이션이 추측 대신 호환 가능한 상호작용 방식을 선택할 수 있게 했습니다.
자동화가 흔히 잃어버리는 경계선을 그어 두었습니다. 객체의 읽기·쓰기 접근은 프로토콜상 타당성을 말하며, 행정적 승인은 별개의 정책 문제입니다.
sysObjectID일치, 모듈 지원 주장, 그리고 허용된Set형태가 있다는 사실만으로는 현재 지원이 완전하다는 것, 어떤 주체가 행동할 권한이 있다는 것, 쓰기가 수용되었다는 것, 네트워크 상태가 바뀌었다는 것을 증명하지 못합니다.

분석

서술은 운영 보조 도구였지 명령 채널이 아니었다

RFC 1303은 1992년 2월에 정보성(Informational) 문서로 나왔으며, 모든 SNMP 에이전트가 하나의 보편적 진실을 드러낼 것이라는 선언이 아니었습니다. 실용적인 관심사는 더 단순했습니다. 관리 스테이션은 에이전트와의 대화를 최적화하기 시작하기 전에 그 에이전트가 무엇을 유의미하게 논할 수 있는지 알아야 합니다. MIB에는 객체 타입이 들어 있습니다. 에이전트는 일부 그룹을 구현하고, 다른 그룹은 생략하며, 또 다른 그룹은 제한된 형태로 제공할 수 있습니다. 모든 공개된 MIB를 완전히 동일한 것으로 취급하면 스테이션은 기껏해야 서툴고, 나쁘게는 오해를 낳게 됩니다.

RFC의 답은MODULE-CONFORMANCE였습니다. 구현자는 지원 그룹과 명시적 변형에 대한 서술을 에이전트의sysObjectID에 연결할 수 있었습니다. 스테이션은 그 식별자를 조회하고, 서술 데이터베이스를 참조하여, 호환되는 읽기·쓰기 방식을 선택할 수 있었습니다. 이는 가치 있는 분업이었습니다. 장치는 경계가 분명한 능력 표면을 서술하고, 스테이션은 그 서술을 이용해 잘못된 프로토콜 행위를 피합니다.

그러나 이러한 분업이 그 서술을 명령으로 만들지는 않습니다.sysObjectID는 서술의 식별자이지, 주체의 위임이 아닙니다. 모듈 지원 주장은 특정 작업에 대한 서명된 승인이 아닙니다. 관리 인터페이스는 행동 표면에 가까울 수 있기 때문에 이 점은 특히 중요합니다. 스테이션이 쓰기 가능한 필드를 보는 순간, 다음 패킷을 정당화된 변경으로 이야기하고 싶은 유혹이 생깁니다. RFC 1303은 그런 결론을 제공하지 않습니다.

혼합되어서는 안 되는 네 가지 레이블

이 문서는 신중한 목록으로 시작합니다. 관리 객체에는 이름, 문법, 접근 수준, 구현 상태가 있습니다. 각각은 서로 다른 질문에 답합니다. 이름과 인스턴스는 무엇을 논하는지 식별합니다. 문법은 어떤 추상 값이 대화에 속하는지 말합니다. 구현 상태는 필수, 선택, 폐기, 사용 권장 폐기(deprecated) 객체를 구분합니다. 접근은 인스턴스를 읽거나 쓰는 것이 프로토콜상 의미가 있는지를 말합니다.

마지막 표현은 RFC가 즉시 그 한계를 밝히기 때문에 특히 유용합니다. 접근 수준은 행정적 승인 정책과 독립적입니다. 따라서 관리자는 로컬 규칙상 권한이 없더라도 프로토콜적으로 유효한 요청을 만들 수 있습니다. 반대로 조직은 원칙적으로 변경을 승인하면서도, 그 변경을 표현하는 데 필요한 지원 객체, 값 형태, 생성 경로가 에이전트에 없을 수 있습니다. 프로토콜 문법과 의사결정 규칙은 만나야 하며, 어느 쪽도 다른 쪽을 대신하지 않습니다.

이 구분은 읽기 증거가 쓰기 권한으로 이어지는 것도 막습니다. RFC는 읽기 위한SYNTAX정제와 쓰기 위한 별도의WRITE-SYNTAX정제를 허용합니다. 예제는 이 비대칭을 구체적으로 보여 줍니다. 일부 객체는 사용할 수 없고, 하나는 읽기만 가능하며, 특정 경로 관련 객체는 쓸 때보다 읽을 때 더 좁은 값 집합을 허용합니다. 보이는 값이 곧 수용 가능한 새 값은 아닙니다. 수용 가능한 값이 곧 승인된 지시는 아닙니다. 승인된 지시가 곧 관찰된 효과도 아닙니다.

능력 지도는 거짓 없이 불완전할 수 있다

sysObjectID결합은 안정적인 출발점을 제공하지만, RFC 1303은 그것을 전지적이라고 만들지 않습니다. 에이전트는 일부 지원을 동적으로 학습할 수 있습니다(예: 피어 메커니즘을 통해). 그런 경우 추가 MIB 객체가 능력 서술을 보강해야 합니다. 식별자는 여전히 유용하지만, 살아 있는 표면 전체를 다 담지는 못합니다.

이것은 기술적 한정 사항이면서 더 넓은 규율을 담고 있습니다. 목록은 명시된 범위에서 본 시스템의 한 시점입니다. 독자는 이를 통해 경계가 분명한 추론을 할 수 있습니다. 이러한 그룹과 변형이 여기에서 주장된다. 목록이 조용히 완전성 증명으로 변해서는 안 됩니다. 즉 다른 관련 능력, 조건, 제약이 존재하지 않는다는 증명이 되어서는 안 됩니다. 목록을 완전하다고 취급하는 스테이션은 잘못된 요청을 내보낼 수 있고, 목록을 권위로 취급하는 검토자는 잘못된 변경을 승인할 수 있습니다.

RFC 1303은 완전 지원과 부분 지원을 더 분리합니다.SUPPORTS는 에이전트가 구현을 주장하는 모듈을 명명하고,INCLUDES는 그 주장에 포함된 그룹을 명명합니다.VARIATION은 정제된 문법, 접근 규칙, 생성 요구 사항 등의 차이를 기록할 수 있습니다. 이 절들은 모호성의 변명이 아닙니다. 차이를 검사 가능하게 만들어 줍니다. 그러나 검사는 실행이 아닙니다. 매크로는 구현 시점에 개념적으로 확장되며 런타임에 확장되지 않고, 문서의 보안 고려 사항은 실제 운영자 요청에 대한 정책을 해결해 주지 않습니다.

생성에는 입력이 필요하다; 그리고 여전히 의사결정이 필요하다

CREATION-REQUIRES절은 특히 날카로운 경계입니다. 이 절은 에이전트가 개념적 행(conceptual row) 안에 인스턴스를 생성하기 전에 SNMPSet이 공급해야 하는 값들을 명명합니다. 예제에서는 특정 주소 또는 경로 행의 생성에 다른 필드도 필요합니다. 이 규칙에 따르면 부분 요청은 이 인터페이스를 통해서는 행을 생성할 수 없습니다. 절이 없으면 에이전트는 SNMP 작업을 통한 그런 인스턴스 생성을 지원하지 않습니다.

이것은 사소한 스키마 규칙처럼 보이지만, 흔한 운영상 허구를 막아 줍니다. 필요한 모든 칸이 채워진 양식이 곧 승인된 변경은 아닙니다. 필수 속성은 프로토콜이 완전한 후보를 표현할 수 있음을 확립할 뿐입니다. 네트워크의 소유자를 식별하지 않고, 주변 정책을 검사하지 않고, 작업 일정을 잡지 않고, 하류 반응을 확인하지 않으며, 롤백 기록을 보존하지도 않습니다. 생성 전제 조건은 메시지 완전성에 대한 증거이지 기관적 권한의 증명서가 아닙니다.

따라서 역사적 교훈은 관리 서술이 약하다는 것이 아닙니다. 경계가 읽기 쉽게 유지될 때 비로소 유용합니다. 스테이션은 주장된 모듈, 허용된 프로토콜 형태, 선언된 변형을 알아야 합니다. 그 다음에는 결과에 대한 책임을 지는 당사자로부터 승인을 받아, 경계가 분명한 작업을 수행하고, 그 결과를 별도의 증거를 통해 관찰해야 합니다.