요약

  • RFC 1444는 객체 어휘, 최소 준수 계약, 제품 릴리스 기능 주장을 분리했다. 각각은 구현을 서술했을 뿐, 살아 있는 장치를 측정하지는 않았다.
  • 필수 그룹을 주장하려면 그 안의 모든 객체를 구현해야 했지만, 런타임에서는 여전히 관련 뷰에서 해당 객체, 정직한 값 또는 예외, 그리고 실제 제공되는 접근이 나타나야 했다.
  • 선언은 관리자의 동작을 최적화할 수 있었다. 그러나 값의 정확성, 쓰기의 효과, 재시작 이후의 지속성, 그리고 어떠한 보안 속성도 증명할 수 없었다.

하나의 단어 속에 숨어 있던 세 개의 문서

“지원(Support)”은 마치 하나의 사실처럼 들린다.RFC 1444는 이를 세 개의 기록으로 분해했다.

주체-GROUP은 관련된 관리 객체들을 모았다.MODULE-COMPLIANCE문은 에이전트가 준수를 주장할 수 있는 최소 구현을 서술했다.AGENT-CAPABILITIES문은 제품 릴리스가 주장하는 정확한 지원 범위와 변형을 서술했다.

이러한 구분은 하나의 넓은 MIB 이름이 너무 많은 일을 하도록 하는 것을 막았다. 한 모듈은 여러 그룹을 포함할 수 있었다. 어떤 그룹은 무조건 필수였고, 어떤 그룹은 특정 프로토콜이나 다른 그룹이 존재할 때에만 필수가 되었으며, 다른 그룹은 선택 사항이었다. 개별 객체는 정제된 읽기 구문, 쓰기 구문 또는 최소 접근을 가질 수 있었다. 제품은 모듈의 일부만 지원하면서 실제 출하된 변형을 서술할 수 있었다.

RFC 편집자 기록은 이 체계를 1993년 4월로 기록하며, RFC 1444를 나중에 RFC 1904가 대체한 제안 표준(Proposed Standard)으로 표시한다. 이는 “준수(conformant)”를 의례적인 것이 아니라 분해 가능한 것으로 만들려는 역사적 시도였다.

최소 범위는 맥박이 아니라 계약이었다

RFC 1444는 이러한 매크로의 전개가 런타임이 아니라 구현 과정에서 개념적으로 일어난다는 점을 반복해서 밝혔다. 그 문은 구현자에게 무엇을 만들어야 하는지 알려주고, 관리자에게 어떤 지원이 주장되는지 알려주었다. 선언을 읽을 때 살아 있는 프로세스를 질의하지는 않았다.

MANDATORY-GROUPS아래에 나열된 그룹에 대한 규칙은 엄격했다. 준수를 주장한다는 것은 해당 그룹의 모든 객체를 구현한다는 의미였다. 에이전트가 모든 MIB 뷰에서 하나의 필수 객체에 대해noSuchObject를 반환한다면, 그것은 해당 모듈의 준수 구현이 아니었다.GROUP절은 조건부 요구—예를 들어 특정 프로토콜을 구현한 시스템에서만 요구되는 그룹—를 표현할 수 있었고, 그 설명에는 조건이 명시되어야 했다.

이는 단순한 체크박스보다 더 유용하다. 조건, 최소 집합, 그리고 주장이 실패할 수 있는 객체를 식별해 주기 때문이다. 그러나 그것은 여전히 계약이다. 이 장치에서 조건이 참인지, 현재 보안 컨텍스트가 그 객체를 포함하는 뷰를 선택하는지, 프로세스가 응답할 만큼 건강한지는 별개의 관찰이다.

기능 식별자는 주장에 대한 색인이었다

AGENT-CAPABILITIES는 실용적인 문제를 다뤘다. 관리 소프트웨어는 특정 제품 릴리스가 대형 MIB의 어느 부분을 지원한다고 주장하는지, 그리고 일반적인 모듈 정의가 예측할 수 없는 제약까지 알아야 했다.

RFC 1444는 그 서술을sysObjectID또는snmpORID의 인스턴스와 연결할 수 있게 했다. 관리 스테이션은 기능 문의 데이터베이스를 유지하고, 에이전트에서 식별자를 검색하고, 일치하는 레코드를 찾아 동작을 최적화할 수 있었다. 에이전트가 객체 자원을 동적으로 학습한다면sysObjectID만으로는 충분히 정밀하지 않을 수 있었기에, 운영 자원 식별자가 추가 좌표를 제공했다.

이것은 불확실성의 강력한 축소다. 관리자는 모든 이론적 연산을 시도하며 대화를 시작할 필요가 없다. 알려진 미지원 그룹을 피하고, 읽기 전용 변형을 존중하며, 값을 선언된 구문으로 제한하고, 행 생성에 필요한 추가 셀을 제공할 수 있다.

그러나 이 지름길에는 경계가 있다. 식별자는 구현자가 제공한 문을 가리킬 뿐이다. 그 문을 살아 있는 에이전트에 대한 측정으로 바꾸지는 못한다. 릴리스 변동, 비활성화된 기능, 뷰 제한, 고장난 프로세스, 부정확한 값은 여전히 검증해야 할 관찰이지, 식별자가 허가한 결론이 아니다.

변형 덕분에 부분적 진실을 공표할 수 있었다

