輻輳制御アルゴリズムの新仕様に関する文書がRFC 5033として承認された。
　　RFC 5033の目的は、IETFで代替となる輻輳制御アルゴリズムを検討する際のガイダンスである。IETFの標準輻輳制御スキームには高速ネットワークなど、さまざまな環境で不十分であることが広く知られている。近年の研究には代替となる輻輳制御スキームがあるが、現在のIETFの輻輳制御原則からはかけ離れている。インターネット全体で新しい輻輳制御スキームを用いると、新しい輻輳制御スキームを使ったトラフィックと、現在の標準輻輳制御スキームを使ったトラフィックとが分離してしまうことも考えられる。したがって、代替となる輻輳制御案を扱うにあたっては、IETFは注意深く事を進めなければならない。

　対称的なRTP/RTCP（）についての文書がRFC 4961として承認された。
　RFC 4961は両方向のRTP（Real Time Protocol）およびRTCP（RTP Control Protocol）セッションでは、通信方向の双方で1つのUDPポートを用いることを推奨している。この仕様は一般的には「対称的RTP」や「対称的RTCP」と呼ばれている。

　AAA（Authentication, Authorization, and Accounting）鍵管理のガイダンスがRFC 4962として承認された。
　RFC 4962はAAA鍵管理プロトコルの設計者用ガイダンスである。また、AAA鍵管理プロトコルを含むシステムやソリューションの設計者にも便利な内容になっている。セキュアな設計における複雑性と困難性や長期間使える鍵管理アルゴリズム、専門知識を持つセキュリティ分野の専門家が開発したプロトコルがなければ、IETF作業部会がAAAに基づく独自の鍵管理アルゴリズムとプロトコルを設計することは非常に難しい。RFC 4962におけるガイドラインはIETFのRFCとして発行される他の文書にも適用される。また、こうしたガイドラインは他のSDO（Standards Development Organization：標準化団体）がAAAに基づく鍵管理技術を標準化する際にも有用である。

　OSPFに関するIANAの検討事項に関する文書がRFC 4940として承認された。
　RFC 4940は、OSPFに関するいくつかの登録事項と、そのコードポイントを割り当てるためのIANAへのガイダンスである。

　MPLSネットワークにおける同コストの複数経路の取り扱いの回避に関する文書がRFC 4928として承認された。
　RFC 4928は現在利用されているMPLSネットワークのECMP（Equal Cost Multipath）の振る舞いについて述べている。RFC 4928は、MPLSネットワーク上でアプリケーションを実行するとき、同コストの複数経路上の同じフローの異なるパケットの伝送によって引き起こされる再構成をIPパケットのバージョン番号フィールドの監視によって避けるための、現状の最善の慣行による推奨仕様である。推奨仕様は、発見的手法を採っているにも関わらず、MPLSネットワークの運用において比較的安定した効果がある。

　MPLS（Multiprotocol Label Switching）およびGMPLS（Generalized MPLS）のプロトコルと手続きの変更処理に関する文書がRFC 4929として承認された。
　RFC 4929はMPLSおよびGMPLSプロトコルスイートの仕様に適用されるか、MPLSおよびGMPLSプロトコルスイートの仕様を拡張し、IETFのMPLSおよびGMPLS作業部会のMPLSおよびGMPLSプロトコルスイートに関する責任を明確にするためのガイドラインである。RFC 4929はベンダー同士の協議の場や、標準化団体（SDO：Standards Development Organization）に対して、IETFにおけるMPLSおよびGMPLSの標準化作業の概要を示し、MPLSおよびGMPLSのアプリケーションやプロトコルを拡張する際のIETFの査読手続きの必要性を示している。

