IETF 組織結構
與
Internet 標準產生流程
楊禎葆
82nd IETF
台北，台灣
Agenda









IETF 歷史與簡介
IETF 角色與範圍
IETF 組織結構與相關組織
IETF 管理與事務
IETF 工作進展與程序
工作小組
文件
智慧財產權問題
其他
IETF 歷史與簡介

IETF (Internet Engineering Task Force) 成立於
1986 年
由
ARPANET 計劃相關活動而來
 成立後很長一段時間不被重視 – Great !
 沒有被任何政府相關組織認可 – Great !
 1997年前活動曾受政府部門贊助
 參加對象以個人為主，而不是公司或團體
“We reject kings, presidents and voting. We believe in
rough consensus and running code”
綜觀 IETF


http://www.ietf.org
網際網路必須透過網際網路標準(Internet
standards)所定義下來的通訊協定(protocols)與程
序(procedures)兩者，來達成彼此之間互相溝通
交流的目的。故因此而成立IETF。
用 @ 當作識別符號或用 ! (或其他)，在70年
代 APRANET 有所爭論。
 經討論定板:RFC733。
 RFC733 所描述內容目前已更新至 RFC5321、
RFC5322
 Email
綜觀 IETF

Internet 標準的制定單位



沒有會員及投票制度，組織特性相當開放
每年3次會議，每次千餘人



不包含實體網路 (Ex: AP, 802.11x…)
大多數的標準討論都在 mailing lists 上進行,會議僅是確認最後結
果
人人可參加，可發言或發表文件(draft)
經過討論認可的內容，經過發行程序確認即
可成為RFC

標準程序: RFC2026
IETF 運作現況

八大領域 (Area),每個領域設置2名 Directors







Applications
General
Internet
Ops & Management




RAI
RTG
SEC
TSV
Real-time Applications & Infrastructure
Routing
Security
Transport
130 餘工作小組(Working Group) 分屬於八大領域中


APS
GEN
INT
O&M
工作小組時有增減，新開 WG 需經 BOF (Birds of a Feather)
程序 (RFC2418)
Directors 與 IETF 主席組成 IESG (Internet Engineering
Steering Group)，共同處理業務及標準審查
IETF 主席由 ISOC (Internet SOCiety) 指定
IAB 為指導建言單位，為 IETF/ISOC/ICANN/IANA/ ITUT …等提供建言及橫向協調
IETF 標準範圍

在實體線路(wire)之上,應用之下


但是實體線路介定愈來愈不清楚


IP, TCP, email, routing, IPsec, HTTP, FTP, ssh, LDAP, SIP, mobile IP,
ppp, RADIUS, Kerberos, secure email, IDN, streaming video &
audio, ...
MPLS, GMPLS, pwe3, VPN, ...
隨著時間推衍及 IETF 的發展,愈來愈難定義 IETF
的標準範圍

IETF 不斷的探索新的領域
與其他標準組織的關係

Internet 及其標準已漸被不同領域援用,或藉以
發展自身領域之相關標準
 Internet

標準已漸成為通信領域之通用標準
其他標準制定組織可能藉 Internet 的標準協定，
來解決自身的問題,但是可能因此發展出和原
來 Internet 標準不相容之自身領域標準
如
ITU-T 的 T-MPLS 和 IETF MPLS 的相容性爭議
IETF 組織架構
Internet
Society
IAD
IESG
IASA
IAB
IRTF
RFC
IANA
IANA
“the IETF”
WG
area
WG
area
WG
WG
area
WG
WG
WG
WG
WG
IETF 組織架構縮寫含義

ISOC
Internet Society

IAOC
IETF Administrative Oversight Committee

IAB
Internet Architecture Board

IASA
IETF Administrative Support Activity

IRTF
Internet Research Task Force

IRSG
Internet Research Steering Groups (IRSG).

IANA
Internet Assigned Numbers Authority

