요약

  • RFC 3159는PIB-INDEX가 하나의InstanceId를 이름 지도록 요구했고, 그 식별자에 프로비저닝 클래스 인스턴스를 찾는 기능 이상의 정책적 의미를 의도적으로 부여하지 않았습니다. 유효한 행 번호는 그 행이 의도하는 바의 설명이 아니었습니다.
  • 의미는 PIB 모듈, PRC 및 텍스트 규약 정의, 주체 범주, 접근 모드, 고유성·참조 제약, 적합성 선언, 그리고 기본 행·확장 행·희소 확장 행의 서로 다른 수명 주기에 걸쳐 분산되어 있었습니다.
  • 설치와 효과는 이후의 영수증에 속했습니다. COPS-PR 교환, 트랜잭션 결과, PEP 상태, 강제된 패킷 동작, 애플리케이션 결과가 그것입니다. 이후의 Historic 기록과 제한적인 배포는 “기록을 이름 짓는 것”과 “실행 중인 코드가 그것으로 무엇을 했는지 입증하는 것” 사이의 이 견고한 구분을 지우지 못합니다.

두 행은 번호만으로 달라질 수 있다

정책 결정 지점(PDP)이 라우터에 두 개의 프로비저닝 인스턴스를 보내는 상황을 상상해 보십시오. 의미 있는 모든 속성은 동일합니다. 같은 분류기, 같은 동작, 같은 임계값, 같은 큐 참조. 유일한 차이는 인스턴스 식별자로 할당된 부호 없는 정수입니다.

데이터베이스 뷰어는 두 개의 행을 표시할 수 있습니다. 프로토콜 트레이스는 두 개의 객체 식별자를 보여줄 수 있습니다. 그러나 어느 관찰도 그 행들이 서로 다른 정책 의도를 표현하는지 답해 주지 않습니다. 둘은 의도적으로 중복된 인스턴스일 수 있습니다. 하나는 오래되었을 수 있고, 하나는 다른 가상 스토어에 속할 수 있습니다. 고유성 제약이 이 쌍을 거부할 수도 있습니다. 희소 확장은 기본 행이 없다면 무효일 수 있습니다. 장치는 모듈이 열거하지 않은 이유로 두 설치를 모두 거부할 수도 있습니다.

RFC 3159는 이 좁은 부분을 명시적으로 만들었습니다.PIB-INDEX는InstanceId구문을 가진 정확히 하나의 기술자를 담았습니다. 그 값은 PRC 인스턴스를 식별하는 것 이상의 의미를 갖지 않았습니다. 행 정의의 객체 식별자에 그 값을 덧붙이면 인스턴스의 주소가 만들어졌습니다. 정책 설명이 만들어진 것은 아니었습니다.

이것은 의미 있어 보이는 행 번호에 대한 경고 그 이상이었습니다. 설계 경계였습니다. 어떤 번호가 숨은 업무적 의미(우선순위 7, 테넌트 42, 큐 3)를 획득하면, 소프트웨어는 그런 약속이 전혀 없는 좌표로부터 정책을 추론하기 시작할 수 있습니다. 식별자는 은밀한 스키마가 되고, 형식적 스키마는 더 이상 전체 진실을 말할 수 없게 됩니다.

SPPI는 관리 언어를 빌렸지만 명사를 바꿨다

정책 프로비저닝 정보 구조(SPPI)는 2001년 8월에 SNMP의 관리 정보 구조(SMI)를 개작한 형태로 등장했습니다. 저자들은 익숙한 ASN.1 관례, 구현 지식과 도구를 재사용하고자 했습니다. 그러나 두 세계를 구분해야 할 필요도 있었습니다.

SMI는 관리 대상 객체(managed 주체)를 말했습니다. COPS는 이미 프로토콜 구성 요소에 “객체(주체)”라는 단어를 사용하고 있었기에, SPPI는 모델링된 테이블과 행을 프로비저닝 클래스(PRC)로, 인스턴스화된 행을 프로비저닝 인스턴스(PRI)로, 열을 속성으로 다시 명명했습니다. SPPI는 SMI의 스칼라 객체를 재현하지 않았습니다. 연산은 표 형태의 PRC에 적용되었습니다.

