요약

  • RFC 1127은 IETF 호스트 요구사항 그룹이 아키텍처적 순수성보다 상호운용성을 우선하고, 판결된 질문들에 확정된 요구사항 또는 권고를 부여한 과정을 기록한다.
  • 서로 반대되는 입장이 같은 힘으로 MUST와 MUST NOT을 주장할 때, RFC 1122와 1123은 MAY 또는 OPTIONAL을 유지했다. 다른 논쟁적 기능들은 일정한 한도 안에서만 허용되었다.
  • 텍스트 기준의 준수는 소프트웨어를 기술했다. 그것은 설정된 값을, 실행 상태를, 상대(peer)와의 합의를, 응용의 결과를 밝혀주지 않았다.

프로토콜을 정의하는 문서가 아니라 결정을 설명하는 문서

RFC 1127은 서두에서 모호함을 제거한다. 이 문서는 정보성이며, 표준의 수준이 아니고, 프로토콜을 정의하지 않는다. 이 문서는 두 개의 규범적 텍스트, 즉 통신 계층을 다룬RFC 1122와 응용 및 보조 기능을 다룬RFC 1123을 보조한다.

이 보조적 위치가 오히려 고유한 가치를 준다. 이 문서는 선택과 타협과 결정 실패를 규칙으로 꾸미지 않고 서술할 수 있었다.RFC Editor 기록과Datatracker 문서는 문서의 신원을 고정하고, 본문은 커뮤니티에 남겨진 추론의 부담을 그대로 보전한다.

그룹은 매우 활동적인 약 20명의 전문가를 중심으로 구성되었고, 20여 명의 다른 사람들로부터 중요한 기여를 받았으며, 20개월 동안 7회 회의를 열고 약 3메가바이트의 서신을 주고받았으며 약 20개의 버전을 만들었다. 이 양이 결론을 불가침으로 만들지는 않는다. 다만 규범적 동사들이 원하는 아키텍처와 이미 존재하는 소프트웨어 사이의 긴 중재의 결과였음을 보여준다.

첫 번째 의무는 서로 대화할 수 있는 것이었다

다섯 개의 목표가 순위가 매겨졌다. 상호운용성, 확장성, 기능성, 효율성, 아키텍처적 순수성이다. 상호운용성이 지배했고, 순수성은 마지막이었다. 설계를 경시하자는 것이 아니라, 우아한 해법이 기존 설치 기반과의 대화를 깨뜨릴 때 어떤 가치가 물러나야 하는지를 밝힌 것이다.

많은 조항은 이미 문서화되거나 암묵적이던 규칙을 반복했다. 일부 참가자는 이를 “매뉴얼을 읽으라”는 조항이라고 불렀다. 그러나 최소 하나의 구현이 다르게 선택했고 상호운용성, 성능 또는 견고성의 피해가 실제로 발생했기 때문에 이 조항들은 남았다. 그 반복이 실제로 겪은 결함과 연결될 수 있을 때, 규칙의 반복은 유용해졌다.

RFC 1122와 1123은 또한 짧은 목록이 위험하다고 경고한다. 완전한 지침에는 원초 프로토콜, 그 교정, 설명, 맥락이 포함된다. 호스트는 유리한 로컬 네트워크에서는 만족스러워 보일 수 있지만 다양한 인터넷 경로에서는 실패할 수 있다. 이 계약은 선택된 두 대의 기계 사이 시연이 아니라 알려지지 않은 호스트와의 조우를 겨냥했다.

어휘는 합의의 강도를 측정했다

RFC 1122에서 MUST 또는 REQUIRED는 절대적 의무를 뜻한다. SHOULD 또는 RECOMMENDED는 그 결과가 이해되고 신중하게 저울질된 경우에만 예외를 허용한다. MAY 또는 OPTIONAL은 구현 여부를 실제로 선택하게 둔다.

준수 자체에도 수준이 있다. 하나의 MUST를 놓치면 해당 프로토콜의 구현은 비준수가 된다. 모든 해당 MUST와 SHOULD를 충족하면 무조건적 준수가 되고, MUST는 지키지만 모든 SHOULD는 아니면 조건부 준수가 된다. 이 용어들 중 어떤 것도 특정 설치를 인증하지 않는다.

