요약

  • RFC 1052는 SNMP를 인터넷의 단기 관리 기반으로 선택하면서, Craig Partridge가 HEMS를 후보에서 철회할 것을 권고했다는 사실을 기록했다. 같은 결정은 HEMS의 RFC 1024를 공통 MIB 작업의 입력 자료로 지정했다.
  • 그 철회 이후에 공개된 RFC 1076은 HEMS의 대안적 실행 모델을 보존했다: 작은 스트리밍 해석기가 계층적 데이터 트리를 순회하고, 변하는 테이블을 필터링하고, 읽기 또는 허용된 수정 이후 표현된 값을 반환할 수 있었다.
  • 프로토콜 결정, 재사용된 정보 정의, 질의 발급 권한, 에이전트가 반환한 트리, 기기에서 관찰된 효과는 서로 분리된 사실이었다. HEMS가 몰래 SNMP가 된 것은 아니며, 성공적으로 보이는 응답이 트래픽 결과를 증명하지도 않았다.

프로토콜은 모든 아이디어를 함께 가져가지 않은 채 떠날 수 있었다

1987년 무렵, 네트워크 관리는 조율 문제가 되어 있었다.RFC 1021은 규모와 벤더 다양성이 커지는 인터넷을 기술했다. 소수 제조사가 핵심 게이트웨이 대부분을 공급하던 시절에는 숙련된 관리자가 그들의 전용 도구를 익힐 수 있었다. 기기, 네트워크, 구현이 늘어나면서 그 전략은 더 이상 확장되지 않았다.

High-Level 주체 Management System, 즉 HEMS는 그 이질적인 세계를 위한 공통 언어를 만들려 했다. HEMS는 작업을 관리 대상 개체마다 놓인 작은 질의 처리기, 요청 없이 발생하는 통지를 위한 이벤트 생성기, 관리 센터의 더 지능적인 응용 프로그램으로 나누었다. 처리기는 표준화된 데이터 뷰를 노출했고, 응용 프로그램은 무엇을 물을지 그리고 답을 어떻게 해석할지를 결정했다.

HEMS는 또한 모니터링과 제어를 분리했다. 모니터링은 동작에 관한 사실을 수집했다. 제어는 동작을 실시간으로 바꾸려 시도했다. RFC 1021은 이 의존성을 명시적으로 만들었다: 효과를 관찰하지 않고 네트워크를 바꾸는 것은 유용하지 않다. 따라서 초기 설계는 모니터링에 집중하면서, 범용 제어 기능과 강력한 접근 제어 메커니즘이 아직 완성되지 않았음을 인정했다.

이 신중함이 중요한 이유는, 역사가 가장 표현력이 풍부한 프로토콜이 이기는 단순한 경쟁으로 진행되지 않았기 때문이다. 1988년 3월, Internet Activities Board는 HEMS, SNMP, ISO 지향의 CMIP/CMIS 접근을 검토했다.RFC 1052는 SNMP를 단기 기반으로 권고했다. 그 이유는 운영적이었다: 소프트웨어가 이미 존재하고 사용 중이었으며, 커뮤니티는 신속한 수렴을 필요로 했다.

같은 기록은 Craig Partridge가 인터넷 전체의 합의가 형성될 수 있도록 HEMS를 후보에서 철회할 것을 권고했다고 전한다. 철회는 선정 과정 안에서의 행위였지, HEMS의 모든 아이디어가 결함이었다는 증거가 아니었다. RFC 1052는 즉시 이 구분을 명확히 했다. HEMS의 모니터링 대상 요소 작업을 철저하고 폭넓게 논의된 것으로 칭찬했고, 새 MIB 작업 그룹에게 SNMP와 CMIP/CMIS 자료와 함께 RFC 1024의 정의를 하나의 출발 입력으로 삼도록 지시했다.

프로토콜은 경쟁에서 물러났다. 그러나 그 정보 작업은 자리에 남았다.

