요약

  • RFC 6709는 '루틴'을 패치의 줄 수가 아니라 프로토콜 동작과 호환성의 기준으로 삼았다. 기존 구현은 확장을 안전하게 무시할 수 있어야 했고, 기반 프로토콜, 그 전제 또는 배포된 소프트웨어가 변경되어야 한다면 와이어 포맷이 거의 그대로라도 작업은 주요(major) 규모가 될 수 있었다.
  • 루틴 지위가 전문가 검토의 필요성을 자동으로 없애지는 않았다. RFC 6709는 검토가 적은 절차는 제한적으로 사용해야 하며 루틴 확장도 전문가의 도움을 받을 수 있다고 말하고, RFC 4775는 별도로 새 RADIUS 속성에 아키텍처 검토가 필요한 이유를 설명한다.

두 번째 결정을 숨긴 한 단어

표준화 논의는 한 호흡에 서로 다른 두 질문을 던질 수 있다. 이 확장이 프로토콜과 이미 그 프로토콜을 사용하는 시스템에 무엇을 할 것인가? 그리고 이 제안이 다른 이들이 의존하기 전에 어떤 검토를 받아야 하는가? '루틴'이라는 단어는 둘 다에 답하는 것처럼 보여 매력적이다. RFC 6709는 왜 그럴 수 없는지 보여준다.

인터넷 아키텍처 위원회(IAB)는 2012년 9월 RFC 6709를 정보(Informational) 문서로 공개했다. 이 문서는 기반 프로토콜과 확장의 설계자들이 아키텍처를 고민하도록 돕기 위한 것이었다. 문서는 확장이 프로토콜의 진화를 쉽게 만들 수 있지만 상호운용성, 운영, 보안 문제를 낳을 수도 있다고 말한다. 루틴 대 주요(major)라는 문서의 핵심 구분은 제안의 예상 영향을 필요한 검토의 강도와 연결한다. 이는 설계 지침이지 인터넷 표준도 승인의 보편 규칙도 아니다.

이 RFC는 더 오래된 논쟁 속에 자신을 위치시킨다. 확장 비용에 대한 이전 경고로 1991년 'TCP Extensions Considered Harmful' 메모인 RFC 1263을 지목한다. 그 메모 자체가 하나의 역사적 논거다. RFC 6709는 TCP 버전 경계 논쟁을 다시 열지 않는다. 확장에 대한 일반적 설계 고려사항이 이전에 함께 문서화된 적이 없었다고 말할 뿐이다. RFC 4775는 2006년 BCP 125로 공개되어 IETF 프로토콜 확장에 대한 절차적 지침을 제공했다. RFC 6709는 그런 작업에 반영되어야 할 아키텍처 기준을 서술하는 데 나섰다.

주요(major)는 패킷 크기가 아니라 결과에 관한 것이었다

RFC 6709는 설계자가 살펴야 할 여덟 가지 영향을 제시한다. 기반 프로토콜의 구현을 변경해야 하는가? 제안이 상태 없음을 지향하는 프로토콜에 세션 상태를 요구하는 것 같은 아키텍처 전제를 바꾸는가? 기존 시스템이 감당할 수 있는 수준을 넘어 트래픽, 패킷 크기, 처리 부하를 늘릴 새로운 용도나 규모를 도입하는가? 기반 프로토콜이 실제로 정의한 확장 모델에 부합하는가? 구문을 바꾸거나, 프로토콜 간 확장을 결합하거나, 보안 모델을 바꾸거나, 기존 배포의 성능에 영향을 주는가?

이 중 어떤 것도 작업을 주요(major) 범주로 밀어넣을 수 있다. 새 메시지 유형이나 전송 방식은 새 기능을 원하지 않는 배포된 구현까지 갱신을 요구할 수 있다. 변경이 와이어의 바이트를 그대로 두면서도 오래된 알고리즘을 압박하는 규모를 가져올 수 있다. 미지 확장에 대한 안전한 처리를 정의하지 않는 기반 프로토콜은 겉보기에 사소한 제안을 기본적으로 주요(major)로 만들 수 있다. 이들은 RFC 6709의 설계 기준이며 수치 점수도, 어떤 현재 제품에 대한 판정도 아니다.

근본 질문은 누가 변경해야 하며, 변경하지 않는 모든 이에게 무슨 일이 일어나는가이다. 수정의 크기는 나쁜 대리 지표다. 짧은 필드 하나가 수신자의 메시지 해석 방식을 바꿀 수 있고, 더 큰 벤더 정의 값은 기반 프로토콜에 보이지 않을 수도 있다. RFC 6709의 용어로는 첫 번째가 주요(major)일 수 있고 두 번째가 루틴일 수 있으나, 실제 호환성 조건이 충족될 때만 그렇다.

루틴에는 엄격한 경계가 있었다

확장은 주요(major) 기준에 해당하지 않고 기반 프로토콜에 대해 불투명하게 유지된다면 루틴으로 볼 수 있었다. 메시지와 응답의 패턴을 실질적으로 바꾸지 않아야 한다. 기반 명세와 이미 배포된 구현은 확장 사용을 선택한 시스템을 제외하고는 변경이 필요 없어야 한다. 기존 구현은 달리 영향을 받지 않아야 하며, 일반적으로 부작용 없이 확장을 무시하면 된다.

RFC 6709는 DHCP 벤더별 옵션, RADIUS 벤더별 속성(Vendor-Specific Attributes), 관리 정보 모듈의 엔터프라이즈 객체 식별자, 벤더 MIME 타입을 예로 든다. 핵심은 이들이 작은 추가물이라는 것이 아니다. 핵심은 확장이 비참여자가 해야 할 일을 바꾸지 않으면서 기반 프로토콜이 마련해 둔 공간에 들어맞을 수 있다는 점이다.

