JPNIC News & Views vol.780【臨時号】

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲         ◆ JPNIC News & Views vol.780【臨時号】2010.9.15 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.780 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.779に続いてRFC5952の話題として、共著者であるＮＥＣビッ
グローブ株式会社の川村聖一氏により、RFC5952ができるまでの経緯について
ご紹介いただきます。

なお、本RFCで記述されている、IPv6アドレスの推奨表記そのものに関する解
説については、以下のバックナンバーをご覧ください。

□ IPv6アドレスの推奨表記、RFC5952ができるまでの道のり [前編]
   ～IPv6アドレス表記の柔軟性が引き起こす問題とRFC5952の解説～
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol779.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ IPv6アドレスの推奨表記、RFC5952ができるまでの道のり [後編]
   ～一つのRFCができるまで～
                                   ＮＥＣビッグローブ株式会社 川村聖一
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2009年3月13日、後にRFC5952となるメモ書きが生まれました。この時点では、
まだInternet-Draft(I-D)の形にすらなっておらず、社内での検討事項や自ら
の経験談を書きなぐって、RFCのような段組を真似て整形したテキストファイ
ルでした。当時のタイトルは、"A Strict IPv6 Address Representation 
Model"でした。

IETFが策定しているRFCシリーズは、仕事上読むことは多々ありましたが、ま
さか自分がインターネットプロトコルの標準化活動に加わることなんて、全
く考えていませんでした。私は、ISPネットワークを運用する仕事に就いてい
るため、RFCはどこかの偉い人が策定した技術であり、運用者とはあまり縁が
無いものと考えていました。ISPで運用を担当している側のほとんどの人が、
おそらくIETFに対して同様の距離感を持っているのではないかと思います。
「餅は餅屋」、私が技術者としてインターネットに関わり出した2004年には、
既にそういう風潮でした。もちろん、すべての方がそうではありませんが、
IETFと運用現場には、埋めがたいほどの距離ができていたと感じます。

■ きっかけ

長年IPv6のネットワークを運用していて、機器の出力するログ、コンフィグ
レーションファイルの表示、WHOISなどのインターネット上にあるデータベー
ス、さらには人と人の間で伝えるアドレスの書き方がバラバラであることは、
インターネットに関わる人々、エンジニアだけでなく営業や顧客、事務職員
なども含め、全員にとって一つもメリットが無く、むしろ障害時間を長引か
せたり、誤りを増やしたり、デメリットばかりだということに気付きました。

「どうすればこれを正すことができるのか」

IPv6が関係するすべての人・物に共通の基準を、標準化として策定するしか
ないと感じました。

しかし、IETFになんて参加したことがない……どうすれば良いのだろうか。
オペレーターが標準化なんて場違いなのでは。そんな時に私を助けてくれた
のは一人の友人でした。

■ Internet-Draft(I-D) 初版提出

この業界で、Randy Bushという名前をご存じの方は多いと思います。IETFの
ワーキンググループ(WG)チェアを務め、世界各地のNOG(*1)の運営に携わった
り、発展途上国のインターネット発展に貢献したりするなど、功績を挙げる
とキリがありません。

どうやってIETFに提案してよいかわからない私は、RFCを真似たメモ書きを彼
に送り、二つお願いをしました。

  1. IETFに提案したいので、相談に乗ってください。また、他に相談に乗っ
     てくれそうな人を紹介してください。

  2. I-Dを提出するためにはどうすればいいでしょう。

Randyはメモの内容に賛同してくれ、すぐ力になってくれました。まず、正し
いI-Dの形式に仕上げるためのツールと、力になってくれる知人を紹介してく
れました。その時に紹介された知人は、今では会うたびに、一緒に夜遅くま
でお酒を飲む仲です。

この段階で、実装面での相談をしていた、共著者であるＮＥＣアクセステク
ニカ株式会社川島正伸さんも加わり、周りの手厚い支援のおかげもあって、
I-D初版が完成しました。初版提出の時点で、現在のRFC5952のタイトル"A 
Recommendation for IPv6 Address Text Representation"になっています。

(*1) Network Operator's Groupの略。地域毎に開催されている特徴があり、
     日本はJANOG、北米はNANOGなど、xxNOGという名前になっていることが
     多いようです。

■ IETFの洗礼

