Presentation is loading. Please wait.

Presentation is loading. Please wait.

IETF 組織結構 與 Internet 標準產生流程

Similar presentations


Presentation on theme: "IETF 組織結構 與 Internet 標準產生流程"— Presentation transcript:

1 IETF 組織結構 與 Internet 標準產生流程
楊禎葆 82nd IETF 台北,台灣

2 Agenda IETF 歷史與簡介 IETF 角色與範圍 IETF 組織結構與相關組織 IETF 管理與事務 IETF 工作進展與程序
工作小組 文件 智慧財產權問題 其他

3 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”

4 綜觀 IETF http://www.ietf.org
網際網路必須透過網際網路標準(Internet standards)所定義下來的通訊協定(protocols)與程 序(procedures)兩者,來達成彼此之間互相溝通 交流的目的。故因此而成立IETF。 當作識別符號或用 ! (或其他),在70年 代 APRANET 有所爭論。 經討論定板:RFC733。 RFC733 所描述內容目前已更新至 RFC5321、 RFC5322

5 綜觀 IETF Internet 標準的制定單位 沒有會員及投票制度,組織特性相當開放 每年3次會議,每次千餘人
不包含實體網路 (Ex: AP, x…) 沒有會員及投票制度,組織特性相當開放 每年3次會議,每次千餘人 大多數的標準討論都在 mailing lists 上進行,會議僅是確認最後結 果 人人可參加,可發言或發表文件(draft) 經過討論認可的內容,經過發行程序確認即 可成為RFC 標準程序: RFC2026

6 IETF 運作現況 130 餘工作小組(Working Group) 分屬於八大領域中
八大領域 (Area),每個領域設置2名 Directors APS Applications GEN General INT Internet O&M Ops & Management 130 餘工作小組(Working Group) 分屬於八大領域中 工作小組時有增減,新開 WG 需經 BOF (Birds of a Feather) 程序 (RFC2418) Directors 與 IETF 主席組成 IESG (Internet Engineering Steering Group),共同處理業務及標準審查 IETF 主席由 ISOC (Internet SOCiety) 指定 IAB 為指導建言單位,為 IETF/ISOC/ICANN/IANA/ ITU- T …等提供建言及橫向協調 RAI Real-time Applications & Infrastructure RTG Routing SEC Security TSV Transport

7 IETF 標準範圍 在實體線路(wire)之上,應用之下 但是實體線路介定愈來愈不清楚
IP, TCP, , routing, IPsec, HTTP, FTP, ssh, LDAP, SIP, mobile IP, ppp, RADIUS, Kerberos, secure , IDN, streaming video & audio, ... 但是實體線路介定愈來愈不清楚 MPLS, GMPLS, pwe3, VPN, ... 隨著時間推衍及 IETF 的發展,愈來愈難定義 IETF 的標準範圍 IETF 不斷的探索新的領域

8 與其他標準組織的關係 Internet 及其標準已漸被不同領域援用,或藉以 發展自身領域之相關標準
其他標準制定組織可能藉 Internet 的標準協定, 來解決自身的問題,但是可能因此發展出和原 來 Internet 標準不相容之自身領域標準 如 ITU-T 的 T-MPLS 和 IETF MPLS 的相容性爭議

9 IETF 組織架構 IAD IAB IESG IASA area area RFC IRTF IANA area IANA
Internet Society IAB IAD IASA IESG area IANA RFC area IRTF WG WG WG WG WG IANA area WG WG WG WG “the IETF”

10 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

11 The Internet Society (ISOC)
非營利,非政府的獨立國際組織 在全球超過 100個組織成員、44,000個獨立會員 及80個分部 成立於 1992 年 提供 IETF 的法律保護傘 為發展中國家提供 Internet 相關建言 致力於 Internet 開放性的的發展和演變,並確 保 Internet 帶來的效益,提供世人利用網路走 入世界的機會” join at