　標準化過程文書に対する規範的参照の取り扱いに関する文書がRFC 4897として承認された。
　IETF（The Internet Engineering Task Force）とRFC（Request for Comments）編集者は、長期にわたって、参照先のすべての文書の成熟度が参照元の文書の標準化過程における成熟度と同じがそれ以上でない限り、文書を発行しないというルールに基づいてきた。しかし、このルールはしばしば文書の公開に遅れを来すほか、標準化過程文書の成熟度を進行させる上での障害になっているとの指摘もあるほどである。IETFはRFC 3967によってこのルールを迂回する場合があるが、RFC 4897は、参照先の標準化過程またはBCP（Best Current Practice）文書の成熟度が参照元よりも低い場合のより簡単な手続きについて述べている。つまり、「メモって前に進め！」というわけである。
　なお、RFC 3967に定められた手続きは参照先が標準化過程またはBCPではない場合には引き続き適用される。いずれにしても、参照先についての注釈は加えられるべきである。

　RFC 3979にある第三者公開手続きの説明がRFC 4879として承認された。
　RFC 4879はRFC 3979の一文、特に、IPR（Intellectual Property Rights：知的所有権）の第三者公開について説明し、更新している。RFC 3879の意図は、この場合にIETFの執行理事が知的所有権の権利者に第三者公開の手続きに入ったことを通知し、RFC 3979のルールによって、知的所有権を公開するかどうか尋ねることである。

　IETF信託財産を承認するためのRFC 4181の更新に関する文書がRFC 4841として承認された。
　RFC 4841は「MIB文書の著者および査読者のためのガイドライン」（RFC 4181）を更新し、IETF信託財産の創設を承諾する。
　

　ユニキャストUDP用のNAT（Network Address Translation：ネットワークアドレス変換）の処理要件がRFC 4787として承認された。
　RFC 4787は、ユニキャストUDPを扱う場合のさまざまなタイプのNATの処理を述べるための期四用語について定義し、マルチメディア通信やオンラインゲームなどのアプリケーションが安定して動作するための要件についても述べている。この要件に適合するようにNATを実装すれば、こうしたアプリケーションが適切に機能する可能性が著しく高まる。

　エニーキャストの運用に関する文書がRFC 4786として承認された。
　インターネットの成長と企業内のシステムおよびネットワーク化されたサービスが以前よりも普及したことにより、高い稼働率が求められるサービスがいくつも現れるようになった。そのため、高い稼働率が要件になり、サービスを支えるネットワーク基盤にはより高い信頼性が要求されている。
　一方、インターネットで現在使われているサービスには稼働率を高めるためのさまざまなテクニックが用いられている。RFC 4786では、こうしたテクニックの1つであるエニーキャストについて、サービスをエニーキャストで実現しようと考えるネットワーク管理者向けに現状と推奨仕様を述べている。

　エニーキャストの運用に関する文書がRFC 4786として承認された。
　インターネットの成長と企業内のシステムおよびネットワーク化されたサービスが以前よりも普及したことにより、高い稼働率が求められるサービスがいくつも現れるようになった。そのため、高い稼働率が要件になり、サービスを支えるネットワーク基盤にはより高い信頼性が要求されている。
　一方、インターネットで現在使われているサービスには稼働率を高めるためのさまざまなテクニックが用いられている。RFC 4786では、こうしたテクニックの1つであるエニーキャストについて、サービスをエニーキャストで実現しようと考えるネットワーク管理者向けに現状と推奨仕様を述べている。

　プロトコルの拡張および改変の手続きに関する文書がRFC 4775として承認された。
　RFC 4775は、IETFプロトコルの拡張や改変について、何も評価せずに済ませてかまわない場合から、IETFのコミュニティによって評価すべき場合まで、IETFプロトコルの拡張性に関する手続き上の問題について議論している。これまでの経験から、プロトコルの拡張に際して初期の段階でIETFによる評価を受けないことはリスクを伴うことがわかっている。また、RFC 4775はIETFプロトコルに対する大きな拡張や改変は、通常のIETFの討議過程を経るか、IETFとの調整を受けるべきであることを勧告している。
　RFC 4775はおもに他のSDO（Standards Development Organization：標準化機関）およびIETFプロトコルの拡張用要件を検討する企業などに向けられた文書である。したがって、IETFの公式の討議過程に変更を加えることはない。

