IETF 117 現地参加記 Vol. 7 美味しい食べ物と美しい街並み！

この度，JPNIC様の国際会議参加支援プログラムにご採択いただき，IETF 117に現地参加させていただける運びとなりました．

2023年度 IETF参加支援 - JPNIC

初めての渡米，初めてのIETF Meetingということで，可能な限りの情報をここに残しておきたいと思います．

このページでは，これまで記さなかった範囲のごはん・観光に関する情報を記します．

その他の記事は以下よりご覧いただけます．

tamasan238.hatenablog.com

真面目な記事が続いて，少々退屈させてしまったかもしれません．
今回の記事は，美味しいものがたくさん登場します！

Egg Benedict

こちらも念願のエッグベネディクト！
ホテルの近くのダイナーでいただきました．
軽食のつもりでしたが結構量があり，お腹いっぱいになりました．
日本のカフェで頼むと，この1/4の量で提供されると思います．

奥にあるのはハッシュブラウン．えぇ，じゃがいもです．

New Participants' Dinner

会期中，New Participants' Dinnerという新規参加者向けの夕食会が開催されました．
こちらは事前にAttendee Dashboardからチケットの購入が必要です．

用意されているテーブルが少ないので，半ば強制的にグローバルなメンバーでお食事をいただくことになります．
日本人メンバーは，JPNICの花井様・五島様，そしてソフトバンクの藤田様がいらっしゃいました．

ここで初めて年確されてちょっとびっくり．パスポートは常に肌身離さず持ち歩いていたほうが良さそうです．
チーズケーキが美味しかった！

健康的なお皿ですね．

2回目のSuper Duper

水曜日のランチは，WIDEなたくあんさんとソフトバンクの藤田様と再びSuper Duperへ訪れました．
私の身の回りにはNWの話が通じる若い方が多くないため，新鮮でとても楽しかったです．

前回より量多かった気がする．

X社 (旧Twitter社)

Super Duperでのランチの後は，何かと話題のX社を訪れることに．
届け出をしておらず，地元当局に工事を止められた"er"ボードを見ることができました．

er

Social Event at SF MoMA

その日の夜はSocial Event！
こちらもAttendee Dashboardからチケットの事前購入が必要です．

たくさんのお料理．和/洋/中/...もっともっとたくさんありました．

皆さまとのお話のほか，自転車で氷を砕いたり，MoMAの展示を楽しんだり．

ジュースだと思ってtryしたら，しっかりお酒でした...！

あまり写真を取っていなかったのが悔やまれますが，とても楽しませていただきました．

Beanstalk Cafe

翌日のお昼は，2日目とは異なるカフェに赴きBagelを．

これがまた最高に美味しかったです．

ベーグルの種類は，店員さんおすすめの"Everything"

Cable Car Museum

ランチの後は少し時間がありましたので，近くのケーブルカー博物館を訪れました．

博物館とありますが，入場は無料．誰でも自由に入れます．
サンフランシスコを走るケーブルカーの動力部を間近に見ることができます．

すべての路線へ繋がっています．

これで地下に埋設されたケーブルを
掴んだり離したりしてコントロールするそうです．

研修を受けても，実際に運転が認められるのはわずか数名の狭き門なのだとか．

こちらがケーブルカー．

Mel's Drive-In

この日の夜は，いかにもアメリカンな雰囲気のお店に連れて行ってくださいました．

初めてのミートローフ．日本のハンバーグとも少々似ていますが，より肉々しさを感じました．

本当にどこに行って何を頼んでもポテトが出てきます．

Continental Breakfast

会期中は，以下のような軽食がちょこちょこ出てきます．
ありがたいですね．

どれも美味しいんです．

コーヒーとともに．

Fisherman's Wharf

最終日はお昼ちょっと過ぎに終わります．

GMOサイバーセキュリティ byイエラエ株式会社の菅野さま・酒見さまとフィッシャーマンズ・ワーフを訪れました！

The 観光地，という混み様．

トリが堂々と闊歩しています．

Oh...

本来はアシカが数百匹に及ぶほどたくさんいるらしいのですが，この日は4匹だけでした．

暑そう．22℃くらいだったんですけどね．

ニンゲンのほうが圧倒的に多かったです．

先に見えるのは，アルカトラズ島でした．

きっと島からもこちらが見えるはず．
囚人にとってはさぞ残酷だったことでしょう．

ふと振り返ってみると，サンフランシスコがいかに傾斜しているかがよく分かります．

お兄さん，驚かせてごめんなさい．

お昼ごはんには，海沿いのテラスで名物のクラムチャウダーを．
しっかり海鮮の風味を感じる，とても美味しいクラムチャウダーでした．

溢れるほどたっぷり入ってます．

せっかく来たからにはシーフードをもっと堪能したい，ということで店員さんおすすめのプレートもいただきました．

美味しい海鮮たちに加えて，アメリカ生活初のライス！！

特に海老が最高でした．
ポテトに飽き始めていた私にとって，ライスがとても嬉しかったことを覚えています．

お食事を終え，中華街を経由してホテルに戻ります．

どこを切り取っても，見応えのある街です．

異質な雰囲気が漂います．

吉野家ではありませんでした．

君は本当に焼きそばなのか？

帰路には謎のオブジェが．

ホテルに近づいた頃，スーパーに立ち寄りました．

美味しそう...

家の近くにこんなスーパーがほしいです．

この日はここまで．
サンフランシスコ最後の夜に寂しさを覚えつつ，ホテルでぐっすり眠りにつきました．

菅野様・酒見様，ありがとうございました！

続きはVol. 8へ．
いよいよ最終章です．

tamasan238.hatenablog.com

IETF 117 現地参加記 Vol. 6 Plenaryで感じた，IETFの光と影

この度，JPNIC様の国際会議参加支援プログラムにご採択いただき，IETF 117に現地参加させていただける運びとなりました．

2023年度 IETF参加支援 - JPNIC

初めての渡米，初めてのIETF Meetingということで，可能な限りの情報をここに残しておきたいと思います．

このページでは，中日に行われたPlenaryに関することについて記します．
現状，うまくまとまっているとは到底言えないのですが，Done is better than perfect. の精神で暫定的に公開しております．

その他の記事は以下よりご覧いただけます．

tamasan238.hatenablog.com

Plenary

はじまりはじまり．

IETF Meetingでは，中日となる水曜日の最後のコンテンツとして "Plenary" (全体会合)が用意されています．

• ホスト(NOKIA)による挨拶
• IETF Chair・IESG・IAB・IRTF・NomComなど，関係各位による報告
• 関係者の追悼
• Open Mic Session

といった流れで進みます．

スライドは以下より参照いただけます．

https://datatracker.ietf.org/meeting/117/materials/slides-117-ietf-sessc-all-slides-ietf-117-plenary