RFC
Request For Comments

IAD
IETF Administrative Director

IESG
Internet Engineering Steering Group

WG
Working Group
The Internet Society (ISOC)

非營利,非政府的獨立國際組織
 在全球超過
及80個分部

100個組織成員、44,000個獨立會員
成立於 1992 年
 提供
IETF 的法律保護傘
 為發展中國家提供 Internet 相關建言

致力於 Internet 開放性的的發展和演變，並確
保 Internet 帶來的效益，提供世人利用網路走
入世界的機會”
join at www.isoc.org
ISOC, (續)


IETF 在 1996年，以公開性的工作小組方式討論，
同意加入了 ISOC
ISOC 現在負責了 IETF 的組織運作和管理工作
legal umbrella, insurance, IASA home, IAD employer, etc
ISOC Board of Trustees part of appeal chain
ISOC President appoints chair of nomcom
IAB chartered by ISOC
ISOC president is on the IAB list & calls


IETF（通過 IAB）的任命3 位 ISOC 理事會理事
IETF 會議期間通常 ISOC 一起舉行會議
Internet Research Task Force

專注於目前 Internet 長期問題的相關研究







Anti-Spam Research Group (ASRG)
Crypto Forum Research Group
Delay-Tolerant Networking Research Group (DTNRG)
Host Identity Protocol (HIP) Research Group
Internet Congestion Control Research Group
IP Mobility Optimizations (Mob Opts) Research Group
Network Management Research Group (NMRG)
IRTF (續)

Peer-to-Peer Research Group

Routing Research Group
Scalable Adaptive Multicast Research Group
Transport Modeling Research Group
Virtual Networks Research GROUP (VNRG)




IRTF 主席由 IAB 指派


更多資訊可參考 http://www.irtf.org
現任 IRTF 主席: Lars Eggert

諾基亞 CEO 技術委員會成員的首席科學家
Internet Architecture Board








對 IESG/IETF/ISOC 等單位，提供整體的架
構建議及監督
批准提名委員會(nomcom, Nominating
Committee) 建議的 IESG 提名名單
監督 IETF 標準產生過程
處理 IETF 涉外之相關連絡及協調
指派 IRTF 主席
檢討目前 IETF-IANA 的職能是否洽當
任命和監督 RFC Editor 工作
IAB 相關章程由 ISOC 擬定
IAB 監督機制

審查 BOFs (Bird Of Feather)

提供 IESG 關於 WG 的資訊與章程之意見





協助和組織 IRTF 相關事務
召開特定主題之研討會 (以邀請性質為主，非公開)
組織專家委員會調解技術爭議
撰寫 IAB 對於 IDs/RFCs 的意見書，並參與社群與 IESG 之
審查
參與 WG 或其他 IETF 相關討論
Internet Assigned Numbers Authority (IANA)


美國官方贊助之組織，ICANN 之分割單位，主要負
責 IP 及 Domain name 業務相關之執行面
分配資源以避免重覆
 IP
Address/ Ports/ MIME types/ Protocol Parameter
 核配 IP 給５大洲 IP 管理單位APNIC/ARIN/
LANIC/AFRNIC/RIPE-NCC
 Root DNS servers 及 gTLD/ccTLD 域名管理與 DNS 授權

IANA 的成立早於 IETF
IANA (續)

IANA 在 IETF 成立後，相關職能受 IETF 領導
 1998年前受美國政府的經費支援



1998 年後，從 IETF 中分割出來改歸為 ICANN
之管轄，但為一獨立公司。
ICANN 與美國政府有合約關係
RFC 中若有關資源分配部份皆需向 IANA 註冊後
才能發表
 RFC
中之 「IANA Considerations 」 章節說明
IETF Management

IETF Chair



由 ISOC 指派，擔任 IETF 對外主要之發言人
同時需擔任 General AD
Area Directors (ADs)
每個領域2 人