실제 예시가 계시적(시사적)인 이유는 구현이 균일하다고 가장하지 않기 때문이다. 그 예는 한 객체는 구현되지 않았고, 여러 객체는 제한된 구문을 가지며, 다른 하나는 읽기 전용이고, 어떤 객체는 읽기와 쓰기에 서로 다른 값이 허용되며, 어떤 테이블 행은 다른 셀이 있어야 생성할 수 있다고 서술했다.

이러한 세부 사항은 표기법의 결함이 아니다. 그것이 바로 요점이다. 유용한 기능 문은 “전부”라고 말하지 않으면서도 아무것도 말하지 않을 수 있다. 부재와 읽기 전용을 구별하고, 읽을 수 있는 값과 쓸 수 있는 값을 구별하고, 일반 접근과 생성 전제 조건을 구별할 수 있다.

또한 의미적 동일성도 보존한다. RFC 1444는 비편집적 변경이 객체 그룹, 준수 정의 또는 기능 정의를 바꿀 때 새로운 디스크립터와 객체 식별자를 요구했다. 그렇지 않으면 재사용된 식별자가 두 개의 서로 다른 계약을 가리킬 수 있었다. 따라서 버전 동일성은 증거 사슬의 일부였지만, 여전히 실행을 증명하지는 못했다.

최후의 발언권은 객체에 있었다

RFC 1444의 구현에 대한 운영적 정의가 결정적인 구절이다. 검색(retrieval)에 대해 에이전트는 합리적으로 정확한 값을 반환해야 했다. 객체가 쓰기 가능하다면, 설정(set) 연산은 관리되는 실체에 합리적으로 영향을 미칠 수 있어야 했다. 객체를 구현할 수 없다면 프로토콜은noSuchObject같은 예외나 오류를 제공했다. 에이전트는 구현되지 않은 객체에 대해 값을 조작해서는 안 되었다.

이는 네 가지 서로 다른 관찰을 낳는다. 첫째, 기능 선언은 릴리스가 무엇을 주장하는지 말한다. 둘째, 뷰와 접근 상태는 현재 주체가 무엇을 다룰 수 있는지 말한다. 셋째, 프로토콜 결과는 이 요청이 값, 예외, 오류 중 무엇을 낳았는지 말한다. 넷째, 독립적인 관찰은 값이 정확했는지, 요청된 변경이 의도한 시스템에 영향을 미쳤는지, 그리고 그것이 지속되었는지 말한다.

반환된 숫자는 그 객체 이름과 함께 바이트가 돌아왔다는 것만 증명한다. 그것만으로 그 숫자가 기저 카운터를 합리적으로 표현한다는 것은 증명하지 않는다. 성공한 설정 교환은 프로토콜이 무언가를 수용하고 처리했다는 것을 증명할 뿐, 의도한 인터페이스가 변경되었는지 또는 재시작 후에도 변경된 상태를 유지했는지 증명하지 않는다. 반대로, 예외는 빈 대시보드 셀을 0으로 채우라는 초대가 아니다. 부재는 증거이며, 그대로 보여져야 한다.

계보는 분리를 유지했다

RFC 1904 기록은 첫 번째 계승을 보여준다. 1996년 초안 표준(Draft Standard)이 RFC 1444를 대체했다.RFC 2580 기록은 두 번째를 보여준다. SMIv2의 1999년 준수 문서가 RFC 1904를 대체했다.

RFC 2580은 핵심 구조를 유지했다. 주장된 그룹은 여전히 그 안의 모든 객체 또는 알림을 요구했다. 기능 매크로는 여전히 제품 릴리스가 주장하는 정확한 지원을 서술했고, 여전히 구현 시점에 개념적으로 전개되며, 여전히 관리자가 운영 자원 식별자를 검색하고 데이터베이스를 참조할 수 있게 했다. 표기법은 성숙했지만, 주장이 런타임 증명(attestation)이 되지는 않았다.

보안 경계도 중요하다. RFC 1444는 보안 문제는 논의되지 않는다고 밝혔다.RFC 3410은 이후 이전 SNMPv2 프레임워크가 의도된 인증, 개인정보 보호, 권한 부여, 접근 제어, 원격 관리 목표에 비추어 불완전했다고 서술하고, 그 결함에 대해 SNMPv3를 가리켰다. 관리 객체에 대한 준수 문을 보안 관리 채널의 증명으로 승격시켜서는 안 된다.

선언과 실행은 한 필드가 아니라 하나의 사슬에 속한다

Lu Heng의 Running-Code Primacy는 유용한 판독 규칙을 제공한다. 공표는 현실이 아니며, 이후의 변경은 구현, 검증, 배포, 사용을 통해서만 현실이 된다.현실 계층 노트는 상징적 힘을 지닌 진술과 실제로 실행될 수 있는 결과 사이의 구분을 더 선명하게 만든다.

RFC 1444를 그것이 하지 않은 정치적 논쟁에 강제로 끌어들일 필요는 없다. 그것 자체의 역학으로 충분하다. 이 표준은 가치 있는 선언을 만들면서도, 그 선언이 객체 동작을 지워버리는 것을 거부했다. 따라서 관리 기록은 기능 식별자와 정의, 제품 릴리스, 준수 문, 활성 뷰와 주체, 요청된 객체, 반환된 값 또는 예외, 검증 출처, 쓰기 확인, 관찰된 효과, 이후의 지속성 검사를 하나로 합쳐버리는 것이 아니라 연결해야 한다.

기능 카드는 그 기록에서 자리를 마땅히 차지한다. 그것은 관리자에게 어디를 봐야 하는지, 무엇이 있어야 하는지 알려준다. 그러나 객체는 여전히 응답해야 한다.

출처