요약

  • RFC 2051은 Admin 테이블을 구성된 기본값의 읽기 전용 뷰로, Oper 테이블을 현재 상태 또는 협상된 상태의 목격자로 만들었다. 그리고 활성 세션과 그 운영 행이 유지되는 가운데 관리 모드 행을 삭제할 수 있음을 명시적으로 허용했다.
  • 세션, 대화, 선택적 카운터, 비정상 이력 행은 서로 다른 생성·삭제 규칙을 따랐다. 그 어느 하나만으로도 구성, 피어 동의, 애플리케이션 성공, 완전성 또는 보안을 증명할 수 없었다.

RFC 2051에서 가장 많은 것을 드러내는 대상은 존재하지 않는 행이다. 1996년의 APPC MIB는 활성 세션이 여전히 해당 모드를 사용 중인 경우에도appcModeAdminEntry를 삭제할 수 있다고 말한다. 그에 대응하는appcModeOperEntry는 계속 존재한다. 따라서 관리 화면에는 관리 템플릿이 전혀 표시되지 않으면서도 그 아래에서 진행 중인 관계를 여전히 정확하게 보여 줄 수 있다.

이것은 데이터베이스 사고가 아니었다. 이것이 바로 아키텍처였다. 관리 테이블은 기본값 또는 기대되는 구성을 나타냈지만, MIB는 그 구성을 만들거나 수정하지 않았다. 이 테이블의 항목들은 읽기 전용이었다. 운영 테이블은 지금 존재하는 것, 또는 두 시스템이 협상한 것을 나타냈다. 동적 항목은 Admin 행을 템플릿으로 시작할 수 있고, 이후 자기만의 수명 주기를 갖게 된다.

이 구분이 중요한 이유는 “구성됨”, “요청됨”, “수락됨”, “협상됨”, “실행 중”이 서로 다른 주장이기 때문이다. 삭제된 구성 기록은 템플릿이 더 이상 관리 표면에 제시되지 않는다는 말일 뿐이다. 이미 수립된 세션을 되감지 않는다. 반대로 남아 있는 운영 행은 오래된 템플릿이 앞으로의 사용에 여전히 승인되어 있다는 것을 증명하지 않는다.

RFC 2051은 이 모델을 글로벌, 논리 장치, 트랜잭션 프로그램, 세션, 대화, CPI-C 그룹으로 조직했다. 이러한 폭 때문에 독자는 MIB를 APPC의 리모컨으로 취급하려는 유혹을 받을 수 있다. 그러나 RFC는 더 좁은 경계를 그었다. 이 RFC는 일반적으로 파트너 LU, 모드, 트랜잭션 프로그램을 만들거나 삭제하고, LU와 프로그램을 활성화하거나 비활성화하고, 대화를 시작하거나, 세션을 활성화하지 않았다. 이러한 작업은 계측된 표면 바깥에 남았다.

일부 제어는 존재했지만, 특정한 것이었다. 관리자는 통계 또는 추적 상태를 선택하고, Change Number of Sessions 명령을 내리고, 세션 비활성화를 요청할 수 있었다. 이러한 쓰기 가능 항목은 제어 표면에서의 요청이었다. 결과에 대한 영수증이 아니었다.

CNOS는 이 구분을 구체적으로 만든다. 관리 CNOS 항목은 원하는 값을 담았다. 운영 항목은 협상 이후의 실제 값을 담았다.세션 시작에 대한 IBM의 현재 설명도 CNOS를 Change Number Of Sessions로 풀고, 모드별 협상을 설명한다. 이 문서는 용어를 제공할 뿐, 특정 제품이 이 RFC를 구현했다거나 어떤 협상이 성공했다는 증거가 아니다.

활성 세션 테이블에는 자체 시계가 있었다. 행은unbound,pendingBind,bound또는pendingUnbind일 수 있었다. 에이전트는 명세의 수명 주기에 따라 행을 만들고 제거했다. 바인딩된 세션에unbound를 쓰면 비활성화가 시작될 수 있었다. 쓰기는 지시가 제출되었음을 증명할 뿐이었고, 에이전트가 실제로 무엇을 했는지 보이려면 이후의 운영 상태가 필요했다.

“bound”조차 제한된 의미를 갖는다. 이는 세션 상태를 기록할 뿐이다. 대화가 할당되었는지, 트랜잭션 프로그램이 완료되었는지, 피어가 올바른 데이터를 반환했는지, 업무 프로세스가 성공했는지는 말하지 않는다. 피어 상태와 애플리케이션 결과는 세션 행 너머에 있다.