RFC 1127은 이러한 범주가 만들어지는 과정을 보여준다. 정리된 주제에는 확정된 입장이 부여된다. 열린 질문에서는 일부가 MUST 또는 SHOULD를, 다른 일부가 MUST NOT 또는 SHOULD NOT을 비슷한 확신으로 주장한다. 그룹은 그때 논거를 공개하고, 명확한 다수를 흉내 내기를 거부하며, MAY 또는 OPTIONAL로 남긴다. 옵션이라는 표시가 모든 변형의 위험이 같다는 뜻은 아니다. 공통 합의가 더 강한 규칙을 허용하지 않는다는 뜻이다.

타협은 세 번째 부류를 이룬다. 호스트에 의한 전송, 트레일러 캡슐화, 지연 확인, TCP keep-alive, UDP 체크섬의 선택적 생략, 그리고 여러 Telnet 동작은 명확한 범위 안에서 허용되었다. 신중한 기본값이나 스위치가 효과를 제한했다. 논쟁은 여전히 보였다.

설정에는 또 다른 권위가 있었다

가장 중요한 범위의 문장은 소프트웨어 구현을 그 설정과 사용에서 분리한다. 관리상의 요구사항은 지역적 결정에 속한다는 이유로 문서에서 제외되는 경우가 많았다.

RFC 1122는 이유를 설명한다. 완전히 자동 설정 가능한 호스트는 여전히 먼 이상이었다. 한 값은 기계의 크기, 부하, 인접 토폴로지 또는 관리 정책에 달려 있을 수 있었다. 자가 조정 알고리즘이 없는 경우도 있었고, 다른 곳에서는 최선의 값이 여전히 논쟁 중이었다.

가장 곤란한 경우는 부정확한 오래된 소프트웨어, 때로는 소스 없이 배포된 소프트웨어에서 왔다. 그들과 통신하기 위해 관리자는 때때로 올바른 시스템을 “잘못 설정해야” 했다. 본문은 이 필요성을 호환성 부채로 받아들이면서도, 기본값이 공식 프로토콜에 준수하도록 유지할 것을 요구했다. 그렇지 않으면 우회가 표준이 되고 결함의 소멸을 막는다.

따라서 매개변수가 설정 가능하도록 요구하는 것은 가능성을 확립한 것이다. 공급자는 설정 항목을 제공하고 그 효과를 문서화해야 했다. 운영자는 그것을 건드릴지의 결정을 보유했다. 준수 선언은 어떤 값이 작동했는지, 언제 바뀌었는지, 어떤 상대가 그 예외를 정당하는지 말해주지 않는다.

완결되지 않은 것에는 가짜 규칙 대신 이름이 주어졌다

RFC 1127은 미래 작업을 나열한다. 균일한 초기화, 죽은 게이트웨이 감지, 게이트웨이와 MTU 발견, 동적 TTL 선택, 재조립 타이머, TCP 알고리즘의 상호작용, 그리고 여러 응용 문제다. 너무 일반적인 권고, 과도한 트래픽을 낸 폴링 기법, 한 번도 테스트되지 않은 코드도 기록한다.

그럴듯한 MUST를 쓰는 것은 이 결손들을 감췄을 것이다. 실험할 질문으로 공개하는 것은 계약을 개정할 수 있는 여지를 보전했다. RFC 1123은 명세의 속도에 맞춰 자기 소프트웨어를 유지하는 것을 멈춘 공급자는 사용자를 버리게 된다고 덧붙인다. 따라서 준수에는 버전과 날짜가 있다. 그것은 브랜드에 붙는 영원한 자질이 아니다.

종이는 증거 사슬의 시작만 연다

RFC 2119는 나중에 규범적 키워드를 일반화했고, 그RFC Editor 기록은 BCP로서의 역사를 보전한다. 이 공통 어휘는 결코 실행 엔진이 아니었다.

실제 호스트를 이해하려면 명세, 코드 버전, 대상 프로토콜을 식별하고, 누락된 MUST와 SHOULD를 점검하고, 출하 값, 설치 오버라이드, 활성 값을 기록하고, 상대와의 합의를 관찰하고, 마지막으로 응용 결과를 확정해야 한다. 이 각 단계에는 소유자와 타임스탬프가 있다.

1989년의 성과는 첫 번째 부분을 더 선명하게 만든 것이었다. RFC 1127의 신중함은 그것을 마지막 부분으로 여기게 하지 않은 것이었다.

출처