이 어휘는 메커니즘이 어디에 놓였는지를 알려줍니다. PIB 모듈은 구조화된 프로비저닝 정보를 기술합니다. 그 자체가 업무 목표를 실행하지는 않습니다.MODULE-IDENTITY는 모듈 수준의 의미를 담았습니다.주체-TYPE정의는 PRC와 그 속성들을 기술했습니다. 텍스트 규약은 반복되는 전송 유형에 더 구체적인 의미를 부여했습니다. 객체 그룹과 모듈 적합성 선언은 최소 구현 주장을 기술했습니다.

이 구조가 중요한 이유는 ASN.1 구문이 완전성의 인상을 만들 수 있기 때문입니다. 행은 파싱되고, 유형은 맞고, 식별자는 해석되고, 모든 필수 필드가 존재합니다. 그러나 파싱은 기록이 모델에 맞는지만 확립합니다. 어떤 정책 결정이 그것을 만들어냈는지, 정책 시행 지점(PEP)이 수락했는지, 패킷 처리가 어떻게 바뀌었는지는 확립하지 않습니다.

인덱스는 주소였지, 축소판 정책이 아니었다

기본 행에 대해 SPPI는 두 가지 확장 형식 중 하나를 쓰지 않는 한PIB-INDEX를 요구했습니다. 인덱스는 단일 속성을 이름 지었으며, 이는 통상 같은 PRC 안에 정의되지만 반드시 그럴 필요는 없었습니다. 그 속성은 부호 없는 32비트 값인InstanceId를 사용했습니다.

생성된 PRID는 두 조각을 결합했습니다. PRC 행 정의의 객체 식별자와, 하나의 하위 식별자로 더해진 인스턴스 값입니다. 결과는 적용 가능한 모델 내에서 한 인스턴스를 모호하지 않게 가리킬 수 있었습니다. 그 정밀도는 실재했지만 의도적으로 제한되어 있었습니다.

선택적인 일반INDEX절도 있었지만, RFC 3159는 그것에 다른 역할을 부여했습니다. PIB를 MIB로 변환하는 알고리즘적 변환입니다. 두 절을 동의어로 다루면 SPPI에서 프로비저닝 행이 식별되는 방식과, 변환된 관리 표현이 인덱싱될 수 있는 방식 사이의 구분이 지워집니다.

이것이 문서의 첫 번째 근거 규칙입니다. PRID를 보존하되, 그와 함께 스키마 좌표도 보존하십시오. PIB 모듈과 개정판, PRC 정의, 적용 가능한 텍스트 규약 없이는 숫자 주소가 고아로 남습니다. 그 정의들이 있더라도, 그것은 행이 허용되는 의미를 말할 뿐—장치가 그것을 설치했거나, 의도된 동작이 발생했다는 뜻이 아닙니다.

의미는 의도적으로 흩어져 있었다

행의 의미는 하나의 마법 필드에 담기지 않았습니다. 여러 계약으로부터 조립되었습니다.

PRC 정의는 속성들과 그 설명을 제공했습니다. 텍스트 규약은 단순한 기저 정수나 옥텟 문자열을, 명시된 정책 의미를 가진 값으로 바꿀 수 있었습니다.SUBJECT-CATEGORIES는 모듈을 명명된 COPS 클라이언트 유형 또는 전체 범주와 연결했습니다. 모듈은 하나 이상의 가상 스토어에 존재할 수 있으므로 스토어 맥락도 중요했습니다.

PIB-ACCESS는 또 다른 질문에 답했습니다. PDP와 PEP는 이 PRC와 어떤 관계를 가질 수 있는가?install은 PDP가 인스턴스를 프로비저닝 정보로 설치할 수 있음을 뜻했습니다.notify는 PEP가 모든 인스턴스와 값을 PDP에 알리도록 요구했습니다.install-notify는 둘을 결합했습니다.report-only는 일반적인 설치도 알림도 없음을 뜻하되, PRC는 동기 또는 비동기 보고서에 나타날 수 있었습니다.

식별자는 이 중 어느 것도 드러내지 않았습니다. 설치 가능한 행의 PRID와 report-only 데이터의 PRID는 똑같이 깔끔해 보일 수 있었습니다. 오직 둘러싼 정의만이 정보를 어느 쪽이 만들어내고 어떻게 전달될 수 있는지 보여주었습니다.