Internet Engineering Steering Group (IESG)


Internet Architecture Board


由 ADs + Chair 組成
IETF 主席為 IAB 當然成員
IETF management selected by nomcom

以２年一任，最多連任一次
IETF Management (續)





IETF 所有的管理階層都是自願參加
AD : 一半至 ¾ 時間
IAB : 約 1/3 時間
IETF Chair : 全職
IETF 不支付 Ads, IAB 成員, 或 IAOC 成員或是
WG 主席或甚至是 IETF 主席等人薪水


以上費用由自身公司支付或自己掏腰包
秘書處及 RFC 出版相關工作及 IAD 業務等仍由 IETF 直接支付
IETF Chair

現任主席 Russ Housley <chair@ietf.org>




由 IETF 社群內的人提名(由 ISOC 指派) 候選–
也包含你


同時也是 IESG 主席
同時擔任 General Area 的 AD
也是 IAB 的當然成員
由 nomcom 完成提名名單
主席就是 CTO“Chief Talking (& Traveling)
Officer”
Area Directors (ADs)



每個 Area 有2名 AD, General Area 除外
負責導引或制定 Area 的走向
負責管理 Area 內相關程序及步驟



BOFs 的審查及提出工作小組
在 IESG 之審查之前，先檢示 WG 產出之文
件
調合 Area 內各項工作及相關 WG 的 I/O
IESG








由 ADs + IETF Chair 組成
處理 IDs (Internet Drafts) 轉換到 RFC 相關事宜
依據 IAB 意見成立 WG 的
WG 的建立與結束程序
跨 Area 間連絡協調事宜
審查及 公告 IETF 相關文件事宜
組成跨領域的審查小組
目前成員資訊
http://www.ietf.org/iesg/members.html
IETF 管理層選舉制度

由提名委員會進行提名
 提名委員會主席由
RFC3777

ISOC 指派，相關細節可參考
從自願參加者的候選名單中亂數選出候選人
 候選人必需在最近５次的
IETF 會議中參加過3次
以上
 亂數要求等相關程序可參考 RFC 3797

羅列出需要填補之職位列表
 包含了

IETF 主席、IESG、IAB、IAOC 等成員
每個職位提名１人
由 IESG 選擇生效；IESG & IETF 主席由 IAB
指派；IAB 則由 ISOC 指派
 IAOC
IETF Areas








General Area (gen) - 0 WGs (至2011年中)
Applications (app) - 15 WGs
Internet (int) - 26 WGs
Operations & Management (ops) - 17 WGs
Real-time Applications and Infrastructure (rai) 29 WGs
Routing (rtg) - 17 WGs
Security (sec) - 15 WGs
Transport Services (tsv) - 17 WGs
IETF Secretariat


目前由 Association Management Solutions, LLC Fremont, CA, USA 擔任秘書處工作
 相關管理由 IASA 進行
運作項目
會議是的開幕工作、郵任列表管理、RFC
Editor、出版業務及 IESG 電話會
 IETF

協調 IESG 日常業務
IETF Administrative Support Activity (IASA)



提供管理架構方案以支援標準形成過程所需
之協助。細節可參考 RFC4071 & RFC 4371
對標準形成的過程中無權過問
目前由 ISOC 運作中





建立 IETF 預算制度
經費來由主要為 IETF 會議報名費用和 ISOC 支援
管理 IETF 財務
簽定相關能對標準有幫助之合約
處理 IETF IPR 問題
IASA (續)

IASA 包含了兩個部門
 IETF
Administrative Director (IAD)
 目前由

Ray Pelletier 擔任
ISOC 員工，並負責 IETF 日常運作事務與監督
 IETF
Administrative Oversight Committee (IAOC)
 目前共有8名成員
- IAB & IETF 主席 & ISOC 董事
長 (當然成員)
 Nomcom 另外提名 5位 (由 ISOC/IAB/IESG 中選出)