今回のIETFは，ちょうどサンフランシスコマラソンの開催日と重複していました．
よって(?)その両方に参加した方には表彰が．

大きなメダルは，IETFのSecretariatの手で製作されたそうです．

また，今回のIETFでは託児サービスが提供されていたとのことでした．
お客様の声は大切です．

「ともだちとあそべて、とてもたのしかったです。」(職業：子ども，年齢：3歳)

さて今回のIETFには，日本から総勢60名程度の参加者がいたようです．

内訳は以下の通り．(数名の誤差を含む可能性があります．)

• オンサイト：40名
• リモート：20名

世界で6位の参加者数でした．

追って，これからの各組織のChairの紹介などが行われました．

Open Mic Session

この記事のメインコンテンツはこちらです．

一通りの発表が終わると，参加者が自由に発言してChairたちと対等に議論できるOpen Mic Sessionが始まります．

まず，こういった取り組みがなされている事自体に驚きました．
参加者が集う中，Chairたちはいかなる意見や質問にも適切に応じなければなりません．
運営する立場に立って考えてみると，いかに難しいことであるか想像がつくかと思います．
時間内に収拾をつけなければならないプレッシャーは，相当なものであるはずです．

まず1人目は，リモート参加のお爺さまからでした．
異議申し立てをしているが，進展がない．どうなっているんだ，というご意見．
どうやらChairたちとのやり取りの中で齟齬が生じていたらしく，こちらは比較的スムーズに話が終わりました．

そして2人目は，NomComによって提供されていた会場ネットワークについての意見．
こちらもスムーズに終わります．

重要な問題はここからです．
次のご意見は，以下でした．

「Diversity and Inclusionと謳っているが，各組織のChairは“old white guy”ばかりじゃないか．何をしているんだ．」

ハッとさせられました．

今回のIETFでは "Diversity and Inclusion Sponsors" を募り，膨大な資金を集めています．
そして，確かについ先ほど発表されたChairたちの多くは“old white guy”ばかりです．
ぼうっとスライドを眺めて，「この人たちが次のChairなのか」と特段何も感じなかった自分を恥じました．

ここから，立て続けにとても多くの方々がD&Iについての意見を述べ，Chairたちとの議論が始まります．
以下に少しだけ，発表された意見やこれに対する返答を抜粋してみました．

なお，ここに示す内容は私が拙い英語力・記憶力でメモしていたものに過ぎません．
本来の意図とは異なる意訳が含まれている可能性が多分にあります．
ぜひ，アーカイブ映像をご参照ください．

IETF117-PLENARY-20230727-0030 - YouTube

一通りの引用の後に，自らの考えを示します．

事実，顔を上げてみると“old white guy”が多い．
しかし，候補者の殆どが“old white guy”という現状があり，そしてまたこちらから見ても“old white guy”ばかりであることも事実である．
ぜひ，同僚や身近な人をIETFに参加し，深く携わるように助言してください．
我々はIETFにおいてリーダーシップを張れる人材を求めている．
問題に対してお金を投じるだけでは解決しないと言わざるを得ない．
企業からDiversity Moneyをもらっているが，企業はIETFに同じ人材を派遣している．
誰がIETFに送られるかによって決まることでもある．そして皆さんはたくさんのことができる．
我々が取り組める追加のアクションがあればぜひお知らせください．

なぜみなさんがテーブルに座っているのか より，
なぜテーブルメンバーが聴衆と同じように見えないのか ということだろう
座っているみなさんはとても頑張っている．
しかし，聴衆にはもっと多くの女性や過小評価されている人々がいる．
ここのいる人々が同じ機会を確実に得られるためにはどうすればよいかを考えるのがよいかもしれない

私達は積極的に提案を求めている．
例えば，保育について提案を受け，これを確立した．
うまくいっているほかのイベントがあれば，知らせてほしい

いえ，それは資金が増えるだけである．
WGや運営で何が起きているか，内面を観察することが必要である．
解決不可能なものではない

時にはお金が役に立つこともある
例えば，クローズドキャプションがついており，これはほんの些細なことであるが役に立っている．

お金を投じるだけでは十分でない
しかし，予算と何をするべきかのアイデアがいることは事実だ．

例えば，50人をここに送ることにお金を使うのであれば，彼らがここに戻ってくる方法を見つけなければならない
文化，教育，...
新しい人は，1,2回の会議にしか訪れない．新しい人材の定着率を高める方法が必要である．

18人の手数料免除が行われたというが，ここにいる人数を鑑みるとそれは十分ではないと思う．
財務状況がどうなっているか分からないが，お金を持っていない人々がここに来ることを助けるために，もっとできることがあるだろう
部屋を見渡すと，全体的に高齢化が進んでいる．大学と連携して，もっと多くの大学生を受け入れられればより素晴らしいだろう．
新鮮なアイデア，新しい人々，とてもよい．
人材の維持について，もっとできることがあるだろう．

IETF Webサイトに書かれた内容を読んだ，運営方法についてすべてのRFCを読むことができるが，非常に大規模な組織なのでなかなか理解が難しい．
最初のミーティングでもっと協力関係を築くことが重要だ

• 誰がD&Iについて何らかの形で責任を負っているのか
• 誰のところに行けば，内密に議論することができるだろうか，
• 監視し，測定するために，私達は何をしているか

といった，基本的な質問について理解する必要があるだろう．

誰かが帽子をかぶらなければならない．”ここにいる誰か”が担当しなければならない．

エンジニアが出席するには，マネージャを説得しなければならない．
彼らはIETFを知らないことも多い．
エンジニアが出席することについて同意してもらい，これを維持することが非常に難しい

上席の人，つまり管理職の参加者が多い
彼らは若い同僚と働いており，決裁権を有している．
誰を来させるかについて，配慮が必要では

1回限りの参加者がいる理由について，調査をしているのか気になる．
ただ来てもらうだけでなく，継続して来てもらうことが重要
しかし2度目以降参加しない人は少なくない．
旅費，トレーニング，その他，何が要因なのか調べる必要があるだろう

RFCを公開するのに，平均して3年の時間がかかる．
1度会議に参加して，あと8回来なければならない．

インターネット協会は以前，技術フェロープログラムを運営していて，目標の一部を達成した．
しかし，様々な理由からこれは中止された．
LLCが同様の取り組みを行えるかについて議論したが，多額の投資となるため，資金が不足してしまう．
また，フェローの選出にはプロセスが必要．

単に予算を上げてレバーを動かすことで解決するような問題ではないことは承知している．
アウトリーチはよいこと．ただし，そこには構造的な問題がある．
多様性を確保するには，桁違いの規模の資金が必要

大雑把にまとめると，以下のようになるでしょうか．
うまくまとめきれた自信がありません．