적합성 선언은 또 하나의 경계를 더했습니다. 속성 그룹을 요구함으로써 최소 PRC 지원을 요구할 수 있었습니다. 이는 구현이 선언한 능력에 대한 근거였습니다. 특정 시점의 특정 행에 대한 영수증은 아니었습니다.

고유성은 의도적으로 정체성과 분리되어 있었다

SPPI의UNIQUENESS절은 많은 데이터베이스가 감추는 구분을 드러냈습니다. 이 절은 인스턴스 전체에서 결합된 값이 고유해야 하는 의미 있는 속성들을 나열했습니다.PIB-INDEX가 이름 짓는 속성은 포함될 수 없었습니다.

따라서 한 집합의 필드가 내용으로 인스턴스를 구분하는 데 필요하고 충분할 수 있고, 다른 필드가 프로토콜 수준의 행 정체성을 제공할 수 있었습니다. 빈UNIQUENESS절은 더 나아갔습니다. 두 행은 인스턴스 번호를 제외한 모든 속성에서 동일할 수 있었습니다.

그래서 “다른 ID”와 “다른 정책”은 동치가 아닙니다. 전자는 식별자를 비교해 판정할 수 있습니다. 후자는 속성, 그 의미, 적용 가능한 제약을 필요로 합니다. 운영자가 PRID만으로 중복을 제거하면 중복된 정책 내용이 살아남습니다. 운영자가 내용만으로 행을 병합하면 서로 다른 수명 주기·참조 의무가 사라질 수 있습니다.

표준은UNIQUENESS가 유용한 정보를 전달하는 곳에서 이를 권고했지만, 모든 곳에서 요구하지는 않았습니다. 따라서 부재는 부재로 남아야 했습니다. 소프트웨어가 편리해 보이는 필드들로 자연 키를 몰래 만들어낼 수는 없습니다.

참조에는 선언된 목적지가 필요했다

정책 행은 종종 다른 행을 가리킵니다. RFC 3159는ReferenceId가 맥락 없이 떠다니는 것을 허용하지 않았습니다.PIB-REFERENCES는 참조되는 인스턴스가 속한 PRC를 이름 지어야 했습니다.TagReferenceId도 마찬가지로PIB-TAG를 요구했으며, 이는 태그가 붙은 인스턴스 집합을 형성하는 데 쓰이는 속성을 이름 지었습니다.

이 구분은 외래 키와 집합 선택자를 닮았지만, 역사적 메커니즘은 구체적이었습니다. 하나의 참조는 선언된 PRC 안의 한 인스턴스를 선택했습니다. 다른 하나는 태그 값을 공유하는 다른 PRC의 모든 인스턴스를 선택했습니다. 같은 정수 바이트가 어느 관계가 의도되었는지를 드러낼 수는 없었습니다.

이것은 해석을 숫자의 우연으로부터 보호했습니다. 큐 PRC의 인스턴스 12가 임계값 PRC의 인스턴스 12인 것은 아니었습니다. 태그 값은 그 범위를 정의한 PRC와 속성 밖에서 보편적 그룹 이름이 되지 않았습니다.

완전한 기록에는 따라서 참조하는 속성, 그 텍스트 규약, 명명된 대상 PRC, 대상 자신의 정체성 규칙, 모듈 맥락이 필요했습니다. 번호만 복사하면 링크의 겉모습은 남지만 목적지는 버려집니다.

기본, 확장, 희소 확장은 서로 다른 삶을 살았다

모든 SPPI 행 정의는 정확히 하나의 정체성 관계를 가졌습니다. 자신의PIB-INDEX,AUGMENTS절 또는EXTENDS절입니다. 이 선택은 구문 이상을 통제했습니다.

PIB-INDEX를 가진 행은 기본이었습니다.AUGMENTS행은 명명된 기본과 일대일 관계를 가지며 기본의 정체성을 재사용했습니다. 그 인스턴스들은 같은 존재 의미를 따랐습니다. 기본을 설치하거나 제거하면 모든 확장이 함께 설치되거나 제거되었습니다.

