요약

  • RFC 3737은 이후 RMON MIB 모듈 루트 할당 책임을 워킹 그룹이 관리하던 목록에서 IANA로 이전했지만, 기존 OID는 그대로 두었습니다.
  • 경계는 좁게 그어졌습니다. IANA는 rmon 아래의 모듈 MODULE-IDENTITY 루트를 할당하고, 모듈 작성자와 편집자는 모듈 내부의 일반 객체 식별자를 할당합니다.

후반 수정이 필요할 때까지 잘 돌아간 레지스트리

원격 모니터링 MIB는 MIB-II 트리의 rmon 노드, 즉 1.3.6.1.2.1.16 아래에 축적되어 있었습니다. RMONMIB 워킹 그룹은 새 모듈 할당 목록을 자체적으로 관리해 왔습니다. RFC 3737은 그 체계를 실패로 규정하지 않았습니다. 오히려 상당히 잘 작동해 왔다고 밝힙니다. 다만 절차 후반에 오류를 수정해야 했고, 일부 할당은 더 이상 사용되지 않게 되었습니다. 또한 이 관행은 표준 트랙 MIB 모듈이 RFC 발행 시점에 루트를 받는 일반적인 경로와 달랐습니다.

RFC의 표는 물려받은 구조를 그대로 드러냅니다. 초기 항목은 statistics, history, alarm, capture 같은 객체 그룹 이름이고, 이후 번호는 MODULE-IDENTITY 루트, 사용 가능 공간, 예약된 값, 그리고 더 이상 사용되지 않는 할당을 식별합니다. 이 트리는 한 종류의 객체로 이루어진 깔끔한 수열이 아니었습니다. RFC 3737은 일부 초기 선택이 논리적이지 않으며 변경할 수 없다고 분명히 말합니다. 그 해결책은 번호를 다시 매기는 작업이 아니라, 이후 결정의 관리 주체를 바꾸는 것이었습니다.

IANA가 받은 것은 루트이지 모듈 전체가 아니다

RFC 3737은 기존 할당 기록을 SMI Numbers 레지스트리로 옮기고 IANA에 그 관리를 맡겼습니다. 이후 IANA는 rmon 아래의 MODULE-IDENTITY 루트만 할당합니다. 모듈 내부에서는 작성자나 편집자가 일반적인 MIB 절차에 따라 일반 OID를 계속 할당합니다. 새 루트는 당시 기준 RFC 2434에 따른 Standards Action이 필요했으며, IANA는 RFC 발행 시점에 번호를 할당했습니다.

이 경계가 중요합니다. 루트는 두 모듈이 충돌할 수 있는 공유 네임스페이스 지점입니다. 모듈이 자체 루트를 갖게 되면, 최상위 RMON 레지스트리에 객체마다 할당을 요청하지 않고도 모듈 안에서 내부 구조를 구성할 수 있습니다. RFC 3737은 충돌에 민감한 경계는 중앙화하면서 모듈 설계는 사양에 맡겼습니다.

이후 IANA SMI Numbers 페이지에는 여전히 rmon 트리가 표시되어 있으며, 참조가 이제 RFC 4502를 가리키는 항목, 사용 가능한 값, 더 이상 사용되지 않는 모듈 항목, 예약된 할당이 포함되어 있습니다. 이는 시점이 기록된 레지스트리 기록이지, 특정 모듈이 구현되었거나 배치되었다는 증거가 아닙니다. 목록에 올라 있는 루트, 구현된 MIB, 실제 모니터링 관측은 서로 다른 증표입니다. RFC 3737은 다음 루트를 기록하는 주체를 바꿨을 뿐, 레지스트리 등재를 동작하는 코드의 증명으로 바꾸지는 않았습니다.

출처