IETF的運行方式
互聯網工程任務組IETF的研究從大方向上主要分為應用、一般領域、互聯、運行、路由、安全和傳輸等領域。
IETF的組織架構由三部分組成：互聯網體系結構委員會（IAB）、互聯網工程指導委員會（IESG）以及涵蓋了互聯網各領域的工作組（Working Group）。
標準制定的工作由工作組承擔，它們專注于互聯網路由、傳輸、應用等領域。標準制定的工作大都通過所設立的郵件組完成。此外，IETF每年還會召開3次為期一周的會議，幫助工作組完成任務，并促進工作組之間的交流。
IESG的主要職責是接收各個工作組的報告，對報告進行審查，然后對其所提出的相關標準和建議提出指導性的意見。
IAB是IETF的頂層委員會，主要由探討與互聯網結構有關問題的互聯網研究員組成，參與建立各種與互聯網有關的組織，如互聯網數字分配機構（IANA）、互聯網工程指導委員會（IESG）和互聯網研究指導組（IRSG）。
通過定期召開會議、頻繁發布RFC的方式，IETF打造了互聯網的技術規范。
RFC的形成過程
可以說，如果一項技術想要成為全世界軟件開發商、硬件制造商以及網絡運營商自愿實施的標準和遵守的規范，那么成為RFC是它的必經之路。
一般來說，IETF標準的相關文檔包括互聯網草案（Internet Draft）和RFC。草案是供IETF討論的文檔，是對互聯網問題的描述和解決方案。RFC可被視為草案的最終版，具有特定的編號。
草案可由任何個人或工作組提交，但只有6個月的生命周期（可以不斷更新）。需要注意的是，草案并不等同于標準、論文或正式報告，大多數草案也不會成為RFC。RFC才是互聯網正式的文檔。已發布的RFC即使有錯誤也不能更改，只能發布“錯誤訂正”或用另一個RFC將其廢除或取代。
工作組是產生RFC的首要途徑，通常要經歷以下幾個流程：個人提交草案，工作組認領草案，工作組反復迭代討論，工作組最后詢問，IESG內部討論，IESG批準，獲得RFC編號，RFC文字編輯，正式發布。
其中最大的難點是工作組認領草案。RFC7221對工作組主席考慮是否認領草案提供了具體建議，包括：
草案必須符合工作組目前的章程或只需對章程作簡單修改。
草案的目的應該明確。
草案應該是有用的。
文檔的寫作質量應足以作為進一步工作的基礎。
不應有強烈的技術異議。
相關知識產權信息的披露都應是可接受的。
不與IETF中的其他工作沖突。
產生RFC的第二條途徑則針對沒有相應工作組的文檔，需要經過領域主席個人提交到IESG。
以上兩條途徑都要提交到IESG進行討論，IESG再進行IETF范圍內的最后詢問。在多次反饋、修改，得到所有IESG成員的認可后，草案就可以送交RFC編輯部，授予RFC編號，進行文字編輯和格式協定，最終作為RFC發布。
產生RFC的第三條途徑是針對非IETF提交的RFC，同樣也沒有經過工作組，而是個人直接提交文檔至編輯部，并與后者進行討論，考慮內容和編輯細節，與此同時，RFC編輯部和IESG直接交換意見，RFC形成后，由RFC編輯部直接發布。
從個人提交草案到工作組草案，再到IESG、RFC編輯部，直到最終成為RFC發布，整個過程最快也要2年以上，有時則需5年。從草案到標準，全程記錄郵件收發并公開會議記錄。
成為RFC作者象征著互聯網技術界的榮譽和責任，但RFC定義的技術和標準能否在互聯網中大規模得到應用，才是更大的挑戰。
來源：《中國教育網絡》2024年9月刊