12 ISOC, (續) IETF 在 1996年,以公開性的工作小組方式討論, 同意加入了 ISOC
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 一起舉行會議

13 Internet Research Task Force
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)

14 IRTF (續) IRTF 主席由 IAB 指派 現任 IRTF 主席: Lars Eggert
Peer-to-Peer Research Group Routing Research Group Scalable Adaptive Multicast Research Group Transport Modeling Research Group Virtual Networks Research GROUP (VNRG) IRTF 主席由 IAB 指派 更多資訊可參考 現任 IRTF 主席: Lars Eggert 諾基亞 CEO 技術委員會成員的首席科學家

15 Internet Architecture Board
對 IESG/IETF/ISOC 等單位,提供整體的架 構建議及監督 批准提名委員會(nomcom, Nominating Committee) 建議的 IESG 提名名單 監督 IETF 標準產生過程 處理 IETF 涉外之相關連絡及協調 指派 IRTF 主席 檢討目前 IETF-IANA 的職能是否洽當 任命和監督 RFC Editor 工作 IAB 相關章程由 ISOC 擬定

16 IAB 監督機制 審查 BOFs (Bird Of Feather) 提供 IESG 關於 WG 的資訊與章程之意見
協助和組織 IRTF 相關事務 召開特定主題之研討會 (以邀請性質為主,非公開) 組織專家委員會調解技術爭議 撰寫 IAB 對於 IDs/RFCs 的意見書,並參與社群與 IESG 之 審查 參與 WG 或其他 IETF 相關討論

17 Internet Assigned Numbers Authority (IANA)
美國官方贊助之組織,ICANN 之分割單位,主要負 責 IP 及 Domain name 業務相關之執行面 分配資源以避免重覆 IP Address/ Ports/ MIME types/ Protocol Parameter 核配 IP 給5大洲 IP 管理單位APNIC/ARIN/ LANIC/AFRNIC/RIPE-NCC Root DNS servers 及 gTLD/ccTLD 域名管理與 DNS 授權 IANA 的成立早於 IETF

18 IANA (續) IANA 在 IETF 成立後,相關職能受 IETF 領導
1998年前受美國政府的經費支援 1998 年後,從 IETF 中分割出來改歸為 ICANN 之管轄,但為一獨立公司。 ICANN 與美國政府有合約關係 RFC 中若有關資源分配部份皆需向 IANA 註冊後 才能發表 RFC 中之 「IANA Considerations 」 章節說明

19 IETF Management IETF Chair Area Directors (ADs)
由 ISOC 指派,擔任 IETF 對外主要之發言人 同時需擔任 General AD Area Directors (ADs) 每個領域2 人 Internet Engineering Steering Group (IESG) 由 ADs + Chair 組成 Internet Architecture Board IETF 主席為 IAB 當然成員 IETF management selected by nomcom 以2年一任,最多連任一次

20 IETF Management (續) IETF 所有的管理階層都是自願參加 AD : 一半至 ¾ 時間 IAB : 約 1/3 時間
IETF Chair : 全職 IETF 不支付 Ads, IAB 成員, 或 IAOC 成員或是 WG 主席或甚至是 IETF 主席等人薪水 以上費用由自身公司支付或自己掏腰包 秘書處及 RFC 出版相關工作及 IAD 業務等仍由 IETF 直接支付

21 IETF Chair 現任主席 Russ Housley <chair@ietf.org>
同時也是 IESG 主席 同時擔任 General Area 的 AD 也是 IAB 的當然成員 由 IETF 社群內的人提名(由 ISOC 指派) 候選– 也包含你 由 nomcom 完成提名名單 主席就是 CTO“Chief Talking (& Traveling) Officer”

22 Area Directors (ADs) 每個 Area 有2名 AD, General Area 除外 負責導引或制定 Area 的走向
BOFs 的審查及提出工作小組 在 IESG 之審查之前,先檢示 WG 產出之文 件 調合 Area 內各項工作及相關 WG 的 I/O

