うなすけとあれこれ

2024年11月25日

IETF 121 Dublinにリモート参加しました

IETF 121 Dublin

はい。今回はTZ的にはいわゆる仕事が終わった後に開始、というセッションが多く日本からのリモート参加も比較的しやすい回ではありましたが、Kaigi on Rails 2024のアフターイベントとか何やらとかでリアルタイム参加はひとつもできませんでした……

それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。

httpbis

Agenda

minutesがいつものHedgeDocじゃなくて https://httpwg.org/wg-materials/ietf121/minutes.html になっているのはなにゆえ……？

Resumable Uploads

05での更新はUpload-Lengthヘッダの追加など。次やることは文書の整理、実装の最新draftへの追従、相互運用性のテスト、本番環境での運用経験を得ること。クライアント側実装はSwiftとObjective-C(というかiOS用のライブラリ)、JavaScript。サーバー側実装はSwift、Go、.NETの3つ。

ハッカソンにおいて相互運用性のテストが行われ、全ての実装が最新のdraftに追従、試験もたくさん成功したとのこと。

https://wiki.ietf.org/en/meeting/121/hackathon#resumable-uploads-for-http-rufh

アップロードの進捗を取得するために1xx status codeを使うことについての議論があった。もしかしたら現在未使用の104が割り当てられるかもしれない？

QUERY Method

120からの主要なupdateとして、Content-Location ヘッダと Location ヘッダの用途についてとそれに設定するURIのガイダンス、Accept-QueryヘッダのIANAへの登録が挙げられている。議事録にはAccept-Queryの値に対してStructued Field Valuesは使わないでくれ、くらいしか記載がない。

Cache Groups

スライドがない。とはいえIn WG Last Callだし、もう特に議論すべきこともない段階？

Incremental HTTP Messages

last updatedが10/15で新しい、奥さん(連名)のdraft。

This document specifies the “Incremental” HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally.

abstractを読むとやはりCDNベンダっぽい課題感だなと感じる(とはいえ連名はFastly, Apple, Mozillaだけど)。HeaderにIncremental を指定することで、通信の中継者が全てのメッセージをクライアントから受信する前に背後(クライアント)に渡し始められる。これによって最終的にクライアントがタイムアウトとなる前にサーバーからのレスポンスを返せるようになる(例としてserver side events)……ってことかなあ。

スライドのmemeっぷりたるや。incremental enthusiastが多めで前向きな感じがする。

The HTTP Wrap Up Capsule

“GOAWAY is a sledgehammer”

00 → 01でIntroductionが大幅に加筆された。WRAP_UPによって、(MASQUEの例として)あるclientがCONNECT-UDPとCONNECT-TCP(あるいは別のproxy connection)の2つの接続を互いに別々のoriginに、単一のproxyを介して接続しているとき、CONNECT-UDPのほうでGOAWAYが起こると全部のconnectionが突然に終了されてしまう問題を解決できる。proxyの側がWRAP_UPをclientに送信することでclientがgracefullyにconnectionをdrainできる。client側からWRAP_UPを送信することを可能にするか？という議題がある。前進しそう。

Guidance for HTTP Capsule Protocol Extensibility

Capsuleプロトコルについては以下。

RFC 9297をupdateするもの。RFC 9297のwgはmasqueだけど、このdraftはhttpbisの議題になっている。capsuleの拡張性について。

Endpoints that receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule and skip over it to parse the next Capsule.

という文書における “endpoint” が一体何であるかが曖昧、というのを出発点にしている。proxyは含まれるのか、とか。

結論としてはもうすこし議論しようということっぽい。

Cookie eviction

Delete-Cookie ヘッダーで明示的にCookieを削除できるようにする？

https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ がちゃんとRFCになってから取り掛かるのでいいのでは？という意見があった。

AD-Requested Feedback (draft-ietf-netconf-http-client-server)

YANG（ヤン、英: Yet Another Next Generation）は、データモデル言語の一種である。NETCONF や RESTCONF などのネットワーク管理用プロトコルによりアクセスされるネットワーク機器の設定や状態、遠隔手続き呼出し (RPC)、通知をモデル化するために開発された。 https://ja.wikipedia.org/wiki/YANG

netconf wgのdraftについてhttpbis wgからのフィードバックはあるか、というやつかな。肯定的ではあるものの、もっと議論が必要という感じ。

Template-Driven CONNECT for TCP

MASQUE for TCPってスライドには書いてるし、そういうものを実現するためのもの？

HTTPの拡張CONNECTメソッド について復習する - ASnoKaze blog で connect-upd を使うという解説があるけど、こっちは TCPの上に載せるのでconnect-tcp を新しく定義して使うとある。

Capsuleを使うべきでは？という意見がいくつか。賛否両論で、さらに議論しようという結論。

Security Considerations for Optimistic Protocol Transitions in HTTP/1.1

もともと “Security Considerations for Optimistic Use of HTTP Upgrade” という名前だったのが後半が “Protocol Transitions in HTTP/1.1” に変更されている。

101(Switching Protocols) が返ってきた場合やCONNECT methodを使用する場合に使用されるプロトコルが変わることがあり、その場合におけるセキュリティ上の問題を解決するためのもの。Proxying UDP in HTTP" (RFC 9298)を更新するとも。 https://datatracker.ietf.org/doc/rfc9298/

スライドには120以降の変更についてと、HTTP CONNECTについて新規に追加された記載についてしか書いてないな？実際最終段階らしく、last callに向けてもっとreviewしようという感じで終わっている。

No-Vary-Search

No-Vary-Search というヘッダーで、URLのparamsに入っているものがレスポンスに影響するかどうかを知らせることができるようになる。なのでparamsのバリエーションによるキャッシュのうんぬんを制御できるってことだろうか。既にChromeにはサポートが入っているっぽい？call for adoptionされそう。

上記は前回の自分のblogより。

スライドで「CG Draft」にsuspendedとなっているのは、WICGでの策定？はやめて、httpbis wgでの作業に一本化したということ？なのか？

Editorial: Move No-Vary-Search to IETF HTTPbis by jeremyroman · Pull Request #338 · WICG/nav-speculation

IP Geolocation & HTTP

いわゆるGeoIPの話。間に中間者を挟むなどで自分のIP addrは知られたくないが、地理情報は伝えたい(？)ケースがある。そのときに Sec-CH-IP-Geo で地理情報をサーバーに送信できるようにする提案。目的としてはIP addrによる地理情報の推測をやめていきたい、というものだとか。問題意識はわかるような……とりあえず継続して議論しようというステータス。

moq

この章を書いている途中で 第2回 Media over QUIC とか勉強会 - moq-wasm 開発秘話!!【Media over QUIC とか勉強会】 | 高田馬場 Live Cafe mono に参加し、nttcom/moq-wasmを実装している方々とお話しすることができました。なので色々なワケワカラナイだった部分がだいぶわかるようになりました。やっぱ実装してるとより理解が進むし、実装しなければわからないこともあるということで。

Agenda

IETF 120からinterim meetingsが12も実施されている。やば。そしてこの記事を書いてる間にもどんどんinterimが予定されていって、今ではこうなっている。

めちゃくちゃ予定されているinterimの様子

https://quic.video/blog/transfork/ が気になってるけど、議題にはないのかな？まあないか……

Interop

一番実装が進んでいるものでも 6 (unsubscribe) までで、7 (goaway) を実装できているものはない。そもそもinteropの内容が120から変わっていなかった、という話も(前述のスライドで)ありましたね。

MoQT Updates Since Vancouver

IETF 120以降でMoQ Transportに入った変更まとめ。超interimがあったので、こういうのがあるのが本当に助かる……そしてまあ、いっぱいありますね。

JOIN

複数のgroupにobjectが配置されている場合においてRTTを削減できるってことか？beneftとしてスライド内で説明されているのが以下。例えば解像度の切り替えなんかで嬉しいというように読める。議事録によると、スライドにあるproposal #2が賛成多数ということでその方向で進むらしい。

スライド読んで！

Updating MoQT Priorities based on Implementation Experience

priorityについての記述のあいまいさがあるみたいで、そのための議論のよう。複数のgroup間でのpriorityの順序がどうなるか、ということっぽい。これもproposalが2つ挙げられており、決を取ったところproposal 2が賛成多数となった。proposal 2はsubgroup内でuniqueなpriority値をつける方式。見た感じgroupにもまたがっていそうだけど……？