RFC 1076은 선택되지 않은 길을 기록했다

RFC 1076의 시점은 편한 승자·패자 서사를 막는다. 이 문서는 1988년 11월, RFC 1052로부터 7개월 뒤에 나왔고 RFC 1023을 대체했다. 저자들은 새로운 인터넷 전체 선정을 제시하지 않았다. 대신 실험적인 HEMS 모니터링·제어 언어에 대한 더 상세한 기술을 완성했다.

그 언어는 하나의 원격 절차보다 풍부했다. HEMS 요청은 여러 명령을 담을 수 있었는데, 이 성능 선택은 이미 RFC 1021에서 설명된 바 있다. 관리 대상 개체는 요청 전체를 저장할 필요가 없었다. ASN.1 객체가 도착하는 대로 소비하고, 데이터 객체를 크기가 제한된 스택에 밀어 넣고, 연산 코드를 즉시 실행하며, 이후 명령이 아직 전송 중인 동안에도 응답의 일부를 만들기 시작할 수 있었다.

설계는 작업을 신중하게 배분했다. 에이전트는 실행 가능한 여덟 개 연산만 이해했다: BEGIN, END, GET, GET-ATTRIBUTES, GET-RANGE, SET, CREATE, DELETE. 저장된 프로그램도, 서브루틴도, 명시적 제어 구조도 없었다. 표현력은 이 소수의 연산을 경로, 템플릿, 값, 필터와 조합하는 데서 나왔다.

관리 대상 세계는 트리로 나타났다. 내부 사전은 관련 정보를 묶었고, 경로는 알려진 루트로부터 노드를 이름 붙였으며, 리프는 값을 담았다. 질의는 그 계층 구조를 따라 커서를 이동시켰다. 처리기가 한 분기를 방문하면, 응답에 그 완전히 한정된 구조를 재현했다. 그 결과는 비격식적인 출력물이 아니었다. 질의가 순회한 관리 트리 부분의 인코딩된 이미지였다.

이 분업은 까다로운 조합을 추구했다: 핵심 게이트웨이의 소프트웨어를 작게 유지하면서, 원격 응용 프로그램이 선택적이고 복합적인 질문을 던질 수 있게 하는 것. 복잡성은 폐지되지 않았다. 요청 작성자와 데이터 정의, 응답을 해석하는 데 필요한 증거로 옮겨졌다.

필터는 위치가 아니라 의미로 변하는 개체를 골랐다

큰 테이블은 위치 인덱스를 취약하게 만들었다. 재부팅 전에 세 번째로 번호 매겨진 인터페이스가 재부팅 후에도 세 번째에 있으리라는 보장이 없었다. 라우팅 테이블과 TCP 연결 테이블은 운영자가 질의를 작성하는 동안에도 바뀔 수 있었다. 그래서 RFC 1076은 필터가 배열 항목을 내부의 값으로 선택하도록 허용했다.

필터는 항목의 존재 여부를 묻거나, 등식 또는 상한·하한과 비교하고, AND·OR·NOT으로 검사를 결합할 수 있었다. 필터된 GET은 특정 IP 주소를 지닌 인터페이스의 카운터만 요구할 수 있었다. 필터된 SET은 일치하는 모든 항목을 수정할 수 있었다. 필터된 BEGIN은 일치하는 사전으로 내려가 그 아래의 테이블을 다룰 수 있었다.

이 편의에는 선언된 모호함이 있었다. 여러 사전이 필터된 BEGIN에 일치하면 처리기는 어떤 일치든 고를 수 있었다; 명세는 다중성을 대신 오류로 다뤄야 하는지 판단하려면 경험이 필요하다고 말했다. 따라서 통사적으로 유효한 필터가 반드시 하나의 안정적인 개체를 식별하지는 않았다. 운영자는 여전히 유일성 가정과 그것이 성립한다는 증거를 필요로 했다.

