IETF

IETF 는 인터넷을 굴리는 기술 규격을 문서로 만들어 내놓는 공개 공동체입니다. 회사가 대표를 보내는 자리가 아니라 개인이 참여하는 자리입니다. 여기서 합의된 문서가 RFC 라는 이름으로 나옵니다.

상세

동호회를 떠올리면 가깝습니다. 회비도 가입 신청서도 없습니다.

IETF(Internet Engineering Task Force)는 네트워크 설계자·운영자·벤더·연구자로 이루어진 열린 국제 공동체입니다. 인터넷 아키텍처의 진화와 인터넷의 원활한 운영을 위한 기술 명세를 만듭니다. RFC(Request for Comments) 3233 이 이 정의를 조직 관계 문서인 BCP 11(Best Current Practice 11)에서 그대로 가져와 적었습니다. BCP 11 자신은 여기에 한 줄을 더 답니다. IETF 는 새 인터넷 표준 명세를 개발하는 주된 조직이라는 문장입니다. IETF 에 한 번도 참여하지 않은 사람들이 쓰는 장비도 그 명세를 따릅니다.

법인이 아닙니다. RFC 3233 은 IETF 를 등기되지 않은 독립 조직이라고 적습니다. 이사회가 없습니다. 정식으로 서명된 정관이 없습니다. 회계 담당도 없습니다. ISOC(Internet Society)가 일부를 지원하지만 IETF 가 ISOC 의 공식 하위 조직인 것은 아닙니다. ISOC 에 가입해야 IETF 의 일원이 되는 것도 아닙니다.

그러면 무엇이 IETF 인가를 무엇으로 가르느냐가 남습니다. RFC 3233 은 그 답을 이렇게 적습니다. RFC 들이 "the IETF" 라고 적을 때 그것은 BCP 9·BCP 10·BCP 11 에 따라 행동하는 집단을 가리킨다는 것입니다. 정관이 아니라 따르는 문서가 경계를 만듭니다.

회원 자격도 같은 방식입니다. 인터넷 표준 개발 절차와 관련된 모든 목적에서, IETF 와 그 워킹그룹의 회원 자격은 오로지 개인의 참여로만 성립한다고 BCP 11 이 못 박습니다. 참여는 조직의 공식 대표로서가 아니라 개인 기술 기여자로서 합니다. 회의는 1년에 세 번 열립니다.

기술적인 작업은 워킹그룹에서 이루어집니다. 워킹그룹은 주제별로 묶여 여러 영역으로 나뉘고, 각 영역은 영역 책임자가 조율합니다. 라우팅·네트워크 관리·보안 같은 것이 그 영역의 예입니다. 워킹그룹은 대체로 초점이 좁고, 특정 과업을 끝내면 수명이 끝납니다.

배경

무엇을 하려고 모였는지는 문서로 적혀 있습니다. RFC 3935 는 IETF 의 목표를 인터넷이 더 잘 돌아가게 하는 것이라고 적습니다. 그 목표를 위한 사명은 문서를 내놓는 것입니다. 사람들이 인터넷을 설계하고 쓰고 운영하는 방식에 영향을 주는, 품질 높고 시의성 있는 기술·엔지니어링 문서입니다. 그 문서에는 프로토콜 표준, 최선 현행 관행, 여러 종류의 정보 제공 문서가 들어갑니다.

RFC 3935 는 이 사명을 지키는 기본 원칙도 함께 적습니다. 열린 절차, 기술적 역량, 자원봉사 중심, rough consensus and running code, 프로토콜 소유권입니다. rough consensus and running code 는 참여자들의 종합된 엔지니어링 판단과, 자기 명세를 실제로 구현하고 배치해 본 경험에 근거해 표준을 만든다는 뜻입니다. 프로토콜 소유권은 IETF 가 어떤 프로토콜이나 기능의 소유권을 가져오면 그 프로토콜의 모든 측면에 대한 책임을 받아들인다는 뜻입니다.

