요약

  • RFC 1264는 라우팅 표준이 명세 품질, 관리 가능성, 보안 설계, 독립 구현, 기능 테스트, 운영 경험, 확장 한계에 대해 서로 구분되는 근거를 갖추도록 요구했습니다.
  • RFC 4794는 2006년에 이 라우팅 전용 보편 체크리스트가 적시 출판을 저해한다는 이유로 이를 폐기했습니다. 다만 IESG가 근거를 요구할 수 있는 권한과 워킹 그룹이 자체 절차를 유지할 수 있는 선택권은 유지했습니다.
  • 이후의 프로세스 문서들도 상태와 실행을 계속 분리했습니다. RFC 6410은 인터넷 표준의 성숙도를 독립적인 상호운용성, 광범위한 배포, 성공적인 운영에 연결했고, RFC 7942는 구현 현황 보고를 유용하지만 자발적이며 독립적으로 검증되지 않는 것으로 만들었습니다.

근거 서랍을 갖고 들어온 라우팅 문서

RFC 1264는 라우팅 프로토콜을 분산 실시간 시스템으로 보았습니다. 그 약점은 단일 실험실에서는 보이지 않을 수 있었습니다. 하나의 구현이 한 토폴로지에서 잘 작동하다가도, 다른 코드베이스가 코너 케이스를 다르게 해석하면 실패할 수 있었습니다. 프로토콜이 오늘의 네트워크 규모에서는 안정적으로 보이다가 예상치 못한 한계에서 무너질 수도 있었습니다.

해답은 단일 인증서가 아니었습니다. 서로 분리된 기록들의 서랍장이었습니다. 한 서랍에는 프로토콜과 사용 명세가 들어갔습니다. 다른 서랍에는 원격 관리에 필요한 관리 정보 베이스(MIB)가, 세 번째에는 보안 아키텍처가 들어갔습니다. 그 밖의 서랍에는 구현의 기원, 테스트 시나리오, 테스트 결과, 운영 환경, 확장성 분석이 들어갔습니다.

이것이 중요했던 이유는 각 기록이 서로 다른 질문에 답하기 때문입니다. 읽기 쉬운 명세는 외부인이 설계를 재현할 수 있음을 보여줍니다. MIB는 운영자가 관찰 가능하고 제어 가능한 상태를 정의했음을 보여줍니다. 보안 아키텍처는 의도된 보호를 설명합니다. 그러나 어느 것도 두 구현이 경로를 교환했는지, 인증이 작동했는지, 프로토콜이 운영 토폴로지에서 생존했는지를 증명하지 않습니다.

독립성은 기원에 대한 주장이었다

RFC 1264는 일반적으로 다수의 상호운용 가능한 구현, 그중 최소 두 개는 독립적으로 작성된 구현을 요구했습니다. '독립적'이라는 수식어가 근거의 성격을 바꿨습니다. 하나의 코드베이스에서 파생된 두 바이너리는 같은 해석과 같은 결함을 반복할 수 있습니다. 독립적인 기원은 문서 자체가 충분한 의미를 담고 있는지에 대한 더 엄격한 시험이 되었습니다.

따라서 구현 목록은 코드의 기원을 기록해야 했습니다. 테스트 보고서는 시나리오와 결과를 식별해야 했습니다. Draft Standard로 진급하려면 보안 기능을 포함한 모든 기능이 최소 두 구현 사이에서 동작해야 했습니다. 이 문서는 구현 개수가 기능 커버리지를 대신할 수 없도록 했습니다.

그마저도 경계가 있었습니다. 테스트 환경에서의 성공적인 교환은 그 버전, 입력, 조건에서의 동작을 보여줄 뿐입니다. 규모에 따른 다중 벤더 운영, 모든 공격에 대한 저항, 사용자를 위한 신뢰할 수 있는 서비스를 증명하지 않습니다. 구현, 상호운용, 보안 입증, 결과는 여전히 별개의 사실이었습니다.

