요약

  • RFC 3359는 충돌을 막기 위해 IS-IS TLV 값의 공통 지도를 공개하면서, 이 문서는 표준도 아니고 번호를 할당하는 권위도 아니라고 명시했다.
  • 이후 RFC 3563은 그 스냅샷을 지정 전문가 심사를 거치는 IANA 임시 관리 레지스트리로 만들었다. 등록은 이름을 조율했을 뿐, 파서 지원, 배포 또는 네트워크 결과를 입증하지 못했다.

두 프로토콜 설계자는 각자 신중하면서도 함께 쓰면 호환되지 않을 수 있다. 각자는 비어 보이는 옥텟을 보고 서로 다른 확장에 배정하고, 자신만의 비공개 표에 따르면 올바르게 동작하는 소프트웨어를 만든다. 두 구현이 만나면 회선에는 하나의 번호가 실리고 수신자들은 두 가지 의미를 제시한다.

이 실패는 형식이 잘못된 패킷에서 시작되지 않는다. 공유 메모리가 없는 이름공간에서 시작된다.

2002년 8월 Informational로 공개된 RFC 3359는 IS-IS Type-Length-Value 요소에 그 메모리를 공급했다. T. Przygienda의 짧은 문서는 프로토콜이 사용 중이거나 대기 중인 것으로 알려진 최상위 값들을 모았다. 각 TLV가 IIH, LSP 또는 SNP 중 어디에 속하는지 보여 주었고, 폭넓은 상태 출처를 제공했다.

그 표는 눈에 띄게 정돈되지 않았는데, 프로토콜의 제도적 역사 자체가 정돈되지 않았기 때문이다. 일부 값은 ISO 10589에서 왔다. 다른 값들은 IS-IS를 IP에 사용한 RFC 1195에서 왔다. 여러 값은 IETF 드래프트에 붙어 있었다. 하나의 DECnet 항목은 'ancient(고대)'로 표시되었다. Lucent와 Nortel의 독점 값들이 공개 작업 옆에 나타났다. 'Used(사용됨)'가 '한 기구가 표준화함'을 의미하지 않았고, 모든 행이 동일한 권위를 지니지도 않았다.

그 혼합된 상태는 작은 글씨 속에 숨겨진 결함이 아니었다. 그것이야말로 목록이 중요한 이유였다. 확장 작업은 여러 곳에서 진행되고 있었는데, 숫자 필드는 하나의 공유 회선 공간으로 남아 있었다. 각 커뮤니티가 자기 문서만 본다면, 어떤 조직도 그 존재를 알기 전에 제도적 경계를 넘어 충돌이 일어날 수 있었다.

RFC 3359는 자신이 할 수 없는 일에 대해 이례적으로 직접적이었다. 문서는 미래의 충돌을 피하기 위해 존재하지만, 표준을 구성하거나 대표하지 않으며 TLV 번호를 할당하는 권위도 아니라고 밝혔다. 할당은 ISO, SIF, IETF 그룹 사이의 공유되는 정보적 방식으로 이루어졌다. ISO는 이 공간에 대한 번호 부여 권한을 제공하지 않았고, 당시 IANA의 책임은 IP 관련 코딩 포인트로 한정된 것으로 기술되었다. 그 메모는 그 시점에 그럴듯한 중앙 권위가 존재하지 않는다고 결론 내렸다.

따라서 그 목록은 공개를 통해 조율했다. 새 확장의 저자는 어떤 값이 이미 점유되었거나 대기 중임을 보고 다른 값을 선택할 수 있었다. 목록이 유용하기 위해 경찰 권한은 필요 없었다. 그 힘은 참여자들이 옥텟에 대한 사적 권리 주장보다 상호운용성을 선호하는 데서 나왔다.