スライド読んで！！

Process / Workflow

moq wgのプロセス及びワークフローについて。chairがコンセンサスを確認できていない、virtual interimで物事が進んでいて参加できない人がおいていかれる、運営が難しいという問題が挙げられている。いくつかの解決策が挙げられていて、議事録を見た感じではそれで合意した……？

WARP + Catalog Merge

なんか色々ある……まず、10月のinterimにおいて、CatalogについてはWARPにmergeし、個別のdraftにはしない。interopはメディアストリーミングフォーマットに焦点をあてる。この2つがCatalog design teamのsummaryとして合意を得られている。

interopに関するInformationalなdraft (MOQ-MI)も作成されている。

https://datatracker.ietf.org/doc/draft-cenzano-moq-media-interop/

WARPとMOQ-MIでサポートしている機能が異なることについての議論がされたっぽいけど、議事録は簡潔すぎてちょっとわからない。Core featureとして最低限どこまでサポートするべきか、みたいなところが今後のワークで明確になる？

スライド読んで！！！

SWITCH

解像度を変えるなどしたい場合に、新しいgroupを受信しても今ある解像度から新しい解像度とのgroupの間のobject(？)をもらわないといけないとき、SUBSCRIBE+UNSUBSCRIBEか、それにFETCHもまざってくるかというケースの複雑さを解決するために導入する仕組みがSWITCH。具体的にどうするかについてはこれからっぽい。

スライド読んで！！！！

Timestamps

Delivery TimeoutとMax Cache Durationが相対的でありベストエフォートである。もしパケロスや順序の入れ替わりがある場合にskewedとなる。エンコードに時間がかかるケースにおいてはcaches upできない？？optionalな"timestamp"を導入することで解決するということらしいが。わかりません！

STOMP

latencyの計測のためにmoqt上で時刻のmetadataを交換できるようにするっぽい。地理情報も含められるようになっている。しかし事情によりskipとなった。

ccwg

Agenda

recharterするっぽい？その兼ね合いでテストスイートがあると嬉しい、古くならないよう長期的にメンテされているべきだ、みたいな話がされていた。これ、Hackathonと関係していそうだけど。ns-3っていうやつが便利なツールっぽい。

https://www.nsnam.org

なんか日本の大学の名前が見える……

Hackathon Update

なんかあったらしい。"Design a suite of test cases based on 5033bis, the proposed new BCP on Specifying New Congestion Control Algorithms" は超ステキだと思うが。成果は……どこにまとまってるんだろう？？？

BBRv3

変更点としては、wg draftになっているとか、元文書がXMLからMarkdownになっているとか、明確化したとかとか。軽微なアルゴリズムの変更をするpull reqが2つopenになっていて、TCPでないtransport(主にQUICのことを指してる)に対する一般化についてのissueがopenになっている。

SEARCH

現実世界でのdeployに協力してくれるボランティアを募集している段階？ccwgのワークとして取り組むことに賛成の意見が多いので、引き続きなにかしら行われそう。

Increase of the Congestion Window when the Sender is Rate-Limited

送信者のデータ送信がrate limitedな場合における輻輳ウィンドウの増加について……？この挙動について、十分な送信が行われていない場合には輻輳ウィンドウの増加に制限をかけるようにする提案。"Who thinks we should not do work on this topic" が0 votesなので、肯定的な反応。

が、前回。これも投票の結果、ccwgのワークとして取り組むことに前向き。

SCReAMv2

スライドの最後がオシャレ。ccwgのワークとして取り組むことの賛成は反対より多かったけど、no opinionを含めてあまり差がない感じ。どうなるんだろう？

他のものについては時間切れ。

wish

Agenda

こんなwgありましたっけ……？って思ったけどpast meetingsは110からあって完全に節穴でしたね。

WebRTC Ingest Signaling over HTTPSなのでWHIP/WHEPのwg。

WebRTC のシグナリング規格 WHIP と WHEP について が概要をつかむのにはわかりやすいかも。

WebRTC-HTTP Egress Protocol (WHEP)

agendaはこれだけ。そしてin WG Last Call状態。行われた議論自体はGitHubで未解決のissueについてとWHEPについて。WHEPはURLをどうするかについてどうしようか状態なのと、失敗(何に？)した場合の振る舞いについて定義しないといけない、ということについての議論があった。minutesを読むと議論があったことはわかるけど結論は書かれていなくて、合意に至らなかったのかな。

quic

Agenda

Multipath QUIC

10から11の変更点は4-tuple addressがhas already been validatedな場合にendpointがchallenge(とは何だ)なしでpacketをsendできるようになった、PATH_ABANDON frameのerror codeについての再定義とreason phaseの削除、最大path identifierに達したことを通知するPATHS_BLOCKED frameの追加、transport parameterの変更といったところ。hackathonでのinterop testの結果報告も。

話し合われたissueは4つ。issue 459はendpointがCIDを有効な各Path IDに対して発行しなかった場合どうなるかについて。現在のdraftにおいてはpeerが新規pathを開いたらCIDを発行するのがRECOMMENDED。 ただしMAX_PATH_IDがnegotiateされるまではPATH_NEW_CIDを送ることができないので、遅延させたい。合意に至らず。

issue 414はPath Abandonのerror codeについて。UNSTABLE_INTERFACEやNO_CID_AVAILABLEのようなものが必要か？という話。新規にpull reqを作成して議論するみたい。

issue 457はPTO handlingについて。ある1つのpathにendopointがpacketを送り、突然そのpathがブラックホールになった場合(つまりpacketが虚空に消えた場合か？)の挙動かな。RFC 9002に従えば、endpointはackがそのpathから戻されない場合、PTOが発生するまでそのpacketが失われたと見做されない。議論の結果、何らかの指針を追加することが決まったみたい。

issue 458はmultipathがnegotiatedな場合においてPath migrationかnew pathのどちらをすべきかについて。endpointは通信内容を送信するために新規4-tuple addressを使いたい。新規pathを作成するのがREDOMMENDEDとなっている。ここの内容、どういうことなんだ……

WG last callになるかどうかについては、もう一回改訂を重ねるということになった。そもそもやろうとしてることが多くて大変とも。

qlog

なんだこのbikeshedは(スライドp6)。qlog-main-schemaについては09で識別子の名前が変更されたりなんだり。

JSON-SEQがpainfulであるというbikeshedについて。JSON-SEQが何かというとRFC 7464のことらしい。今はJSON-SEQを使うこともできる、という状態(application/qlog+json-seq で返す)。他にもNDJSONやJSON linesという選択肢もある。JSON-SEQを使う場合、grep、vimとの相性が悪く、またjqで使うには --seq optionを渡す必要がある。それらを踏まえてJSON-SEQのままでいくか、他の何かを採用するか、それとも他のserialization formatを追加するか、何のstreaming serialization formatも推奨しないかのどれにするかという議論。結論は出なくて、年内のWGLCに向けて解決しないといけない、というところで終了。

Address Discovery

P2Pな状況におけるQUICにおいてpublic addressを検出、シグナリングするための拡張。そもそもquic wgとして取り組むべきかどうかについての投票が行われ、賛成多数。

Flexicast QUIC

The deployment of QUIC opens an interesting opportunity to reconsider the utilization of IP Multicast. As QUIC runs above UDP, it could easily use IP multicast to deliver information along multicast trees. Multicast extensions to QUIC have already been proposed in [I-D.pardue-quic-http-mcast] and [I-D.jholland-quic-multicast-05]. To our knowledge, these extensions have not been fully implemented and deployed.Flexicast QUIC takes a different approach. Instead of extending QUIC [QUIC-TRANSPORT], Flexicast QUIC extends Multipath QUIC [MULTIPATH-QUIC]. Multipath QUIC already includes several features that are very useful to allow a QUIC connection to use unicast and multicast simultaneously.

おお……？unicastについてはbidirectionalなpathを使い、multicastについてはshared unidirectional flowを使う？(p4の図)

フィードバック求む！状態。

httpapi

Agenda

HTTP Privacy

httpなpathにrequestをした場合、httpsへと301 redirectするというのはありふれている。このとき最初のnon-secureなrequestにapi keyなどのcredentialが含まれているとunsecureだよね、という話。このdraftはBest Current Practiceなやつ。serverおよびclientに最初からsecureな通信での開始を行うための指針を提供するもの。HSTSとかHTTPS DNS recordとか。