운영 경험에는 형태가 있었다

RFC 1264는 '운영 경험'이라는 표현을 좌표 없이 받아들이지 않았습니다. 보고서에는 토폴로지, 환경, 시점, 기간, 구현, 전반적 결과, 결론이 포함되어야 했습니다. 중요한 기능은 실제로 실행되어야 했습니다. 외부(exterior) 프로토콜은 전체 외부 경로 집합을 다루어야 했고, 내부(interior) 프로토콜은 다른 메커니즘이 그 역할을 하지 않는 한 내부 경로와 외부 경로를 모두 다루어야 했습니다.

부담은 성숙도에 따라 달라졌습니다. Proposed Standard는 구현과 주요 기능이 테스트되었다는 근거가 필요했지만 운영 경험은 요구되지 않았습니다. Draft Standard는 운영 인터넷의 일부인 중간 규모 라우터 모수와 중간 복잡도 토폴로지에서의 유의미한 경험을 요구했습니다. Full Standard는 대규모 라우터 모수, 복잡한 토폴로지, 다중 벤더 운영을 요구했습니다.

이 기준들은 요구사항이었지 역사적 판정이 아니었습니다. RFC 1264는 모든 후보가 이를 충족했다고 인증하지 않았습니다. 표준화 조치와 그 밑바탕의 구현 보고서는 각자의 식별자, 날짜, 범위를 갖고 있어야 했습니다.

두 번째 보고서는 프로토콜이 어디서 무너지는지 물었다

이 체크리스트에서 가장 특이한 부분은 상호운용성 개수가 아니라 두 번째 보고서였습니다. 프로토콜의 핵심 알고리즘이 설명되어야 했고, 정상 조건에서의 대역폭·메모리·CPU 사용이 검토되어야 했으며, 최소 한 자릿수(10배) 이상 더 큰 규모에서의 성장이 모델링되어야 했고, 한계와 부적합한 환경이 명시되어야 했습니다.

이로써 적용 가능성은 성숙도의 일부가 되었습니다. 프로토콜은 단순히 '확장 가능하다'는 것이 아니라, 특정 가정 아래에서 특정 자원을 소비하며 경계 조건을 가진 것이었습니다. 기존 라우팅 프로토콜과의 비교는 주장된 개선점을 검사 가능하게 만들었습니다.

그러나 분석은 여전히 관찰이 아니었습니다. 확장성 모델은 설계자가 실패를 예상하는 지점을 말할 수 있습니다. 테스트는 그 경계에 다가갈 수 있습니다. 실제 네트워크는 다른 경계에 부딪힐 수 있습니다. 모델, 실험, 운영을 분리해 두면 예측이 배포 영수증으로 변질되는 것을 막을 수 있었습니다.

2006년, 적시성이 통제 지점을 바꿨다

RFC 4794는 2006년 12월에 RFC 1264를 Historic으로 선언했습니다. 그 논거는 제도적 것이었습니다. 한 부류의 프로토콜에 일괄적으로 추가 절차를 부과하면 출판이 느려지는데, 일반 표준화 절차와 다른 압력들이 이미 불합리한 설계를 제약하고 있었다는 것입니다. 문제는 라우팅이 단순해졌다는 것이 아니었습니다.

폐기는 정밀하게 이루어졌습니다. RFC 4794는 모든 라우팅 문서에 적용되던 포괄적 요구를 없앴습니다. 동시에 라우팅 영역 디렉터(Area Director)가 여전히 RFC 2026에 따라 구현이나 운영 경험을 요구할 수 있고, 워킹 그룹이 유용하다고 판단하면 RFC 1264 기반 절차를 계속할 수 있다고 명시했습니다. 관리 가능성과 보안은 더 넓은 정책 아래에서 계속 관심사로 남았습니다.

