요약

  • BCP 14는MUST를 명세의 절대 요구사항으로 만든다. 이 단어를 명세, 그 규범적 주체, 조건, 적용 범위에서 분리하지 않는다.
  • RFC 8174는 문서가 명시된 상용구로 BCP 14를 활성화했을 때만 전부 대문자인 키워드에 특별한 의미를 부여한다. 소문자 일반 산문은 자동으로 BCP 14 요구사항이 아니다.
  • 자발적 채택과 엄격한 적합성은 양립한다. 운영자는 자발적 표준의 배치 여부를 선택할 수 있지만, 관련 적합성을 주장하는 구현체는 해당되는MUST를 선택 사항으로 다룰 수 없다.
  • 방어 가능한 감사 결과에는 규범 문장 영수증이 필요하다: 문서와 버전, 상태, 섹션, 주체, 트리거, 동작, 예외 경계, 적용 가능성, 적합성 대상, 테스트 증거, 그리고 해당 RFC를 채택한 별도의 문서.

한 칸짜리 결과

구매자가 빨간 칸 하나짜리 보안 평가를 받았다고 상상해 보자. 요구사항 열에는RFC 8200 MUST라고 적혀 있다. 결과에는 “비준수”라고 적혀 있다. 증거 열에는 제품 버전의 스크린샷이 들어 있다. 정확한 문장이나 그것이 다루는 행위자를 식별하는 정보는 없다. 트리거 조건을 보여주는 패킷 캡처도 없다. 테스트된 제품이 문제의 프로필을 노출한다는 구성 정보도 없다. 그 RFC가 이 구매에 왜 의무였는지 설명하는 계약도 없다.

평가자는 최종적으로 옳았을 수도 있다. 문제는 그 행이 그것을 보여주지 못했다는 점이다. 요구사항은 마법의 단어가 아니다. 문서, 행위자, 조건, 동작, 적합성 주장 사이의 관계다. 그 구성 요소 중 하나라도 빠지면, 단언적인 빨간 칸은 표준 문서 서체를 입은 추측으로 변할 수 있다.

이것이 거버넌스 문제인 이유는, 압축된 행이 누가 어떤 권한을 행사했는지 가리기 때문이다. IETF는 기술 텍스트를 작성하고 검토했다. 구현자는 기능 집합을 선택하고 제품 주장을 했다. 운영자는 제품을 구성하고 배치했다. 구매자는 수용 기준을 선택했다. 규제기관이나 계약 당사자는 별도의 권한 아래 RFC를 편입했을 수 있다.MUST만 쓰면 이 서로 다른 결정들이 하나의 보이지 않는 화자 속으로 접혀 버린다.

BCP 14가 실제로 활성화하는 것

RFC 2119는 그 척도에 대해 정확하다.MUST,REQUIRED,SHALL은명세의절대 요구를 뜻한다.MUST NOT과SHALL NOT은 명세의 절대 금지를 뜻한다. 마지막 네 단어는 장식이 아니다. 그 힘이 정의된 기술 문서 안에 위치함을 밝히는 것이다.

같은 문서는 다른 키워드들에 서로 다른 형태를 부여한다.SHOULD는 유효한 예외를 허용하되, 그 함의를 이해하고 저울질할 것을 요구한다.MAY는 진정으로 선택 사항이다. 그 경우에도 옵션의 양쪽에 있는 구현체들은, 옵션이 제공하는 기능을 제외하면 상호운용될 준비가 되어 있어야 한다. BCP 14는 엔지니어링 호환성과 리스크를 위한 어휘이지, 제도적 위상의 척도가 아니다.

RFC 2119는 저자에게도 제한을 둔다. 그 명령형은 상호운용성을 위해 동작이 요구되거나, 피해를 일으킬 수 있어 제약되어야 하는 경우에 신중하고 아껴서 사용해야 한다. 상호운용성이 요구하지 않는 한 하나의 구현 방법을 강제해서는 안 된다. 따라서 이 키워드는 양방향의 부담을 만든다: 구현자는 유효한 요구를 준수해야 하고, 저자는 공통 규칙에 왜 명령적 강제력이 필요한지 정당화해야 한다.