대화는 더 짧은 수명의 목격자였다. 에이전트는 대화가 시작될 때 활성 대화 행을 만들고, 대화가 끝나면 그 행을 제거했다. 활성 대화는 세션과 연관되었지만 세션 자체는 아니었다. 여러 대화가 하나의 세션을 통과할 수 있으며, 그 세션 자체의 수명은 그 대화들보다 앞서도 뒤에서도 계속된다.

통계는 또 하나의 선택적 층을 이루었다. 수집이 활성화되면 에이전트는 각 활성 세션마다 통계 행을 만들었다. 카운터는RFC 1902에서 정의된 SNMPv2Counter32유형을 사용했고, 측정 구간의 업타임과 짝을 이루었다. 구간, 오버플로 동작, 수집 상태가 없는 숫자를 완전한 이력으로 격상시킬 수는 없다.

RFC는 이 취약성을 이례적으로 잘 드러냈다. 관리 통계 상태를 inactive로 설정하면 세션 통계 테이블의 모든 행이 제거된다. 그러나 그렇다고 활성 세션이 종료된다는 말은 없다. 빈 카운터는 수집이 꺼졌다는 뜻일 수 있지, 활동이 멈췄다는 뜻이 아니다.

이력도 선택적이었다. 이력 세션 테이블은 비정상적으로 종료된 세션을 보존했고, 이력 대화 테이블은 오류로 끝난 대화를 보존했다. 얼마나 많은 항목이 얼마 동안 남는지는 구현에 달려 있었다. 그 테이블에서의 부재는 정상적인 활동이 없었다는 것을 증명할 수 없고, 모든 과거 비정상 기록이 여전히 이용 가능하다는 것을 증명할 수도 없다.

더 큰 계보는 참조된 SNA 관리 모델인RFC 1666에 문서화되어 있다. 이는 APPC MIB를 관리 계기의 계열 속에 위치시키는 데 도움이 되지만, 정의를 배치 증거로 바꾸지는 않는다. 표준 문서는 항목을 정확히 규정하면서도, 운영자가 설치·활성화·보호·해석을 올바르게 했는지에 대해서는 아무 말도 하지 않을 수 있다.

상태에도 똑같은 주의가 필요하다.IETF Datatracker 기록과RFC Editor 정보 페이지는 RFC 2051을 1996년 10월에 발행된 Standards Track 제안 표준(Proposed Standard)으로 식별한다. 캡처된RFC 상태 변경 색인에는 이 RFC에 대한 이후의 상태 변경이 나열되어 있지 않고, 공식 기록에도 이를 갱신하거나 폐기하는 RFC가 없다. 이 RFC는 오래되었고 레거시 기술을 다루지만, 고정된 공식 근거는 그 형식적 상태를 Historic로 부르는 것을 뒷받침하지 않는다.

RFC Editor 정오표 검색은 일치하는 정오표를 반환하지 않았다. 이는 한 종류의 문서적 불확실성을 좁혀 준다. 그러나 구현, 상호 운용성, 완전성 또는 현재의 관련성을 보증하지는 않는다.

보안이 가장 날카로운 한계다. RFC 2051은 보안 문제를 다루지 않는다고 명시한다. 따라서 그 Standards Track 레이블을 접근 제어, 안전한 관리 쓰기, 신뢰할 수 있는 카운터의 증거로 바꿀 수 없다. 세션은 안전하지 않으면서 운영 상태일 수 있고, 관리 항목은 기반 시스템을 변경할 권한이 누구에게 있었는지 밝히지 않은 채 존재할 수 있다.

올바르게 읽으면, MIB는 서로 다른 관할권을 가진 목격자들의 집합이다. Admin은 어떤 구성이 제시되었는지 말한다. 쓰기 가능한 제어는 무엇이 요청되었는지 말한다. 에이전트의 다음 상태는 무엇을 수락했는지 말한다. CNOS 운영 값은 협상이 무엇을 산출했는지 말한다. 세션 행은 전송 관계가 활성인지 말한다. 대화 행은 하나의 애플리케이션 상호작용 단위가 존재하는지 말한다. 카운터는 수집이 작동하는 동안 무엇이 측정되었는지 말한다. 이력은 선별된 비정상 종료를 기록한다. 피어와 애플리케이션은 각자 자신의 영수증을 제공해야 한다.

이 연쇄가 없어진 행이 왜 중요한지 설명한다. 구성은 쉽게 편집하고 보관할 수 있기 때문에 종종 권한처럼 보인다. 런타임 상태는 편집 이후에 보이기 때문에 준수처럼 보인다. RFC 2051은 이 두 지름길을 모두 거부했다. 세션이 한번 존재하면, 그 진실은 자신을 만드는 데 도움을 준 템플릿보다 오래 살 수 있다. 카운터 테이블이 한번 지워지면, 실행 중인 세션은 자신의 증거보다 오래 살 수 있다.

출처