EXTENDS행은 희소(sparse)였습니다. 이것도 기존 인덱스를 재사용했지만, 관계는 영(零)또는일(1)이었습니다. 희소 인스턴스는 대응하는 기본 없이 존재할 수 없습니다. 기본이 존재한다고 해서 반드시 존재할 필요는 없었습니다. 명시적으로 설치되어야 했고 명시적으로 제거될 수 있었으며, 기본의 제거는 이를 암묵적으로 제거했습니다. 희소 기본과 확장이 함께 설치될 때는 둘 다 하나의 COPS 메시지에 나타나야 했습니다.

행 번호만으로는 이 삶들을 구분할 수 없었습니다. 같은 인스턴스 값이 기본, 의무적 일대일 확장, 또는 선택적 희소 확장을 나타낼 수 있었습니다. 관계 정의 없이 행을 복원하면 주소 지정 가능해 보이지만 법적으로 존재할 수 없는 기록이 만들어질 수 있습니다.

이것이 두 번째 근거 규칙입니다. 정체성은 기록들을 결합하고, 수명 주기 규칙은 시간에 걸쳐 어느 결합이 유효한지를 결정합니다. 번호가 일치하는 스냅샷은, 기본이 존재했고 확장이 허용된 트랜잭션에서 설치되었으며 제거가 명세대로 전파되었다는 역사보다 약합니다.

스키마에 유효한 행도 여전히 거부될 수 있었다

INSTALL-ERRORS는 PRC가 자신의 인스턴스 설치 또는 제거가 실패할 수 있는 구체적 이유들을 열거하도록 했습니다. 명명된 각 번호는 PRC 고유의 COPS 오류 서브코드가 되었고, 그 의미는 PRC에서 기술되었습니다.

중요한 문장은 열거 규칙 뒤에 왔습니다.INSTALL-ERRORS가 없더라도 설치나 제거는 여전히 실패할 수 있다는 것입니다. 부재는 PRC 고유 오류가 제공되지 않을 뿐이라는 의미였습니다.

이것은 흔하지만 위험한 추론을 막습니다. 스키마에 유효한 PRI가 수락된 PRI는 아닙니다. 수락된 메시지가 반드시 완료된 트랜잭션은 아닙니다. 완료된 트랜잭션이 자동으로 검증된 장치 구성은 아닙니다. 구성된 분류기가 패킷이 그것에 일치했다는 증거는 아닙니다. 패킷이 기대한 경로를 따르는 것이 애플리케이션이 목적을 달성했다는 증거는 아닙니다.

COPS-PR은 PIB 데이터 주변의 전송과 트랜잭션 장치를 제공했습니다. 그 결정, 오류, 커밋 또는 중단 동작, 캐시된 상태, 재연결 규칙은 이후의 영수증을 만들었습니다. RFC 3159는 정책 데이터가 기술되는 언어를 제공했습니다. 어느 쪽도 다른 쪽을 사칭할 수 없었습니다.

적합성은 능력을 기술했지, 한 번의 실행을 기술하지 않았다

SPPI는 SMI 전통에서 객체 그룹과 모듈 적합성을 유지했습니다. PIB 모듈의 모든 속성은 최소 하나의 적합성 그룹에 속해야 했습니다. 모듈 적합성 선언은 의무 그룹을 명명하고 구문 또는 최소 접근을 세분화할 수 있었습니다. 그 적합성을 주장하는 구현은 요구되는 속성과 그 PRC들을 구현해야 했습니다.

이것은 조달과 상호운용성 계획에 유용한 근거였습니다. 구현이 이해한다고 말하는 범위를 한정했습니다. 그러나 그 선언은 모듈 능력 계층에서 작동했습니다. 특정 PRI가 장치에 존재하는지, 그 참조 대상이 존재하는지, 트랜잭션이 커밋되었는지, 시행 지점이 의도대로 동작했는지를 말하지 않았습니다.

능력, 구성, 결과는 세 가지 다른 질문입니다. 장치는 PRC를 구현하면서 설치된 인스턴스가 없을 수 있습니다. 인스턴스를 저장하면서 대응하는 동작을 활성화하지 않을 수 있습니다. 라이브 트래픽과 한 번도 일치하지 않는 동작을 활성화할 수 있습니다. 세 상태를 모두 “적합”으로 표시하는 모니터링 시스템은 이 아키텍처가 제공한 정확한 구분을 파괴합니다.

보안 문장은 좁았다

