요약

  • RFC 1065는 객체 유형을 이름, 구문, 인코딩, 접근 범주를 갖춘 선언으로 만들었지만, 그 선언을 특정 기계의 실시간 측정값으로 만들지는 않았다.
  • 이 문서의 식별자 트리는 내구성 있는 이름을 위임했고 유형 어휘는 표현을 규율했지만, 존재하는 것이 무엇인지, 인스턴스를 어떻게 찾는지, 응답이 무엇을 의미하는지는 여전히 MIB 정의와 관리 프로토콜이 말해야 했다.

카탈로그는 계기판이 아니었다

초기 TCP/IP 관리는 겉보기에 평범한 문제에 직면했다. 관리자, 에이전트, MIB가 값에 대해 다투기 전에, 대상의 라벨에 대해서는 합의해야 했다. 공통 구조가 없다면 한 구현의 "인터페이스 오류"가 다른 구현의 사유 번호일 수 있고, 다른 형식으로 표현되어 다른 전송 규약으로 보내질 수 있었다. 그러나 공통 라벨은 더 큰 실수를 부를 수도 있었다. 카탈로그를 마치 이미 네트워크의 상태를 담고 있는 것처럼 다루는 실수 말이다.

RFC 1065(1988년 8월 발행)는 이 두 역할을 분리했다. 이 문서는 ASN.1을 사용해 TCP/IP 기반 인터넷의 관리 정보를 위한 공통 구조와 식별 체계를 정의했다. 그 관리 정보 구조(SMI)는 의도적으로 기반 시설이었다. 정보 모델을 제공하면서도, 특정 시스템에서 실제로 사용 가능한 관리 대상 객체나 객체 인스턴스를 지칭하는 프로토콜별 장치를 정의하지 않는다고 명시했다. 이는 희망적 독해로 채워야 할 누락이 아니라, 동반 문서가 맡아야 할 책임이었다.

이 구분은 문서가객체 유형(주체 type)을 사용하는 방식에서 가장 쉽게 드러난다. 유형은 한 부류의 관리 정보가 어떻게 명명되는지, 그 값이 어떤 구문을 쓰는지, 그 값이 어떻게 인코딩되는지, 어떤 접근 범주가 적용되는지를 말한다. RFC 1065는 그 선언을 선언적(declarative)이라고 부른다. 반면객체 인스턴스(주체 instance)는 어떤 시점에 값에 결합된 유형이다. 유형은 응답이 도착했을 때 관리자가 그것을 어떻게 읽어야 하는지 알려줄 수 있다. 그러나 유형 자체가 응답을 보고하거나, 어떤 장치가 응답했는지 증명하거나, 언제 샘플되었는지 확정하거나, 그 값이 여전히 실행 중인 시스템을 기술한다는 것을 보여주지는 못한다.

트리는 값을 짓기 전에 책임을 명명했다

객체 식별자는 이 규율의 가시적인 축이었다. RFC 1065는 주체 IDENTIFIER 아크의 계층 구조를 사용해 인터넷 관리를iso.org.dod.internet분기 아래에 배치했다. 숫자 경로 덕분에 중앙의 평면적 목록 없이도 독립적으로 관리되는 하위 트리들이 공존할 수 있었다.

이 계층 구조는 흔히 과잉 해석되기 쉽다. 객체 식별자는 물리 장치의 일련 번호도, 모든 발생 항목에 대한 데이터베이스 기본 키도, 구현이 그 객체를 내보낸다는 약속도, 측정값도 아니다. 그것은 관리를 위임할 수 있는 구조화된 이름일 뿐이다. 문서의 트리는 유형의 정의를 참조하는 방법을 제공한다. 관리 프로토콜은 여전히 인스턴스 정보를 덧붙이거나 전달하는 규칙이 필요하고, MIB는 여전히 그 유형 자체를 정의해야 한다.