• 今回のChairメンバーに多様性が欠けていると言われる直接的な要因は，そもそもChair候補者が"old white guy"ばかりであったことである
  • スキルをもつ，多様な候補者を求めている
• 予算は重要だが，お金さえあれば解決する問題ではない
  • ともにアイデアを出し合い，解決に繋がる建設的な議論を経るプロセスが重要
• 参加者の高齢化が進んでいる
  • 管理職や上級技術者ばかりとなっている
  • 参加に要する費用が年々増している
    • 参加登録費だけでも倍増している
    • RFC公開には平均3年，つまり9回の会議に参加しなければならず，負担が大きい
    • エンジニアが出席することを承諾してもらい，これを維持することはとても難しい
• 1回きりの参加者が多い

少し本題から逸れますが，昨今，著名なOSSであっても収益化が難しく開発を取りやめるケースが散見されます．
これに対して，私が長期インターンシップでお世話になっているwolfSSLでは，

• 個人利用・検証目的のためのオープンソースライセンス (GPLライセンス)
• 商用利用のための商用ライセンス

のデュアルライセンスモデルによって存続を可能とし，さらなる発展につなげています．

そうした観点でIETFを覗いてみると，果たして持続可能な取り組みと言えるのか疑問を感じました．
スポンサーシップや寄付に頼ったアクティビティには，どれほどの公共性があったとしてもいずれ限界が訪れることはいくつものOSSプロジェクトが証明しています．

利益に直結するとは言い難いIETFは，経済的に余裕のある企業や人材，すなわち"white old guy"やそれに準ずる方ばかりとなっているのではないでしょうか．
このような組織で，多様性を実現するにはどうするとよいか．
簡単な問題でないことは明らかですね．

「多様性を確保することは急務」とよく言われていますが，現場に立つ人からしてみれば最低限のスキルを持ち合わせていることは必須条件であると考えます．
無論，そうしたスキルを持っている人材がいるのであれば，そうした方を組み込むことで素晴らしい組織が出来上がることに異論はありません．
しかし，現在のIETFのようにそもそも候補者自体が偏ってしまっている現状があるのであれば，むやみやたらと構成人数におけるマイノリティの少なさを糾弾するのではなく，

1. そうした方々にアウトリーチして，
2. トレーニングを提供し，
3. さらに上のポジションを望む人には，より高度なトレーニングを提供することで素養を持つ人材を育成する

といった取り組みが必要だと考えます．
問題を把握した上で，いかに建設的な意見を作り出せるか．難しいですね．

またIETFにおいては，主目的である議論以外にかかっているコストが非常に大きいのではないかと感じました．
本質的でない部分にかかるコストを抑えることで，本来のターゲットであろう次なるインターネットを作り上げる人材が参加しやすい，発言しやすい環境を整備することが必要だろうと考えた次第です．

ここまで本格的な議論を目の当たりにしたのは初めてで，度肝を抜かれました．
新卒採用でもよく目にする "Diversity & Inclusion"．
単に言葉で遊んでいるだけに留まってしまわないよう，我々1人1人のアクションが大切だと感じた1件でした．

続きはこちら．
紹介しきれていないIETF期間中のごはんや，Fisherman's Wharfについての記事です！

tamasan238.hatenablog.com

IETF 117 現地参加記 Vol. 5 WG Meetings

この度，JPNIC様の国際会議参加支援プログラムにご採択いただき，IETF 117に現地参加させていただける運びとなりました．

2023年度 IETF参加支援 - JPNIC

初めての渡米，初めてのIETF Meetingということで，可能な限りの情報をここに残しておきたいと思います．

このページでは，本イベントにおけるメインコンテンツWorking Group Meetingsに関する情報を記します．
なお，本記事は気になる箇所だけをかいつまんでご覧になることをおすすめします．
次のVol.ではPlenaryにて多様性尊重に関して考えたことを記し，その後にはFisherman's Wharf観光などについて記す予定です．

その他の記事は以下よりご覧いただけます．

tamasan238.hatenablog.com

WG Meetings

いよいよIETF Meetingのメインコンテンツ，WG(Working Group)ごとの会合が始まります．
気になったものを抜粋してまとめてみました．

と，その前に，今回初めて対面でRFCの議論の場に参加して，どのように内容を理解したのか，どのようなことを感じたか簡潔に示します．

• 基本的にはHedgeDoc(リアルタイムで記される議事録)を段落ごとに翻訳して雑感を把握します．
  • 書いてくださる方によって，理解のしやすさには結構揺れがあります．
• 関連する技術について調べながら，まとめてゆきます．
• 会場が沸いたときには，MeetechoのCCを適宜翻訳して理解の支えにします．
  • 自分で有効化しないと表示されず，有効化前のCCは表示されないので要注意です．
  • 特にWi-Fiが落ちてリロードしたときに忘れやすい．
• 英語を母国語レベルですんなり理解できる人と比べ，あくまで私の場合ですが発表内容の理解には概ね2倍程度の時間を要すると感じました．
  • 1セッション中，2件目の発表が終わる頃にようやく1件目の趣旨が理解でき，質問が湧いてくる，といったイメージです．
  • 無論，これは経験値や英語力，技術力によって多分に左右されます．
  • 聞き取ることができても，そもそもの技術や背景を把握しきれていなければ喋っていることを"理解"することはできない
    • プログラムコードは共通言語．
• これはJPNICの木村様より事前に教えていただいていたことですが，
  ある程度方向性が固まっているDraftについては(他と比べて)盛り上がるような発表・議論は行われませんでした．
  • 序盤〜中盤くらいのものだと，よりリアル参加のメリットを享受できるなと感じました．
    • 目安として，発表時間20分程度の枠でしょうか．

以降，大見出しがWG名，中見出しが発表タイトルです．
簡単な日本語タイトルも添えています．

Domain Name System Operations

Updates on draft-ietf-dnsop-cds-consistency

日訳：IETFドラフト，Consistency for CDS/CDNSKEY and CSYNC is Mandatoryに関する最新情報

https://datatracker.ietf.org/meeting/117/materials/slides-117-dnsop-updates-on-draft-ietf-dnsop-cds-consistency-00

Compact Denial of Existence in DNSSEC

日訳：DNSSECにおける処理負荷の小さな不在証明

https://datatracker.ietf.org/meeting/117/materials/slides-117-dnsop-compact-denial-of-existence-01

NXDOMAINを利用するか，ENTシグナルを利用するか，いずれにも対応すべきか...
NS1：ENTを利用
Cloudflare：NXNAMEを利用

Authentication and Authorization for Constrained Environments

EDHOC (Ephemeral Diffie-Hellman Over COSE)

https://datatracker.ietf.org/meeting/117/materials/slides-117-lake-draft-ietf-lake-edhoc-00.pdf