RFC 3159의 보안 절은 이 문서가 프로비저닝 정보를 위한 언어를 정의하며, 그 언어 자체는 인터넷에 보안 영향을 미치지 않는다고 말했습니다. 적절한 범위로 읽으면, 이 문장은 구문 정의와 주변 시스템의 보안을 분리합니다.

이것은 COPS 세션을 인증하거나, 모든 PDP를 인증하거나, 모든 정책 저자를 승인하거나, 분류기의 안전성을 검증하거나, PEP가 행을 올바르게 시행할 것을 보장하지 않았습니다. 그 질문들은 프로토콜 보안, 구현, 운영 승인, 그리고 정책 내용 자체에 속했습니다.

교훈은 그 언어가 몰래 불안전했다는 것이 아닙니다. 언어 수준의 보안 문장은 배포 수준의 보증으로 승격될 수 없다는 것입니다. 영수증은 자신이 다루는 계층을 이름 지어야 합니다.

아키텍처는 역사가 되었지만 무의미해지지는 않았다

이후의 근거는 표준 이야기를 바꿨습니다. RFC 6632는 COPS-PR이 널리 배포되지 않았고, 운영자들이 단순한 텍스트 지향 스크립팅에는 이진 관리 인코딩이 불편하다고 느꼈으며, 어떤 PIB 모듈도 제안 표준(Proposed Standard)에 도달하지 않았고, COPS-PR 사용은 권고되지 않았다고 기록했습니다. RFC 3159는 이제 Historic 지위를 지닙니다.

이 사실들은 중요합니다. SPPI를 오늘날 지배적인 네트워크 구성 시스템으로 제시하는 기사는 독자를 오도할 것입니다. 그러나 “널리 배포되지 않음”은 “한 번도 구현된 적 없음”이 아니고, Historic은 설계 기록을 지우라는 명령이 아닙니다.

버려진 경로가 가치 있는 이유는 정확히 그 경계가 명시적이었기 때문입니다. 행의 주소를 내용으로부터, 내용을 접근 모드로부터, 접근을 수명 주기로부터, 수명 주기를 전송으로부터, 전송을 효과로부터 분리했습니다. 새로운 모델링·자동화 시스템은 다른 인코딩을 쓰면서도, 객체 ID나 리소스 URI 또는 성공한 API 응답을 실행 증거로 받아들이면 같은 실수를 반복할 수 있습니다.

역사는 인기 경쟁이 아닙니다. 메커니즘은 채택에서 밀려나면서도 입증에 관한 날카로운 교훈을 유지할 수 있습니다.

견고한 결과물은 PRID가 아니라 사슬이다

책임성 있는 프로비저닝 기록은 정확한 PIB 모듈, 개정판, 주체 범주로 시작합니다. 각 속성을 정의한 PRC와 텍스트 규약을 보존합니다. 행이 기본인지, 확장인지, 희소 확장인지, 그InstanceId, 적용 가능한 고유성·참조·태그 제약, 가상 스토어 맥락, 접근 모드, 적합성 프로필을 기록합니다.

그다음 운영으로 넘어갑니다. COPS-PR 요청과 결정, 트랜잭션 식별자, 설치 또는 제거 결과, 일반 또는 PRC 고유 오류, 재연결 또는 캐시 상태 맥락, PEP의 트랜잭션 후 구성을 보존합니다. 패킷 경로 또는 다른 시행 표면을 관찰합니다. 마지막으로, 실제로 판단할 수 있는 계층에서 애플리케이션 결과를 기록합니다.

각 링크는 주장을 좁힙니다. 모듈은 필드가 무엇을 의미하는지 말합니다. PRID는 어느 인스턴스가 지목되는지 말합니다. 프로토콜 영수증은 무엇이 교환되었는지 말합니다. 장치 영수증은 무엇이 설치되었는지 말합니다. 트래픽 근거는 어떤 시행이 발생했는지 말합니다. 애플리케이션 근거는 목적이 달성되었는지 말합니다.

RFC 3159의 인덱스는 전체 사슬인 척하지 않았기 때문에 유용했습니다. 그 번호는 행을 이름 지었습니다. 행을 설명하거나, 승인하거나, 설치하거나, 결과를 입증하지 않았습니다. 시스템은 이 겸손을 보존할 때 감사 가능해집니다.

출처