한계는 구체적으로 남았다. RFC 3359는 모든 값 뒤의 구체적 정의 문서를 밝히지 않았다. 서브-TLV 코드포인트를 해결하지도 않았다. 주기적 갱신을 기대했고 공식 레지스트리가 이를 대체할 수 있음을 인정했다. 한 행은 재사용에 대한 경고이지 완전한 출처 기록이 아니었다.

바로 같은 해에 RFC 3232는 Assigned Numbers 카탈로그를 연속되는 RFC로 재출판하던 관행을 온라인 데이터베이스로 대체하며 은퇴시켰다. 살아 있는 레지스트리는 모든 할당마다 새로운 역사 문서를 발행하지 않고도 변경될 수 있었다. 그러나 IS-IS는 추가적인 난제를 제시했다. 그 핵심은 ISO에서 왔고, 인터넷 확장은 IETF를 통해 왔으며, 구현들은 이미 하나의 깨끗한 절차 밖에서 값을 점유하고 있었다.

제도적 수복은 RFC 3563에서 왔다. 2003년에 공개된 이 문서는 ISOC/IETF와 ISO/IEC JTC1/SC6 사이의 협력 합의를 기록했다. 합의는 ISO를 통해 관리되는 핵심 IS-IS 메커니즘과 IETF 범위 안의 인터넷 고유 확장을 구분했다. 또한 JTC1이 레지스트리 서비스를 제공할 때까지 IANA에게 IS-IS TLV 레지스트리를 임시로 관리하도록 요청했다.

'임시'라는 말이 중요하다. RFC 3563은 IANA를 영구적 주권자로 임명하지 않았다. 통지 후 할당 권한을 JTC1로 이전하는 것을 상정했고, IANA는 JTC1에서 갱신된 정보 사본을 유지할 수 있었다. 웹 페이지의 보관, 값을 승인하는 권한, 프로토콜 표준에 대한 책임은 분리 가능한 역할이었다.

새 레지스트리는 소거가 아니라 연속성으로 시작했다. RFC 3563은 초기 상태가 RFC 3359와 동기화되어야 한다고 밝혔다. 비공식 지도는 공식 절차의 종자 증거가 되었다. 새 값은 IESG가 임명한 지정 전문가의 승인을 필요로 했다. IETF는 JTC1/SC6에게 계속 알리고, JTC1/SC6는 자기 구성원의 요청을 IANA 절차로 회부했다.

그 합의가 모든 옛 행을 동등하게 만들지는 않았다. 그것은 미래 할당을 위한 공유된 문을 만들고 그것을 기록할 관리되는 장소를 만들었다. 이후 명세는 여전히 구문과 동작을 정의해야 했다. 소프트웨어는 여전히 구현해야 했다. 운영자는 여전히 활성화해야 했다. 피어는 여전히 교환하고 올바르게 해석해야 했다.

레지스트리 자체는 계속 구조를 쌓았다. RFC 6233은 Purge 열을 추가해 최상위 표가 TLV가 삭제된(purged) LSP에 나타날 수 있는지를 기록하도록 했다. 이것은 장식적 메타데이터가 아니었다. PDU 맥락은 동일한 바이트가 유효한지에 영향을 준다. 따라서 레지스트리 스키마는 프로토콜 해석의 유한한 부분을 담을 수 있고, 정의하는 RFC가 전체 규칙을 유지한다.

2014년 Standards Track으로 공개된 RFC 7370은 표와 그 뒤의 인간 심사를 모두 정제했다. 하나의 이름공간이 의도된 관련 서브-TLV 레지스트리들을 결합하고, 드래프트가 RFC가 되기 전에 요청된 코드포인트에 대해 지정 전문가에게 지침을 제공했다.

그 절차는 단순히 '전문가가 좋아한다'가 아니었다. 요청은 워킹그룹 문서 또는 적합한 그룹이 없을 경우 AD 후원 경로에서 나와야 했다. 전문가는 워킹그룹 합의를 위해 의장과, 승인을 위해 Area Director와 확인해야 했다. 기술적 가치를 심사하되 IETF 합의를 뒤집어서는 안 되었다. 문서가 진전에 실패하면 할당은 만료될 수 있고, RFC 7120과 연관된 조기 할당 규율에 따라 제거될 수 있었다.

