URI（Uniform Resource Identifier）用のMIB省略表記の仕様がRFC 5017として勧告された。
　このMIBモジュールはURI（STD 66）を表現するための省略表記を定義している。独自の表記方法を持つMIBモジュールで導入される。

　S/MIME（Secure/Multipurpose Internet Mail Extensions）におけるスイートB暗号に関する文書がRFC 5008として承認された。
　RFC 5008は、RFC 3851で定義されているS/MIMEにおける米国国家安全保障庁のスイートBアルゴリズムを使うための方法について定義している。

　DHCPv6（Dynamic Host Configuration Protocol for IPv6）のリース期間問い合わせに関する仕様がRFC 5007として勧告された。
　RFC 5007はDHCPv6でリース期間を問い合わせるやりとりの仕様を定めて、DHCPv6クライアントがDHCPv6サーバーからリース期間の情報を取得できるようにする。RFC 5007は取得できるデータの範囲と、DHCPv6のリース期間問い合わせの要求とサーバー側の処理を定義している。

　フィードのページ化とアーカイブ化に関する仕様がRFC 5005として勧告された。
　RFC 5005は3つのタイプのWebフィードを定義して、1つ以上のフィード文書にまたがるエントリーを発行できるようにする。
　ページ化フィードは、フィードをページに分けた形態であり、アーカイブ化フィードはフィードの内容を再構成できる形態であり、完全フィードはすべてのエントリーを含む形態である。

　外部から外部へのBGP最良経路の遷移回避の仕様がRFC 5004として勧告された。
　RFC 5004では、ある条件下における外部の経路間の不要な最良経路の遷移を回避するBGPの経路選択ルールの拡張が提案されている。この拡張により、ネットワーク全体の安定性が高まり、さらに重要なことに、1つのBGPスピーカーが引き起こされる外部経路の遷移が繰り返される現象をなくせる。

　MSCML（Media Server Control Markup Language）とプロトコルについての文書がRFC 5022として承認された。
　MSCMLとは、SIPとともに用いて、先進的なカンファレンスとIVR（Interactive Voice Response：音声自動応答）を実現するためのマークアップ言語である。MSCMLが表現するのは装置レベルの制御モデルではなく、アプリケーションレベルの制御モデルであり、IETFのSIPカンファレンスフレームワークにおいて、カンファレンスフォーカスとミキサー間の通信を実現するために利用できる。

　DHCPv4（Dynamic Host Configuration Protocol version 4）リレーエージェントフラグサブオプションの仕様がRFC 5010として勧告された。
　RFC 5010はDHCPリレーエージェント情報オプションの新しいサブオプションを定義して、DHCPリレーで転送されたパケット用に2つのフラグを付けられるようにする。
　1つのフラグは、DHCPリレーがパケットをユニキャストパケットで受信したか、ブロードキャストパケットで受信したのかを示すためにある。DHCPサーバーがこのフラグを使って、クライアントからの要求が元々ブロードキャストなのかユニキャストなのかで扱いを変えられるようになる。

　検索方式に関する頑強なP2P（Peer-To-Peer）ネットワークに対する研究の調査についての文書がRFC 4981として承認された。
　最近5年間のP2Pネットワークに関する研究の進歩は、P2Pを重要視した調査が真実であったことがわかる。P2Pは破壊的な技術となる可能性を秘めており、導入コストや拡大コストをなるべく抑えながら、膨大な量のストレージや処理能力を集約しうる。ただ、従来型アーキテクチャに比べれば個々のエラーの影響はずっと少ないとはいえ、分散された膨大な数のピア間ではエラーが日常茶飯事であり、すでにあるファイル共有以上のアプリケーションをP2Pで実現する鍵となるのは頑強さである。
　RFC 4981ではまず、P2Pに分類されるあらゆる技術における検索方式を調べている。Plaxtonツリーやリング、tori、バタフライ、de Bruijnダイグラフ、スキップグラフに基づく、簡単なキー検索用P2Pインデックスを評価し、同様にキーワード検索や情報取得、データ管理用のP2Pインデックスについても調べている。最後に、検索範囲の最適化やマルチ属性、参加、P2Pインデックスの問い合わせの集約に関する初期の模索についても評価している。
　検索方式について基本文献で言及されている限りにおいて、RFC 4981では頑強さのメカニズムとその指標に重きを置いているが、文献中では頑強さにもっとも影響を与える低レベルメカニズムが上位のメカニズムきちんと分離していない。RFC 4981には将来の研究用の推奨仕様も含まれる。

