요약

  • RFC 시리즈는 IETF, IAB, IRTF, 독립 제출이라는 네 개의 출판 스트림이 공급하는 하나의 영구 아카이브다. 공유된 번호 체계가 각각의 승인 주체와 심사 절차의 차이를 지우지는 않는다.
  • 스트림과 카테고리는 서로 다른 질문에 답한다. 표준 트랙과 BCP(현재 최선의 실천) RFC를 낼 수 있는 스트림은 IETF 스트림뿐이지만, IETF 스트림은 정보성, 실험적, 역사적 문서도 산출한다.
  • IRTF 또는 독립 제출 문서에 대한 IESG 심사는 본질적으로 IETF 작업과의 충돌 여부 확인이다. 충돌 없음 판정은 문서의 기술적 가치나 배포 적합성에 대한 IETF의 보증이 아니다.
  • 조달, 감사, 아키텍처 또는 공공정책에서 RFC를 인용하는 사람은 출판 수취증을 첨부해야 한다: 스트림, 카테고리, 승인 문구, 심사 범위, 현재 상태, 계보, 적용 범위, 구현 증거, 실제 채택 주체의 신원.

세 개의 기관을 지운 한 칼럼

보증 레지스터에 네 개의 문서가 등록되어 있다고 상상해 보라. 하나는 IETF 스트림을 통해 승인된 표준 트랙 프로토콜이다. 하나는 인터넷 아키텍처 위원회(IAB)의 합의를 기록한다. 하나는 인터넷 리서치 운영 그룹(IRSG)을 통해 출판이 승인된 연구 작업을 보고한다. 하나는 독립 제출 편집자(Independent Submission Editor)가 선정한 문서다. 레지스터는 각각을RFC ####로 기록하고 그 칼럼에 “IETF 표준”이라고 표기한다.

그 번호 안에는 이 표기를 뒷받침하는 어떤 것도 없다. 번호 자체는 중요한 역할을 한다. 독자가 문서와 그 현재 기록을 검색할 수 있는 RFC 시리즈의 안정적 항목을 가리킨다. 그러나 그것은 등록 번호이지, 네 개의 승인 경로를 하나로 압축하는 인장이 아니다.

이 오류가 살아남는 이유는 아카이브의 일관성 때문이다. RFC들은 공통의 표기 관례, 내구성 있는 URL, 익숙한 숫자 형식을 공유한다. 그 일관성은 성과다. 동시에 출처를 간과하기 쉽게 만든다. 정교한 공통 표지는 성급한 독자가 공통의 입법기관을 상정하게 만들 수 있다.

해결책은 RFC를 불신하는 것이 아니다. 시리즈가 이미 제공하는 출판 수취증을 읽는 것이다.

하나의 아카이브, 네 개의 스트림

RFC 8729는 RFC 시리즈를 인터넷 기술 사양의 아카이브 시리즈로 규정한다. 그 내용에는 표준 문서와 인터넷 연구·엔지니어링 커뮤니티의 더 폭넓은 기여물이 포함된다. IETF 문서는 시리즈의 큰 부분을 차지하지만 전부는 아니라고 이 RFC는 밝힌다.

시리즈는 네 개의 스트림을 통해 문서를 받는다.IETF 스트림은 워킹 그룹 문서와 IESG 에어리어 디렉터가 후원한 제출물을 포함한다.IAB 스트림은 IAB 자체 절차에 따라 승인된 문서를 싣는다.IRTF 스트림은 IRSG의 심사를 거친 연구 그룹 작업을 출판한다.독립 제출 스트림은 나머지 세 스트림 바깥의 자료를 위한 경로를 제공한다.

각 스트림은 “누가, 어떤 절차로 이 문서의 출판을 승인했는가?”라는 질문에 답한다. RFC 편집자는 그 결과에 하나의 아카이브적 보금자리를 준다. 공동 보관이 IAB를 소급하여 IETF 워킹 그룹으로 만들거나, IRSG를 IESG로 만들거나, 독립 제출물을 IETF 산출물로 만들지는 않는다.