이 배열은 심사를 이름공간의 개인적 소유가 아니라 기록된 입력을 가진 필터로 만든다. RFC 8126의 등록 정책 어휘는 이런 필터를 기술하는 데 도움이 된다. Standards Action, Specification Required, Expert Review 등 각 정책은 서로 다른 전제를 요구한다. 그 어느 것도 할당된 기능이 잘 구현되었거나 어디선가 사용되고 있다고 말하지 않는다.

반대 위험은 과도한 마찰이다. RFC 9650은 2024년에 IS-IS 이웃 링크 속성 비트 레지스트리 하나를 Standards Action에서 Expert Review로 변경했다. 이유는 운영적으로 날카로웠다. 더 엄격한 정책이 실험적 프로토콜이 비트를 얻는 것을 막아, 미등록 값을 사용하고 코드포인트 점거로 충돌할 유혹을 높였다. 들어가기 너무 어려운 문은 공유 지도를 덜 완전하게 만들 수 있다.

따라서 지속적인 설계 문제는 중앙집중화 대 자유가 아니다. 그것은 조율을 침묵 속 재사용보다 저렴하고 신뢰할 수 있게 유지하는 일이다. 너무 적은 절차는 충돌을 허용한다. 너무 많은 절차는 실험을 기록 밖으로 내몰 수 있다. 유한한 전문가 심사, 보이는 참조, 만료 규칙이 그 중간을 점유하려 한다.

현재의 IANA 페이지는 그 진화의 살아 있는 결과다. 2002년 표에는 없던 최상위 및 중첩 레지스트리, 적용성 열, 참조, 정책들이 포함되어 있다. 이 글은 그 페이지를 시점이 기록된 출처로 고정한다. 오늘의 모양이 RFC 3359에도 존재했거나 다시는 바뀌지 않으리라고 주장하지 않는다.

가장 중요하게는, 레지스트리의 한 행은 실행되는 코드가 아니다. 그것은 어떤 정책 아래 조율 기록이 값과 이름 및 참조를 연관시킨다는 것을 입증한다. 파서가 그 값을 인식한다는 것, 그 값이 관측된 PDU에서 합법적이라는 것, 두 벤더가 상호운용한다는 것, 운영자가 확장을 활성화했다는 것, 경로가 데이터베이스에 들어갔다는 것, 패킷이 도착했다는 것을 입증하지 않는다.

그것들은 후속 증빙이다. 기능 문서와 적합성 테스트는 구현에 대해 말한다. 구성은 의도된 사용에 대해 말한다. 패킷 캡처는 어떤 값이 한 측정 지점에서 나타났음을 보여 준다. 로그와 데이터베이스 상태는 로컬 처리를 보여 준다. 트래픽 테스트는 결과를 보여 준다. 레지스트리는 이 관찰들을 비교 가능하게 만들 뿐, 그것들을 대체할 수 없다.

Lu Heng의 두 에세이가 여기서 공개된 분석 렌즈로 사용된다. “Minimum Initial Specification”은 최종 제도적 보관권이 정해지기 전에 소박한 공유 표가 왜 가치 있을 수 있었는지 설명하는 데 도움이 된다. “Reality Layers”는 수치 기록, 명세, 구현, 배포, 결과를 구별해 준다. 이것들은 편집적 독해이며, RFC 3359의 저작이나 의도에 대한 주장이 아니다.

RFC 3359에는 할당 권한이 없었다. 그렇다고 무력했던 것은 아니다. 커뮤니티들이 선택하기 전에 하나의 공통 사실을 얻게 해 주었고, 때로는 하나의 공통 사실만으로도 두 개의 올바른 사적 세계가 호환되지 않는 공개 회선을 만드는 것을 막기에 충분하다.

출처