23 IESG 由 ADs + IETF Chair 組成 處理 IDs (Internet Drafts) 轉換到 RFC 相關事宜
依據 IAB 意見成立 WG 的 WG 的建立與結束程序 跨 Area 間連絡協調事宜 審查及 公告 IETF 相關文件事宜 組成跨領域的審查小組 目前成員資訊

24 IETF 管理層選舉制度 由提名委員會進行提名 從自願參加者的候選名單中亂數選出候選人 羅列出需要填補之職位列表 每個職位提名1人
提名委員會主席由 ISOC 指派,相關細節可參考 RFC3777 從自願參加者的候選名單中亂數選出候選人 候選人必需在最近5次的 IETF 會議中參加過3次 以上 亂數要求等相關程序可參考 RFC 3797 羅列出需要填補之職位列表 包含了 IETF 主席、IESG、IAB、IAOC 等成員 每個職位提名1人 IAOC 由 IESG 選擇生效;IESG & IETF 主席由 IAB 指派;IAB 則由 ISOC 指派

25 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) WGs Routing (rtg) - 17 WGs Security (sec) - 15 WGs Transport Services (tsv) - 17 WGs

26 IETF Secretariat 目前由 Association Management Solutions, LLC - Fremont, CA, USA 擔任秘書處工作 相關管理由 IASA 進行 運作項目 IETF 會議是的開幕工作、郵任列表管理、RFC Editor、出版業務及 IESG 電話會 協調 IESG 日常業務

27 IETF Administrative Support Activity (IASA)
提供管理架構方案以支援標準形成過程所需 之協助。細節可參考 RFC4071 & RFC 4371 對標準形成的過程中無權過問 目前由 ISOC 運作中 建立 IETF 預算制度 經費來由主要為 IETF 會議報名費用和 ISOC 支援 管理 IETF 財務 簽定相關能對標準有幫助之合約 處理 IETF IPR 問題

28 IASA (續) IASA 包含了兩個部門 IETF Administrative Director (IAD)
目前由 Ray Pelletier 擔任 ISOC 員工,並負責 IETF 日常運作事務與監督 IETF Administrative Oversight Committee (IAOC) 目前共有8名成員 - IAB & IETF 主席 & ISOC 董事 長 (當然成員) Nomcom 另外提名 5位 (由 ISOC/IAB/IESG 中選出)

29 IETF Trust 在 2005 年 12 月建立,用以管理 IETF 相關智 慧財產權
版權,如 RFC 等 網域名稱 (ietf.org) 商標 IETF 所使用的相關軟體 資料庫 其他 秘書處將所有的 IETF 版權進行了信託,而非 形成一個專利池

30 Dots IAB member (red) IESG member (yellow) Working Group chair (blue)
nomcom (orange) Local host (green) IAOC member (purple)

31 Working Group (WG) IETF 主要核心部份,標準是由下而上的決策模式
大多數的討論及意見交換在 WG mailing list 進行會議僅是針對關鍵或爭 議議題進行討論 主要由參與者主導議題,主席及秘書處進行彙整 對於新的事項或主題,許多人感到興趣時,可透過 AD 及 IAB 於會期進 行 WG BOF (Bird Of a Feather),即必需排入 IETF 會議的議程 每次會議前,可由 IETF 網站確認該次會議相關 BOFs 項目 BOF 由發起人進行議案報告,AD需與會了解情況 與會人員表決成立與否 同意則起草章程(charter),並確立工作小組主席及部份重要文件作者, 會後再將結果送交 IESG 討論,大多數的情況下,工作小組皆會順利 成立 不同意則議題結束,工作小組不成立,近期內相同主題不可再 BOF

32 WGs (續) WG 專注在章程中所提及之相關標準(通常經 過大家看過,由 WG Chair 和 AD 同意)
章程中需提及階段性任務 (milestones) 或工作小 組工作項目 WG章程認可最後是由 IESG 參考 IAB 意見後 可批審 在公開宣布後,也會將此訊息發佈到其他相關標 準組織,以避免重複投入 IESG 對 WG 章程有最終解釋權,工作小組在 完成任務後即關閉