IETF Trust

在 2005 年 12 月建立，用以管理 IETF 相關智
慧財產權
 版權，如
RFC 等
 網域名稱 (ietf.org)
 商標
 IETF 所使用的相關軟體
 資料庫
 其他

秘書處將所有的 IETF 版權進行了信託，而非
形成一個專利池
Dots
IAB member (red)
IESG member (yellow)
Working Group chair (blue)
nomcom (orange)
Local host (green)
IAOC member (purple)
Working Group (WG)




IETF 主要核心部份，標準是由下而上的決策模式
大多數的討論及意見交換在 WG mailing list 進行會議僅是針對關鍵或爭
議議題進行討論
主要由參與者主導議題，主席及秘書處進行彙整
對於新的事項或主題，許多人感到興趣時，可透過 AD 及 IAB 於會期進
行 WG BOF (Bird Of a Feather)，即必需排入 IETF 會議的議程
 每次會議前，可由 IETF 網站確認該次會議相關 BOFs 項目
 BOF 由發起人進行議案報告，AD需與會了解情況
 與會人員表決成立與否
 同意則起草章程(charter)，並確立工作小組主席及部份重要文件作者，
會後再將結果送交 IESG 討論，大多數的情況下，工作小組皆會順利
成立
 不同意則議題結束，工作小組不成立，近期內相同主題不可再 BOF
WGs (續)

WG 專注在章程中所提及之相關標準(通常經
過大家看過，由 WG Chair 和 AD 同意)
 章程中需提及階段性任務
組工作項目

(milestones) 或工作小
WG章程認可最後是由 IESG 參考 IAB 意見後
可批審
 在公開宣布後，也會將此訊息發佈到其他相關標
準組織，以避免重複投入

IESG 對 WG 章程有最終解釋權，工作小組在
完成任務後即關閉
WG (續)


沒有特定成員，大家都是參與者
大致的共識和可運作的程序



非正式的投票
可以舉手或只是嗡一聲，不確實計票
主要在了解取向，WG主席判斷是否取得共識
在 mailing list 上或會議現場透過討論解決爭議
 最後的定案需由 mailing list 確定，以讓那些因故不能
參加會議的人也有表達意見的機會

WG 會議期間

每次的 IETF 會期，WG 僅僅只有1-2小時的會
議時間





會議過程皆會錄音和可線上收聽



大多數的 WG 討論是透過 mailing list 進行
會議主要討論未解決或意見不一的問題
參加 WG 會議前請先讀完議程所列之相關 IDs
建議在說話之前，請先聽聽大家的說法或讀過文件
用麥克風說話（若前面有人需排隊），不要隨意發言
每一次發言前，請先介紹一下自己的名字，以利線上聽的人和
會做會議記錄時可以知道是誰說的
簽到

會議時會有簽到表傳交，這個表僅是紀錄誰來了這個 WG ，其
他並無作用
WG 產生過程
Chair, description,
goals and milestones
community
may have BOF
new-work &
IETF Announce
Area Director
IESG
Working group created
IAB
Document

IETF 文件包含了兩大部份
 Internet
Draft，代表的是草案，通常會以 ID 或 I-D
等表示
 RFC ( Request for Comments)，代表的是標準

所有的文件都是公開的，任何人皆可複製或下
載
Document – Internet Draft






Internet Draft 是 WG 的根本
英文是唯一語言 ( document & mailing list)，並以 ASCII 的
編碼撰寫
可以 透過WG 投稿，或是以獨立身份投稿發表自己的
看法及技術標準，惟格式有一定要求，發表之文件即視
為 Internet Draft
當 WG 及 IESG 對某一 ID 認為已有一致結論時，即可
進入轉換為 RFC 的程序(後述)
ID 之生命週期為6個月，未更新即視為 expired，
目前編寫ID主要使用 XML 語言，並透過工具轉成 txt


