記事を読んでいただきありがとうございます。
モブエンジニア（@mob-engineer)です。
モブエンジニアのネットワーク大全というテーマでひとりアドベントカレンダーを生やしてみたので、ネットワーク関連に関してキャッチアップしたことをつらつらとまとめていきたいと思います。
前回記事ではプライベートIPアドレスのレンジ戦略についてつらつら書いてきましたが、第2回目ではネットワークエンジニアのバイブルであるRFCをいい感じで読む方法についてつらつら書いていきたいと思います。
対象読者
対象読者として次の方を想定しています。
- RFC文書の読み方をキャッチアップしたい方
- ネットワークエンジニアとしてRFCをサラッと読みたい方
持ち帰ってもらいこと
本記事を通じて次のことを持ち帰っていただきます。
- RFC：request for commetsの略
- RFCを読む目的：ネットワーク技術の背景を理解する
- 実装レベルについては論文・ホワイトペーパーを読む必要がある
RFCあれこれ
JPNICさんのページに分かりやすくまとめられていたため、そちらを引用してみたいと思います。
RFCは"Request for Comments"の略で敢えて訳を付けるのならば『求むコメント』とでもなる用語である。 RFCに初めて触れた方の多くの方はまず『どうしてRFCが"RFC"と呼ばれているのか?』と、 現在のRFCの位置づけと名前が持つ意味のギャップに悩むに違いない。 この悩みがRFCを理解する上で最初の関門であることは確かで、かつ、 解消するまでに長い時間がかかる(かもしれない)ものなのだ。 なぜなら、 本当に正確な理解をするためにはRFCの歴史にまで踏み込まなければならない、 からだ。 だが…、 読者の中には今日RFCに入門したばかりの方もいるかもしれない。 そこで、ここではひとまずそのような『歴史』についてはおいておいて、 『RFCの現在』に注目することにしよう。 RFCの歴史については今後ゆっくりと説明するので、 それまで待っていて欲しい。
ざっくり言えば、ネットワーク技術実装について課題点・改善点を求めるパブリックコメントと思ってもらえれば分かりやすいと思います。
原典に入る前に
いきなり原典を読んでもいいと思いますが、基本英文＋何が書いてあるかよくわからないので、JPNICさんから提供されているRFC一覧ページをさっと読むことが大事だと思います。
とは言え、RFCを隅から読んでいこうとするとなかなか大変だと思いますので、サマリの部分を読んで「深掘りした方がよい」と思ったら中身を読んでいくことがいいと思います。
実務ベースで考えると
RFCで示されている実装方式はあくまで「XXの技術を実装するのであればRFCYYYYを利用してみよう」を提言しているにすぎません。実務ベースで考えるのであれば、ベンダーから提供されているホワイトペーパーを読み込んでみることをおススメします。（実際、RFCと異なる実装方式を採用している場合もあるので）
より深掘りしたい方であれば、公開論文を読んでみてキャッチアップしてみることをおススメします。
まとめ
RFCの読み方についてザクっとまとめてみましたが、深掘りすればもう少し考える要素があると思います。若手エンジニア向けに整理していきたいと思います。