COSE：CBORオブジェクトの署名・暗号化アルゴリズム
CBOR：RFC8949，データ交換フォーマットの1つ．JSONなどと違ってバイナリで表すため，バイナリデータをいちいちエンコードする必要がなく効率的．IoT向け．

Lightweight Authorization using EDHOC

日訳：EDHOCを用いた軽量な認証

https://datatracker.ietf.org/meeting/117/materials/slides-117-lake-lightweight-authorization-for-edhoc-second-version-00.pdf

COSE (CBOR Object Signing and Encryption)

COSE IETF 117 - HedgeDoc

セコムの磯部様による発表もございました．HPKE関連の発表があり，関心を抱く．

ACME (Automated Certificate Management Environment)

Automated Certificate Management Environment (acme) - HedgeDoc

QUIC

Multipath extension for QUIC

https://github.com/quicwg/wg-materials/blob/main/ietf117/multipath.pdf

マルチパス実装がすでに5つあり，相互接続性についての検証を実施中．

PATH_STATUSはavailable, standbyの2つだが，本当にこれで良いのか
→前回のミーティングから新しい情報はない．これ以上増やすと冗長．

エラーコードが1つだけだが，よいのか
→理由はreason領域で示せばよい．ここでこれ以上増やすべきでない
→デバッグ用にあってもよいのでは
→週末にもう少し詳しく話そう

PATHをコネクションから分離させては(パケットNo. を含むQUICパス)
→あまりに破壊的な変更
→アイドル状態のコネクションにより，メモリが圧迫される
 →続きはGitHubで

経路と暗号化キーに関しては分けて考えるべきとの声
(複数のencryptコンテキストがあると，メモリの使用量が大幅に増加する)

Resetting and Closing Streams

https://github.com/quicwg/wg-materials/blob/main/ietf117/reliable-resets.pdf

RESET_STREAMフレームを送信すると，当該ストリームではデータは再送されない．
これに対して，ロスデータの再送は行わせるのが今回の提案
あらゆる再送を受け付けるわけではなく，CLOSE_STREAMフレームで許容する量を示す
- RESET_STREAM：一切受け付けない
- CLOSE_STREAM：以降，指定した量の再送を許容する
- STREAM (with FIN bit)：まだまだ受け付ける

フレームタイプサイズは1byteでよいか
→1でよい．2でもよいがそんなに使わない

適用したv2を作ってプラハに持っていく
思っていたより早く実装/相互接続の検証が行われていて驚いている，よい．

Post-Quantum Use In Protocols

最近流行りのポスト量子(耐量子)系ですね．

Post-Quantum Cryptography for Engineers

日訳：耐量子暗号入門

https://datatracker.ietf.org/meeting/117/materials/slides-117-pquip-post-quantum-cryptography-for-engineers/

PQCを理解するための，大変分かりやすいなと感じた資料です．

IETF117-PQUIP-20230725-2000 - YouTube

上記動画でCCをつけてご覧になると，より理解しやすいかもしれません．

Post-Quantum Cryptography at Google

日訳：Googleにおける耐量子暗号の運用状況

https://datatracker.ietf.org/meeting/117/materials/slides-117-pquip-post-quantum-cryptography-at-google/

Terminology for Post-Quantum Traditional Hybrid Schemes

日訳：耐量子暗号と従来の暗号のハイブリッドスキームに関する記述について

https://datatracker.ietf.org/meeting/117/materials/slides-117-pquip-pqt-hybrid-terminology/

Crypt Forum

A Modest Proposal for HPKE

日訳：HPKEへのささやかな提案

https://datatracker.ietf.org/meeting/117/materials/slides-117-cfrg-deterministic-nonce-less-hpke/

TLS (Transport Layer Security)

A well-known URL for publishing ECHConfiLists

日訳：ECH Config Listを取得するための Well-known URL

https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-draft-ietf-tls-wkech/

ECHを利用するとき，クライアントはpublic-name(カバーするホスト名)とprivate-name(真にアクセスしたいホスト)を用いる．
クライアントがpublic-nameを何にするとよいかはサーバによって提供されるech-configに格納されている．
これはDNSのHTTPSレコードで取得する．(A, AAAAレコードのWebサーバ向け拡張版？)

例えば，「https://draft-13.esni.defo.ie/.well-known/origin-svcb」で取得できるように統一しないか？

ECH SVCBドキュメントにマージするべき？
→誰も はい と言わず

ALPNはまだ修正されるかもしれない
(Webサーバの)同じDocRootからの異なるECHをサポートしないように編集する
443以外のポートでも動作するよう，Issue #12に対処する予定
次のドラフトが最終になるだろう．しかし，まだ作業する予定

このドラフトを認めるかの投票 → ほぼOK

ECH Update

https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-ech-update/

ECH：Encrypted Client Hello

TLS 1.2 is frozen

https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen/

とてもわくわくさせてくれるタイトルですね．
以下，聴講時のメモです．

TLS 1.2を凍結しよう

• 新しいアルゴリズムを追加しない
• ALPN, Key Exporterラベルは追加可能
• それ以外の新しいエントリは認めない
• 新しい技術はTLS 1.3以降用であることを示そう
• すなわち，耐量子技術はTLS 1.2では実装されない．

他のプロトコルへの影響

• MUST say TLS 1.3
• デプロイにあたって懸念事項がある場合は，TLS 1.2と示すことも可能

反応

• not “MUST TLS 1.3”, “MUST TLS 1.3 or newer”
  1.3と示されたすべてを書き換える必要があるね
• TLS 1.2に致命的な欠陥が見つかったら，IETFはどうする？
  わからない，1.2を使うのをやめると言うかもね
• WGの”感情”を外に伝える，よいdraft
• TLS 1.2への機能追加を予定していないことを示すには，
  「frozen」は「do not touch」よりも適した表現だね
• TLS 1.2の機能に依存している企業が，新しい機能を必要としたときに拒否される
• 一部の機能は1.2から動けず，1.2をサポートしなければならない現状がある
  それらの企業が1.3に移行するには，まだ時間を要する
• 現在の検証で，既にTLSの古いバージョンへの更新を禁止している．RFCは必要なのか？
• Enterpriseはなかなか移行しないよ x N人
• だからこそ，このRFCがいる
• 「あなた達は移行しなければならない，価値が下がる」と伝えることに意味がある

57件の投票に対し，14件の反対
新しいドラフトを書いて，リストに確認します．とのこと，

New Post-Quantum Signatures on the Horizon

日訳：新しい耐量子署名アルゴリズム

https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-post-quantum-signature-algorithms-on-the-horizon/

利用しやすい完璧な耐量子署名アルゴリズムはまだ存在しない．
ただ，いくつかのスキームはTLS/WebPKIに移行するより容易に利用可能
まだまだ多くの検討が必要