HTTP Signature

なぜスライドにこんなに映画ネタを……？ https://httpsig.org/ を今さら見て気付いたけど、Ruby gemとして https://github.com/nomadium/linzer というのができているのか。これはRFC準拠っぽい。

Digest FIelds Problem Types

RFC 9530のDigest Fieldでdigestが不正だった場合に、RFC 9457の仕組みを用いて結果を返すためのschemaを定義するものかな？

oracle attackに注意というコメントがあった。

REST API Media Types

OpenAPIやJSON Schemaをresponseとして返せるようにするもの。レビューしてlast callの準備ができたか確認するということになった。

RateLimit header

そういえばRate limitの仕組みがRailsに入ったよな……

patition keyが入った？のかな、これは便利という意見があった。

masque

Agenda

いつ見てもなんかSEGAを彷彿とさせる。

QUIC-Aware Proxying

04での更新点は、Proxyはoriginal CIDsに限定した(as long asをこう理解していいのか？)virtual CIDsをpickしないといけない、MAX_CONNECTION_IDSをproxyに登録されるconnection idsの上限を限定するために追加した、など。スライドにある議題として、issue 113のPreferred address migrationについては追加の議論はなかった。issue 115のActive attack on scramble transformが主な議論。active attackerはiv生成のために使われるバイト列を複数のpacket間で共通になるように変更できる。packetそのものは無効または破棄されるけど、scrambled packetには一致するバイト列が含まれており、プロキシの両側のフローを対応することができる、と……結論としてはこのような攻撃手法がある、という対応のみに留まりそう。

Proxying Linstener UDP in HTTP

前回(っていうのは120のこと？)からの変更は特になく、WGLCになるまでに相互運用性があると嬉しいので、実装に意欲的な人を募集中、という段階。hackathonで1つ実装した、という話があった。Googleによるもの。それってこれのことなのかな？ https://github.com/google/quiche/commit/29f785f59dfb33f4fff4c87852983c2cb7808ad0

Proxying Ethenet in HTTP

hachathonでericsson clientとgoogle serverとのinteropが行われたとのこと。もっと他の実装も募集中。輻輳制御に関して未解決の問題が残っている。これについてどうすべきかはまだまだ議論が必要という感じになっている。

DNS Configuration for Proxying IP in HTTP

dnsop wgに持っていって早期レビューを受ける流れ？

tls

Agenda

会場めっちゃ広くない？？？？？

あとIETF 121が終わってからML-DSAがめっちゃもりあがってるんだが……

Trust Tussle Interim Summary

Avoid client trust conflicts by enabling servers to reliably and efficiently support clients with diverse trust anchor lists, particularly in larger PKIs where the existing certificate_authorities extension is not viable.

たぶんinterimの議事録をもっとちゃんと読めばどういうものかわかりそうなのであとで読むかも……

https://datatracker.ietf.org/meeting/interim-2024-tls-01/session/tls

ステータスとしては、もうひとつdraftが来るという。

TLS Registries Update

TLS Registyに入った変更について。"A stunning presentation.“

ECH Discussion

issueについて議論する回。AD reviewでついたDNSの問題については、合意に至らずADからの勧告があれば従うと。他にもいくつかあるopen issueについての議論が行われた。今repoを見てる感じでは、それらに対応した変更がcommitされていそう。

FATT Updates

FATTの現状について。議論は公開されるべきだ、という意見が多い。(動画だと結構長い時間話してたけどmisnutesがアッサリめ)

DTLS Clarifications

RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3の改訂が必要だ、という1枚目から始まる。TLS 1.3とDTLS 1.3でKeyUpdatesの適用タイミングが異なるとか(マジで？)、1.3でしか対応していないACKがversionをまたいで使われる場合の挙動とか、Epoch managementが明記されていないとか、とか、とか……結構ございますわね。

repositoryを作るよ、という話になったぽい。

Abridged Certs Update

certificateの圧縮。pass 2は複雑(これ2パス圧縮のことでいいのかな？)なので辞書なしのBrotilを使おうという提案がある、と。よりシンプルになるが圧縮率は落ちる。それはそれとしてZstdとBrotilのどっちでいくかはまだ議論中かな？

Extended Key Update

ExtendedKeyUpdateRequestを受信したときにalert & terminateしていたのがExtendedKeyUpdateResponseを返すように定義されたり、ExtendedなKey Updateが実行されたときにSSLKEYLOGFILEにどう記録するか、などの更新。未解決issueはもうない！

SSLKeylog ECH

最新のWiresharkではもうサポートされている！！

まとめ

アー

2024年11月25日
2024年10月29日

Kaigi on Rails 2024 運営記

感謝

Kaigi on Rails 2024に参加していただいたみなさま、ありがとうございました。登壇者の皆様、Proposalを出してくださった皆様、協賛してくださった企業の皆様、そして一般参加者の皆様のご協力のおかげでKaigi on Rails 2024を終えることができました。今年もハイブリッド開催となりました。2年目そして2回目ではありますが、いかがだったでしょうか。

以下、手短にふりかえっていきます。

インタビュー

まさかのFindyさんにインタビューをしていただけることになりました。

コロナ禍・逆境からの立ち上げを経て、人気カンファレンスへ。Kaigi on Rails運営の裏側 - Findy Engineer Lab

10月25、26日に開催されるKaigi on Railsに取材しました！

コロナ禍・逆境からの立ち上げを経て、人気カンファレンスへ。Kaigi on Rails運営の裏側 https://t.co/8Cnl3nGu9n #EngineerLab #kaigionrails @findy_englabより

— Findy Engineer Lab (@findy_englab) October 22, 2024

いやはや、なんとまあ……まさかインタビューをされる側になるとは思いませんでした。

conference-app

せっかくv8.0.0.beta1が出たばかりなのだし、思いきってconference-appも v8.0.0.beta1 に上げてみました。また、SidekiqからSolid Queue + Mission Control Jobsへの移行もしています。他にもRailsに関係しないところだと、HerokuからAWS App Runnerに乗せかえました。参加者の皆さんから見れる機能としてはあまり変化はしていませんが、裏側は色々と変わっていたのでした。

ただ、deploy後に放置しているとrequestがtimeoutするという現象が発生しており、ご迷惑をおかけしました。原因は謎1です。空deployをすることで解決することはわかっているので、会期中は思いついたタイミングでこまめにdeployを行うようにしていました。

せっかくなので、会期中のmetricsを出しておきます。

conference-appの10/25～10/26のmetrics (request count, 2xx response count)

conference-appの10/25～10/26のmetrics (cpu utilization, memory utilization)

リクエスト数が跳ねてるのがオープニングのタイミングですね。みんながスクリーン上のQRコードを読んだのがそれだと思います。

オープニング

なんとオープニングの挨拶をすることになってしまいました。初日の一発目ということもあり、ハイテンションで元気良くを心掛けた結果、皆さんから「元気があってよかった」「高専の寮生の挨拶かよ」などと好評だったようでよかったです。

2025

とうとう今年はクロージングで来年の会場と日程を発表できましたね。「成長」を感じます。

スタッフはまだまだKaigi on Rails 2024の作業が残っているので気持ちが2024のままなのですが、今回参加していただいた皆さんの高まった気持ちをKaigi on Rails 2025がちゃんと受け止められるよう頑張っていきたいと思います。

  1. 「これか？」というアタリはついているのですが…… ↩

2024年10月29日
2024年09月30日

unasuke.fmの再始動(再)

unasuke.fm artwork

再始動(再)

https://unasuke.fm を公開しました。ロゴは衰咲ふち(@otoroesaki)さんに作成していただきました。この場を借りてお礼申しあげます。ありがとうございます。

一旦は今までのエピソードを聞けるようにしただけになります。今後、エピソードごとのサマリやshownoteの記載、RSS feedの公開などの改善を進めていきます。

加えて、次の収録についても日程含め検討中になります。

……と、unasuke.fmの再始動で書きました。結局、その後長い間新規のエピソードの公開はできていませんでした。

ですがなんやかんやあり、2024年07月06にosyoyuさんとの回を、続けて07月14日にsylph01さんとの回を公開することができました。

podcast platforms

