放置しすぎた。 まめに書かなくては。

netbsdメーリングリストでroute6dのバグについてのメールがでていた。bind()した後でsetsockopt(IPv6のみ)しているのでうまく動かんとのメールだった。

大御所がいるので、黙っていたが案の定大御所からレスポンスがあり、結局setsockopt()の後でbind()するのが正しいという結論になる。

よほど変わった実装のカーネルで無い限りbindの後にIPv6オンリーにsocketを変更できないのはあたりまえのように思う。

VoIPによる110番,119番のトラフィックの誘導はSIPやH.323のサーバで可能。

関係省庁間の通信はVPNなりのトンネルでやっていただいて、そのトンネルに対して帯域制御するかな。

出張者サポートはどうしようかな。事前に固定割り当てトンネル張っておくかな～

wideのIAAみたいなやつは参照系と登録系で分けて考えないといかん。現在のバージョンのIAAはどちらもHTTPだから大きな違いはないが将来はわからんな。

• 参照系 共通アドレスで空いてる(ネットとサーバ負荷)サーバへ誘導
• 登録系 共通アドレスで空いてるサーバもしくは近いサーバに誘導(どちらがいいかなー)

流量制限はどうしようか、tcpのハンドシェークで制限するか?

tcpのkeep aliveとかやられると帯域占有されて困るからサーバ側に協力してもらわないとだめだな

当面の課題は介護などのアプリケーションサポートか....

任意の2点間の通信に対して帯域確保するのはいややな

やはし電話系とか電波系のvoiceコミュニケーションに関する話題 てんこ盛りなれど新しい知見があまりないぞ～

インターネットでの緊急通信関連WG ieprepの ドラフトをIETFの準備として読んでいるが、 どーもいまいち｢なんだかなー｣という気持ちに させられる。

｢帯域の確保と不正アクセスの防止をしろ｣はわかるが それをどうやるのかが問題なのになー。 そこがなにも書いてないわ。

コストが安く スケーラビリティのある方式が必要だと思うが、 そこはなぜか避けられている雰囲気ありあり。

IETFの準備の残項目(金の手配,ID読み込み)のうち金の手配のめどが たっていな～い。

なさけなさすぎ

IETFの準備で関連WGのID全部読まんといかんのにぜんぜんはかどらん

ちなみにieprepでごわす。

参加費$600の当日払いの円立て価格はいくらだろうか。

ちゃんとした飯を食った (ミラノ風カツレツ) 大学内にあるホテル系列のレストラン

飯時にインターネットセキュリティ関連の研究者とお話した。 (IPsecとかX509とかいろいろ)そのとき、リゾルバのホールの話になり、BSD以外の対応について皆でちょっち心配する。

今日は帰りに預金残高の確認が必要だ。IETF当日参加料金と旅費の立替払いはビンボー人にはつらいぞ