인터넷 규격을 적는 문서들이 "the IETF" 를 이미 정의된 실체인 것처럼 불러 왔습니다. 정작 IETF 가 무엇인지 제대로 정의한 IETF 문서는 없었습니다. 인터넷 표준화 절차를 설명하는 주 문서인 BCP 9 조차 IETF 를 정의하지 않습니다. RFC 3233 은 이 공백을 스스로 지적하면서, 오늘날 이해되는 대로의 "the IETF" 에 더 구체적인 정의를 준다고 적습니다.

예시

IETF 가 실제로 내놓는 물건은 RFC 한 편입니다. 그 성격은 본문이 아니라 머리글에 박혀 있습니다.

RFC 9110 — 표준 트랙 문서

Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
Request for Comments: 9110                                        Adobe
STD: 97                                                M. Nottingham, Ed.
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235,                   Fastly
           7538, 7615, 7694                              J. Reschke, Ed.
Updates: 3864                                                greenbytes
Category: Standards Track                                     June 2022
ISSN: 2070-1721

                             HTTP Semantics

Category: Standards Track 이 이 문서가 표준 트랙에 올라 있다고 밝힙니다. STD: 97 은 이 문서에 인터넷 표준 번호(STD, Internet Standard)가 붙었다는 뜻입니다. Obsoletes: 줄에 적힌 번호들은 이 문서가 밀어낸 옛 RFC 입니다. 머리글 아래 "Status of This Memo" 절은 이 문서를 IETF 의 산물이라고 적습니다. IETF 커뮤니티의 합의를 담았다는 문장이 뒤에 붙습니다. 공개 검토를 거쳐 IESG(Internet Engineering Steering Group)의 승인을 받아 발행됐다고도 적습니다.

RFC 1958 — 정보 제공 문서

Network Working Group                              B. Carpenter, Editor
Request for Comments: 1958                                          IAB
Category: Informational                                      June 1996

              Architectural Principles of the Internet

같은 RFC 번호 체계를 쓰지만 STD: 도 BCP: 도 없습니다. Category: Informational 뿐입니다. "Status of This Memo" 절도 다르게 적힙니다. 이 메모는 인터넷 커뮤니티에 정보를 제공하며, 어떤 종류의 인터넷 표준도 규정하지 않는다는 문장입니다. RFC 번호가 붙었다는 사실만으로는 그 문서가 표준인지 아닌지 알 수 없습니다. 머리글의 Category: 와 STD: 줄이 그것을 가릅니다.

httpbis 워킹그룹

문서를 만드는 자리도 실물로 남습니다. 데이터트래커에 등록된 httpbis 워킹그룹은 이렇게 적혀 있습니다.

WG name        HTTP
Acronym        httpbis
Area           Web and Internet Transport (WIT)
State          Active
Charter        charter-ietf-httpbis-09 approved
Chairs         Mark Nottingham, Tommy Pauly
Area Director  Mike Bishop

워킹그룹마다 약칭, 소속 영역, 상태, 승인된 헌장, 의장, 영역 책임자가 붙습니다. httpbis 의 헌장은 HTTP(HyperText Transfer Protocol)를 STD 97 과 RFC 9110 으로 정의된 인터넷 표준이라고 적습니다. 캐싱 동작은 RFC 9111 에 있습니다. HTTP 시맨틱스는 여러 판으로 쓰입니다. HTTP/1.1 은 RFC 9112, HTTP/2 는 RFC 9113 입니다.

동작

초안 한 편이 RFC 가 되기까지 정해진 단계를 지납니다. 절차의 정본은 BCP 9, 곧 RFC 2026 입니다.

flowchart TD
    A["Internet-Draft 게시"] --> B{"IESG 의 발행 권고 없이 6개월 그대로인가"}
    B -->|그렇다| C["디렉토리에서 삭제"]
    B -->|아니다| D["영역 책임자를 거쳐 IESG 로"]
    D --> E["IETF Last Call"]
    E --> F["IESG 최종 결정"]
    F -->|승인| G["RFC 편집자가 발행"]