RFC 1076은 또한 GET-RANGE가 OctetString의 일부를, 기기 의존적인 메모리 표현을 포함하여 검색하도록 허용했다. 그러나 메모리는 사전 전체 GET에서는 의도적으로 제외되었다. 일반적인 탐색이 모든 민감하거나 비용이 큰 객체를 덤프할 권한을 주는 것은 아니었다. 데이터 뷰는 광범위한 검색이 무엇을 의미하는지에 관한 정책 선택을 인코딩하고 있었다.

응답은 기기 전체가 아니라 표현된 상태를 반영했다

HEMS 규칙 중 가장 계몽적인 것은 수정에 관한 것이었다. SET과 CREATE는 연산 이후 트리의 영향받은 부분을 반환했다. DELETE는 보통 아무것도 반환하지 않았으며, 일치했지만 삭제될 수 없는 항목은 반환될 수도 있었다. 응용 프로그램이 설정 불가능한 항목에 SET을 시도하면, 처리기가 반드시 오류를 내보내는 것은 아니었다. 현재 값을 반환했고, 응용 프로그램은 요청된 값과 비교할 수 있었다.

보통의 저장된 구성에 대해, 그 연산 후 이미지는 유용한 증거가 될 수 있었다. 제어 기능은 더 어려웠다. RFC 1076은 “가상 명령·상태 레지스터”를 제안했다: 트리 항목에 명령 코드를 부여하면 인터페이스를 내리거나 올리는 것 같은 임의의 구현 정의 부수 효과를 트리거할 수 있었다. 항목을 읽으면 현재 상태가 반환될 수 있었다.

“~될 수 있었다”라는 표현이 경계를 지킨다. 요청된 값을 담은 응답은 처리 이후 HEMS 데이터 트리 인터페이스가 표현한 것을 확립한다. 물리적 인터페이스가 프레임 전달을 멈췄다거나, 경로가 수렴했다거나, 피어가 변화를 인지했다거나, 상태가 재시작 이후 유지되었다거나, 트래픽이 의도된 대안을 따랐다는 사실을 독립적으로 확립하지는 않는다.

이것은 오래된 프로토콜에만 고유한 결함이 아니다. 명령 평면 증거와 결과 증거의 차이이다. 관리 시스템은 자신이 수용한 표현을 정확히 보고하면서도, 제어되는 하위 시스템은 지연되거나 부분적으로만 바뀌거나 곧 덮어써지거나 다른 표면에서만 관찰될 수 있다.

권한 부여는 언어 바깥에 있었고, 부재는 모호해졌다

RFC 1022는 질의, 응답, 이벤트, 오류를 감싸는 HEMP 봉투를 정의했다. 인증과 암호화 정보를 위한 자리를 예약하고 프로토콜 오류를 응용 프로그램 오류와 구분했다. 그러나 봉투 필드가 존재한다는 것이 특정 요청이 인증되었거나 암호화되었다는 증거는 아니었다; 1987년 명세는 암호화 유형을 지정하지 않았다.

RFC 1076은 권한 부여 시스템을 의도적으로 열어 두었다. 질의는 그 HEMS 환경이 공급하는 레벨 또는 능력 집합으로 실행되었고, 각 데이터 항목은 지역 검사를 적용했다. 언어 자체에는 로그인이나 권한 연산이 없었다. 검색과 수정은 제한될 수 있었지만, 그렇게 하면 BEGIN이 실패하고 질의 전체가 종료될 수 있어 사전 탐색을 숨길 수는 없었다.

이 선택은 유용하면서도 결과가 따르는 모호함을 만들었다. 정의되지 않았거나, 구현되지 않았거나, 권한이 없는 태그에 대한 GET은 동일한 길이 0의 no-value 객체를 반환했다. 제네릭 질의는 선택적 필드마다 죽지 않고 이질적인 기기에 대해 실행될 수 있었다. 대가는 응답만으로는 세 가지 다른 침묵의 원인을 구분할 수 없다는 것이었다.