ついでにRSSの準備と、Apple Podcast及びSpotify Podcastでの公開をしました。

説明がおざなりなのはまあ、はい……あとでなんとかします。unasuke.fm上にもそのうちリンクを置きます。

公開が遅くなることへの言い訳

さて、大倉さんが始めたOH! MY RUBYISTSを聞いた人はもうご存じかと思いますが。大倉さんとの回をもう収録済みです。で、それがまだ公開できてないわけですが……

episode 8からですが、transcriptionを用意することにしました。単純にその書き起こしを準備するのに時間がかかっているためです。なぜ書き起こしを用意するかというと、自分が音声を聞くより文章を読むほうが頭に入りやすいからです。Podcastをやっておいて何を言っているんだという感じではありますが……

次々回以降

当人には伝えていませんが、候補にしている人は2人ほどいるので、再開したと言いましたが引き続き期待せずお待ちいただければと思います。

2024年09月30日
2024年08月21日

IETF 120 Vancouverにリモート参加しました その2

IETF 120 Vancouver

前回の続きです。

前回 → IETF 120 Vancouverにリモート参加しました

参加したセッション

例によって、以下常体と敬体が入り乱れます。

httpbis

mozaic.fmの方々による復習がX上で行われていたので、そちらを参考してもらうほうがいいような気がしますが……一応自分でもまとめます。

IETF120 復習 - Google ドキュメントhttps://t.co/M7tRiPAcik

— mozaicfm (@mozaicfm) July 29, 2024

Agenda

https://datatracker.ietf.org/meeting/120/session/httpbis

Resumable Uploads

再開可能なアップロード。HTTPで再開可能なアップロードを可能にする提案仕様 - ASnoKaze blog

minutesによると大まかな議題は3つで、Upload-Limitはproxyとorigin serverのどちらによってセットされるのか、Upload size、サーバーからのdigestのリクエストについて。

QUERY

特に資料はなし、expired & archivedになってるけど……

“weather in Vancouver” という検索をした場合に返却されるのは現在の天気へのリンクか、これまでの天気をリストしてあるページへのリンクかという議題と、Cacheについての議題。質問した人はdraftのautherになるべきだろうという結論になっている。

Cache Group

openなissueがないのでReady for last callとのこと。実装が無い？というところが気になるけど、既存のコードとの互換性がある(？)のでいいのでは、ということになっている？

Communicating Proxy Configs in Provisioning Domains

httpbisではなくintareaからのもの。Motivationとしてはモダンなproxy typeの探索、既存のシンプルなproxy設定との共存、PACファイル、WPADへの依存をなくす、とあるけどこれは何……？

なるほど。で、それらに依存しない方法として、Provisioning Domain(PvD) JSON formatに対してproxyのサポートを追加しようというもの。提案しているのはAppleの人とMicrosoftの人。Private Relayが関連している可能性がありそう。資料では、 /.well-known/pvd に対してGETすることを想定している。認証についてや、クライアント証明書についての設定がどうなるかについての疑問が出ている。

Security Considerations for Optimistic Use of HTTP Upgrade

https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/ * https://datatracker.ietf.org/meeting/120/materials/slides-120-httpbis-sessa-security-considerations-for-optimistic-upgrade-00 * https://github.com/httpwg/http-extensions/labels/optimistic-upgrade

https://http.dev/ というサイトがあるんですねえ。openなissueについての議論が行われた様子。

Secondary Certificate Authentication of HTTP servers

HTTPレイヤで追加のサーバ証明書を送信する Secondary Certificate の仕様について - ASnoKaze blog

なるほど……議論としては証明書のサイズの問題に関すること以外はちょっとわからない。

The HTTP Wrap Up Capsule

Privacy Proxy(Priovate Relayみたいなの？)においてlong-livingなstreamを終了したいが、ブラウザからはリクエストが処理されたかどうか不明な場合にはそのリクエストを再試行できない。クライアントがあるstreamにおけるリクエストを中断して別のstreamもしくはconnectionに対して新しいリクエストを送信できるように、proxyのような仲介者が実際の終了が行われる前にそろそろ終了する通知を送るようにできるのが最善。なので、proxyがそのconnectionで新規のリクエストを開始すべきでないと通知し、既存のリクエストの終了を可能にする WRAP_UP カプセルの提案。(abstractの要約)

GOAWAYではなく？という質問に対して、GOAWAYはproxy自体がいなくなることを表し、これはリクエストごとに対する通知になるという返答があった、くらいしか読み取れず。webtransportに似たような提案がある？

HTTP No-Vary-Search

No-Vary-Search というヘッダーで、URLのparamsに入っているものがレスポンスに影響するかどうかを知らせることができるようになる。なのでparamsのバリエーションによるキャッシュのうんぬんを制御できるってことだろうか。既にChromeにはサポートが入っているっぽい？call for adoptionされそう。

Revising Cookies

“Yet another cookie spec revision! But why?!”

Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog 既にある6265bisではなぜいけないのか。それは “cookie store"の概念を明確に定義したいからだ、Webブラウザ以外のagent(例えばcurlとか？)がどのようにcookieを扱うかを定義するためだ、と。6265bisの編集者から好意的に受け止められている。

Versioning for HTTP Resources

あるリソースを共同編集している場合や、Gitリポジトリのホスティングなどにおいて、リソースのバージョンとその祖先についての情報をリクエストヘッダに付与することでなんかいろいろできるようにしようという提案。最終的に目指すところまでには4つの提案が必要と言ってて、これはその最初の1つらしい。す、すごい。もっと議論が必要というところで終わっている。

httpapi

Agenda

https://datatracker.ietf.org/meeting/120/session/httpapi

スライドはほぼない感じ。大部分はChair slideに書いてあるのかな。

https://datatracker.ietf.org/meeting/120/materials/slides-120-httpapi-chair-slides-00

The Idempotency-Key HTTP Header Field

まだまだ議論中という感じ。8月末までに合意が得られるようにしたいとのこと。

Link relationship types for authentication

SECDIRからの早期レビューを受けたとのこと。

HTTP Link Hints

いくつかの未解決issueがあるが、それを話す人がいない。

Byte Range PATCH

byterangeと言いつつ、単位がbyte以外のユースケースが出てきている……？あとgzipされている場合に展開されているほうなのか圧縮後のほうなのか、だとか。言及されているhttpbisの "bride” っていうのはこれかな？

https://datatracker.ietf.org/doc/draft-toomim-httpbis-braid-http/

Internet-Draftの冒頭がこんなことになってるのは初めて見た(是非見てみてほしい)。(あれ、これってVersioningのやつでは……？)

RateLimit header fields for HTTP

以前のdraftからの更新点の共有とフィードバックくださいという報告かな。unit と scope が追加された。

REST API Media Types

“openapi+json” や “openapi+yaml” をどうするかについて議論中。

HTTP Problem Types for Digest Fields

今回出てきた新しいinternet-draft。RFC 9530 Digest FieldsではContent-DigestやRepr-Digestなどのヘッダを定義して内容および表現の完全性を保証する仕組みがあり、しかし完全性に関連するエラーを通知する方法の標準がないことを解決するためのもの。興味深い。他にもそういった、問題が発生したときにそれを通知する標準がないものはいくつかあるらしい。

masque

Agenda

https://datatracker.ietf.org/meeting/120/session/masque

QUIC-Aware Proxying Using HTTP

そもそもは、RFC 9208: Proxying UDP in HTTPを用いてQUICに最適化したProxyを可能にするためのドラフト。これどういうことをしたいのかちゃんと理解しておきたいな……

議題は「Preferred address migration」、「Limiting CID registrations」、「Client VCID length」の3つかな。それぞれ、再接続でいいのでは、制限に到達したらフロー制御を行う、同じかそれより長くする必要がある……という結論になったように見える。

Proxying Bound UDP in HTTP

やりたいことは、1つのProxyに対するconenctionで複数のtargetsに対する接続を行うこと？例えばRFC 9208だとWebRTCでICEをしたい場合などがサポートされていない。 connect-udp-bind というheaderを付けることで使用を宣言する。

相互運用性がどうなのか、というのの確認段階に進んだみたい。

Proxying Ethernet in HTTP

Ethernet framesをproxyするためのdraft。これが可能になると追加のencapsulationによるadditional MTU costが削減できるという利点がある？