　ECN（Explicit Congestion Notification）フィールドの別解釈の仕様がRFC 4774として承認された。
　IPヘッダーにECNフィールドを追加する仕様（RFC 3168）は、別の解釈をするさまざまな提案を生み出してきた。そこでRFC 4774では、ECNフィールドにさまざまな解釈を定義することの問題点を議論し、別の解釈を理解できないルーターもインターネットにおいて安全に共存するための要件を定めている。
　なお、RFC 4774はそうした別の解釈をする最近の提案の著者との議論によって生まれた。

　観察されたDNS名前解決の間違いに関する文書がRFC 4697として承認された。
　RFC 4697はDNSのDNSのルートまたはTLD（Top-Level Domain）ネームサーバーに、膨大なクエリを送信してしまう反復モードのリゾルバーの振る舞いについて述べている。反復モードのリゾルバーの開発者は、不要なクエリーを送信しないように改めるべきである。
　RFC 4697で示されている推奨案は、13台あるうちの2台のルートサーバーおよび.com、.netを所管する13台すべてのTLDネームサーバーに送られてくる以上なクエリーのトラフィック観察と分析から副次的にもたらされたものである。

　IETFへの信託を確認するためのRFC 3978の更新に関する文書がRFC 4748として承認された。
　RFC 4748は「寄稿された文書等に関するIETFの権利」（RFC 3978）を更新して、IETFの持つ信託財産は今や、IETFに関連するすべての知的財産権の適切な管理方法であることを確認する文書である。また、IETFへの信託が知的財産権をどのように行使するかについて強制するものではない。

　言語タグの比較方法に関する文書がRFC 4647として承認された。
　RFC 4647は、ユーザーの言語選好リストで項目を特定するための「言語範囲」と呼ばれる文法について述べている。また、言語タグに対して、言語選好リストの項目を比較し、一致させるためのさまざまなメカニズムについても述べられている。
　フィルタリングと検索という2種類の一致メカニズムが定義されており、フィルタリングでは0個以上の言語タグのリストが生成され、検索では1つの言語タグが判明する。言語タグの用途としては、使用言語のネゴシエーションや言語別コンテンツの選択がある。
　RFC 4647は、RFC 4646とともに、RFC 3066（元になっているのはRFC 1766）を置き換える。

　言語識別用タグに関する文書がRFC 4646として承認された。
　RFC 4646は、情報オブジェクトにおいて言語を指定する必要のある場合に使われる言語タグの構造、内容、生成方法、解釈について述べている。また、言語タグで用いる値をどのように登録するか、プライベートな情報交換において、ユーザー定義の拡張仕様をどのように作成するについても述べられている。
　RFC 4646は、RFC 4647とともに、RFC 3066（元になっているのはRFC 1766）を置き換える。

　MSDP（Multicast Source Discovery Protocol：マルチキャスト送信元発見プロトコル）実稼働へのシナリオの文書がRFC 4611として承認された。
　RFC 4611は、ドメイン内およびドメイン間でMSDPをPIM-SM（Protocol Independent Multicast - Sparse Mode）と組み合わせて実稼働させるための現状で最善の慣行（BCP：Best Current Practices）について述べている。

　CIDR（Classless Inter-domain Routing）と呼ばれるインターネットのアドレス付与および集約の計画の仕様がRFC 4632として承認された。
　RFC 4632は、アドレス空間の節約とインターネット全体のルーティング状態の増加率を制限することに重点を置きながら、既存の32ビットIPv4アドレス空間のアドレス付与のための戦略について議論している。
　RFC 4632によって、RFC 1519によって定義されたCIDRの元の仕様は廃止される。また、RFC 4632の変更点には、CIDRが導入した概念の詳細をはっきりさせること、公開から12年が経過し、CIDR技術の普及による結果に関して、インターネットコミュニティに属する技術者の知識を更新することが含まれている。

　SIP（Session Initiation Protocol：セッション開始プロトコル）用の会議呼制御の仕様がRFC 4579として承認された。
　RFC 4579は、密結合SIP会議フレームワークがどのように動作するかを定義するために、会議の要件およびフレームワーク文書を追加している。このような取り組み方は、会議に参加できるだけのSIPソフトウェア（conference-unaware UA）、SIPの会議用機能を利用できるSIPソフトウェア（conference-aware UA）、会議を主催できるSIPソフトウェア（focus UA）という会議エージェントの3つの類型から検討されたものである。
　また、会議におけるURI（Uniform Resource Identifier）の利用、ある機能が利用できるかどうを調べるOPTIONS機能、REFERを使った呼制御などが呼フローダイヤグラムの例とともに記されている。「isfocus」機能タグについても定義されている。