처리를 종료하는 오류들은 눈에 띄게 만들어졌다. 오류는 종류, 구현 인스턴스, 바이트 오프셋, 연산, 인쇄 가능한 설명을 식별했다. 처리기가 이미 여러 겹의 중첩된 ASN.1 응답 객체를 열어 둔 상태였다면, 미완료된 모든 레벨에 오류 사본을 삽입하고 마지막에 한 번 더 삽입했다. 입력이 끝나기 전에 출력이 시작될 수 있었기 때문에, 실패 증거는 이미 전송 중인 구조를 닫아야 했다.

따라서 응답은 시간 없는 스냅샷이 아니라 처리의 장부였다. 어떤 값들은 이후 명령이 실패하기 전에 이미 내보내졌을 수 있었다. 중첩된 종료는 해석이 어디서 멈췄는지 디코더에 알렸다; 그것은 이전의 부수 효과를 롤백하지 않았다.

선택된 프로토콜은 더 단순했다; 상속 주장은 좁게 유지되어야 한다

1989년 8월까지RFC 1109는 벤더와 공개 참조 작업 등 여러 네트워크에서의 SNMP 구현을 보고했다. 동시에 확장성, 구성 관리, 사용자 접근 제어, 명령 인증에서 계속되는 공백도 기록했다. 선정은 즉각적인 조율 문제를 해결했을 뿐; 네트워크 관리를 끝내지는 않았다.

이후의RFC 1155는 표준화된 Structure of Management Information을 기술했다: 계층적 주체 IDENTIFIER 이름, 제한된 ASN.1 유형, 가상 정보 저장소.RFC 1157은 의도적으로 작게 줄인 Get, GetNext, Set, Trap 표면으로 SNMP를 명세하고, SMI·MIB·SNMP 프레임워크를 권고되는 운영 아키텍처로 기록했다.

HEMS 트리에서 이후 모든 OID로 곧은 화살표를 그리고 싶은 유혹이 있다. 그러나 출처는 그것을 지지하지 않는다. RFC 1052가 증명하는 기관적 연결은 하나다: RFC 1024가 MIB 그룹의 명시적 출발 입력이었다는 것. 유사한 계층 구조와 ASN.1 선택은 설계들이 같은 문제 공간에 살았음을 보여준다. 그러나 이후 모든 객체, 연산, 인코딩이 RFC 1076에서 내려왔음을 확립하지는 않는다.

더 방어 가능한 역사는 더 흥미로운 역사이기도 하다. 커뮤니티는 하나의 배포 가능한 프로토콜을 선택해야 할 필요와, 유용한 의미론적 작업을 보존해야 할 필요를 분리했다. HEMS는 공통 프로토콜 후보로서는 철회하면서도, 그 객체 정의는 또 다른 작업 그룹을 위한 증거로 남을 수 있었다. RFC 1076은 선정을 뒤집지 않고 대안적 질의 모델을 문서화할 수 있었다.

출처와 한계

RFC 1021은 실험 시스템의 범위를, RFC 1022는 메시지 봉투를, RFC 1024는 입력으로 지명된 객체 정의 작업을, RFC 1052는 선정과 철회 결정을, RFC 1076은 질의 언어를, RFC 1109는 운영 후속을, RFC 1155는 이후의 SMI 구조를, RFC 1157은 이후의 SNMP 프레임워크를 제공한다. 이들은 HEMS의 배포 조사, RFC 1076의 패킷 캡처, 필드별 완전한 마이그레이션 지도, 특정 기기 효과의 증명을 제공하지 않는다.

결론은 정확하게 유지되어야 한다. HEMS는 공통 프로토콜 선정에서 이기지 못했다. 그 정보 작업이 자동으로 지워진 것도 아니었다. RFC 1076은 응답이 표현된 트리 상태를 신중하게 기술하는 일관된 관리 언어를 보여준다. 역사는 이 세 가지 명제를 분리된 채 유지해야 한다.