5 min read ietf

IETF 표준화 절차 이야기

IETF 표준화 절차 이야기
Photo by Matthew TenBruggencate / Unsplash

이번 포스트에서는 인터넷 기술 관련 표준화 단체인 IETF (Internet Engineering Task Force)에서의 RFC 표준화 절차에 대해 이야기해보려 한다. 일단, 그에 앞서 표준화 절차의 이해를 돕기 위해 IETF 내부 및 이와 관련된 표준화 기구의 구조에 대해 설명부터 한다.

표준화 기구 구조도

IETF 및 관련 기구
  • IETF
    • WG (Working Group) - 표준화 작업을 진행하는 최소 단위로, 표준화 범위 및 목표를 charter로 작성하고 시작한다. WG 의장 (chairman)이 관리한다.
    • Area - 유사 범위의 WG들을 묶은 그룹으로 각 area 별로 AD (area director)를 둔다.
    • IESG (Internet Engineering Steering Group) - IETF의 표준화 절차를 관리하고 각 WG의 표준화 방향을 조정하는 역할을 담당하며, 각 area의 AD들이 IESG의 위원으로 활동한다.
  • IRTF (Internet Research Task Force) - IETF가 표준화 기구라면, IRTF는 연구 기구이다. IRTF는 IETF에서 하기 어려운 장기 연구 과제를 진행한다. 구조 상 IRSG와 RG는 IETF의 IESG와 WG에 매핑된다. IRTF에서 직접 RFC 문서가 산출되기도 하고, IRTF에서의 RG의 결과물이 성숙해지면 IETF의 WG으로 전환되기도 한다.
  • IAB (Internet Architecture Board) - IETF의 상위 기관으로, IESG 구성원 및 RFC Editor의 선임, IESG의 감독 등을 담당한다.
  • ISOC (Internet Society) - IAB의 상위 기관이다. IESG 및 IAB를 관리 감독하는 역할을 담당하고, IAB 구성원을 선임한다.
  • IANA (Internet Assigned Numbers Authorities) - IETF와 직접적인 연결은 없지만 같은 ISOC의 감독을 받는 기관으로, protocol number나 well-known 서비스의 port number 등 고유 숫자의 할당에 관한 처리를 담당한다.

IETF의 표준화 절차

개인 (personal) draft 제출부터 시작하여 standards track 또는 non-standards track RFC가 되기까지의 절차를 아래 그림에 도시하였다.

IETF 표준화 절차
  • 먼저 개인 draft를 IETF에 제출하는 것부터 시작한다.
  • 그 draft와 관련된 WG에서 메일링 리스트, 정기 meeting 또는 interim meeting 등에서 협의 및 논쟁을 거쳐 WG draft로 받아들여질 수 있도록 WG 구성원들과 합의를 해야 한다. 개인 draft와 WG draft는 파일명에서 구분할 수 있는데, 후자의 경우 draft-ietf--... 으로 시작하고, 개인 draft는 draft-<작성자 이름>-... 으로 시작한다.
  • WG draft의 수준이 어느 정도에 도달됐다고 판단하면, WG 의정은 해당 area의 AD에게 보내기 위해 WG Last Call (WGLC)을 선언한다. WGLC 기간 동안 WG 구성원들의 반대가 없으면 AD에게 전달된다.
  • 여기서 해당 draft가 표준 RFC 문서가 되는지 (standards track) 아니면 비표준 RFC (non-standards track)이 되는지에 따라 경로가 달라진다. 비표준 RFC인 경우 바로 RFC로 출간되며 Informational RFC와 Experimental RFC가 있다.
  • AD는 IETF-wide Last Call (LC)을 선언한다. WGLC나 LC 과정 중에 RFC가 되기에 부족하다고 판단되면 다시 WG 내 논의 절차로 돌아갈 수 있다.
  • LC를 통과한 draft는 RFC Editor에 의해 RFC 번호를 부여받고 proposed standard가 된다.
    최소 2개 이상의 구현체가 있고 구현체 간에 상호운영성 검증이 이루어지면 Draft Standard를 요청할 수 있다.
  • Draft Standard에서 다수의 구현체가 있고 시장에 널리 받아들여지면 Internet Standard를 요청할 수 있다. 전체 RFC 중에 여기까지 온 RFC의 비중은 높지 않다. IP, TCP, UDP, SMTP 등 대부분 인지도가 높은 프로토콜들이 이에 해당된다.
  • Internet Standard가 되기까지 소요되는 시간은 표준마다 천차만별이다. IPv6의 예를 보자. RFC 2460은 1998년에 발행되었지만, Internet Standard인 RFC 8200이 나오기까지 거의 20년의 시간이 걸렸다. 예상보다 IPv6 deployment 진도가 높지 않아서 그런 것이지만, 최종 표준에 이르기까지 많은 경쟁과 도전을 물리쳐야 한다.

참고

— END OF POST.

Published by:

ikpark