　LDAP（Lightweight Directory Access Protocol：軽量ディレクトリアクセスプロトコル）拡張について考慮すべきことをまとめた文書がBCP 118およびRFC 4521として承認された。
　LDAPは拡張可能なプロトコルであり、新しいオペレーションを追加したり、既存のオペレーションを拡張したり、ユーザーおよびシステムの構成を拡張したりできる。RFC 4521は、LDAP拡張の設計者用に考慮すべきことを議論している。

　LDAP（Lightweight Directory Access Protocol：軽量ディレクトリアクセスプロトコル）に関するIANA（Internet Assigned Numbers Authority）の検討項目について述べた文書がBCP 64、RFC 4520として承認された。
　RFC 4520は、LDAPの拡張要素の登録手続きについて述べている。また、IANAに対して新しい値が割り当てるときの条件についてのガイドラインを示している。

　社内電話網（企業ネットワーク）におけるSIP（Session Initiation Protocol：セッション開始プロトコル）とQSIGの相互作業に関する文書がBCP 0117およびRFC 4497として承認された。
　SIPはインターネットのアプリケーション層制御（シグナリング）プロトコルであり、1組またはグループのセッションの作成、変更、終了を担当している。この場合のセッションとは、おおまかにいって通話のことである。
　QSIGとはPISN（Private Integrated Services Network：私設総合サービス網）における回線交換型通話（特に電話の通話）の作成、変更、終了を担当しているプロトコルである。QSIGはECMA標準で定義されており、ISO/EC標準としても発行されている。

　PWE3（Pseudo Wire Edge to Edge）用のIANA割り当てに関する文書がBCP 116およびRFC 4446として承認された。
　RFC 4446では、PWE3作業部会で定義されたプロトコル用に擬似回線用の固定IDと固定的なプロトコルの値を割り当てている。詳細なIANA割り当ての指示もRFC 4446に含まれている

　定型リソース識別子（URI）スキーム定義用の指針がRFC 4395およびBCP 0115として承認された。
　RFC 4395により、RFC 2717とRFC 2718は廃止され、URIスキームの審査過程とIANA登録手続きが一部変更される。

　BGB-4の標準的な（外向きの）コミュニティと、BGP経路の収集用にコミュニティを書き出すときのエンコード方式についての仕様がRFC 4384のBCPとして承認された。
　BGPコミュニティ（RFC 1997）は、顧客やピア接続、地理的に送信元が近い経路をタグ付けするといった多くの用途で、通信事業者が利用している。こうしたタグ付けは、事業者のネットワーク内および事業者とピア接続する他のプロバイダと顧客間で経路の再配布の範囲を制御するのに利用するのが一般的である。大規模なBGBデータが収集される（関連する研究もある）ようになったことで、今やそうしたコミュニティで伝送される情報が地球規模の経路制御システムの理解に欠かせないことが明らかになっている。

　IETFの新しい知財信託（IPT：Intellectual Property Trust）を考慮してBCB 101を更新する文書がRFC 4371として承認された。

　IETF運営監視委員会（IAOC）委員選考指針およびIAB/IESGによる選考過程の概要がBCP 0113およびRFC 4333として承認された。

　MIMEや他のインターネットプロトコルで用いるメディアタイプの仕様および登録手続きに関する文書がRFC 4288およびBCP 0013として承認された。

　MIMEや他のインターネットプロトコルで用いるメディアタイプの仕様および登録手続きに関する文書がRFC 4288およびBCP 0013として承認された。

　音声トランキングとして2点間で複数のRTP（Real-time Transport Protocol）ストリームを並行して伝送するネットワーク経路上の帯域幅の効率を改善するための方法がRFC 4170およびBCP 110として承認された。
　この方式は、圧縮や多重化、トンネリング用の標準プロトコルを組み合わせて、あるネットワーク経路上で複数RTPストリームを伝送するときの帯域幅の消費を抑える目的で利用できる。