RFC 8174는 또 하나의 함정을 막는다. 정의된 BCP 14 의미를 지니는 것은 전부 대문자인 용례뿐이며, 문서는 해석 상용구를 포함해야 한다. 소문자 “must”는 일상 언어로서 진지한 지시일 수 있다. 다만 어휘만으로는 그것이 특수한 BCP 14 용어로 변환되지 않는다.

따라서 감사자는 동작을 테스트하기 전에 두 가지 활성화 질문을 던져야 한다. 이 문서가 BCP 14를 인용하는가? 인용된 단어가 활성화된 대문자 키워드 중 하나인가? “must”를 포함한 검색 결과는 어느 질문에도 답하지 않는다.

명령형보다 주체를 먼저 찾아라

자연 언어에서 대문자는 시각적으로 두드러지지만, 문법적 주체가 운영적으로 결정적이다. 다음의 가상 문장들 사이의 차이를 생각해 보자:

  • 송신자는 전송 전에 기형 옵션을MUST폐기한다.
  • 수신자는 알 수 없는 선택적 필드를MUST무시한다.
  • 프로필 A를 주장하는 구현체는 진단 카운터를MUST노출한다.
  • 운영자는 확장을 활성화하기 전에 고유한 로컬 값을MUST구성한다.

술어들은 비슷해 보인다. 책임 있는 행위자들은 그렇지 않다. 수신자는 결과 패킷을 처리한다는 이유만으로 송신자 전용 요구를 실패할 수 없다. 프로필 A를 결코 주장하지 않는 라이브러리는 그렇게 주장하는 것처럼 테스트될 수 없다. 구현체 요구가 자동으로 운영자에게 재배정될 수는 없고, 운영적 전제 조건은 소스 코드 검사만으로 증명될 수 없다.

조건도 똑같이 중요하다. “확장 X가 협상되었을 때”는 배경 산문이 아니라 요구를 활성화하는 스위치다. “피어가 Y를 제공하지 않는 한”은 예외 경계를 정의한다. “로컬 링크를 넘어 전달되는 패킷에 한해”는 영역을 좁힌다. 트리거를 생략한 테스트는, 아무것도 할 필요가 없을 때 아무것도 하지 않았다는 것만 증명할 수도 있다.

그래서 인용된 조각은 위험하다. “엄격한 프로필을 협상한 수신자”를 빼고MUST reject만 복사하면, 대상 모집단, 이벤트, 의미가 바뀐다. 단축된 문장은 단어 수준에서 완벽하게 충실하면서도 시스템 수준에서는 거짓일 수 있다.

문서의 상태도 여전히 중요하다

키워드는 그것을 담은 문서의 제도적 상태를 식별하지 않는다.RFC 7841은 독자가 RFC를 어떻게 다루어야 할지 이해할 수 있도록 상태와 검토 맥락을 요구한다. Standards Track, Best Current Practice, 실험적, 정보적 출판물은 각각 대문자 요구를 담을 수 있다는 이유만으로 서로 바꿔 쓸 수 없다.

이 상태 질문이 Standards Track이 아닌 문서의 요구를 무의미하게 만들지는 않는다. 프로토콜 실험은 두 실험적 구현체가 유효한 메시지를 교환하도록 엄격한 규칙을 필요로 할 수 있다. 정보적 형식은 그 형식을 구현하기로 선택한 사람을 위한 필수 필드를 기술할 수 있다. 규칙은 문서가 인터넷 표준이 되지 않거나 모든 네트워크가 채택자가 되지 않아도, 지정된 설계 안에서는 절대적일 수 있다.

현재 기록도 중요하다. 업데이트, 폐기, 정오표는 현재 평가가 무엇을 인용해야 하는지 바꿀 수 있다. 문서 번호에만 고정되고 현재 상태와 분리된 컴플라이언스 행은 잘못된 계보를 테스트할 수 있다. 해결책은 최신 기록을 원격 명령으로 다루는 것이 아니다. 제품, 운영자 또는 외부 문서가 실제로 선택한 명세와 버전을 식별한 뒤 그 선택을 정직하게 평가하는 것이다.

명세 범위와 적용 가능성