VLAN tagging、Ethernet versionのサポート範囲、レイヤー分離と輻輳制御などについてのopen issueがあり、それらについての議論が行われた。実装はまだないのかな？実装したい人は教えてね、というログがあった。

DNS Configuration for Proxying IP in HTTP

RFC 9208ではHTTP load balancersを介したVPNを構築できるが、DNSに関する構成情報を交換することができない。ので、RFC 9297: HTTP Datagrams and the Capsule Protocolを用いてDNS configuration informationの通信を行えるようにするもの。どうやら名前解決そのものの通信は範囲外？

議事録を見る感じでは否定的な意見が多めのよう。

What’s next for MASQUE

MASQUE自体について。現在どうデプロイされているかどうかなどなど。輻輳制御が入れ子になっている場合とかについての研究が必要など。

なんにせよ、ちょっとまだわかないことが多すぎました。

webtrans

Agenda

https://datatracker.ietf.org/meeting/120/session/webtrans

chair slide(というかwg全体で1つの資料)のみ。

W3C WebTransport Update

IETF 119からのupdateとして、retransmissions and send orderについてのnote、相対URLのサポート、データグラムを優先するがストリームをブロックしないようにする(実装依存)挙動についてなどがあった。ブラウザのサポート状況は変わらずなのかな？Safari(WebKit)にはいくつかissueが作成されている？

あとはいくつか追加された統計情報についてそれが実用的なのか、不足しているものはないか、実装が可能かなどの議論もあった。

WebTransport over HTTP/2

Key ExportersについてHTTP/3の場合と同様でいいのかの確認。"This is the first time key exporters would be available to Javascript in a browser.“ らしく、TLSを解釈する(復号できる)proxyが間に存在する場合に動作しないかも、という指摘があった。

Mozilla (Firefox)は6ヶ月以内にWebTransport over HTTP/2を実装するらしい。canisueによればWebTransportはFirefoxにおいて既に実装済みというステータスだけど、これはover HTTP/3ってことなのでしょう。Bugzillaは 1874097 - WebTransport over HTTP/2 かな。

相互運用性のテストが終わるまでdraftの更新はされないということになった模様。

WebTransport over HTTP/3

"Data Recvd” について、懸念事項があるのでpull reqにコメントするという発言。"subprotocol"という単語の使用について"protocol" を使用するよう変更することが決まった(W3C updateの議題のときに)。

HTTP authenticationの使用可否については、禁止する理由がないということで使用できるという方向でまとまった。

DRAIN_WEBTRANSPORT_SESSIONについてはめっちゃ議論が長びいてて、さらに数回議論が行われそう。

David thanks the academy, his family, and all the friends he made along the way. In lieu of flowers he requests PRs and comments.

💐

ccwg

Agenda

https://datatracker.ietf.org/meeting/120/session/ccwg

Increase of the Congestion Window when the Sender Is Rate-Limited

送信者のデータ送信がrate limitedな場合における輻輳ウィンドウの増加について……？この挙動について、十分な送信が行われていない場合には輻輳ウィンドウの増加に制限をかけるようにする提案。"Who thinks we should not do work on this topic" が0 votesなので、肯定的な反応。

BBR Congestion Control

GoogleとMetaの人によってInternet-Draftが作成されている！BBRv3がRFCになるかも。BBRはGoogle内部のtrafficとGoogleが提供するサービスで使用されている(YouTubeとかgoogle.comとか)。BBRv1とBBRv3でのA/Bテストが行われている。公平性についての発言がいくつかあったけど、ここで課題になっている公平性ってどういうことなんだろうか。

BBR Improvements for Real-Time connections

これもできたてホヤホヤのdraft。BBRのstartupには2*RTT必要で、かつWi-Fi環境においては容易に停止及び悪化するなどなどなどの問題点がある。Real-Time接続、特にメディアに関することについてはmoq側との連携が必要では、という話も。

HPCC++: Enhanced High Precision Congestion Control

データセンターにおける通信は超低レイテンシと高い帯域幅がある。そのような環境に向けた新しい輻輳制御アルゴリズムとして提案されているのがHPCC++。そういう環境では正確なテレメトリが得やすいというのがあるのかな。ccwgでやるべきかどうか……という感じ？

SEARCH – a New Slow Start Algorithm for TCP and QUIC

これもホヤホヤdraft。"Slow start Exit At Right CHokepoint" でSEARCH。特に無線ネットワークにおいて既存のTCP Cubic with HyStartはスロースタートからの脱出が早すぎる？ためにリンク使用率(とは何？)を低下させる。とはいえHystartがない場合はスロースタートの期間が長すぎ不要なパケロスが生まれる。ack済の配送に基づく輻輳制御をTCP senderが行うようにするSEARCHは既にLinux kernel v5.16 moduleとして実装されて評価済み。

主な著者の所属であるviasatはアメリカの通信事業者で、衛星通信事業が主っぽい。wgの反応としては前向きな感じ。

Prague Congestion Control

It is mainly based on experience with the reference Linux implementation of TCP Prague and the Apple implementation over QUIC, but it includes experience from other implementations where available.

とのことだけど、"TCP Prague"というのはなんだろう？https://github.com/L4STeam/linux がそれっぽいのだけど。地名のプラハに由来してるのかな？よくわからなかった。実装としてはTCP版がいくつかのLinux kernel versionsで(前述含む)、UDPのものが https://github.com/L4STeam/udp_prague にある。

実装から得られた知見を反映したdraftが欲しいというコメントで終わっている？

Rechartering

5033bisの取り組みが終わったことについての情報の反映、輻輳制御がいかに重要であるかの文言の追加、などなどなどについて。

minutesを読んでも着地点はよくわからないけど、まあ https://datatracker.ietf.org/wg/ccwg/about/ の文章の更新がされるのでしょう。

CC Response While Application-Limited

時間切れとのことで触れられなかった。

moq

Agenda

https://datatracker.ietf.org/meeting/120/session/moq

IETF 120が終わってからこの記事を書いてるあいだにもうinterimがひとつ、さらに予定としてもうひとつあって議論が活発だ……

あと、minutesに書かれている順にまとめているけど、2回目 → 1回目で書かれている？

WARP Streaming Format

どのようなUpdatesがあったのか。CMAFに加えてLoCのパッケージもサポートされるようになった、タイムライントラックの提案、Chatの内容をどのようなフォーマットで送信するかなど。

着目している人数が少ないことに注意したほうがよいとのコメントがある。

Metrics/Logging

ホヤホヤ。Media over QUICのログやmetricをどうするかというdraft。QUICの上に乗るということでqlogかと思いきやデータモデルにはOpenTelemetryを使うらしい。好意的な反応。

“Peeps” an Extended MoQT Object Model

“An Extended MoQT Object Model” として提案されているもの。PDFの5ページがつまりこれは何なのか、の説明なのかな。議論の様子を見るに好意的に受け入れられてる感じはする。

Track Switching in Media Over QUIC Transport

挙げられている問題を解決するのにとるべき手段がこれなのか、という議論になったように読める。

MoQ Transport Issues

“github.com/moq-wg/moq-transport” 上のissueについて。ここで議論されてることについては実装を知らないと理解できないことばかりに思えるのでパスで……

Livestreaming this meeting over MoQ

この会議の様子をMoQで配信してたらしい。配信するサイトはMetaの人の管理するドメイン上にあった。short.gy っていうURL短縮サービスがあるんだね。

The MoQ Journey

これはなんというか、これまでのMoQの軌跡まとめみたいなものかな。現状がどうなってるかわかっていいですね。

MoQ Transport-05 updates+priorities

MoQ Transportのdraftにおける03、04、05での更新まとめと、新しい優先度とグループの送信順番、次に送信するものは何かということについて。主に現状共有っぽい？minutesを見る限りではここではそんなに議論されてない印象。

Common Catalog Format

individual draftからwg draftになったのが6月のこと。新規のIANA registry “MoQ Streaming Format Type” が定義されたり、fieldやroot objectの追加、renameなどなど。 trackのformatについて、MIMEではなく文字列なのは何故か、IANA registryは必要か？などの議論があった。trackのtype属性について、任意でいいのでは？という話も出ていたが、相互運用性のためには取りうる値はどこかに定義があるべきだろう(それはcatalogではなくWARPかも？)という話があった。relative track prioritizationについては必須であるべきだという意見。Streaming formatに入る値はどのようなものであるべきかについては単なる文字列の識別子(バージョンは含まない)が格納されることで合意。