詳細：Post-Quantum signatures zoo

HTTP about using exported authenticators

これに関しては，予定されていた発表が一通り終わった後に「今思いついたんだけどさ」と口頭で発表・議論が始まりました．
こういったことが起きるのが面白いですね．

概要だけ示します．

Exported Authenticators in TLSについて，クライアントがサーバーから証明書を要求されずに証明書を送信できるようにするのはどうだろう

反応

• Exported Auth in TLSには unpromotedモードがあったが，削除した．
  必ずしも不可能ではないだろうが，削除したのには理由がある．
• early dataで送信されると，クライアント証明書が漏洩する．それはよくない

Abridged Certs

日訳：証明書の要約

https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-abridged-certificate-compression/

SAAG (Security Area Open Meeting)

Lessons from ACME

https://datatracker.ietf.org/meeting/117/materials/slides-117-saag-lessons-from-acme/

WHODIS (Wholistic Human-Oriented Discussions on Identity Systems)

https://datatracker.ietf.org/meeting/117/materials/slides-117-saag-whodis/

MLS (Messaging Layer Security)

祝，RFC9420！！
冒頭でシャンパンが配られました．

予想外の出来事に，ついXにポスト．

-mls-addl-creds

https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-mls-addition-credentials/

現状のクレデンシャル

• 0x0000 reserved
• 0x0001 basic
• 0x0002 x509

提案

• 0x0003 userinfo-vc
• 0x0004 multi
• 0x0005 weak-multi

userinfo-verifiable credentials

資格情報の新しい形式．ユーザに認証情報をより簡単に発行する方法

https://www.w3.org/TR/vc-data-model/ VCフレームワークに基づき，OpenIDプロバイダがMLSと互換性のある資格情報を発行できるようにする．
例えば，Webexミーティングを開催しているとき，MLSを利用してユーザの資格情報を提示できるようになる．
相手側企業のSSOプロバイダに直接聞くため，Webexが何者かになりすましていないことがわかる．

multi, weak-multi

他のタイプの資格情報をいくつか組み合わせて，単一グループ内の単一クライアントに対して複数の資格情報を提示できるようにする仕組み．

特定のセッションで同一のクライアントに対し複数の資格情報を提示したい場合がある．
例えば，このハンドルネームを有していることを示す証明書，
この電子メールを所有していることを示すVC資格情報，といったように．

multi：すべてのクレデンシャルをサポートしなければならない
weak-multi：いずれか1つのクレデンシャルをサポートしなければならない

反応

• 循環参照に陥らないか？
  → multi-in-multiを禁止すべきだね

反対0

Lots of Proposed MLS Extensions

日訳：たくさんのMLS拡張に関する提案

https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-lots-of-proposed-mls-extensions/

MLS Extensions

https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-status-on-mls-extensions/

一通りのupdate．

Gurdianship for MLS

https://datatracker.ietf.org/meeting/117/materials/slides-117-mls-guardianship-for-mls/

HTTP (Hyper-Text Transfer Protocol)

Discovering WebSockets over HTTP/2 and HTTP/3 Design Team Report

日訳：HTTP/2，3におけるWebSockets

https://datatracker.ietf.org/meeting/117/materials/slides-117-httpbis-websockets-design-team-report/

Secondary Certificate Authentication of HTTP Servers

日訳：Webサーバにおける2つ目の証明書認証

https://datatracker.ietf.org/meeting/117/materials/slides-117-httpbis-secondary-certificate-authentication-of-http-servers/

DMARC (Domain-based Message Authentication Reporting and Conformance)

Food For Thought

日訳：議論のために．

https://datatracker.ietf.org/meeting/117/materials/slides-117-dmarc-ad-slides/

DMARC WGができてから9年経った．
成果を上げていないWGを終了する圧力が高まっている．
次のエリアディレクターはもう我々の活動を認めないかもしれない
このWGのエネルギーを他のプロジェクトに費やしたほうがよいのではないでしょうか．
「我々のWGは役目を全うしたのではないか」

WG Meetingについてはひとまず以上です．

続きはこちら．

tamasan238.hatenablog.com

IETF 117 現地参加記 Vol. 4 プレIETF

この度，JPNIC様の国際会議参加支援プログラムにご採択いただき，IETF 117に現地参加させていただける運びとなりました．

2023年度 IETF参加支援 - JPNIC

初めての渡米，初めてのIETF Meetingということで，可能な限りの情報をここに残しておきたいと思います．

このページでは，渡航後2日目の情報を記します．

その他の記事は以下よりご覧いただけます．

tamasan238.hatenablog.com

朝ごはん

こんなに早く目が覚めるとは．

6:30に目を覚まし，向かったのはPosh Bagel．
私がアメリカで絶対に食べたいと思っていた食事の1つです．

本場のベーグル．

ここではどのベーグルに何を挟むのか自由に選ぶことができます．
ぜひGoogle Mapsのレビューをご覧になってください．
今回私は，たまご・チーズが挟まったセット(名前は忘れました)を頼みました．
ベーグルの種類も選べることを知らなかったので，おすすめは何かと尋ねてセサミを選択．
期待していた通り，とっても美味しかったです．
ここはどこかのタイミングでもう1回行きたかった！

ホテルに戻って，Registration

お腹を満たしたら，ホテルに戻ってIETFのRegistrationを行い...たかったのですが，まだ時間になっていなかったので自室へ．
ちょうど前週がドタバタでスケジュールを把握しきれていませんでしたので，ゆっくり腰を据えて1週間の流れを整理することにしました．
結果，こんな感じに．もちろんこの通りに進んだわけではないのですが，暫定的に見通しを建てることができました．

ギッチギチ．途中まで参加して気づきましたが，
すべてのセッションに参加するには相当の体力が必要です．
1週間を完走するためには，多少の休息を挟むことが不可欠だと感じました．

そうこうしていると10:00になり，Registrationも始まりましたので会場に向かいます．
なぜか私のネームプレートが見つからず，少々時間を要しました．

写真撮影の可否が分かりやすくてよい．

COVID対応もしっかりと．

Language Buttons

扱える言語や，社会的距離に対する考えを示すバッジが用意されています．
パッと見の印象で「お，日本語通じるかな？」と話しかけてみると台湾からいらしている方だった，なんてこともありましたので，こういったグッズは助かります．

完成形

IEPG (Internet Engineering and Planning Group) ミーティング

IETFのコンテンツが始まる前に，IEPGミーティングというものが行われていましたので，足を運んでみました．

JPNIC様の用語集では，以下のように解説されています．

IEPGは、インターネットがグローバルに相互接続性を持って運用されるための調整を行うインターネットオペレーターのグループです。

Agendaはこちら．

