4/13/2017

IETFを終わらせてはいけない

CircleIDのブログより。

IETFはギブアップする時なのか? Martin Geddesは要するにIETFにとってフェードアウトする時だと証拠を挙げて説明している。彼が提示する事例は説得力がある。はじめに、IETFは実際にはエンジニアリング組織ではない。成功モードをたくさん追いかけているが、失敗モードはほとんど考慮されておらず、どのように対策を取ることができる・取るべきである。第二に、IETFは解決すべき存在論的(ontological)で認識論的(epistemological)な枠組みが無いという問題を抱えている。

本質的に、Martinの見解では、IETFはエンジニアリングと関係がなく、実際にはそうではあってはならない。

もちろん、最初の問題はMartinが正しい。しかしながら、二番目の問題は彼が大きな問題をほのめかしていると同時に、IETFの足元で間違って押し付けられている。三番目の問題は、Martianが提案する解決策では目の前の問題を解決できない点である。

まず第一に: Martinは正しい。IETFは混乱であり、失敗に関心を向けるよりも成功を追い掛けている。私は、これは大部分エンジニアリング・スキルの欠如要因だとは考えてはいないが、IETFへの取り組みに20年を費やした後では、問題を引き起こす多くのエゴがあるように思う。「誰も功績を認められる人を気にしないため、どれだけの仕事ができたか驚いている」と言う言葉は遠い昔のことで、それがIETFの真実だった。ワーキンググループとメーリングリストは、彼らがどのように賢く見え、何回勝利したか、名前の付いたドラフトの数が主な関心事項がある人の場になっている。もちろん、これは人間組織にはつきもので、現実のエンジニアリング作業のなぶり殺しである。

第二に、問題はIETF(だけ)ではない。問題は一般にネットワーク・エンジニアリングの世界である。何年も前、私はエンジニアリング社会に対して腹を立てて「あなたはエンジニアではないので、あなたの保証でエンジニアを使うことはできない。」と言った。今、彼らは狙いがあると思う。ネットワークキングの世界は、ラップシートメタル、プロセッサの設計、プログラミング、ネットワークの設計、コンソール・ジョッキーと奇妙な人々が入り混じっている。そして、我々はこれらの人々全てを「エンジニア」と呼んでいる。何人の人が、入力している(あるいは自動)CLI、あるいはチップセットの内部以上に何かを実際に知っているだろうか? 私の経験では、極わずかだ。

一方、一般にネットワーク工学や情報技術を守るためにここで言われるべき必要な何かがある。呼び出され、扱われる必要のある論法には2つの論理的な見落としがある。

最初の論点はこのようなものである:「しかし、私の父は飛行機修理士で、彼は認証が必要だった!」確かに、飛行機は珍しく、落ちれば人が死ぬ。サーバやネットワークは珍しくはなく意図的に構築され、アプリケーションに障害があっても人が死なないように意図的に構築されている。実世界がネットワークと交差する場所、特に人が住む境界では、障害が起きないようにもっと考える必要があるのは確かに事実である。しかし、大数の法則が正しい中心では、我々は境界ギリギリ失敗よりも過激な(rabid)成功について考える必要がある。

どんな場合でも適切とは限らないが、失敗の周りにエンジニアリングする多くの方法がある。エンジニアリングの一部は、全てのエンジニアリング問題が同じ方法で解決される必要があると仮定するのではなく、適切な問題設定を考える適切な失敗モードを適用することを学ぶべきである。

第二の論点は次のようなものである:「しかし、飛行機は落ちないなら、我々は考え方の航空方針を採用すべきである。」これを言うのは申し訳ないが、最も正確なエンジニアリングでさえ実世界に直面して失敗する。次の例はいかが? おそらく、これ、あるいはこれ、あるいはこれ、あるいはこれが起こるだろうか? 明確な考え方は、実際に有していない神秘的雰囲気を伴う他のエンジニアリング世界を植え付けることで始まらない。

第三に、提供されるソリューションは実際には役立たない。あなたが珍しいものに対処する時、それらが落ちてきて人が死んだ時に、ライセンス契約はふさわしい。しかし、多くの場合、ライセンスは利用できる人材プールを制限し、価格を引き上げながら品質とイノベーションを実際に低下させる理由となる。どこかでバランスが必要である。そのバランスはおそらく実世界の中に到達するのは不可能だろう。しかし、我々が試すべきではないと言う意味ではない。

何がなされるべきか?

IETFを扱うだけなら、いくつかの実践的なものが役立つかも知れない。

第一に、文書がワーキングループの文書にするなら、編集者/寄稿者モデルに移行すべきだ。個々の著者は仕事がコミュニティに移った時に消えるべきで、仕事は少数の個人ではなくチームの仕事に移行する。言い換えると、ゲームからエゴを取り除き、うまくいった仕事を誇りに置き換えるためにできることをやる。

第二に、標準は失敗モードが何か、設計者がどのようにこれらの失敗モードに取り組むことが期待されるかを明示的に呼び掛ける必要がある。特にエッジ・コンピューティングにとって、「さらにいいものを構築し、デプロイする」が選択肢ではない。中心に全ての技術を置くことでごまかすのではなく、もう一つの道を見つけるというIPパラダイムが働くとしたら、これは取り組む必要性のある重要な領域である。

第三に、IETFはIRTFを強化する必要があり、必要なエンジニアリングの種類と、様々な種類のエンジニアリングの共通部分がどこでどのようにが見えるか違いを定量化する方法について考え始める必要がある。あまりにも頻繁に、我々IETFは、どの町で会議を開催するか見極めるために多くの時間を費やし、結局は提案されていないもっと大きな問題をそのままにしてきた。我々は一つの勝者を欲し、巨大なベンダーあるいは部屋の中で最も政治的に結びついた人物の利益になるよう幅広い問題を受け入れることができない。

第四に、IETFはその境界が何か理解することを学び、諦めることを学ぶ必要がある。例えば、私は何百ものYANGモデルがあることを考えると、オープンソース・コミュニティが何をすべきか(できるのか)、何が標準になるべきかとの間の曖昧な境界線をどこに置くかについてどこかで何らか根本的な間違いをしているのではないかと疑わしく思い始める。おそらく、モデルを支えるために使われるプロトコルは標準であるべきで、オペレータがプロトコルについて調査できると期待するものは標準の一部であるべきで、モデリング言語は標準にしなくてはならない。しかし、モデル自身のアウトラインは加速する市場の力に委ねるべきだろうか?

巨大コミュニティの中では、私が何年も話していることを変更するつもりはない。我々は成長し、本当はエンジニアになる必要がある。製品ラインとCLIに焦点を当てるのをやめ、ネットワークがどのように実際に動いているのか学ぶことに焦点を当て始める必要がある。私はこの場所で一つのプロジェクトに取り組んでおり、アイデアを持っているが、今のところ、私がいつこれまでに指摘してきた同じ方向を指し示すことができるだけだ。

LinkedInでネットワーク・アーキテクトのラス・ホワイトによる