33 WG (續) 沒有特定成員,大家都是參與者 大致的共識和可運作的程序 在 mailing list 上或會議現場透過討論解決爭議
非正式的投票 可以舉手或只是嗡一聲,不確實計票 主要在了解取向,WG主席判斷是否取得共識 在 mailing list 上或會議現場透過討論解決爭議 最後的定案需由 mailing list 確定,以讓那些因故不能 參加會議的人也有表達意見的機會

34 WG 會議期間 每次的 IETF 會期,WG 僅僅只有1-2小時的會 議時間 會議過程皆會錄音和可線上收聽 簽到
大多數的 WG 討論是透過 mailing list 進行 會議主要討論未解決或意見不一的問題 參加 WG 會議前請先讀完議程所列之相關 IDs 建議在說話之前,請先聽聽大家的說法或讀過文件 會議過程皆會錄音和可線上收聽 用麥克風說話(若前面有人需排隊),不要隨意發言 每一次發言前,請先介紹一下自己的名字,以利線上聽的人和 會做會議記錄時可以知道是誰說的 簽到 會議時會有簽到表傳交,這個表僅是紀錄誰來了這個 WG ,其 他並無作用

35 WG 產生過程 community Chair, description, may have BOF
goals and milestones may have BOF community Area Director IESG new-work & IETF Announce IAB Working group created

36 Document IETF 文件包含了兩大部份 所有的文件都是公開的,任何人皆可複製或下 載
Internet Draft,代表的是草案,通常會以 ID 或 I-D 等表示 RFC ( Request for Comments),代表的是標準 所有的文件都是公開的,任何人皆可複製或下 載

37 Document – Internet Draft
Internet Draft 是 WG 的根本 英文是唯一語言 ( document & mailing list),並以 ASCII 的 編碼撰寫 可以 透過WG 投稿,或是以獨立身份投稿發表自己的 看法及技術標準,惟格式有一定要求,發表之文件即視 為 Internet Draft 當 WG 及 IESG 對某一 ID 認為已有一致結論時,即可 進入轉換為 RFC 的程序(後述) ID 之生命週期為6個月,未更新即視為 expired, 目前編寫ID主要使用 XML 語言,並透過工具轉成 txt RFC Writing I-Ds and RFCs using XML ID & RFC 需為完全公開標準,並放棄文件所提及之智財 權,且不能涉及利害關係及受保護的專利

38 Document – RFC standards track obsolete Standards Requirements
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

39 Document – RFC (續) RFC Index
由於 RFC 可能已被淘汰或部份項目更改,建議在閱 讀前可先上 IETF 網站上查閱

40 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

41 Document – RFC 標準分類 (續) Informational Experimental Historical 資訊性質之文件
廣泛性的描述問題點 Experimental 實驗性質為主的協議標準,在驗證方案後可成為 PS 或 DS。 Historical 交待歷史

42 RFC Editor IETF 官方出版團隊 曾經是一個人先做,後來才慢慢發展成為一個 功能編組 RFC Editor 由下列項目所組成
處理編輯上的問題 (RFC Series Editor, RSE) 編輯 發佈 個人提交的 ID 編輯工作 ( Independent Stream Editor, ISE) RSE 及 ISE 皆由 IAB 指派

43 文件生命週期 文件版次 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

44 WG 處理階段 上述不同階段皆會對 draft 造成極大影響 對 ”作者” 這一層級,必需了解 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

45 留意重要日期

46 RFC 發布流程 發布 RFC 在 IETF mailing list RFC Editor Team
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

47 個人提交 RFC 流程 由個人提交 ID,最後會送到 ISE (Independent Stream Editor)審議
ISE 發布草案(draft),並公布在 IETF mailing list ISE 僅能發布 informational 或 experimental 的 RFC 尋求 IESG 的建議 依據 IESG 的建議調整內容後可以考慮發不發布成為 RFC 這一類的 RFC 可能會和現存的 RFC 內容有所衝突