I-Dの提出はごく簡単なもので、XMLファイルとテキストファイルを、IETFの
Webページにあるツールからアップロードするだけです。XMLファイルで原稿
を書き、xml2rfcというツールを使い、テキストファイルに整形しました。
XMLのひな型は、IETFのページで探してきたものをベースに作成しました。

提出した後、通常は想定しているWGのメーリングリスト(ML)に、「こういう
Draft書きました。ぜひ読んでコメントください」と投げるのが一般的なよう
です。このような慣例を全く知らず、出しっ放しにしていました。しかし、
提出した時点からすぐに、たくさんの賛同、コメント、修正案が、知らない
人からメールで届くようになります。私はこれには感激しました。いただい
たコメントの中に、IPv6に関するオペレーション技術や、移行技術に関する
議論を行う、v6ops WG(IPv6 Operations WG)で取り上げる方が良いのではな
いか、という提案がありました。

そこで、何のツテもコネも無い私は、Ccに友人のRandyを入れ、IPv6のプロト
コルそのもののメンテナンスを実施する6man WG(IPv6 Maintenance WG)と、
v6ops WGの、チェアとエリアディレクターの方々に、どのWGに、どのような
形で紹介するのが良いか、相談メールを出しました。

今までIETFで登場したこともない人間が、よくもこんな怖いもの知らずな行
動を起こしたものです。最初は、ほとんど相手にしてもらえませんでした。
しかし、提出当初にコメントをいただいた方のうちの一人が、「こんなDraft
出たんだけど、とても良いと思います」というコメントを、v6opsのMLに出し
てくれました。そこからWGチェアも少し注目してくれるようになり、チェア
とディレクターの間で議論した結果、6man WGの題材として、IETFのミーティ
ングで取り上げることが決まりました。

■ 感動の初IETF参加

初めてのIETF参加で、初めてのInternet-Draftで、初めてのヨーロッパ。初
めて尽くしの中、体調不良により、予定している飛行機に乗れないアクシデ
ントもあり、1日遅れでIETF75開催地のスウェーデン入りしました。周りは知
らない人ばかり。その中で初発表です。Draftについて発表を終えた途端、た
くさんの人がマイクに並びました。感動的なことに、一つもネガティブな意
見は無く、満場一致で6man WG Draftとなることが、その場で決まりました。
後々知ったのですが、初回提案で、個人執筆のI-DがWG Draft(*2)となること
は、かなりレアケースのようです。

初回でこれだけ成功したのは、初版を提出した2009年3月から7月までの間、
何十通のメールをさまざまな方々に個別に書いたり、アドバイスを聞いたり
した結果と、大切な友人に支えられていたからだと思います。

(*2) I-Dは一般的に、個人としての提案からWG Draftを経てRFCとなります。
     個人としての提案がそのままRFCとなるケースもありますが、そのたぐ
     いの文書はIETFの中でも、一般的な標準RFCと扱いが異なります。
     http://www.nic.ad.jp/ja/rfc-jp/Std-track.html

■ 日本開催IETFでの成果

6man WG Draftとして、ラストコール(*3)をホームである日本で迎えたい、と
いう思いは初版を作成した時からありました。願いはかない、広島で開催さ
れたIETF76で無事ラストコール状態に持って行くことができ、RFCまでの道の
りは順調かと思いました。IETFをよく知る日本人の方々にも「おめでとう」
と言われ、正直あまりピンときませんでしたが、周りの人が言うなら、これ
でほぼ終わりなのかな？と思っていました。

(*3) http://www.nic.ad.jp/ja/tech/glos-ra.html#19-last-call

■ 苦難の連続

しかし、ここからが本当の戦いの始まりでした。ラストコールは、6man WGと
してのラストコールの他に、"Standards Track"(*4)として進められる文書
は、IETF全体でのラストコールにかかります。このIETFラストコール中に、
他WGからさまざまな変更、追加依頼が加えられます(RFC5952のSection 5、
Section 6は、この時点で大きく変わりました)。ラストコール中の調整もか
なり大変だったのですが、その後のIESG reviewという状態が最も大変でし
た。IESG(Internet Engineering Steering Group)(*5)は、RFCを承認する機
能を持っている組織であり、IETFの技術活動すべての責任を負っています。
そのIESGからストップがかかりました。