う〜ん、何ひとつピンとこないですね。やっぱり実装しないとわからない領域なのかも。実装する気はないけど……

MoQ Secure Objects

MoQ Transportにおけるend-to-end encryption。minutesからは、なぜSFrameにしないのか、いやSFrameは嫌だ(というより同じことのやりなおしになるのが嫌？)、などの意見が見られたけど、結論としてこの提案自体がどうなったのかについてははっきりしない印象。

https://sora-e2ee.shiguredo.jp/sframe

SFrameっていうのがあるんですね。

The Many Faces of SUBSCRIBE

SUBSCRIBE を実装して得られた知見についての共有。これはライブストリーミングを実装した人にはピンとくるんだろうか……ギブアップです。

まとめ

なんもわからん。

これは再掲になるんですが、sylph01さんとIETFなど標準化活動について話した内容をPodcastとして公開しました。ぜひ聞いてください。そして文字起こしを買ってください。

というわけでPodcast初出演です。ここにない範囲では、SMTPをやめろとは何か（メッセージングの未来とその課題について）、「真のIETF/RubyKaigiは廊下にある」とはどういうことか、あとふるさと納税のおすすめの柑橘について話しました。よろしくねよろしくね https://t.co/JvI2LwcIoe

— sylph01 (@s01) July 22, 2024
2024年08月21日
2024年07月31日

IETF 120 Vancouverにリモート参加しました

IETF 120 Vancouver

5回目のIETF Meeting参加シリーズ、リモート参加の4回目です。期間中のバンクーバーはUTC-7(PDT)なので、日本からだと1時から13時の範囲となり、リアルタイムの参加はあきらめていました。

参加したセッション

「参加したセッション」とはいっても前述のようにリアルタイムでmeetechoに入るのは厳しく、基本的に資料と議事録を見て書いています。httpbis、httpapi、masque、webtrans、ccwg、moqについてもまとめようと思ったんですが、一旦7月中に出すことを考えると余裕がなく、力尽きました。追って書くかもしれません。

2024-08-21 追記

書きました。

IETF 120 Vancouverにリモート参加しました その2

Transport Layer Security (tls)

Agenda

https://datatracker.ietf.org/meeting/120/session/tls

ML-KEM Post-Quantum Key Agreement for TLS 1.3

draft自体は今年3月から更新はされていない。Named Groupに mlkem768(0x0768) と mlkem1024(0x1024) を足すという提案。MTI(Mandatory To Implement、必須実装)にはしないという。MLKEM512 も欲しいという声や、文書を分割したほうがいいのでは？という案が出てきているが、前回と比較して提案自体はおおむね前向きな印象？

The Transport Layer Security (TLS) Protocol Version 1.3

エラッタの修正が入っている。X25519をMTIとするかどうかで投票が行われたようで、結果としては今は行わないということに。

Hybrid key exchange in TLS 1.3

X25519Kyber768Draft00はChromeとCloudflareでもう使用できるようになっていて、20%のnegotiationsにおいてこれが使われるようになっている(マジで！？)。

https://pq.cloudflareresearch.com/ にアクセスすると X25519Kyber768Draft00 が使われているかどうかわかります。

Chrome 127.0.6533.73 Firefox 128.0.3
Chrome 127の結果 Firefox 128の結果

TLS Formal Analysis Triage

“Formal Analysis Triage Panel” ではなく “Formal Analysis Triage Team” ということになった？略して “FATT"。学術論文の査読のように匿名で行なわれていることに対する議論が行なわれていたように見える(賛否両論)。というかこの議論を簡潔にまとめられる気がしないので気になる人は議事録を参照してください。かなり長い。

A well-known URI for publishing ECHConfigList values

ドラフト自体の説明は ECH の config を well-known URI で配布するドラフトのメモ - araya’s reservoir に詳しい。i18nの問題があるらしいけど、それは国際化ドメイン名のことなんだろうか？"more generic?” とされているけど、ECHだけではなくkey_shareなどTLSで必要なパラメータの公開のためにも使うことはできないのか？みたいな議論がされたみたい。dnsop wgと連携する案も。

TLS 1.2 is in Feature Freeze

TLS 1.2にはpost-quantumのサポートは入らないだろう(しかしminutesを読むと逆の意味にも取れるような……TLS 1.2にpq関連のものを追加することを咎めないようなニュアンスの記録がある？)。

SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH)

ドラフト自体の説明は TLS Encrypted Client Hello用のSSLKEYLOGFILE拡張の提案仕様 - ASnoKaze blog に詳しい(いつもありがとうございます)。SSLKEYLOGFILEにおいてEncrypted Client Helloが行われた場合における鍵も記載するようにしたいというのは、それはそう。

もう既にいくつか実装がある(！)。SSHKEYLOGがTLSのセキュリティを崩壊させるという意見、いやいやデバッグ用なのでそういうものではない、など意見の対立はあったものの採用する方向でいくことになっている。

Extended Key Update for Transport Layer Security (TLS) 1.3

長生きなTLS connectionにおいての鍵更新をなんとかしたいという話。TLS 1.2での再ネゴシエーションが脆弱であるということでTLS 1.3では削除されている仕組み。(ラムダノートさんの「プロフェッショナルTLS＆PKI改題第2版」では「8.1 安全でない再ネゴシエーション」として記載があります)

これが、通信インフラやIoT機器などのコネクションが長生きする場面において通信内容をよりセキュアにするために有用であるという提案。仕組みではpost-quantumでも使われるKEMを使う？RFC 9180を参照するとのこと。

以上が前回書いたこと。SSH3のケースを考えると有用だ、という意見。前向きなように見える。

Towards SSH3: How HTTP/3 improves secure shells | APNIC Blog

TLS Trust Expressions

ドラフトの内容については 信頼しているCAをネゴシエーションする TLS Trust Anchor Negotiation のメモ - ASnoKaze blog を参照してください。

Trust Anchor IDsとTrust Expressionsのどちらを採用するか、という投票の結果はTrust Anchor IDsが優勢。その場合のShort CA Nameってどう決めるんだろう。IANAに置くのかな。

QUIC (quic)

Agenda

https://datatracker.ietf.org/meeting/120/session/quic

Multipath QUIC

Chair slideにおいて3GPP(モバイル通信規格の標準化プロジェクト)との連携があることが述べられている。3GPP側からはATSSSの内容においてこのMultipath QUICのdraftを参照しているよ、という連絡があった……と書いてあるけど、その3GPPのドキュメントがどこにあるのか、探しかたが全然わからない……Zennでの解説は発見しました。

Multipath QUICそのものについては、Frame名が変更されたり、エラーコードをどうするか、pathがタイムアウトしたときにどうするか、実装間の相互運用性の状況はどうか、などもりだくさん。

qlog

時刻表現を相対的なものか絶対時刻のどちらを採用するかという議論が行なわれたようだけど、議事録を見る感じではどっちに決着したかがわからない。

IETF 120が終わったタイミングで https://github.com/quicwg/qlog/pull/433 が出ている。この提案だとどのような時刻表現を採用しているかをlog先頭で宣言する形式か。……複雑ではないかなあ。

Accurate ECN

ACCURATE_ACK_ECN frameの導入によって輻輳制御アルゴリズムに対しより詳細な情報を提供できるようにしようというもの。累積のECNカウントではなく、個別にどのpacketがCongestion Experiencedとなったかを知れるようにしたい。そもそもコンセプトに反対だったり、ack frequencyのほうがよいのではないかという意見があった。QUICの拡張としてやってみようという結論になったように読める。

HTTP/3 Prioritization in the wild

特定のdraftというよりは現実世界における調査のまとめのよう。 Extensible Prioritization Schemeというのはこれかな。

各ブラウザおよびサーバー実装のサポート状況、fetchpriorityの効果についてまとめられている。うまくいってない感じ……？

QUIC tokens

RFC 9000における

When a server receives an Initial packet with an address validation token, it MUST attempt to validate the token, unless it has already completed address validation. If the token is invalid, then the server SHOULD proceed as if the client did not have a validated address, including potentially sending a Retry packet. Tokens provided with NEW_TOKEN frames and Retry packets can be distinguished by servers (see Section 8.1.1), and the latter can be validated more strictly. https://datatracker.ietf.org/doc/html/rfc9000#section-8.1.3-10

