RFC (Request for Comments)란?
RFC (Request for Comments)란 미국의 국제 인터넷 표준화기구인 IETF(Internet Engineering Task Force)에서 제공, 관리하는 문서로, 인터넷 개발에 있어서 필요한 기술, 연구 결과, 절차 등을 기술해놓은 메모를 나타낸다. 거의 모든 인터넷 표준은 항상 RFC로 문서화가 되어있으며, 인터넷 개발에 관련된 기술을 연구하거나 알고있는 사람은 누구나 RFC 문서를 작성할 수 있다. RFC 문서가 필요한 단계를 통과하게 되면 IETF에서는 문서에 번호를 붙여주게 되는데, RFC ****의 형식으로 번호가 순서대로 부여된다. 1
RFC의 역사
RFC 형식은 1969년 ARPANET 프로젝트의 일부로 시작되었으며, 이 프로젝트에 대해 공부중이던 미국의 학생들이 자신들이 토론한 것이나 이야기 한 내용들을 어떤 문서에 기록하겠다는 것에서 출발하게 되었다. 첫 RFC 문서는 1969년 4월 7일에 Steve Crocker에 의하여 작성된 Host Software란 제목으로 시작됐다.
RFC의 종류 (Status)
RFC 데이터베이스에서 관련 자료를 검색하게 되면 Status 부분이 나오는데, 이를 RFC 종류 (Status) 라고 한다. RFC 종류에는 대표적으로 아래와 같은 종류가 있으며, 인터넷 표준인 2Internet Standard를 기준으로 RFC를 확인하면 된다.
- 정보 관련(Informational) 상태 : 일반적인 정보 전달을 목적으로 하는 정보성 문서이다.
- 실험 관련(Experimental) 상태 : 진행중인 연구 또는 개발과 관련되어있으며 표준 트랙에 있지 않은 실험적 표준 제안이다. 제안한 내용을 시험을 해보려는 것이 목적이며, 검증이 이루어지면 상위 단계인 표준(Standard) Track 상태가 될 수 있다.
- 역사 관련(Historic) 상태 : 말 그대로 역사적인 면에서 중요한 의미를 갖는다. 인터넷 표준이 되기 위한 필요한 단계를 통과하지 못하거나 최신 규격의 등장 또는 다른 이유로 인하여 쓸모가 없어진 규격을 말한다.
- 표준(Standard) 트랙 상태 : 표준 문서로 인정 받은 상태를 말한다. 이 상태가 되면 오류가 발견되어도 수정이 되지 않고, 다른 RFC 번호를 가진 문서로 새로 출판된다.
- 제안 표준 (Proposed Standard) : 기술적 오류가 없는, 완전한 표준 문서로 인정 받은 첫 단계이다. 시험중인 단계로 계속적인 개정이 필요하다.
- 초안 표준 (Draft Standard) : 적어도 2개 이상의 다른 코드로 구현, 상호운용에 대한 충분한 필드 구현이 되었으나, 더 많은 테스트(필드 경험)가 필요하다.
- 인터넷 표준 (Internet Standard) : 실제 표준안으로써 절대적으로 필요하며 안정적으로 동작되는 것이 확인되었고 성공적으로 구현되어 사용되고 있다.
RFC 표준화 절차 3
RFC 표준화는 아래 그림과 같은 절차로 이루어진다.
일반적으로 표준화는 Internet-Draft(I-D)로 시작하여 인터넷 표준 트랙(Internet Standards Track)을 거쳐서 완성이 되는데, 여기에는 Internet Standard로 시작하는 표준 트랙(Standards track)과 그렇지 않은 비표준트랙(Non-Standards Track)이 있다. 실제로 대부분의 RFC는 표준트랙 보다 비표준트랙인 경우가 많다.
1. Internet-Draft(I-D) 문서 작성 (개인 또는 워킹그룹)
2. Internet-Draft(I-D)에 대한 의견 수렴 & 의견에 따라 문서의 수정 작업
3. 1~2번의 단계를 반복
4. 개인 기고일 경우 개인이, 워킹그룹 기고일 경우 의장이 분야책임자에게 IESG 검토를 요청.
5. IESG의 요청에 맞춘 수정 작업
6. RFC Editor에 의한 발간
- 트랙 진입 전 - Internet Draft
1. Internet Draft 작성
개인, 또는 워킹그룹에서 자유롭게 작성할 수 있으며, 매월 약 300개의 Internet Draft들이 신규 또는 수정되어 등록된다. Draft는 "Internet-Drafts" 디렉토리에 저장되어 누구나 볼 수 있으며, ID Tracker라는 메뉴를 통하여 웹상에서 Draft의 변화를 검색할 수 있다. Internet Draft는 RFC와 같은 양식으로 작성하여 Draft 편집자(IETF)에게 제출하게 되는데, 이름의 양식을 맞춰서 제출해야 한다. 개인이 작성할 경우는 파일명은 "draft-(개인명)"으로 시작하고 00.txt로 끝나며, 워킹그룹에서 작성할 경우 파일명은 "draft-ietf-(워킹그룹명 약어)"로 시작하고 00.txt로 끝난다. 예를 들어 net_study 개인이 작성할 경우 "draft-net_study-keying-00.txt"라는 파일명을 정할 수 있고, net_study 워킹그룹에서 작성할 경우 "draft-ietf-net_study-keying-00.txt"라는 파일명을 정할 수 있다. 문서를 수정했을 경우에는 뒤의 숫자를 증가시켜 01, 02...로 표시한다.
2. Last Call (최종 검토요청)
Internet Drafts 디렉토리의 문서들은 외부의 의견을 수렴하면서 수시로 수정이 가능하다. 만약 어느정도 의견수렴이 마무리됐다고 판단되면, 개인은 최종 수렴, 워킹그룹 의장은 워킹그룹 내에서 최종의견 수렴을 거친 후 해당 분야책임자에게 제출하여 IESG 승인을 요청한다. 만약 IESG의 승인을 받지 못하고 6개월동안 수정없이 남아있을 경우 Internet Drafts 디렉토리에서 삭제된다. ISEG는 제출된 문서에 대해 4전체공지 메일링리스트(IETF Announce)를 통해 LAST Call을 알린다. 이는 해당 문서를 모르고 있던 사람들에게 알려주고, 필요하면 수정하기 위해서다. Last Call 기간은 워킹그룹 문서 2주, 개인 문서 4주이다. Last Call이 끝난 뒤 IESG에서 승인되면 RFC Editor는 편집 후 RFC 번호를 부여하여 발간하게 된다.
여기서 표준 RFC 문서가 되는지, 비표준 RFC 문서가 되는지에 따라 경로가 달라진다. 비표준 RFC일 경우 바로 RFC로 출간되며, Information RFC와 Experimental RFC가 있다.
- 표준 트랙 진입 - Standards Track
표준트랙은 아래와 같은 3단계의 완성 단계로 이루어져 있으며, 표준트랙 상의 모든 단계의 규격을 표준(Standard)으로 통칭한다.
Proposed Standard - Draft Standard - Internet Standard
ISEG는 각 단계마다 수정되는 범위와 중요성을 판단해야하며, 해당 규격에 중요한 변화가 있었다면 새로운 문서를 보고 2단계까지 갔더라도 1단계부터, 즉 Proposed Standard부터 다시 진행시킬 수도 있다. 만약 Internet Standard까지 가지 않고 2단계인 Draft Standard에서 24개월간, 또는 상태가 변경된 후 12개월간 머물러 있을 경우 ISEG는 해당 규격에 대한 표준화 의지, 실용성 등을 검토한 후 그대로 둘지 또는 Historic 상태로 옮길지 결정하며, 이러한 결정은 전체공지를 통해 협의된다.
1. Proposed Standard (제안 표준)
ISEG에서 Internet Standard로의 진행을 결정하면, RFC Editor가 Draft를 Proposed Standard로 발간한다. Proposed Standard의 규격은 일반적으로 안정적이면서 유용성을 인정받은 상태로서 기술적인 오류가 없어야한다. 이 상태로 최소 6개월 후에 작성자, 또는 워킹그룹 의장은 Draft Standard로의 승인을 요청할 수 있다. 이 때 분야책임자는 최소 2건의 개별적인 상호운용성 구현이 있었음을 요청한다. 대부분은 2단계로 가지 않으며 1단계를 유지하는 경우가 많다.
2. Draft Standard (초안 표준)
최소 2건의 서로 다른 코드로 개발된 독립적인 구현체가 있고, 그 구현체 간의 상호운영성 검증이 확인되면 Draft Standard로 진행되며, 일반적으로 최종 규격으로 받아들여진다. 특정 문제를 해결하기 위해서만 수정이 가능하며, 업체들은 주로 Draft Standard를 이용하여 구현하게 된다.
3. Internet Standard (인터넷 표준)
Draft Standard 상태로 몇년 간 지나면 Internet Standard가 될 수 있다. 이 경우는 매우 드문 경우로써 인터넷이 작동하는데 절대적으로 필요한 프로토콜만이 Internet Standard가 될 수 있다. FULL Standard라고도 하며, RFC번호 외에도 STD 일련번호를 받게 된다. 다수의 상호 구현체가 있고 시장에 널리 받아들여지면 요청할 수 있다. 대부분 인지도가 높은 프로토콜들(OSPF, BGP 등)이 이에 해당된다.
- 비-표준 트랙 진입 - Non-Standards Track
Internet Standard로의 진행을 원하지 않거나, 표준트랙에 진입하기에는 준비가 안된 규격 또는 새로운 Internet Standard의 등장으로 폐지가 되거나 사용되지 않는 규격이 비-표준 트랙으로 진입하게 된다.
1. Experimental (실험 관련)
RFC에 관심은 있지만 구현될 경우 어느정도 이익이 있을지 확실하지 않는 규격들이다. 특정 문제의 해결은 가능하나 많은 사람들이 그 문제를 중요하게 여기는지가 확실하지 않으면 RFC Experimental로 분류가 된다. 만약 추후에 대중적으로 이 규격이 확산이 된다면 표준 트랙으로 전환될 수 있다.
2. Informational (정보 관련)
인터넷 사용자들을 위한 일반적인 정보로 보면 된다. IETF에서 합의가 되었거나 권고함을 의미하는 것이 아니다. 특히 5외부에서 개발되어서 IETF의 표준절차에 따르지 않는 규격들은 작성자들의 허가를 받아 RFC Editor의 협조로 Informational RFC로 발간되기도 한다. 많은 사람들이 외부에서 개발된 규격을 IETF 문서에서 참조하고 있지만, Information RFC를 IETF 표준으로 간주하는 사람들이 있어서 논란의 여지가 있다. 절대 IETF 표준이 아니며, RFC에서 참조하는 문서로만 생각하면 된다.
-> Experimental & Informational RFC
Experimental 또는 Informational 발간을 원하는 문서는 RFC Editor에 직접 제출을 하면 Internet-Drafts 디렉토리에 게재하여 2주간 의견을 받는다. 비표준트랙이 인터넷 표준 절차를 앞지르기 위해 오용되는 것을 방지하기 위해, RFC Editor는 제출된 문서와 관련하여 IETF내에서 이미 진행되었거나, 진행될 작업이 이는지 IESG의 검토를 받는다. 만약 워킹그룹에서 이 문서를 제안한 경우에는 ISEG에 바로 제출된다.
3. Historic (역사 관련)
최신 규격의 등장으로 사용하지 않거나, 그 밖의 다른 이유로 인해 쓸모없어진 규격은 Historic 단계가 된다. Historic으로의 요청은 워킹그룹, 분야책임자, 그 밖의 이해집단에서 할 수 있다. ISEG에서 변경을 승인하며 이에 대해 전체 공지한다. 만약 새로운 RFC가 이전 RFC를 대체할 경우에는 신규 RFC에 "Obsoletes : (이전 RFC 번호)"를 표시하여 대체함을 나타낸다. 이 때 이전 RFC는 히스토릭으로의 별도 신청이 없는 이상 "Unknown" 상태로 전환된다.
- 유의할점은 백서, 협력문서, 절차, 유고사항, 시험기록, 정책 뿐안 아니라 시, 만우절 농담등도 RFC로 발간되기 때문에 모든 RFC를 IETF의 표준이라고 볼 수는 없다. [본문으로]
- 아래의 표준화 방법에 전체 종류 (Status)가 나와있다. [본문으로]
- 출처 : https://www.tta.or.kr/data/androReport/standAnal/IETF.pdf [본문으로]
- IESG (Internet Engineering Steering Group) - IETF의 표준화 절차를 관리하고 각 WG의 표준화 방향을 조정하는 역할을 담당하며, 각 area의 AD들이 IESG의 위원으로 활동한다. [본문으로]
- 위에서 언급했지만 만우절 장난, 시 등이 이 Informational에 포함된다. [본문으로]
'네트워크 > All about Network' 카테고리의 다른 글
RFC (Request for Comments) 문서 열람 사이트 - RFC Editor, IETF® Datatracker (0) | 2020.09.13 |
---|---|
WAN - PPP (Point to Point Protocol) & MLPPP, PPPoE (0) | 2020.03.04 |
WAN - HDLC (High level Data Link Control) (0) | 2020.03.03 |
Routing Protocol - BGP (Border Gateway Protocol) (720) | 2020.03.03 |
Routing Protocol - OSPF (Open Shortest Path First) (906) | 2020.03.03 |