RFC 2629 - Writing I-Ds and RFCs using XML
ID & RFC 需為完全公開標準，並放棄文件所提及之智財
權，且不能涉及利害關係及受保護的專利
Document – RFC









Request for Comments
以序號來區分不同的 RFC
第一篇 RFC 於 1969 年發布，目前已超過 6000篇 RFC
依 RFC 內容及重要性，可分為下列類型
standards track
obsolete Standards
Requirements
Policies
IETF Standards Process





Poetry (詩文)
White papers
Corporate documentation
Experimental history
process documents
Document – RFC (續)

RFC Index
 由於
RFC 可能已被淘汰或部份項目更改，建議在閱
讀前可先上 IETF 網站上查閱
Document – RFC 標準分類


Best Current Practices (BCP)
Proposed Standard (PS)
 good

idea, no known problems
Draft Standard (DS)
 PS
+ stable
 較廣泛的實作基礎

Internet Standard (STD)
 DS
+ wide use
Document – RFC 標準分類 (續)

Informational
 資訊性質之文件
 廣泛性的描述問題點

Experimental
 實驗性質為主的協議標準，在驗證方案後可成為
PS 或 DS。

Historical
 交待歷史
RFC Editor



IETF 官方出版團隊
曾經是一個人先做，後來才慢慢發展成為一個
功能編組
RFC Editor 由下列項目所組成
處理編輯上的問題 (RFC Series Editor, RSE)
 編輯
 發佈
 個人提交的 ID 編輯工作 ( Independent Stream Editor,
ISE)
 RSE 及 ISE 皆由 IAB 指派

文件生命週期

IETF 對 draft 到 rfc 的過程有許多規範，文件生命週期則是意指這些規
範的流程中，對文件所造成的影響


每個 draft 之有效期為6個月，超過時限未更新則視為 expired
文件命名規則
命名規則沒有特別規定
 習慣上已形成 draft-ietf-wg-topic-version 或 draft-author-wg-item-version 之
命名法:
draft-ietf-idnabis-defs-13.txt
draft-resman-idna2008-mappings-01


文件版次



從 -00 開始，最大版次並無限制
-00 代表新的文件
-00 因所提及之想法或看法，故將被投以較多關注
-00 不需要講求章節內容之要求，其重點在想法及看法
draft-andrews-dnsext-multi-match-label-00.txt

WG 處理階段

Initial Submission
-00 初始版本投稿

Author Refinement
可能進行細部修改

WG Acceptance
同意列入 WG draft

Editor Selection
WG (re)charter & Milestone 需選擇作者

WG Refinement
依WG意見進行調整

WG Last Call 意見統一，文件接受，進入 WGLC

WG Request to Publish 進入 IESG 審查階段



上述不同階段皆會對 draft 造成極大影響
對 ”作者” 這一層級，必需了解 WG 的文件流程對其所帶
來的影響
對於會議所需要討論的 draft 版本更新，應特別留意會議
前的重要日期期限，以避免對 WG 造成困擾
44
留意重要日期
RFC 發布流程
46


AD 協助，將 draft 的發行需求提交至 IESG
IESG 認可後，發布 IESG LC (all IETFers)，若通過 LC 將 draft
放入 edit queue。


部份重要文件 可能會請 IAB review
RFC Editor Team




要求提供 xml 檔案，作者需提供以利官方作業
針對 draft 內容提問，作者需回應，或修改文件
提醒作者，針對 RFC 的發布內容，將調整章節及參考資訊
AUTH48 review

IANA Registry 協助 (如果有的話)

發布 RFC 在 IETF mailing list
Document Lifecycle Tutorial
21 March 2010
個人提交 RFC 流程
由個人提交 ID，最後會送到 ISE (Independent
Stream Editor)審議
 ISE 發布草案(draft)，並公布在 IETF mailing list

僅能發布 informational 或 experimental 的 RFC
尋求 IESG 的建議
 ISE