같은 단락은 흔한 오독을 막는다. RFC 6709는 최소 또는 무검토—예컨대 First Come First Served 할당—로 운영되는 루틴 확장 메커니즘은 절약해서 사용해야 한다고 말한다. 상호운용성, 보안, 운영 노출을 일으킬 가능성이 낮은 사례로 한정하라고 제시한다. 그러면서도 루틴 확장조차 전문가의 도움을 받을 수 있다고 덧붙인다. 불투명한 DHCP 값도 데이터가 구조화되지 않으면 클라이언트와 서버가 처리하기 불필요하게 어려울 수 있다.

RADIUS는 두 질문이 왜 분리되어야 하는지 보여준다

동반 문서 RFC 4775는 이 구분을 구체적으로 만든다. 명확한 기존 명세 아래의 루틴 IANA 파라미터 할당은 좁은 절차적 사례로 취급하고, 그 밖의 모든 것은 IETF 전문가의 명시적 프로토콜 검토를 요구한다. 또한 새 RADIUS 속성 제안은 프로토콜의 아키텍처와 기존 용도를 이해하는 사람들과 논의해야 하며, 그 논의 없이 속성을 추가하면 상호운용성이나 기능상 위험이 생긴다고 말한다.

RFC 6709 자신도 RADIUS 벤더별 속성을 루틴 확장성의 예로 든다. 이는 RFC 4775와 모순되지 않는다. 두 라벨은 서로 다른 질문에 답한다. '루틴'은 확장이 아키텍처에 부합하고 사용하지 않는 시스템이 안전하게 무시할 수 있는지를 묻는다. RFC 4775는 제안을 어떤 절차와 전문성이 지배해야 하는지를 묻는다. RFC 6709는 확장이 루틴 기준을 통과한 뒤에도 전문가 검토의 여지를 명시적으로 남긴다.

이 분리가 중요한 이유는 등록이나 공개만으로 확장이 무해하거나 구현되었거나 채택되었다는 것이 확립되지 않기 때문이다. 검토 경로는 제안이 진행되기 전에 문제를 찾아낼 수 있다. 실제 구현의 시험 대신이나 운영자가 배포했다는 증거의 대신이 될 수는 없다.

하나의 라벨이 아니라 세 개의 근거

따라서 유용한 검토 기록은 세 가지 질문을 모두 보이게 유지한다. 첫째, 확장은 기반 프로토콜, 그 전제, 메시지 동작, 자원 요구에서 무엇을 바꾸는가? 둘째, 옵트인하지 않는 기존 구현은 이를 안전하게 무시할 수 있는가? 셋째, 앞의 두 답을 근거로 어떤 수준의 프로토콜, 보안, 운영 검토가 정당한가?

제안이 기존 소프트웨어의 변경을 요구하거나, 메시지 순서를 바꾸거나, 상태를 더하거나, 프로토콜 경계를 넘거나, 보안 전제를 흔든다면 루틴으로 취급하려면 더 강한 설명이 필요하다. 변경이 진정으로 불투명하고 비참여자가 영향을 받지 않는다면 루틴 분류를 지지하지만 전문가 검토를 금하지는 않는다. 시험 사례는 여전히 구현의 동작을 보여야 하고, 등록된 값이 배포된 경로가 그 값을 올바르게 전달한다는 증거는 아니다.

RFC 6709는 또한 프로토콜이 태생적으로 합리적으로 필요로 하는 수준을 넘는 확장성을 설계하지 말라고 경고한다. 미래의 용도는 알 수 없다고 지적하면서도, 초기 설계가 모든 가능한 수요를 예측해야 하는 것은 아니라고 말한다. 이는 절제된 규칙과 양립한다. 변경을 위한 안전한 자리를 남기되, 모든 이후 용도가 그 자리에 들어말 것처럼 꾸미지 말라는 것이다.

기록이 보여주는 것과 보여주지 않는 것

RFC 6709는 구현에 대한 실증적 조사가 아니라 확장 설계에 대한 IAB의 접근을 문서화한다. RFC 4775는 절차를 기록하며, 모든 제안에 그 절차가 지켜졌다는 증명이 아니다. 출처들은 문서들이 명시한 기준과 경고를 확립한다. 얼마나 많은 확장이 배포되었는지, 특정 네트워크가 하나를 채택했는지, 특정 확장이 사고를 일으켰는지는 보여주지 않는다.

Lu Heng의 노트 64는 별도의 편집적 렌즈를 제공한다. 상호운용성에 필요한 공통 규칙만 정의하고, 이후의 선택은 가능한 한 참여자에게 남기며, 변경을 구현과 채택을 통해 운영적으로 실재하는 것으로 다루자는 것이다. 이는 이후의 BTW 해석이지 IAB의 의도에 대한 진술이 아니다. 그 렌즈에서 '루틴'은 호환성 경계를 서술한다. 공개, 레지스트리 항목, 검토 결과를 채택의 증명으로 바꾸지 않는다.

RFC 6709의 역사적 가치는 회피하기 어려운 질문을 제기한 데 있다. 기존 시스템이 이 확장을 안전하게 무시할 수 있는가, 아니면 변경을 요구받고 있는가? 그 답이 명확해지면 검토 절차는 의도적으로 선택할 수 있다. 루틴은 무해함의 축약어가 아니고, 주요(major)는 얼마나 많은 줄이 쓰였는지에 대한 판정이 아니다.

출처