私が聴講したのは以下の2つです．
なお，特にこのミーティングに関してはほぼ予備知識のない状態で聴講しております．
私の理解や解釈が誤っている可能性も充分考えられます．
お気づきの点がございましたら，本記事下部のコメント欄よりご指摘頂けますと幸いです．
(はてなIDでログインいただく必要がございます．)

Enhancements to BMP implementation in FRRouting

日訳：FRRoutingへのBMP実装

https://datatracker.ietf.org/meeting/117/materials/slides-117-iepg-sessa-enhancements-to-bmp-implementation-in-frrouting

OSPFなどを容易に試せるFRRoutingというソフトウェアがあり，これにBMP(BGP Monitoring Protocol)を実装しているよという紹介＆進捗報告でした．
以下のページの解説が分かりやすく，理解の支えになりました．

ネットワーク勉強の続き - 2: FRRouting(FRR)/OSPF入門

BGP Attribute Escape

日訳：BGP属性の漏出

https://datatracker.ietf.org/meeting/117/materials/slides-117-iepg-sessa-bgp-attribute-escape

BGPパス属性が意図しない範囲に伝播してしまうことがあるようです．
こちらへの対応をBGP RFCで明文化しないか，という趣旨だと解釈しました．
非常に理解が怪しいです．詳しくは上記スライドをご参照ください．

New Participants' Overview

IEPGミーティングが終わるのが12:00，次のミーティングが行われるのが12:30という非常にタイトなスケジュールです．
昨日の残りでサクッと昼食を済ませ，そそくさとNew Participants' Overviewへ向かいます．
IETFに初めて参加する人向けのチュートリアルのようなものです．

• IETFとは
• IETFで重要とされていること
• Meeting期間中に行われること
• 利用可能なリソース (スタッフ，ツール，その他)
• 新規参加者向けイベントの紹介

などについての説明がありました．
急にIETF Humの練習が行われて，びっくり．

[参考] IETF Humとは

最近はMeetecho上の投票機能によって取って代わられつつあるようですが，旧来よりIETFではミーティングの場における合意形成に「ハミング」を用いているのだそうです．
参加者の多くはベテランエンジニアですので，ﾌﾝﾌﾝﾌ~ﾝ♪ と軽快なものではなく，ﾌﾝ----⤵といった感じのようです．結構シュールですよね．

Hackathon Results Presentations

https://github.com/IETF-Hackathon/ietf117-project-presentations

IETFでは「実際に動くコード」を重視する文化があります．
そこで，様々なテーマを持ち寄って興味を持つ人達で実装を進めようという趣旨で，WG Meeting開始前の土日にハッカソンが行われています．

今回私は時間の兼ね合い(そして技術力の不安)からハッカソン本体には参加しませんでした．
しかしどのようなことが行われているのかは気になりますので，成果発表は聞いてみることに．

ハッカソン会場でそのまま発表が行われ，聴講席はありませんでしたので自室よりMeetechoにて拝見しました．
みなさん難しいことをしておられる...と眉間にしわを寄せて拝見していると，なんと日本人のお若い女性の方が．
GMOサイバーセキュリティ byイエラエ株式会社 酒見様でした．界隈では「暗号のお姉さん」と呼ばれているそうです．

Welcome Reception

そうこうしていると，いよいよWelcome Receptionの時間です．
いわゆる立食パーティですね．

概観(これからどんどん増えていきました)

日本人も数十名いるはずなのですが，なにぶん全体の参加者が多くてなかなか見つからない．
木村様が様々な方をご紹介くださり，なんとかご挨拶をさせていただきました．
ありがとうございました．

このとき，

• 何をしている人なのか
• 何のために(何の目的で)IETFに来たのか
• 特にどのWGに関心を抱いているか，それはなぜか

あたりはさらっと喋れるようにしておくと，会話をよりスムーズに進められたなと感じました．
お互いに知見をもっている範囲のお話だとより盛り上がりますので，学生であっても名刺があると役に立ちそうです．

Hot RFC Lightning Talks

話に花の咲き出した頃，別の会場でHot RFC LTが始まりました．
Welcome Receptionが2時間あるのですが，開始からちょうど1時間経つともう始まりますのでドタバタです．少々遅刻しました．

ここでは，いわゆる "アツい" RFCがいくつか取り上げられます．
IETF Meetingに興味の湧いた方は，まずこちらの発表をご覧になるとよいかもしれません．
どういったレベル(深さ，広さ)で話があるのかをなんとなく掴めた気がします．

アーカイブ映像はこちら．

IETF117-HOTRFC-20230724-0100 - YouTube

なお，英語に抵抗がおありの方や，パパッと読みたいよという方は少々お待ちください．
おそらく後日木村様が，とても分かりやすい資料を上げてくださるかと思います．

https://www.nic.ad.jp/ja/mailmagazine/backnumber/ietf.html

とはいえ，せっかくですので私も気になったものを取り上げてみます．

Encrypted Client Hello Deployment Considerations

日訳：ECHの普及に向けての懸念事項

https://datatracker.ietf.org/meeting/117/materials/slides-117-hotrfc-sessa-10-ech-deployment-considerations-00

Encrypted Client Helloとはその名の通り，TLSにおいて用いられるClient Helloを暗号化しようという技術です．
もう少し掘り下げると，Client Helloに含まれるServer Name Indicationを暗号化することで，「どのサーバに対して通信を開始しようとしているのか」を秘匿しよう，というものです．

悪意のある人や情報統制を行う国家などにアクセス先を知られないために，非常に有用な技術に思えます．
しかし，必ずしもそういった目的にのみClient Helloの情報を利用しているかというと，そうではないようです．
実際にClient Hello内の情報を用いてフィルタリングなどを行っているアプリケーションは存在しており，これが動かなくなると困るという方々もいらっしゃるわけですね．

ただ，発表を聞く限り，善良な目的のためにClient Helloを見ている実装は他の方法で代替することができるそうです．
そうは言っても，実際にデプロイするにあたって障壁となることは事実である(だから，そのあたりも考慮しつつ策定を進めていく必要がある)という趣旨だと解釈しました．

Steak Dinner :)

Hot RFC LTが終わると時刻はもう20:00．立食パーティで軽食をつまんだとはいえ，お腹の空く時間帯です．

嬉しいことに，お食事に連れて行ってくださいました．

Appetizer

恐るべし破壊力．

デザートの後には食後酒まで．

これが本当に美味しくて...！
一切の誇張なしに，これまで生きてきた中で最も美味しいお食事でした．
Appetizerで頂いたビーフパテ(?)はこれまで口にしたことのない食感・味．
うまく言葉にできませんが，あれは無限に食べられます．一緒に提供されたチップスやソースとの組み合わせも試しながら，美味しい赤ワインも頂いて．
そしてメインのステーキはとてもやわらかく，ちょうどよい加減のシーズニングが施されています．ひとくち食べると，もう顔が綻びます．
そしてしっかり量がありまして，まさに夢の中にいる気分でした．
デザートにさっぱりとしたレモンのジェラートをいただき，最後には初めての食後酒．