　IMAPプロトコルのWITHIN検索拡張の仕様がRFC 5032として勧告された。
　RFC 5032はIMAPのSEARCHコマンドに対するWITHIN拡張について述べている。IMAPのSEARCHは日時が指定された範囲内あるいは範囲外にあるメッセージを応答するコマンドである。SEARCHコマンドの既存のオプションであるBEFOREおよびSINCEでは、クライアントが指定した日時を基準に検索するのに対して、RFC 5032で定義されたOLDERおよびYOUNGERでは、クライアントが指定した間隔（秒）を基準にメッセージを検索する。
　WITHIN拡張は常時検索するクライアントで、一定間隔で検索処理を実行する性能がなかったり、ネットワークの帯域幅が不足していたりして、何度も同じ要求を送りたくない場合や、同じ応答を受け取りたくない場合に有用である。

　DNSSEC（DNS Security）トラストアンカーの自動更新の仕様がRFC 5011として勧告された。
　RFC 5011はDNSSECのトラストアンカーの更新の自動化と認証、証明方法について述べている。この方法は、トラストポイントのキーセットにおけるN個の鍵のうちのN-1個の鍵の危殆化に対する保護になる。現行アンカーの存在によって確立された信頼に基づいて、他のアンカーを階層構造内に追加（究極的には置き換え）してもよい。
　このメカニズムにはリゾルバー管理のやり方を変更（リゾルバーの解決時のやり方ではない）し、DNSKEYレコードのフラグを1ビット追加する必要がある。

　集約用のAII（Attachment Individual Identifier）タイプの仕様がRFC 5003として勧告された。
　AIIとは、疑似有線（Pseudowire）エンドポイントを識別するTLV（Type Length Value）フィールドを含むポイント間疑似有線を確立するために用いるシグナリングプロトコルのことである。RFC 5003は、AII TLVフィールドの新形態となるAII構造体を定義して、スケーラビリティを改善し、VPN（Virtual Private Network）の自動発見用のAII集約に対応する。
　AII集約は、顧客のニーズに基づいて、選択されたローカルPE（Provider Edge）とリモートPE間で疑似有線が確立されている大規模なドメイン間の仮想専用線サービスネットワークで利用する場合に有用である。

　GMPLS（Generalized Multiprotocol Label Switching）ネットワークにおけるアドレスの使用についての文書がRFC 4990として承認された。
　RFC 4990はGMPLSネットワークにおけるアドレスの使用について明らかにし、GMPLS対応のLSR（Label Switching Router）の互換性を高めることが目的である。RFC 4990は、実装や互換性のテスト、実運用での経験に基づいている。
　RFC 4990はGMPLSプロトコルでアドレスや識別子フィールドをどのように解釈すべきか、また、どのアドレスを特定の制御プレーンユーゼージモデルに当てはめるかについても述べている。さらに、IPv6の送信元と宛先アドレスをMPLS/GMPLSのトラフィックエンジニアリングMIB（Management Information Base）でどのように扱うかについても議論している。
　なお、RFC 4990は新しい手続きや処理は定義していない。要件の提示や推奨を示している部分は、規範となる参照先RFCから引用されたものである。

　OMA PoC（Open Mobile Alliance Push to Talk over Cellular）用のSIP（Session Initiation Protocol）のPアンサー状態ヘッダー拡張の仕様がRFC 4964として承認された。
　RFC 4964はOMAのPoCアプリケーションに限定される、SIPのプライベートヘッダー（Pヘッダー）について述べている。Pアンサー状態ヘッダーは特定のPoCアプリケーションがハンドセットの応答モードを示すために用いる。