という記述にあいまいさがあり、NEW_TOKEN か Retry で送信されるtokenは区別できるべきで、serverが不正なRetryトークン以外は正常なclient initialを受信した場合は直ちに INVALID_TOKENエラーで接続を閉じなければいけない。このとき、NEW_TOKEN と Retry トークンの区別が曖昧な場合は誤った処理が引き起こされる……？

“Extensible tokens” がこの問題を解決できるかもしれない、という意見があるけど、"Extensible tokens"とは……？

まとめ

むずかしいですね。こんなにあやふやなまとめになってしまって誰に需要があるのか……1人でこんなに追うものではないのかもしれません。

あと、sylph01さんとIETFなど標準化活動について話した内容をPodcastとして公開しました。ぜひ聞いてください。そして文字起こしを買ってください。

というわけでPodcast初出演です。ここにない範囲では、SMTPをやめろとは何か（メッセージングの未来とその課題について）、「真のIETF/RubyKaigiは廊下にある」とはどういうことか、あとふるさと納税のおすすめの柑橘について話しました。よろしくねよろしくね https://t.co/JvI2LwcIoe

— sylph01 (@s01) July 22, 2024
2024年07月31日
2024年06月23日

高専DJ部は2024年5月で10周年を迎えました

#40の看板

高専DJ部とは

https://kosendj-bu.in

なりたち そもそも高専DJ部は高専カンファレンスという高専生を中心としたコミュニテからのスピンオフになります。もともとは音楽が好きな人達が「高専DJ部」という名前でFacebookにグループをつくっていて、それが2013年の4月5日とのことです (中略) というわけで初イベントは2014年5月31日でした。Facebookにグループをつくってから1年と少しでイベントをやるまでになりました。 高専DJ部について - 良いあそなすちゃん

これが高専DJ部のなりたちです。このときから、rooqさんを部長、asonasさんを顧問として、およそ2ヶ月おきに早稲田の茶箱で高専DJ部は開催されてきました。

僕が高専DJ部を知ったのは高専生の頃、たしかTwitterで流れてきのがきっかけで、東京で就職できたら行ってみたい、できればDJとして出てみたいなあと思ったものでした。

Ust待機 #kosendj

— うなすけ (高専DJ部#40 6/1) (@yu_suke1994) May 31, 2014

当時はUstreamで配信していたんですね。

そして僕は東京の会社に就職し、高専DJ部に現地参加できるようになりました。僕の初DJは高専DJ部第8回のことでした。

https://github.com/kosendj/kosendj-bu.in/blob/master/archive/08.yml

引き継ぎ

そして高専DJ部第8回からDJを始め、よほどのことがなければ毎回DJとして立候補を続けていました。

そんな折、asonasさんが多忙になるということでゆるやかに運営業の引き継ぎをはじめ、第19回以降は僕がオーガナイザーとしての取りまとめを行うようななりました。

その後、開催頻度が3ヶ月毎になったり、配信がTwitchになったりと細かな変更はありましたが、とうとう2024年6月1日の回で第40回かつ10周年を迎えることができました。

第40回では、僕がクラブミュージックを知る切っ掛けとなったKONAMIのBEMANIシリーズから、10年前の稼動シリーズであるbeatmania IIDX 22 PENDUALから中心に曲をチョイスしました。音ゲー君すぎましたね。

高専カンファレンス界隈に向けて

高専DJ部は、前述のように高専カンファレンスからスピンオフとして始まったクラブイベントです。そして10周年を迎えるわけですが、ひとつ課題があります。それは最近新入部員がめっきり減っていることです。そもそも認知すらされていないかもしれません。

ここ最近、コロナ禍で途絶えてた高専カンファレンスの開催がどんどん勢いを取り戻している様子を観測しています。

https://kosenconf.jp

そこで再度現役生や、卒業したばかりの元高専生に高専DJ部の存在を(再度)知ってもらおうと、僕が行ける範囲で参加して高専DJ部についての話ができればいいなと最近は考えています。

首都圏に在住していない方々には、無理に来てほしいとは思っていませんが、とりあえず知っていただけたら、よければ開催しているときにはTwitchでの配信を観ていただければと思います。もし興味があれば、Discordサーバーもあるので覗きに来てください。x.com/kosendj や x.com/yu_suke1994 に話しかけてもらうのでも大丈夫です。

そんなわけで、これからの高専DJ部もよろしくお願いします。

https://kosendj-bu.in

2024年06月23日
2024年05月30日

RubyKaigi 2024 参加記

はじめに

昨年は英語で書いたんですが、今年は発表できなかったので日本語で書きます。

登壇したかったニャンね

いや〜〜〜〜〜〜〜〜〜〜〜〜……はい。

特にしおいさん、いまいずみさんと僕はRubyKaigi Takeout 2021での初登壇以来、RubyKaigi 2023まで連続してacceptされていたので、勝手に同期みたいな仲間意識を感じていたのですが、今年は僕がnot acceptedとなり、ぐぅぅぅ……という感じです1。まあnot acceptedとなることに対しての納得はあるので、精進が必要、といったところですね。

トーク

まともに聞けているのがあまりない……以下箇条書きで感想を書いていきます。

コミュニケーション

やはり普段会えない人と会えるというのはとても貴重な機会でした。STORES CAFEでJeremyを独り占めしてOpenBSDのことを教えてもらったり2、いまいずみさんと英語トークの(自分なりの)準備のしかたについて話したり、RubyKaraokeで転岩を2回リクエストされたり、RubyMusicMixinでありたそと限界になったり……

#rubykaigi @yu_suke1994 pic.twitter.com/PRrRq86Lmj

— ima1zumi (@ima1zumi) May 17, 2024

RubyMusicMixin terfno撮影

#RubyKaigiNOC

昨年までは得に何も考えずにスケジュールを決めた結果、NOC完全撤収の前に帰ってしまうという(自分的)失態をしたので、今年はちゃんと最後の集荷のスケジュールに合わせて帰ることにしました。ので自分史上最も長くRubyKaigiの会場付近にいたことになります。これは来年も継続していきたいことのひとつです。

NOCの仕事としては、ネットワーク構築、発注したケーブルの巻き直し、当日のケーブル敷設、AP設置、会期中の運用、クソクイズ出題、そして撤収などなどなどがあります。このうち、僕が関われるケーブル巻き直し、敷設、設置、撤収については、特に今年はKMCからの若者が多数参加してくれたおかげで、会場作業については例年の比ではない速度で完了させることができました。本当に助かりました。

Today’s #rubykaigiNOC quiz deployed! #rubykaigi pic.twitter.com/nNG47iIDbZ

— osyoyu (@osyoyu) May 17, 2024

ところで皆さんはDay 0の準備中や、Day 4の撤収作業をDiscordで配信していたことにお気付きでしたか？

RubyKaigi Discordサーバのnetops VCでやってます（きてね）。 #rubykaigi #rubykaigiNOC https://t.co/aKfbTF6OSo https://t.co/A2gUzTlHLQ

— 花月かすみΛ__Λ (@k_hanazuki) May 18, 2024

Day 4は何人か聞きにきてくれたのを観測しています。来年どうなるかはわかりませんが、おもしろコンテンツとして聞きにきてくれたらいいかなと思います。

レジャー

完全撤収日まで滞在すると数日何も作業予定のない日が発生します。このタイミングで沖縄を満喫しました。

#rubyistsonwaves

おしょうゆという人がいます。僕は彼に「沖縄行くんだったら船舶免許取ったほうがいいよ」と背中を押され、取りました。

そして土曜日、海へ……

風も強くて波も高いけど最高！！！！！ #rubykaigi #rubyistsonwaves pic.twitter.com/eTayA3Z7J0

— なっちゃん (@pndcat) May 18, 2024

海に出たあとは戻ってバーベキューをしたりして、これは完全に “陽” だな……と改めて思います。

#rubyistsonwaves @yu_suke1994 pic.twitter.com/gLNOKnQgtb

— ねっけつ (@nekketsuuu) May 18, 2024

この日は海から帰った後、なはーとで少しNOCの撤収作業があったのでそりゃ夜にはこうなりますわな、という写真です。

pic.twitter.com/jiJtOt74sT

— そらは (@sora_h) May 18, 2024

ドライブ

果報バンタ(カフウバンタ)

それでもまだ数日の空きがあり、その日はKMCのメンバーで沖縄ドライブをしました。民泊でバーベキュー、美ら海水族館、植物園、辺戸岬、ダム見学、タコライス、24時間営業のmelonbooks……沖縄でやるレジャーっぽいことをそこそこやれて良かったです。

#rubykaigi pic.twitter.com/cnRTTBNbJi

— そらは (@sora_h) May 19, 2024

やっていくぞ

RubyKaigiが終わったら、Kaigi on Railsがやってくるわけです。Kaigi on Railsがんばりモードに切り替えて、やっていきます。

また、ふと思い付いた取り組みがあり、関係者には企みを話して「やろう」ということになったので、やっていきます。こういう話が顔を合わせてやれるのもRubyKaigiのいいところですね。

コミットしよ

  1. この気持ちはおふたりにぶつけ済 ↩

  2. Jeremyと話したかった人がいたらマジごめんという感じ ↩

2024年05月30日
2024年05月25日

技術書典16に出展します

3行で

本について

TLS 1.3のRFCを読んでいく本：キリンセル

詳しくは以前の記事、「C103の2日目(12/31)にTLS 1.3についての同人誌を頒布します」を参照していただきたいのですが、要はRFC 8446の日本語訳にちょっとした解説などが付いた本となっています。

物理在庫について

以前の記事でも書いたように、物理の在庫を売り切るまでは物理本の通販はしません。また、よっぽどのことがない限り物理本を再度印刷することもしません。物理は売り切ったらそこまでのつもりです。

また、後日公開予定1の電子版については、本当に本の内容のみ公開予定で、つまりナナメさんのイラストについては当日会場、または電子版を購入していただいた方のみの限定コンテンツとなります。(おまけポストカードはそれなりの数を用意したので、会場で売り切れとなった場合に余っていればお渡しします)

電子版について

本来、この本はPDFやEPUBなどの形式による頒布をするつもりはありませんでした。ですが技術書典ということで、電子版を用意しました。こちらの電子版にはナナメさんによる表紙絵とイラストが含まれています。(電子を用意するつもりがなかったのは、まずは物理の在庫をなくしてしまいたいので……本がぶ厚いんですよ！8mmあります！)

この電子版についても、可能であれば技術書典16終了後に頒布を停止する予定です。

取り置き制度(C103同様)

pixivFANBOXおよびGitHub Sponsorsで支援していただいている方に対しては、連絡をいただければ取り置きをさせていただきます。当日お渡しする際には支援していることの確認となるものを提示していただくかもしれません。準備をお願いします。詳しくは各プラットフォームからの連絡をご参照ください。なお、申し訳ありませんが支援金額を頒布価格から差し引くという対応はしません。まあそんな爆裂に売れていくなんてことはないと思いますが……

さいごに

TLS 1.3のRFCを読んでいく本：キリンセル

手ぶらで帰りたい！！！皆さんよろしくお願いします！！！！！「か 01」でお待ちしています。

  1. 本当は技術書典終了し次第公開したかったのですが、色々間に合わず……すみません ↩

2024年05月25日
2024年04月28日

ギターを買い、バンドを組み、ライブをしました。

撮影 HoliGrail

まさかこんなことになるとは

以前のブログ記事でも書いたように、バンドを組み、オリジナル曲「タワーマンの孤独」を含む3曲を演奏しました。まさかこんなことになるとは。

経緯

経緯についてはなぜか動画が公開されているので、そちらを見ていただくのでもいいです。なぜあるんだ？

というわけで、あそなすさんという方にめちゃくちゃ「バンドやろうぜ」という勧誘を受けていて、根負けしました。

勧誘の様子

ただ押し切られて嫌々始めたわけでもなく、昔から家族や友達など周囲に楽器を演奏できる人がおり、興味がなくはなかったことと、「How To Become A Hacker」に

なにか楽器を上手に演奏したり、歌が歌えるようになること。

とあることから、楽器を演奏できるようになることには憧れがありました。問題は初期費用とか、練習する時間が確保できるのかとか、そもそも練習しても全然弾けるようにならなかったらとかいう不安もありましたが……

というわけで背中を押され、ギターを買いました。

ギター購入時ログその1

ギター購入時ログその2

#今日のうなすけ pic.twitter.com/JajEw4JhvU

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) October 8, 2023