따라서 권한이 이동했습니다. 모든 사례의 최소 근거를 하나의 의무적 라우팅 체크리스트가 결정하던 대신, IESG와 워킹 그룹이 요구 수준을 조정할 수 있게 되었습니다. 이는 재량과 적시성을 개선했습니다. 동시에 결정 기록의 중요성을 높였습니다. 이제 독자는 누가 어떤 근거를 어떤 리스크에 대해 요구했는지, 그리고 사용 가능한 기록이 충분하다고 판단된 이유가 무엇인지 알아야 했습니다.

일반 절차는 상태를 배포로 축소하지 않았다

RFC 2026은 이미 첫 성숙도 수준과 이후의 운영 신뢰를 구분하고 있었습니다. Proposed Standard는 원칙적으로 구현도 운영도 요구하지 않았지만, IESG는 핵심 프로토콜이나 운영 영향이 큰 동작에 대해서는 이를 요구할 수 있었습니다. 구현자에게는 Proposed Standard를 미성숙한 것으로 다루고 검증과 학습을 위해 구현을 사용하라는 경고가 주어졌습니다.

RFC 6410은 이후 사다리를 세 수준에서 두 수준으로 줄였습니다. 그러나 더 높은 근거 부담을 지우지는 않았습니다. 인터넷 표준 기준에는 오류 정정(errata), 미사용 기능, 라이선스 점검과 함께, 광범위하게 배포되고 성공적인 운영 경험을 가진 최소 두 개의 독립적이고 상호운용하는 구현이 포함되었습니다.

'광범위한 배포'조차 보편적인 서비스 결과가 아니라 하나의 범주입니다. 여기에는 모수, 버전, 시간 창, 관찰이 필요합니다. 프로토콜이 광범위하게 배포되었더라도 특정 네트워크는 이를 활성화하지 않았을 수 있고, 기능이 사용되지 않을 수 있으며, 운영자는 다른 결과를 겪을 수 있습니다.

더 가벼운 구현 기록에는 자체 경고가 있었다

RFC 7942는 인터넷 드래프트에 '구현 현황(Implementation Status)' 섹션을 모범 현재 관행(Best Current Practice)으로 만들었습니다. 이 섹션은 구현의 성숙도, 라이선스, 경험, 연락처, 상호운용성 보고를 나열할 수 있었습니다. 그 이점은 조기 피드백이었습니다. 실행 중인 코드는 명세가 이해하기 쉽고 구현할 만큼 흥미로운지를 드러낼 수 있었습니다.

이 절차는 자발적이었습니다. 표준 서식 문구에는 또한 기여자가 제공한 목록이 IETF의 보증이 아니며, 반드시 독립적으로 검증된 것도 아니고, 사용 가능한 구현이나 기능의 카탈로그도 아니라고 명시되어 있었습니다. 저자는 독자가 항목에서 추론할 수 있는 모든 주장을 증명하지 않고도 구현을 보고할 수 있었습니다.

이것은 절차 속에 숨겨진 약점이 아니었습니다. 선언된 기원(provenance) 경계였습니다. 구현 섹션은 결정을 지원할 수 있지만, 테스트 아티팩트, 운영 텔레메트리, 배포 근거를 대체하지 않습니다.

출처와 근거의 한계

1991년 체크리스트와 단계별 요구사항은RFC 1264에서 나옵니다. 일반 표준화 권한은RFC 2026에서 나옵니다. 라우팅 전용 체크리스트의 폐기는RFC 4794에서 나옵니다. 두 수준 성숙도 모델은RFC 6410에서, 자발적 구현 현황 기록은RFC 7942에서 나옵니다.

이 출처들은 발표된 절차, 기준, 그 절차를 변경한 이유를 확립합니다. 그러나 어떤 특정 라우팅 프로토콜이 RFC 1264를 충족했는지, 나열된 구현이 독립적으로 검증되었는지, 특정 운영자가 기능을 배포했는지, 사용자가 어떤 결과를 얻었는지는 확립하지 않습니다. Historic 상태는 절차에 대한 결정을 기록할 뿐, 과거의 근거를 지우거나 과거의 주장이 거짓임을 증명하지 않습니다.