명세를 개발하는 동안 초안 판은 IETF 의 Internet-Drafts 디렉토리에 놓입니다. 비공식 검토와 의견을 받기 위해서입니다. 이 디렉토리는 여러 인터넷 호스트에 복제됩니다. Internet-Draft 에는 공식적인 지위가 없습니다. 언제든 바뀌거나 없어질 수 있습니다. RFC 2026 은 어떤 경우에도 Internet-Draft 를 논문이나 보고서, 제안요청서에서 참조해서는 안 되고, 벤더가 Internet-Draft 준수를 주장해서도 안 된다고 적습니다.

디렉토리에 그냥 쌓이지도 않습니다. RFC 로 발행되거나, IESG 가 발행을 권고하지 않은 채 6개월 넘게 그대로 있으면 디렉토리에서 삭제됩니다. 같은 명세의 더 최근 판으로 갈아 끼우면 6개월 시계가 다시 시작합니다.

표준 트랙에 들어가거나 그 안에서 올라가려는 명세는 먼저 Internet-Draft 로 게시돼야 합니다. 유용한 커뮤니티 검토가 가능하도록 2주 이상 그 상태로 남아 있어야 합니다. 그 뒤에 조치를 권고할 수 있습니다. 표준 조치는 그 명세를 맡은 워킹그룹이 담당 영역 책임자에게 권고하는 것으로 시작합니다. 사무국에 사본이 갑니다. 워킹그룹에 붙어 있지 않은 명세라면 개인이 IESG 에 권고합니다.

IESG 는 제출된 명세가 권고된 조치의 기준을 충족하는지 판정합니다. 그 전에 IETF 전체에 심의가 걸려 있음을 알립니다. 인터넷 커뮤니티 전체가 마지막으로 검토할 기회를 주기 위해서입니다. 이 통지가 last call 이고, IETF Announce 메일링 리스트로 전자우편으로 나갑니다. last call 에 대한 의견은 누구에게서든 받습니다. 기간은 2주보다 짧을 수 없습니다. 표준 조치를 워킹그룹이 발의하지 않은 경우에는 4주보다 짧을 수 없습니다.

last call 기간이 끝나면 IESG 가 승인 여부를 최종 결정합니다. 결정은 다시 IETF Announce 메일링 리스트로 통지됩니다. 승인되면 RFC 편집자에게 통지가 가고 그 명세를 RFC 로 발행하라는 지시가 함께 갑니다. 그 시점에 명세는 Internet-Drafts 디렉토리에서 빠집니다.

표준 트랙 위의 성숙 단계는 한 번 줄었습니다. RFC 6410 이 RFC 2026 의 표준화 절차를 고쳐 성숙 단계를 셋에서 둘로 줄였습니다.

사다리	단계
RFC 2026	Proposed Standard · Draft Standard · Standard
RFC 6410	Proposed Standard · Internet Standard

RFC 6410 은 그 이유를 이렇게 적습니다. 최근 몇 년 사이 IETF 는 문서를 성숙 단계 위로 올리는 데 어려움을 겪었습니다. 2010년 7월 IETF 78 의 총회 논의에서 3단 사다리를 2단으로 옮기자는 지지가 뚜렷했습니다. 새로 생긴 Internet Standard 는 RFC 2026 의 Draft Standard 와 Standard 를 합친 것입니다. 이 이름을 고른 것은 "Draft Standard" 와 "Internet-Draft" 사이의 혼동을 피하기 위해서입니다. Proposed Standard 에서 Internet Standard 로 올라가는 것은 IESG 가 최소 4주의 IETF 전체 last call 로 확인합니다.

상세

배경

예시

RFC 9110 — 표준 트랙 문서

RFC 1958 — 정보 제공 문서

httpbis 워킹그룹

동작

관련 항목

문서의 종류

IETF 표준화에 관여하는 역할·기구

표준화 과정에서 벌어지는 활동

영역이 다루는 주제

IETF가 지키는 원칙

IETF의 정체성과 절차를 못박은 문서

예시로 삼은 실제 RFC 번호

IETF와 헷갈리는 이웃

IETF가 표준화한 프로토콜·규격