ハネモノ

まず簡単な曲が弾けるようになろうということで、スピッツの「ハネモノ」を課題曲として課されました。

ハネモノ練習時の感想

これがそのままライブで披露する1曲目になりました。ハネモノを家で練習しながら、月に1回くらいのペースでスタジオに集まって練習をしていました。

転がる岩、君に朝が降る

その後、流れで次の曲はASIAN KUNG-FU GENERATIONの「転がる岩、君に朝が降る」にしようということに決まりました。これは確かスタジオ練習で決まったことなのでテキストのログがありません1。

オリジナル曲「タワーマンの孤独」

そして2曲目を決めたのと同じタイミングで、新曲をお願いして作ってもらおうということになりました。というのも、仲間内のDiscordでもともとChatGPTやSuno.aiを使った謎の曲がchiastoliteさんの手によって生み出されており、これをちゃんと編曲してもらったらいいんじゃないか、ということになったのです。

編曲は樫野創音さん (@kashino_tsukune)にお願いしました。

依頼したときのログ

快く引き受けてくださり、また素晴らしい曲に編曲していただき本当に感謝しています。この場を借りてお礼させていただきます。

編曲していただいたものをみんなで聞いたとき、本当に良い曲になっていて感動すると同時に、「これ、自分に演奏できるのか……？」と不安にもなりました。これが3月上旬のことです。

その後練習を重ね、なんとか弾けるようになり、ライブ本番を迎えます。

ライブ

最高 #ukfes pic.twitter.com/J81QChlMSF

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) April 27, 2024

楽しかったです！！！！！！！

来ていただいた皆さん本当にありがとうございました。

そもそもライブで初お披露目となる曲でみんながノッてくれるのか、という不安がありましたが、冒頭の「Road to 1st LIVE うなばん！」を作成したjigsawさんにより歌詞のカラオケ表示があったおかげで、大盛況だった……と聞いています(演奏してるとそこまであまり気にする余裕がない)。本当にありがとうございました。

また、初ライブ&誕生日(誕生日ではありません)祝いということでなっちゃん(@pndcat)にケーキを頂きました。ありがとうございました。美味しかったです。

#ukfes pic.twitter.com/gTxpxkvRVI

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) April 27, 2024

こうしてみると、バンドメンバーはもちろんそうですが、それ以外にもたくさんの方々が関わってくれていることがわかります。とても大きな感謝の気持ちと、ちょっぴりの「あなたたちのせいですからね」という両方の気持ちがあります。これからもよろしくお願いします。

初ライブめちゃくちゃ楽しかったです！！！！！！！ #ukfes

— うなすけ (@yu_suke1994) April 27, 2024

ただ反省点は多くて、まずは主体性を獲得したいと思います #ukfes

— うなすけ (@yu_suke1994) April 27, 2024

あと、ぼざろ観ます #ukfes

— うなすけ (@yu_suke1994) April 27, 2024

次回

ukfesはまた開催されるということもあり、2度目のライブに向けてまた演奏できる曲を増やしたりなんだりやっていくつもりです。がんばります。

  1. 関係者向け おそらく2023年12月23日の練習録画 52:30からの会話 ↩

2024年04月28日
2024年04月02日

バンドを組んでフェスに出ることになったので大岡山に来てください

要約

来てくれ！！！！！！！！！！！！！！！！！

バンド結成しました

#今日のうなすけ pic.twitter.com/JajEw4JhvU

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) October 8, 2023

めちゃくちゃ勧誘されたので、ギターを買ってバンドを組むことにしました。メンバーは以下です。

バンド名は「うなばん！」です。ホントに？いい名前が思い浮かんだら変わるかもしれません。

「新曲」？

初ライブでオリジナルの新曲があるの正気か？と思うんですが、あるのでしょうがないです。この新曲についてはライブが終わったあとに書こうと思っているふりかえりで色々書くつもりでいます。曲はめちゃくちゃカッコイイので気になってる人はぜひukfesに来てください！！！！！！！！！！！

2024年04月02日
古い投稿