RFC 2026은 많은 감사 시트가 지워버리는 구분을 제공한다. 기술 명세(Technical Specification)는 프로토콜, 서비스, 절차, 관례 또는 형식을 기술하고 그 범위와 의도된 영역을 명시한다. 그것만으로는 그 명세가 인터넷 전반에서 사용되어야 하는 상황을 결정하지 않는다. 적용 가능성 진술(Applicability Statement)은 기술 명세가 특정 기능과 시스템 계층에 어떻게, 언제 적용되는지를 다룬다.

이 구분은 두 가지 서로 다른 질문을 만든다. 첫째: 이 시스템이 명명된 명세를 구현하거나 명명된 프로필을 주장한다면, 적용되는 규범 문장을 충족했는가? 둘째: 이 시스템이 그 명세나 프로필을 구현할 의무가 전혀 있었는가?MUST는 첫 질문에는 힘차게 답할 수 있으면서 둘째 질문에 대해서는 아무 말도 하지 않을 수 있다.

둘째 질문은 다른 곳에서 답될 수 있다. 제품 선언이 적합성을 주장할 수 있다. 네트워크 아키텍처가 프로필을 선택할 수 있다. 구매 계약이 RFC 목록을 편입할 수 있다. 유능한 공공기관이 자체 법에 따라 기술 요구를 채택할 수 있다. 각 행위는 결과를 낳을 수 있다. 각각은 고유한 정체성, 범위, 버전, 권한을 필요로 한다.

이 구분을 “자발적”이라고 부르는 것은 “대충”이라는 뜻이 아니다. IETF 명세와 채택 결정이 서로 다른 기록이라는 뜻이다. 구매자가 적합성을 계약 조건으로 만들면, 불이행은 계약적 결과를 낳을 수 있다. 그 결과는 글자의 모양만이 아니라 계약과 그 법적 해석에서 나온다.

자발적 채택과 엄격한 적합성

RFC 3935는 이 경계를 특히 잘 표현한다. IETF 표준은 사실상 이렇게 말한다: 어떤 행위자가 그 표준에 따라 어떤 일을 하고 싶다면, 그렇게 하는 방법은 이것이다. 이 정의는 IETF가 사용을 강제하거나 단속하려 한다는 함의를 지니지 않는다. 그 가치는 같은 규칙을 구현하는 제품들 간의 상호운용성이다.

RFC 6852는 자발적 채택을 현대 표준 패러다임 안에 위치시킨다. 표준은 구현과 배치를 위해 공개되고, 채택은 자발적이며 실용적 성공은 사용을 통해 확립된다.현재 IETF 프로세스 가이드역시 IETF의 산출물을 자발적 표준을 정의하는 기술 문서로 기술한다.

이러한 진술과 엄격한MUST사이에 모순은 없다. 호환성 집합에 들어가는 결정은 자발적일 수 있다. 그 집합의 회원 자격을 정직하게 주장하기 위한 규칙은 정확할 수 있다. 체스 선수는 토너먼트 참가 여부를 선택할 수 있다. 참가한 뒤에는 비숍의 이동 규칙이 제안이 아니다. 벤더는 프로토콜을 구현하지 않기로 선택할 수 있다. 다만 해당되는 절대 요구를 몰래 선택 사항으로 취급하면서 프로토콜 적합성을 광고할 수는 없다.

Lu Heng의Running-Code Primacy는 운영 측면을 날카롭게 한다: 출판은 배치된 현실을 만들어내지 않는다. 구현, 검증, 배치, 사용이 규칙이 작동하는지, 어떤 행위자가 실제로 채택했는지를 드러낸다.Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption의 관련 설계는 공통 규칙이 결정론적 불변식에 묶여 있어야 하고, 이후의 선택이 시스템을 운영하는 참여자들에게 가까이 있어야 한다고 주장한다.

이 관점은 규율을 갖추어 적용해야 한다. 그것이 구현자에게 호환성을 계속 주장하면서 보안 불변식을 무시할 권한을 주는 것은 아니다. 그것은 구현자에게 호환성 주장을 명시적이고 검증 가능하며 경계가 분명하게 만들 것을 요구한다. 채택을 거부하는 것과 적합에 실패하는 것은 서로 다른 사실이다.

규범 문장 영수증