薄暗く落ち着いた雰囲気の店内に，ここは本当にアメリカかと疑いたくなるほど丁寧な応対をしていただけるウェイターさん．
何もかもが最高でした．

食事を終える頃には辺りは真っ暗．街頭の光はありますが，ホテルまでの経路にテンダーロイン地区を含んでおり，徒歩や公共交通機関の利用には危険が伴います．
Lyftを呼んでホテルまで戻ることになりました．
するとやってきたのはまさかのTesla！
ドライバーさんとの話もはずみ，EVならではの加速も体感させてくださいました．

ブレブレですみません．

at Lobby Bar

ホテルに戻ると，ちょうどロビーにはNTTComのMさまを始めとする著名な皆さまが勢ぞろい．
少しだけご一緒させていただき，この日は夢見心地な気分で床につきました．

続きはこちら．

tamasan238.hatenablog.com

IETF 117 現地参加記 Vol. 3 到着日

この度，JPNIC様の国際会議参加支援プログラムにご採択いただき，IETF 117に現地参加させていただける運びとなりました．

2023年度 IETF参加支援 - JPNIC

初めての渡米，初めてのIETF Meetingということで，可能な限りの情報をここに残しておきたいと思います．

このページでは，渡航後1日目の情報を記します．

その他の記事は以下よりご覧いただけます．

tamasan238.hatenablog.com

初めての入国審査

およそ10時間に及ぶフライトを終え，入国審査へ向かいます．
とうとう日本国以外の地へ足を踏み入れたという感動と，日本語の通じない入国審査への不安とで心の中は複雑です．

このボードの先で入国審査

幸い，スムーズに通過することができました．

1. 写真，指紋採取
2. 「何のために来た？」
   to attend a conference
3. 「招待など，それを示せるものはある？」
   IETFのPaid Invoiceを提示
   (IETFのAttendee DashboardからInvitationを申請できることに後ほど気づきました．)
4. 「日本での職業は？」
   an University Student

くらいで終わったように思います．

SFO

ここで予めアクティベーション予約しておいたeSIMの有効化を試みますが，なぜかうまくいかず．
空港の無料Wi-Fiを利用して，公式LINEへ問い合わせます．
ものの数分で返信があり，助かりました．
結果的には，一旦すべてのAPN設定をオフにした上で5分待ち，T-Mobileのみをオンにして5分待つと接続できました．

荷物を取ったら損傷がないか確認して，Union Squareへ移動するためBART(Bay Area Rapid Transit)に乗ります．

空港直結の駅．

予めiPhoneに入れておいたClipperをタッチしてゲートを通ります．
Suica同様にExpress設定しておくことで認証等なしに利用できました．
大きなスーツケースとともに通過しようとして，ゲートに身体を挟まれたことは一生忘れません．

サンフランシスコ初の思い出「ゲートに挟まれる」

BARTの中はこんな感じ．結構綺麗です．

青や黄緑といった，明るめの彩色．

思っていたより加速に勢いがあり，車速も100km/hを超えるためスーツケースを転がしてしまわないよう注意が必要でした．

Union Squareに到着

駅から1歩外に出ると，もう雰囲気が違います．
初めて耳にした音は，街頭での「Check one two. Testing, Testing.」．
高専時代にPA(仮設音響)を齧っていたため，アメリカでも一緒なんだ...！と感動しました．

さて，サンフランシスコはコロナ以降治安が悪化していると言われています．
実際，駅からホテルに移動するまでの間にマ◯ファナの香りに気づけるようになりました．
(もちろん自分で吸ったわけではなく，この香りはこれだよと教えてくださったためです．)
結構な頻度で「明らかにキマってる方」を目にするんです．

そして，街中に下水の匂いが漂っています．
Dysonがマスク型の空気清浄機を販売している理由が分かりました．

とりあえずホテルに向かって荷物を預け，本場のハンバーガーを食べるべくSuper Duperへ．

Superと銘打つ割にはコンパクトサイズ？
いえ，見た目以上に厚みがあってボリューミーです．

ドリンクメニューにRefillできるタイプのものがあったので，それも注文．
謎の飲み物に挑戦してみましたが，湿布のようなテイスト...．

謎のドリンク

2杯目からは他のものを選びました．
バーガーはとても美味しかったです．パティの厚み・味が全然違いますね．

ゴールデン・ゲート・ブリッジへ

語彙力がほしい．

到底視界に収まりきらない，見渡す限りの海．まさに壮観です．
総延長2,737mの大きな橋を，非常に多くの車が行き交います．

はじめLyftで展望台を指定したところ，橋がちょうどまっすぐ見えるポイントでした．

この角度で眺めたことのある人は結構少ないのでは．

そこから冒頭の画像のようにちょうどよく見える場所に歩いたのですが，道中にあるのは砲台，砲台，砲台．
厳密には砲台"跡"ですが，コンクリート製のどっしりとした建造物があちこちに配置されていました．
確かに，ここは守りを固めるにあたって重要な場所であったに違いありません．
平和に観光できることの素晴らしさを実感しました．

橋に近づくと，様々な案内板や模型が並べられていました．
タコマ橋の悲劇を参考にしたねじりに強い堅牢な設計，地震に耐えるため金属が何層にも組み込まれた特殊なゴム，建設プロジェクトにおける労働環境，自殺を防ぐための何重にもなる落下対策，...．
これらはすべて無料で読むことができます．お子さんでも身近に体感できるよう，分かりやすい解説がありました．もし近くを訪れられましたら，ぜひ足を運ばれることをおすすめします．

展示のほんの一部．

ホテルへ

事前にスマートフォンアプリでチェックインを行っておきますと，部屋の用意が整ったと通知が届きます．
そこからバスでホテルへ移動．

フロントを訪れることなく部屋へ赴き，アプリ内のDigital Keyを用いて解錠．
とても豪華なお部屋を用意してくださっていました．

シャワーを浴びて，しばし休憩．長い移動時間の疲れを癒やします．

一段落したらフロントで紙幣を細かくしてもらい，そのまま近くのWalgreensへ向かいました．
ここはWalmart系列のドラックストアですが，食品や日用品など，幅広い取り扱いがあります．九州近辺にお住まいの方であればご存知かと思いますが，まさにディスカウントドラッグ コスモスです．

この店舗の特筆すべき事柄として，なんとお寿司の取り扱いがありました．
もちろん日本のものと一緒とは言いませんが，いわゆる”カリフォルニアロール”と称されるものよりは断然雰囲気が日本寄りで驚きました．