이것은 유용한 제도적 설계다. 인터넷 아카이브는 연구, 아키텍처 선언, 표준 작업, 이견, 벤더 고유 자료, 역사 기록을, 이 모든 것이 같은 위임을 지닌 것처럼 꾸미지 않고 보존할 수 있다. 유입 지점의 다양성과 보존의 일관성은 유입 라벨이 계속 보일 때만 양립한다.

스트림은 카테고리가 아니다

두 번째 오류는 스트림을 찾은 다음에 시작된다. 독자들은 흔히 “IETF 스트림”을 “인터넷 표준”의 동의어로 취급한다. RFC 7841은 이 구분을 명시한다. RFC 카테고리에는 표준 트랙, 현재 최선의 실천(BCP), 실험적, 정보성, 역사적이 있다. IETF 스트림은 이들 여러 카테고리의 문서를 산출한다.

표준 트랙 또는 BCP RFC를 승인할 수 있는 것은 IETF 스트림뿐이다. 그러나 그 대우명은 성립하지 않는다: IETF 스트림의 모든 RFC가 표준 트랙이나 BCP인 것은 아니며, IESG가 승인한 모든 문서가 인터넷 표준 후보인 것도 아니다.

따라서 스트림과 카테고리는 두 개의 좌표다. 스트림은 제도적 출처와 승인 경로를 식별한다. 카테고리는 문서의 출판 상태나 유형을 기술한다. 어느 좌표 하나만으로는 특정 메커니즘이 현재 유효한지, 어떤 시스템에 적합한지, 벤더가 구현했는지, 계약이 요구하는지, 법으로 집행 가능한지를 알 수 없다.

Status of This Memo절은 장식용 상투문이 아니다. RFC 7841은 이 절이 스트림별 상태를 식별하고 해당 자료가 받은 심사를 기술한다고 말한다. 독자에게 텍스트를 얼마나 넓게, 얼마나 깊이 고려해야 하는지 알려준다. 이를 건너뛰는 것은 판결문을 인용하면서 법원과 절차적 지위를 생략하는 것과 같은 문서적 과오다.

승인은 이름이 밝혀진 커뮤니티에 속한다

IAB 스트림은 “승인됨”이 주어를 필요로 하는 이유를 보여준다. IAB 문서는 IAB의 합의를 대표하고 영구 기록에 남을 만한 가치가 있을 수 있다. 그것은 실제 제도적 선언이다. 그러나 그렇다고 해서 IETF 커뮤니티 합의가 되는 것은 아니며, IAB 스트림 문서가 RFC 번호를 달고 있다는 이유만으로 인터넷 표준 후보가 되는 것도 아니다.

IRTF 스트림은 이 경계를 더욱 일깹게 만든다. RFC 5743은 연구 그룹 문서가 지지 수준과 심사의 폭을 기술하도록 요구한다. 그 문서는 연구 그룹의 합의를 대표할 수도 있고, 그룹이 그럼에도 출판에 동의한 논쟁적 견해를 기록할 수도 있다. IRSG 심사는 편집 심사 위원회처럼 작동하며 기술적 명료성, 편집 품질, 사전 심사의 충분성을 점검한다. 문서는 자신이 IETF 산출물이 아니며 표준이 아니라는 점을 명확히 유지해야 한다.

이러한 공시는 가치의 부인이 아니라 강점이다. 연구는 모든 질문이 표준화 준비를 갖추기 전에 결과와 이견을 출판함으로써 진전된다. 과오는 신중하게 진술된 연구 승인을 다른 기관의 표준 결정으로 확대하는 것이다.

독립 제출물도 심사받지 않은 텍스트의 뒷문이 아니다. RFC 4846은 IETF보다 오래된 전통과, IETF 의제 바깥의 기술 아이디어, 학계와 엔지니어링 사이의 다리 역할, 벤더 고유 프로토콜, 비판, 역사 자료, 기타 기여물을 위해 존재하는 경로를 기술한다.