감사 결과는 스프레드시트를 작성한 순간에 참석하지 않은 사람이 재구성할 수 있어야 한다. 최소 영수증이 한 칸보다 긴 이유는, 테스트되는 시스템이 한 단어보다 길기 때문이다.

항목무엇을 증명하는가
문서와 버전평가를 위해 선택된 정확한 텍스트
현재 상태와 계보인용이 현재 유효한지, 업데이트·폐기·정오표의 영향을 받았는지
스트림과 카테고리부풀리지 않은 출판 및 검토 맥락
BCP 14 활성화대문자 키워드가 정의된 의미를 지니는지
섹션과 정확한 문장검색 조각이 아닌 완전한 요구사항
규범적 주체행동해야 하는 송신자, 수신자, 엔드포인트, 구현체, 운영자 또는 기타 행위자
트리거와 사전 조건요구를 활성화하는 이벤트와 상태
요구된 동작테스트 가능한 행동 또는 금지
예외와 복구 경계편차, 강등, 재시도, 실패에 관해 명시된 어떠한 상황
영역과 적합성 대상결과가 적용되는 제품, 프로필, 기능, 환경
테스트와 증거재현 가능한 입력, 구성, 추적, 출력, 기대 결과
배치 정체성실제 평가된 빌드, 버전, 옵션, 운영 상태
외부 채택 문서자발적 적합성 주장 밖에서 명세를 의무화하는 계약, 정책, 법률
소유와 종결누가 시정할 수 있는지, 재테스트가 어떻게 이루어지는지, 결과가 언제 종결되는지

이 영수증은 두 가지 반대 오류를 막는다. 과잉 적용은 감사자가 요구를 범위 밖의 행위자나 제품에 붙일 때 발생한다. 회피는 벤더가 이미 적합성을 주장한 뒤 자발적 채택을 내세울 때 발생한다. 동일한 증거 구조가 양쪽을 모두 구속한다.

압축이 거짓 권위를 만드는 방식

첫 번째 실패는행위자 대체다. 구현체를 위해 작성된 요구가 고객의 운영 의무가 되거나, 송신자에 대한 조건이 수신자의 결함이 된다. 대문자는 살아남고 책임은 이동한다.

두 번째는조건 삭제다. 문장이 협상 후에만, 실패 경로에서만, 또는 특정 프로필 안에서만 적용된다. 감사는 평상 경로를 실행하고 특별 동작의 부재를 위반으로 부른다.

세 번째는상태 대체다. 실험적 또는 정보적 문서의 키워드가 인터넷 전체가 Standards Track 의무를 채택했다는 증거로 제시된다. 기술 규칙은 여전히 유용하고 정확할 수 있다. 제도적 서술이 틀린 것이다.

네 번째는채택 세탁이다. 구매자나 규제기관이 RFC를 선택하면서 기록에는 RFC 요구만 남긴다. 외부 행위자가 사슬에서 사라져, 지역적 결정이 IETF 명령처럼 보인다. 이것은The Multi-Stakeholder Mirage에서 기술된 강제 문제의 축소판이다. 정당한 기술 과정이 실제로 행사한 권한을 넘어 말하게 만드는 것이다.

다섯 번째는서류 적합성이다. 벤더가 테스트 대신 문서 상호 참조를 제시한다. 요구는 정확히 전사되었지만, 출하된 빌드가 무엇을 했는지 보여주는 증거는 없다. 기대 동작의 정밀한 서술이 실제 동작의 증명으로 착각된 것이다.

출처

결론

대문자MUST는 슬로건보다 더 존중받고, 계명보다 더 적은 미신을 받을 자격이 있다. 활성화된 BCP 14 명세 안에서, 명명된 행위자에게 명시된 조건 아래 적용될 때, 그것은 절대적 적합성 요구다. 그 사슬 밖에서, 단어 그 자체는 거의 아무것도 증명하지 못한다.

실용적 규율은 단순하다: 시스템을 판단하기 전에 문장을 복원하라. 주체를 밝혀라. 트리거를 보존하라. 상태와 범위를 식별하라. 선택된 구현체를 테스트하라. 별도의 기관이 RFC를 채택했다면, 그 기관과 그 문서를 밝혀라. 그래야만 빨간 칸이 빌려 온 권위가 아니라 결과가 될 수 있다.