IESGとの調整は難航します。IESGはそもそも忙しい人の集まりなので、なか
なか調整が進まない他、技術的な責任を負っているため、かなりチェックが
厳しいのです。結果として、IESGの承認を通すのに数ヶ月かかり、文書の表
現は厳格な言い回しに変更することになりました。この間、数々のクレーム
やネガティブなコメントを、さまざまな方にいただきました。この時点では、
I-Dを最初に発表した時の純粋な気持ちよりも、いかにして標準化を押し通す
か、挙げられた課題を解決するか、承認が取れるように働きかけるか、とい
うことを、優先して考える必要がありました。会社内の動きと同じです。な
かなか思うように進まない状態に、心が折れそうになることが多々ありまし
たが、標準化する重みと責任を感じながら、何とか承認を得ることができま
した。

(*4) RFCは大きく二つの種類、いわゆる「標準化」であるStandards Trackと
     Non-Standards Trackに分かれます。Standards Trackは、より厳しいプ
     ロセスを通すことになります。
     http://www.nic.ad.jp/ja/rfc-jp/RFC-Category.html

(*5) http://www.nic.ad.jp/ja/basics/terms/iesg.html

■ RFCの発行と振り返り

2010年8月21日、最初のメモ書きができ上がってから約1年半後、RFC5952とし
てIETFから正式に発行されました。最初に感じたのは安堵、そして感謝の気
持ちが止まりませんでした。

1年半の活動を通して、さまざまな方に支えられてきました。RFC5952がRFCに
たどりついたのは、周囲に支えられたことが最大の成功要因でした。著者二
人の力ではありません。本当に仲間に恵まれていて、良い仲間に巡り会える
運があったのだと思います。全員の名前を挙げることはできませんが、支え
ていただいたみなさまに、ここであらためて御礼を申し上げます。

メモ書き作成当初より、RFCにすることがゴールではありませんでした。「実
装、および人々の慣例が共通化されること」がゴールです。RFC化することに
より、参照できるインターネットコミュニティのコンセンサスを代表する文
献ができあがり、この目的を達成しやすくなりました。ここからまた、さま
ざまな方々に協力いただきながら、よりインターネットが運用しやすい環境
になるよう普及努力を続けていくつもりです。

■ IETFについて思うこと

IETFで活動するために必要なのは、重要度の高い順に以下の要素だと私は感
じています。

  1. 強い気持ち
     1.1 技術的な思いの強さ
     1.2 心の強さ
  2. 仲間
  3. 英語力(これはかなり高いレベルが要求されます)

強い気持ちというのは、二つの要素があります。一つは、技術的にこれは本
当に必要だという信念です。これさえあれば、IETFにアイデアを持ち込む価
値がありますし、絶対にそうするべきです。もう一つは、心の強さ。IETFで
の活動は、本当に疲れます。会議では、1,000人を超えるさまざまな国のエン
ジニアが集まり、WGのMLには何千人も参加しています。それだけ人がいれば、
さまざまなことを言われます。Yes、Thank youだけでは、絶対に前に進めま
せん。場合によっては断る勇気、戦う勇気が必要です。もし技術的な思いは
あるが議論に自信の無い方は、心の強い共著者を見つけることが大事だと思
います。

仲間は、最初からいる必要はありませんが、仲間を作る活動はとても大切で
す。困った際には仲間は必ず助けてくれますし、助言もしてくれます。IETF
にもコネの原理は働きます。時間はかかってもよいので、仲間を作る時間は
大切にする必要があります。ただし、自分の目的を達成するためだけの活動
では、なかなか仲間は増えません。インターネットに貢献する気持ちを持っ
て、他の方の活動にもしっかり目を向けることが大事です。

最後に、IETFでは高いレベルの英語力が必要です。もし英語に自信が無いな
ら、英語に強い共著者を見つけるべきでしょう。私は米国出身であることが
幸いしましたが、それでも日本に住んでいるだけで多少のハンデがあると感
じています。ネイティブの方と打ち解けて、一緒にDraftを書くのが最も良い
と思います。もしそれができない場合でも、仲間を増やす程度の英語力は必
要です。

また、日本人らしい謙虚な気持ちを忘れないで活動すれば、外国の方々によ
りよく接してもらえるのではないかと思います。日本は素晴らしい国、日本
には素晴らしい技術者がいるということを、大いに世界にアピールしていき
ましょう！

See you at IETF!


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
            http://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.780 【臨時号】

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 ＠ 問い合わせ先   jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
           本メールを転載・複製・再配布・引用される際には
       http://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  http://www.nic.ad.jp/
■■

Copyright(C), 2010 Japan Network Information Center
このページを評価してください