48 individual standards track doc
IETF 提交流程 (WG) Working group doc, or individual standards track doc Submit Concerns maybe IESG RFC Production RFC Publisher “Last Call” Comments, suggestions IETF Community Review Published RFC

49 Independent Stream Editor
獨立文件的 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

50 從 Draft 到 RFC 流程圖

51 如何撰寫 ID 建議在撰寫前,務必閱讀一定數量的 RFC WG draft 是目前RFC的主流,獨立的文件雖非 主流但仍可一試
撰寫體裁、用句、格式、章節、參考項目等考量 了解文件流程資訊 多加參與 WG 討論 多了解RFC工具 WG draft 是目前RFC的主流,獨立的文件雖非 主流但仍可一試 無相關 WG 的 draft 通常表示未被關注 注:此僅為簡介,因內容較為複雜

52 如何撰寫 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 取得 RFC2629 所提及之 XML 格式 撰寫完後 submission 前,需多加利用 ietf 的 tools 進行內容 及格式上的檢查

53 Tools – xml2rfc 寫好的 xml 檔案需轉化為 txt, 使用 xml2rfc 可將 xml 轉成 draft 格式 頁首&頁尾 章節及目錄 段落及長度控制 頁碼及分頁符號(^L) 參考資料及描述 交互參考之一致性

54 一篇 Draft 多久可成為RFC 短則六個月至一年 長則 N 年
非常好的內容且資深作者可能在 -00 或 -01 時就進 入 WGLC 是其他 RFC 的補充說明或參考資料 長則 N 年 作者不積極 內容爭議大或影響深遠 討論不夠多或較冷門 Draft -> RFC 平均約2-3年,大約僅有約1/5的 draft 可成為 RFC

55 專利與智慧財產權問題 專利和版權是一個組織之重要課題 IETF 希望 RFC 所提及之技術方案是不涉及專利 或版權問題的
draft 內容涉及專利部份,應主動說明 若有涉及專利(不論自己單位或他單位),需有相關 證明 draft 之方案部份不受專利權影響

56 Note Well Note Well - the first
任何提交給 IETF 的 ID 或是 RFC或statements ,在 IETF 這個組織或相關活動內,皆被視為是對 IETF 的貢 獻,statements 包含了 IETF 會議期間的任何發表 IESG 相關活動及產出 IETF 相關的郵件列表 IAB 的建言 RFC Editor 和 IDs 的一些活動 任何參與 IETF 相關活動的人,即代表已同意了 RFC5378 RFC3979 的要求 IETF 活動都是公開的,也可以被任意複製 Note Well - the first All statements of a technical or standards-related nature addressed to the IETF plenary session, any IETF working group or portion thereof, the IESG or any member thereof, the IAB or any member thereof, or any participant in the IETF, at an IETF meeting or other IETF function (other than personal communications outside of meeting sessions not intended to be shared with the IETF membership at-large ), are deemed to be part of an IETF standards-related discussion and, as such, are subject to all provisions of Section 10 of RFC 2026, granting certain licenses and rights in such statements to IETF and its participants.

57 IETF 新人 教育訓練 Time: 13:00 - 14:50 Time: 15:00 - 16:50
Newcomer's Training Newcomer's Training (Mandarin) Time: 15: :50 Routing, Bridging, Switching Document Lifecycle Time: 17:00 – 19:00 Welcome Reception

58 下一步 加入郵件列表參與討論 幾乎所有的工作和討論事項皆在此 在回信前先閱讀過該郵件討論串全部,並 了解大家議題重點
閱讀 draft 並積極貢獻意見與看法 參與活動不要害羞但也不要表現得太強勢 多與人交流 不要沉迷二流的水平的技術討論

59 Questions?


Download ppt "IETF 組織結構 與 Internet 標準產生流程"

Similar presentations


Ads by Google