그곳에서 기술한 구절에서는 RFC 편집자가 심사를 확보했다. RFC 8729는 현재의 독립 제출 편집자 모델을 가리키는데, 이 편집자가 해당 스트림에서 적합성에 관한 판단을 내린다. RFC 편집자에 의한 공동 출판이 그 판단을 IETF 결정으로 바꾸지는 않는다. 독립성은 승인 경로를 식별할 뿐, 판단의 부재를 의미하지 않는다.

충돌 확인은 보증이 아니다

특히 집요하게 남는 오류 하나는 IESG의 역할에 관한 것이다. IRTF와 독립 제출물은 IETF 표준 작업과의 관계를 검토받기 위해 IESG에 보내진다. 메모에서 압축되면 “IESG가 검토했다”처럼 승인처럼 들린다. 이 동사는 심사가 답하도록 요청받은 질문을 감춘다.

RFC 5742는 충돌 검토를 규정한다. IESG는 출판이 기존 또는 예상되는 IETF 활동과 충돌하는지를 고려하고, 관계를 설명하는 주석을 요청할 수 있다. 충돌이 발견되지 않으면, 독립 제출물의 기술적 가치를 판단할 책임은 독립 제출 편집자에게, IRTF 제출물의 책임은 IRSG에 그대로 남는다.

따라서 “충돌 없음”은 좁고 중요한 의미를 지닌다. 다른 스트림들이 출판할 수 있도록 하면서 표준 절차를 유해한 모호성으로부터 보호한다. 그것은 “IETF가 이 설계를 보증한다”, “IETF가 보안 검토를 완료했다”, “IESG가 배포 적합성을 인증한다”를 뜻하지 않는다. 관할권적 통과를 기술적 축복으로 바꾸는 것은 심사자의 권위를 빌리면서 심사의 범위를 버리는 행위다.

거꾸로 된 지름길도 똑같이 틀렸다. IESG가 그 가치를 승인하지 않았다는 이유로 IETF 스트림이 아닌 문서를 무가치한 것으로 치부해서는 안 된다. 훌륭한 연구, 운영 경험, 가치 있는 비판을 담고 있을 수 있다. 올바른 출처 파악은 독자가 거짓 제도적 서열로 문서를 순위 매기는 대신 실제 증거를 평가하도록 돕는다.

번호는 보이는 것보다 적고—또한 더—증명한다

RFC 번호는 승인 도장보다 덜 증명하지만, 성의 없는 인용보다는 더 증명한다. 그것은 영구적이고 편집·색인된 시리즈에 수용된 출판물을 식별한다. 기록은 저자, 날짜, 스트림, 최초 카테고리와 이후 상태 정보, 정오표, 갱신, 폐기 링크를 보존한다.

이 내구성이 중요하다. 엔지니어는 수십 년 뒤에도 같은 텍스트를 인용할 수 있다. 분쟁은 변하기 쉬운 웹페이지가 아니라 안정적 기록에 대비하여 해결될 수 있다. 연구 주장, 아키텍처 입장, 독립적 비판은 표준 트랙 지위가 없다는 이유만으로 사라지지 않는다.

한계도 똑같이 중요하다. 아카이브 수용이 현재의 기술적 적용성을 확립하지는 않는다. 상투문은 최초 상태를 기록할 뿐이며, 나중에 역사적(Historic) 상태로 바뀌어도 옛 문서를 다시 쓸 수는 없다. 독자는 반드시 현재의 RFC 편집자 기록을 확인해야 한다. 관련 절도 식별해야 한다. 하나의 RFC가 규범적 요구사항, 설명 자료, 예시, 범위가 한정된 권고를 섞어 담을 수 있기 때문이다.

출판이 작동하는 코드를 증명하지도 않는다. 표준 트랙 요구사항이 특정 플릿에 배포되지 않을 수 있다. 정보성 RFC가 널리 배포된 시스템을 정확히 기술할 수 있다. 독립 제출물이 이미 사용 중인 독점 프로토콜을 문서화할 수 있다. 스트림과 카테고리는 주장을 정리하고, 구현 증거는 세계를 검증한다.

알맹이 없는 인용이 어떻게 빌린 권위를 얻는가