　OSPF（Open Shortest Path First）バージョン2プロトコルを使ったネットワークのスケーラビリティと安定性を改善する目的で推奨される方法がBCP 0112およびRFC 4222として承認された。
　RFC 4222で推奨される方法には、他のOSPFパケットよりも高い優先度を持つOSPFの「Hello」メソッドやLSA（Link State Advertisement：リンク状態広告）の確認応答といった輻輳回避手続きが含まれる。

　IETFの標準化過程にあるMIB関連仕様書の著者および査読者向けガイドラインがRFC 4181として承認された。標準化過程にない他のMIB関連仕様書の査読時にも部分的に適用される。

　標準準拠のIPv6実装が逆引き用に「ip6.int」を使うことに対する抗議に関する助言がRFC 4159として承認された。

　IPPM（IP Performance Metrics：IP性能指標）の登録に関する文書がRFC 4148として承認された。現在IETFで定義された指標に「OBJECT IDENTITIES」初期セットを割り当てて登録する。
　またRFC 4148では、将来IP性能指標を追加やIP性能指標の策定を促すためのルールも定義している。

　暗号鍵管理のガイドラインがRFC 4107として承認された。
　セキュリティシステムに関しては、「何らかの形態の自動化された鍵管理が必要かどうか」あるいは「ユーザー自身による鍵の設定で十分なのか」という疑問が提起されることがよくある。そこでRFC 4107は、こうした問題を個々に判断する際のガイドラインを提供する。
　たとえば、あるプロトコルで対称鍵暗号が使われている場合に前提となるのは、自動化された鍵管理が一般的には必要だが、すべての場合において必要とされるわけではない、ということだ。例を挙げれば、無線LANのセキュリティシステムであるWEPは対称鍵を使っており、本来であれば自動化された鍵管理によって、鍵を自動的に更新する必要があったが、当初はユーザー自身で鍵の設定していた。そのため、長時間にわたって通信が続くと、鍵を類推される危険が指摘され、WPAではTKIPという自動化された鍵管理が使われている。
　一方、対称鍵暗号が使われているのにユーザー自身が鍵を管理する場合、一般的には自動化された鍵管理が必要であるにも関わらず、そうしたメカニズムを用意しないことについて、RFC 4107はメーカーなどには明確な説明責任が生じることを指摘している。対称鍵暗号の鍵をユーザー自身が管理しても安全性が保たれるのは、鍵を類推されるほどには通信の量が多くなく、万が一鍵を知られたとしても、そもそもやりとりされている内容が重要でないなど、まれなケースでしかないからだ。

　グローバルなIPアドレスの埋め込みが有害であることを指摘する文書がRFC 4085として承認された。
　RFC 4085は、重複しない、グローバルなIPアドレスをインターネット用機器に埋め込むことがどのような問題を引き起こすのかを指摘し、代替案を提示している。

　安全のためのランダム性要件に関する文書がRFC 4086として承認された。
　セキュリティシステムは強力な暗号アルゴリズムによって、暗号の「癖」を分析するような試みに耐性があるように構築される。しかし、こうしたシステムの安全性は、パスワードや暗号鍵といった秘密データの量に依存する。
　秘密データの作成に疑似乱数関数を用いることは、擬似的な安全をもたらすことになる。つまり、卓越した攻撃者であれば、疑似乱数を作り出したときの条件を再現し、膨大な可能性の中から、擬似的に作り出された秘密データの糸口を見つけ出すことも不可能とはいえない。能力もやる気もある敵の裏をかくような秘密データを選択することは、非常に難しいのだ。
　RFC 4086は、精度の低い乱数や秘密データを生成するために使われた従来の疑似乱数生成方法を使うことによる落とし穴について指摘している。RFC 4086は精度の高い乱数を生成するハードウェア機器の使用を推奨するとともに、既存の乱数生成ハードウェアがこうした目的に適っていることを明らかにしている。また、こうしたハードウェアが利用できない場合に問題を改善する方法を述べ、アプリケーションごとに、どの程度の大きさの秘密データが必要なのかの例を示している。