意外とちゃんとしてる(？)sushi

この日の夜ご飯は，ホテル内の売店で販売されていたサンド．
お昼にしっかり食べすぎてしまい，お腹が空く頃にはホテル周辺に"ヤバい"人が増えていたためです．

2食分はあった．

サンドを頂いたあとはそのまま就寝しました．
同行いただいたK様によると，深夜3時ころまで路上で喧嘩している声が聞こえていたそうです．
テンダーロイン地区が近いこともあり，夜は本当に危ないようです．

続きはこちら．

tamasan238.hatenablog.com

IETF 117 現地参加記 Vol. 2 いよいよ渡航

この度，JPNIC様の国際会議参加支援プログラムにご採択いただき，IETF 117に現地参加させていただける運びとなりました．

2023年度 IETF参加支援 - JPNIC

初めての渡米，初めてのIETF Meetingということで，可能な限りの情報をここに残しておきたいと思います．

このページでは，渡航日，アメリカに到着するまでの情報を記します．

その他の記事は以下よりご覧いただけます．

tamasan238.hatenablog.com

いよいよ出発

九工大飯塚キャンパスからだと，福岡空港と北九州空港が概ね同じ距離です．
福岡空港はとても混む上に駐車料金が高いので，今回は北九州空港から飛び立ちます．
予約手配の関係から，北九州 - 羽田 - 成田 - サンフランシスコと移動します．

晴れてよかったです．

早めに着いたので，今のうちに両替．
枚数指定で，50USD x 1，10USD x 15にしました．

北九州空港に置かれた外貨両替機．

ふらっと探索．

名物？の足湯は休止中でした．

北九州空港はJAL便が少ないので，発時刻の1時間前から荷物の預け入れが可能とのこと．
iPhoneのQRコードをなかなか読ませられずに手間取っていたところ，グランドスタッフの方がClaim Tagと一緒に紙の航空券を渡してくださいました．
細かやな気配りを感じると，嬉しくなりますね．
Claim Tagを大切にしまい，空いているうちに保安検査へ．

そのままスムーズに離陸．

JALオリジナルドリンク スカイタイム (ももとぶどう)

いざ東京

羽田に降り立ち，預けていた荷物を受け取ります．
(今回は羽田-成田のバス移動があるため，一旦受け取る必要がありました．)

移動する前に，外形に破損が無いかチェック．

羽田空港で昼食をとり，事前に予約していたリムジンバスで成田空港へ向かいます．
到着すると外国語のほうがよく耳に飛び込んできて，びっくり．

初めての成田空港．

パタパタ...？

エコノミー用のチェックイン機で荷物用のラベルを発行し，貼り付けたら荷物預け機へ．

この日の成田直営両替店のレートはこんな感じでした．

福銀よりレート良い．$1など，細かい紙幣にも対応していました．

JPNICのK様と合流し，無事保安検査を通過．
出国審査(顔認証ゲートを通るだけ)の後，待機スペースへ移動します．

わくわく

途中，グラウンドスタッフの方がパスポートチェックにいらっしゃいました．とても明るいベテランスタッフさんでした．

初めての国際線！

ボーディングブリッジを渡って

機内へ．JAL SKY WIDERでした．

各席に大きめのブランケットとコンパクトな枕(クッション？)が置かれていました．
利用可能な電源はモニタ下のUSB-Aポートだけ？
USB-C to Lightningしか持っていなかったので，モバイルバッテリーで凌ぎました．

離陸してシートベルトサインが消えると，やがてウェルカムドリンクの提供が始まります．
なぜかビジネスクラスのおしぼりですが，席はエコノミーです．

CAさんってすごいですね．
相当な人数に対して，ずっと笑顔でテキパキと仕事をこなしておられます．ただでさえ長時間のフライトで疲れるはずなのに......．ありがとうございます．

今度はりんごジュースをいただきました．

手が空いた頃を見計らって，耳栓とアイマスクをお願いしました．
上級クラスだと初めから配布されているようですが，エコノミーでもアメニティとして提供可能と公式Webサイトに記載があります．

これのおかげで眠れました．

JAL国内線では無料でWi-Fiを使えますが，国際線では有料です．
お手洗いに立ち，パスポートをボディバッグに移し替えつつJALカード番号を入力し，インターネットへのアクセス権を手に入れました．

高い．

しばらくすると，機内食の提供が始まります．
生まれて初めての機内食．美味しかったです．

この後すぐに眠れるよう，白ワインを．

JAL機内限定のハーゲンダッツなんてあるんですね．木苺のミルクプティング，こちらも美味しかったです．こういった特別感のあるものって，思い出に残りますよね．

約10時間のフライトはやはり暇です．
映画館での鑑賞と合わせると3回目となる『すずめの戸締まり』を見ました．
席についているヘッドホン，見るからにちゃちいですが，意外とちゃんとした音出ますね．思っていたよりは聞きやすかったです．
機内販売でBOSEのノイズキャンセリングイヤホン/ヘッドホンの取り扱いもありましたよ．

到着して眠くならないように，機内が暗くなるのに合わせて頑張って寝ます．

この画面，もうちょっとモダンなUIになっても良さそうですよね．

たまにお手洗いに行って伸びてました．ずっと座りっぱなしってこうも辛いんですね．

到着まであと1hを切った頃，朝ごはんの提供が始まります．
予定していたデザートが工場の都合で用意できなかったとのことで，ゼリーで代替されました．

コンソメスープとともに．

タニタさんとコラボしたメニューとのこと．
デザートとドリンク以外全部混ぜて食べてねと記載がありましたが，私としてはサラダの中の酢の物は混ぜずに分けておくべきでした...．

朝食を食べ終わると，もう窓からアメリカの風景が目に飛び込んできます．

Vol. 3はこちら．

tamasan238.hatenablog.com

Raspberry Pi Pico / Pico WでいちいちUSBケーブルを抜き差ししたくない

Raspberry Pi PicoやRaspberry Pi Pico Wでプログラムを動かすときに，いちいち[BOOTSEL]ボタンを押しながらMicro USBケーブルを抜き差しするのは億劫ですね．
やたら硬いですし，いつかポキっとやってしまいそうです．

Resetボタンを作ってしまうことで，USBケーブルは差したままに再起動・再書き込みを行えるようになります．

方法は，GPIO 30をGNDに落とすだけ．
しかも，ちょうど1つ飛ばした隣にGNDがあります．

以下のようにタクトスイッチを接続するか，もしなければ電源断したい間だけこの2つのピンをショートさせてしまってもよいと思います．

タクトスイッチで実装

ちょっと再起動してほしいときは短押し．

書き込みし直したいときは，[BOOTSEL]押しながら，今回接続したボタンを短押しして，[BOOTSEL]を離すとよいです．