번호만의 인용은 이동성이 좋다. 조달 팀이 입찰서에 넣는다. 감사인이 통제 항목에 복사한다. 부처가 감사 보고서를 인용한다. 벤더는 절, 옵션, 시험 결과를 밝히지 않고 “RFC 준수”를 마케팅한다. 전달마다 인용의 권위는 커지고 출처와 범위는 줄어든다.

이것은 단순히 의미론적 문제가 아니다. 구매자는 결코 IETF 표준이 아니었던 연구 문서를 근거로 제품을 기각할 수 있다. 규제자는 실험적 메커니즘을 확립된 업계 관행으로 취급할 수 있다. 보안 팀은 IETF 스트림 정보성 문서를 제품이 완전한 IETF 보안 평가를 받았다는 증명으로 받아들일 수 있다. 벤더는 프로토콜을 기술할 뿐 구현의 행동을 확립하지 않는 RFC 번호 뒤에 숨을 수 있다.

이 오류는 대표성도 왜곡한다. 기술 작업에의 개방적 참여는 가치 있지만, 모든 참여자를 인터넷의 영향을 받는 모든 사람의 대리인으로 만들지는 않는다. 대략적 합의(rough consensus)는 상호운용 가능한 사양을 만드는 엔지니어링 방법이지, 보편적 정치적 위임을 부여하는 국민투표가 아니다. 스트림과 승인 주체를 명명하는 것은 기술 기관의 정당한 권한이 하류 사용자들에 의해 팽창되는 것을 막는다.

출판 수취증 만들기

방어 가능한 인용에는 번호의 긴 주문이 아니라 출처에 관한 한 페이지가 필요하다.

문서를 기록하라: RFC 번호, 제목, 날짜, 그리고 근거로 삼는 절.스트림과 이름이 밝혀진 승인 주체를 기록하라.카테고리를 기록하고, 지지와 심사에 관한Status of This Memo의 서술을 인용하거나 정확히 바꿔 쓰라. IRTF 또는 독립 제출물의 경우, IESG의 충돌 검토와 해당 스트림에서 이루어진 가치 판단을 구분하라.

그다음현재성을 기록하라: 현재 상태, 정오표, 그 문서를 갱신하거나 대체하는 후속 문서.범위를 기록하라: 프로토콜 버전, 배포 맥락, 선택 기능, 적용 조건.증거를 기록하라: 상호운용 가능한 구현, 시험, 관찰된 사용, 알려진 한계. 마지막으로채택 권한을 기록하라: 이 설정에서 그 문서를 관련 있는 것으로 만들기로 선택한 운영자, 계약, 규제자 또는 정책 소유자.

이 수취증은 표준을 약화시키지 않는다. 조직이 증거가 뒷받침하는 것보다 더 많이 주장하는 것을 막는다. 그러면 표준 트랙 RFC는 표준 절차 내에서 실제로 지니는 권위로 인용될 수 있다. IRTF 논문은 연구 증거로서 평가받을 수 있다. IAB 선언은 아키텍처적 입장으로 이해될 수 있다. 독립 제출물은 실제 심사와 내용으로 판단될 수 있다.

번호를 인용하기 전에 스트림을 먼저 읽어라

RFC 시리즈는 하나의 표를 갖는 의회가 아니라, 입장이 규율된 도서관이다. 그 힘은 서로 다른 종류의 기술 작업을 그 출처를 지우지 않고 보존하는 데서 나온다.

문서가 정책 또는 보증 레지스터에 나타나면 다섯 가지를 물어라. 어느 스트림이 이를 운반했는가? 카테고리는 무엇인가? 누가, 어떤 목적으로 출판을 승인했는가? 실제로 어떤 심사가 수행되었는가? 아카이브 바깥에서 누가 이 문서가 여기에 적용된다고 결정했는가?

이 답들이 없으면, RFC 번호는 기관을 흉내 내도록 요구받고 있는 것이다. 출판 수취증을 복원하면 번호는 다시 유용해진다: 위조된 위임장이 아니라 증거의 정밀한 주소로.

출처