이 절제가 중요했다. 도구를 넘어 살아남는 이름은 비교를 가능하게 만들 수 있지만, 비교의 상황 자체를 소멸시키지는 못한다. 같은 유형을 담은 두 응답은 서로 다른 에이전트에서 올 수 있다. 같은 에이전트도 서로 다른 시각에 응답할 수 있다. 응답이 없다는 것은 존재하지 않는 유형 외에도 여러 의미를 가질 수 있다. RFC 1065는 이런 후속 질문들이 표현 가능하게 유지되는 문법을 만들었지, 그 질문들에 조용히 답을 내놓지는 않았다.

구문은 값을 판독 가능하게 만들었을 뿐, 반드시 참으로 만들지는 않았다

RFC는 또한 ASN.1의 기본 어휘 외에Counter,Gauge,TimeTicks,Opaque같은 애플리케이션 전역 데이터 유형을 제공했다. 이 선택은 외양적인 것이 아니었다. 값의 구문과 인코딩을 아는 수신자는 정수인지, 객체 식별자인지, 옥텟 문자열인지 추측하지 않고도 바이트를 파싱할 수 있다.

그러나 표현은 출처가 아니다. 형식이 올바른Counter는 카운팅이 어디서 시작되었는지 말해주지 않고,TimeTicks값은 클록의 넓은 이력을 식별해주지 않으며,Opaque값은 감싸는 필드가 안전하게 전달될 수 있다는 이유만으로 이해 가능해지는 것이 아니다. 이후의 MIB와 프로토콜이 개별 유형에 더 정밀한 운용 의미를 부여할 수 있었다. RFC 1065의 기여는 더 좁았다. 모든 관리 교환이 기본 표기법을 새로 발명하는 일을 막은 것이다.

같은 한계가 접근 필드에도 적용된다.read-only,read-write,write-only,not-accessible은 객체 유형의 기대되는 관리 접근을 분류한다. 이것은 자격 증명도, 인증 결과도, 특정 운영자에 대한 정책 결정도, 요청된 변경이 성공했다는 증거도 아니다. 유형을read-write라고 선언한다고 해서 모든 관리자에게 권한이 부여되는 것은 아니다. 그것은 프로토콜과 MIB 독자에게 읽기와 쓰기가 모두 선언된 표면의 일부이며, 실제 요청을 강제하는 시스템의 제약을 받는다고 알려줄 뿐이다.

경계는 프로토콜이 데이터베이스를 사칭하지 못하게 했다

관리 시스템에 테이블, 카운터, 구성 제어가 축적됨에 따라 SMI의 절제는 더욱 가치를 얻었다. MIB는 관리 대상 객체를 정의할 수 있다. 프로토콜은 인스턴스 참조를 구성하고 요청을 전달하고 응답을 반환할 수 있다. 에이전트는 로컬 상태와 접근 정책을 적용할 수 있다. 그 후 관리자는 결과에 얼마나 신뢰를 둘지 결정한다. RFC 1065는 이들 중 어느 행위자도 친절한 객체 이름 뒤로 사라지게 하지 않았다.

RFC 1155는 이후 RFC 1065를 폐기하면서, 상태와 사소한 인쇄상의 수정을 제외한 기술적 내용을 명시적으로 그대로 재공표했다.RFC 1212는 간결한 MIB 정의를 위한 이후의 규약을 제시했고,RFC 2578은 발전된 SMIv2 형태를 기록한다. 이것들은 계보를 보여줄 뿐, 이후의 메커니즘을 1988년으로 소급 투사할 권한을 주지는 않는다.

출처와 한계

RFC 1065는 초기 SMI의 범위, 객체 유형 선언, 식별자 계층, 값 구문, 접근 범주를 확립한다. RFC 1155는 기술적으로 변경되지 않은 재공표를 확립한다. RFC 1212와 RFC 2578은 이후의 비교 대상을 제공한다. 이 문서들은 현재 배포 현황, 특정 벤더의 MIB 내용, 응답 장치의 신원, 특정 세션에서의 인가, 데이터 플레인 효과, 개별 값의 사실적 진위와 신선도를 확립하지 않는다. 내구성 있는 선언이 실시간 관찰보다 의도적으로 더 좁다는 주장은 그 문서화된 분리에 대한 해석이다.