依據 IESG 的建議調整內容後可以考慮發不發布成為
RFC
 這一類的 RFC 可能會和現存的 RFC 內容有所衝突

IETF 提交流程 (WG)
Working group doc, or
individual standards track doc
Submit
Concerns
IESG
maybe
RFC Production
RFC Publisher
“Last Call”
Comments,
suggestions
IETF Community
Review
Published RFC
獨立文件的 IETF 提交流程
(The IAB & IRTF have their
own procedures)
individual
Content concerns and
editorial details
Submit
Independent Stream Editor
Comments
IESG
maybe
RFC Production
RFC Publisher
Published RFC
從 Draft 到 RFC 流程圖
如何撰寫 ID

建議在撰寫前，務必閱讀一定數量的 RFC
 撰寫體裁、用句、格式、章節、參考項目等考量
 了解文件流程資訊
 多加參與
WG 討論
 多了解RFC工具

WG draft 是目前RFC的主流，獨立的文件雖非
主流但仍可一試
 無相關
WG 的 draft 通常表示未被關注
注:此僅為簡介，因內容較為複雜
如何撰寫 ID (續)

一定要閱讀下列參考資料





*RFC2119 Key words for use in RFCs to Indicate Requirement Levels
RFC2629 Writing I-Ds and RFCs using XML
RFC5234 Augmented BNF for Syntax Specifications: ABNF
RFC3967 Clarifying when Standards Track Documents may Refer
Normatively to Documents at a Lower Level
http://tools.ietf.org/tools/templates
取得 RFC2629 所提及之 XML 格式

撰寫完後 submission 前，需多加利用 ietf 的 tools 進行內容
及格式上的檢查
Tools – xml2rfc

寫好的 xml 檔案需轉化為 txt，http://tools.ietf.org 使用 xml2rfc 可將 xml 轉成
draft 格式

頁首＆頁尾

章節及目錄

段落及長度控制

頁碼及分頁符號(^L)

參考資料及描述

交互參考之一致性
一篇 Draft 多久可成為RFC

短則六個月至一年
 非常好的內容且資深作者可能在
-00 或 -01 時就進
入 WGLC
 是其他 RFC 的補充說明或參考資料

長則 N 年
 作者不積極
 內容爭議大或影響深遠
 討論不夠多或較冷門

Draft -> RFC 平均約2-3年，大約僅有約1/5的
draft 可成為 RFC
專利與智慧財產權問題


專利和版權是一個組織之重要課題
IETF 希望 RFC 所提及之技術方案是不涉及專利
或版權問題的
內容涉及專利部份，應主動說明
 若有涉及專利(不論自己單位或他單位)，需有相關
證明 draft 之方案部份不受專利權影響
 draft
Note Well

任何提交給 IETF 的 ID 或是 RFC或statements ，在
IETF 這個組織或相關活動內，皆被視為是對 IETF 的貢
獻，statements 包含了







IETF 會議期間的任何發表
IESG 相關活動及產出
IETF 相關的郵件列表
IAB 的建言
RFC Editor 和 IDs 的一些活動
任何參與 IETF 相關活動的人，即代表已同意了
RFC5378 RFC3979 的要求
IETF 活動都是公開的，也可以被任意複製
IETF 新人 教育訓練



Time: 13:00 - 14:50

Newcomer's Training

Newcomer's Training (Mandarin)
Time: 15:00 - 16:50

Routing, Bridging, Switching

Document Lifecycle
Time: 17:00 – 19:00

Welcome Reception
下一步







加入郵件列表參與討論
幾乎所有的工作和討論事項皆在此
在回信前先閱讀過該郵件討論串全部，並
了解大家議題重點
閱讀 draft 並積極貢獻意見與看法
參與活動不要害羞但也不要表現得太強勢
多與人交流
不要沉迷二流的水平的技術討論
Questions?