momokaのブログ

Interview on IETF atmosphere (part3: Erik Kline)

Profile for Erik Kline

How many tiems have you participated in the IETF?

My first meeting was IETF 70, in December 2007 in Vancouver, which I attended in person. The most recent was IETF 120, also in Vancouver, also in person. Looking at the list of past meetings, I think I've missed about 7 of these, so I've been to about 44 meetings -- 5 virtual and 39 in person.

 

How is the IETF inperson atmosphere different from other meetings?

I've attended a couple APRICOT and APNIC meetings, two to three RIPE meetings, and a handful of JANOG meetings as well (an excellent way to see beautiful parts of the country!). My experience of these meetings is that they were primarily populated by network operators and, to a lesser extent, policy makers or policy influencers. This mix of folks, plus the sponsor booths (as you note), give the nature of hallway conversations a very operational problem-solving mindset that looks first at whatever operators might do on their own, without requiring collaboration with others. There are also many interesting presentations and discussions about real world problems that are not so simply solved by a single person or organization; often the proposed solutions seemed to take the form of feature requests of network equipment or operating system vendors, and sometimes the discussions proposed more serious protocol changes.

By contrast, my experience of IETF meetings is that while it is attended by a few operators there are many more implementers from across the spectrum of Internet technologies. If you want to discuss making systemic changes that impact and require broad interoperability, then you can find network equipment vendors, browser implementers, desktop/laptop and mobile operating system implementers -- all kinds of folks. A lot of crazy ideas can float around, many of which won't come to much, but big changes are still possible when working with the diversity of folks at the IETF.

 

After your first IETF meeting in 2007 what made you continue to come to the IETF?

If you'll indulge me, I'll give you an example that goes all the way back to my first in-person IETF. I went to IETF 70 to meet folks doing IPv6 and begin to understand how I might help Google (my employer at the time) add support for IPv6, especially to the public services. During the plenary session there was discussion about the lack of deployment of IPv6 and what might be done to help make progress. The Internet Area Director at the time, Mark Townsley, said: "how about we challenge Google to offer native IPv6 before the IETF they are hosting", which was IETF 73 in Minneapolis -- less than a year later. Sitting in the audience, I immediately emailed some fellow Googlers about this challenge and we agreed that we'd like to try, though none of us were in a position to make a public commitment on Google's behalf.

I found Mark after the plenary, introduced myself, and mentioned that some of us at Google were discussing maybe giving this a try. Then began lots of work within Google across several teams that allowed us to serve search queries on ipv6.google.com during the "IPv4 Outage Experiment" at IETF 71 in Philadelphia -- only 3 months after Mark's comment at the plenary. In addition to attending IETF meetings, Google held IPv6 Implementers Conferences in 2008, 2009, and 2010 -- attended by many IETF colleagues. At the very last session of the 2010 conference an idea was floated that would become World IPv6 Day, which led to World IPv6 Launch.

All along the way, many conversations with IETF colleagues -- both in working groups and in the hallways -- were essential to the progress. The work continued from there, for example the development and standardization of 464xlat which involved mobile OS vendors, network equipment vendors, and operators. And it still continues, more than a decade and a half later, as deployment models evolve and interoperability across the Internet ecosystem is needed as we continue to explore IPv6 possibilities.

(I will say, though, that the RIR and JANOG social events were always much more interesting!)

 

Is there something you keep in mind specifically as a Area Director at onsite IETF meetings?

For me, the main focus as an Area Director during a conference is on making sure I do my part to help everyone have a successful meeting, trying to support one of the IETF's stated core values about "why we meet":

Why we meet:

We meet to pursue the IETF's mission [RFC3935]. This is partly done by advancing the development of Internet-Drafts and RFCs. We also seek to facilitate attendee participation in multiple topics and to enable cross-pollination of ideas and technologies.

 

First this means attending the sessions of all working groups for which I'm responsible, helping to address any issues the group or its chairs might need help with. This can also mean attending sessions of working groups where there might be some controversy or overlap with work in one of my working groups.

There are also lots of hallways conversations and INT AD Office Hours, where I try to help folks with document concerns or discuss how new work might get started. This often involves making introductions or references to other IETF colleagues whose expertise might be helpful. I am not a nature extrovert, but I do know friends and colleagues from over the years who each know many other IETFers, and I rely on their help a lot.

 

 

 

------

How I know Eric

During my first IETF meeting at IETF115 London, after the eMPF Bof meeting Eric and Lorenzo took me to a pub in London for a #NetLdn meeting. Lorenzo and Eric were very nice to me during the IETF not only because I was interested in IPv6, but also because they live/lived in Japan for a long time. Eric has been very nice to me for my following IETF meetings and has checked up on me on my drafts and how I was doing. Because Eric has lived in Japan from 2011 to 2018 and knows a lot of network engineers in Japan it was very interesting to hear stories about Japan from him at the IETF.

Interview on IETF atmosphere (part2: XiPeng Xiao)

I've asked questions on the IETF atmosphere from IETF v6ops chair XiPeng Xiao from Huawei.

 

Q1: How many IETF meetings have you attended, and can you share your experiences of both virtual and onsite participation?

XiPeng Xiao: 
I've attended every IETF meetings since Nov. 2019. Some were online due to the pandemic but I have been onsite when onsite meetings re-started in March 2022. Plus, I also attended every IETF meeting during 2000-2004.

  

Q2: How does the IETF maintain a unique atmosphere where participants engage as individuals, despite being sponsored by their companies? How does this impact the discussions and outcomes?

XiPeng Xiao:
The IETF maintains this unique atmosphere because it began as a community to discuss ARPANET matters informally, rather than as a standard organization (SDO). Early RFCs were just “request for comments,” like meeting minutes. This tradition makes it easier for people to participate and leads to a focus on technical merit rather than company interests.

 

 

Q3: How did you become the chair of the v6ops working group, and how do you justify the importance of this role and onsite meetings to your employer, Huawei?

XiPeng Xiao: 
I became one of the co-chairs of v6ops partly because I believe that v6ops should also be doing something it was not doing at that time and partly because the OPS Area Director wanted the existing chairs to mentor a new chair. 
Justifying the importance of this role and onsite attendance to my employer Huawei has not been difficult, as IPv6 is the next-generation Internet and is important for the whole society. 
Huawei always encourages its employees to contribute to the society. 


 

Q4:
Could you elaborate more on what specific areas or activities you wanted to add as co-chair?

XiPeng Xiao: 
I wanted to do three things as a co-chair: 
(1) re-introduce the operational presentations as many people want them 
(2) encourage more participation in the WG by making it easier for people to get presentation slots in the WG meeting 
(3) get people to acknowledge that IPv6 has issues, and that v6ops should actively identify, document and solve the issues.  
Before that, it's sort of politically-incorrect to say that IPv6 has issues as some people fear that saying so would scare potential IPv6 deployers away

 

Me:
I particularly appreciate the side meetings or agenda slots at v6ops that focus on operational presentations and informational talks. The IETF is primarily focused on standards, but presentations like Jen's 'Google’s IPv6 deployment experience' are incredibly beneficial. They allow us to learn about the practical challenges and solutions in IPv6 deployment.
I also liked how you try to highlight local operational experiences. For instance, when you asked for a local presenter in Yokohama, I was able to forward your request to the JANOG Slack, resulting in a valuable presentation on a company's IPv6 experience.
 


Q5: 
How does the work of being a chair differ when you're online versus onsite?

XiPeng Xiao: 
After becoming a chair, I have attended every meeting onsite to chair the WG meeting and personally communicate with various parties who may be debating over an important WG draft. Onsite attendance makes a chair much more effective.

 

Q6: 
As chair, have you encountered situations where you needed to address harassment or overly heated discussions during IETF meetings? How are such challenges handled to ensure a respectful and inclusive environment?

XiPeng Xiao: 
I don't have to do much so far except reminding everybody to maintain such a respectful and inclusive environment for all in every WG meeting. The IETF leadership team has done a lot in this regard for the whole IETF. I think it's in everybody's interest to maintain such an environment. Therefore, if any deviation is reported, I will surely intervene, and seek AD assistance if needed.

 

#技術書典 でオフラインで販売しました! (オンラインで販売中!)

Image

売る側は初参加、買う側は前回に続き2回目でした!

合同誌とういことで総勢15人で14章とデザインを同期でやりました!

実際に製本された本を手に取ってみた感想は「分厚すぎる」でした。さすがに14人が書いた一つの本は分厚すぎる。重い。

売り上げやわかりやすさを考えると合同誌形式で売らず一冊一冊に分けて売った方がたくさんの人に買ってもらえたのかなと思う反省はあったのですが、売り上げを作ることが目的というより同期で一緒にわいわいすることが目的でやってた部分が大きいので、同期のみんなと一緒に楽しく売れて満足です。

いろんな知り合いに買っていただいたり、会社の先輩方がSlackで見たと言って買ってくださったのは嬉しかったです。

 

自分は「インターネットプロトコルを標準化する IETF へなぜ対面参加する? ~インタビューで探ってみた~」というタイトルでインタビュー本を書きました。

気になる方は買ってくださるととても喜びます。買ったとわかるようにツイートで感想もお願いします!

techbookfest.org

自分の章の前書きです。

Image

Image

Image

ツイート

 

他の章の紹介

 

写真

@mochikoAsTech さん

@941 さん

 

 

#技術書典 に同期と書いた合同誌を出します! 11月3日(日)売ります!

こちらです!

techbookfest.org

どこで買える?

技術書典17というイベントで買えます。技術書典はオンラインマーケットとオフライン販売を両方開催するので、ネットでも現地でも紙の本が買えます。紙本を買うと、電子版も付いてきます。

技術書典17 オンライン 

販売期間: 2024年11月2日(土) 〜 11月17日(日)
技術書典オンラインマーケット 令和の新卒エンジニア:Lettuce Yogurt


技術書典17 オフライン会場
販売期間:2023年11月3日(日) 11:00 ~ 17:00
場所:池袋サンシャインシティ 展示ホールD(文化会館ビル2F)
持ち物:「入場券(無料)」と「かんたん後払いアプリ」が必要 

場所は[す10]という後ろらへんの場所。

Image

値段は?

電子+紙(11/3 会場購入):1500円

PDFのみ:1500円

電子+紙:2000円

章紹介

第1章 情報系学生のキャリアの個人的ベストプラクティス @eucyt

新卒が集まって書いた本なので一番新卒の生の声が聞きたい就活事情についてを1章目に置きました。
就活を控えている学生にも、最近の学生の就活事情に興味ある大先輩方にも読んでほしい章です。新卒エンジニアがいかに就活を行なって書類選考や面接を通ってきたのかが書かれている内容です

第2章 学生最後の1年間はリボ払いが有用って本当!? やってみた&半年経ってからの所感 @Lafolia13

2章目も新卒だからこその内容として「リボ」
「リボ払いの技術」について書かれている本 #技術書典 で他にないのでは? 

「リボはやっちゃいけない」「リボを使うのは頭が悪い騙された人」そう私はリボに怖い印象を持っていました。@Lafolia13 の話を聞くまでは

「リボ払いの技術」を読みリボを理解し、リボへの恐れを無くしましょう!

学生最後の一年にリボ払いを使いこなした新卒の話を是非

#リボはやめとけ

 

第3章 音声合成 + LLM でもう一人の自分を作る

個人開発のトピックとしてまず音声合成とLLMを活用した個人開発の話。

音声合成手法の概要がありそして実際にLLMを使用したコードの解説が乗っています。

第4章 DIY のチカラで理想の開発環境を手に入れる @N0n5ense

実は4月の入社すぐに同期での自己紹介LT会を企画したのですが、そのときの同期たちの数々の面白いLTの中でもひときわこだわりを感じたのがこの自作キーボードの話

#技術書典 に同期で出そうと企画を始めた時に真っ先に一緒に執筆して欲しいと頭に浮かび声を掛けました

 

力つきたので残りの紹介は後で書く。

是非買ってツイートしてください!!

techbookfest.org

Interview on IETF atmosphere (part1: Suresh Krishnan)

Interview with Suresh Krishnan on the IETF Experience

 

profile of Suresh

Suresh Krishnan works as a Distinguished Engineer (Strategy, Incubation and Applications) at Cisco. He has a Bachelor's degree in Electrical Engineering from the University of Madras in India and a Masters degree in Electrical Engineering from Concordia University in Canada.

He has chaired the dna, intarea, and the sofwire working groups in the IETF, the mobopts research group in the IRTF and has authored more than 30 RFCs across multiple IETF areas. He is a member of the Internet Architecture Board. He currently serves as a chair for the bpf(INT) working group. He has served as IETF Internet Area Director from 2016-2020.

 

Q0: You've attended numerous IETF meetings both in-person and virtually. Can you share the total number of IETF events you've participated in?

 

A0:  I have attended about 50 IETF meetings on site and attended 2 meetings online. 

 

--- 

 

Q1: How does the atmosphere at onsite IETF meetings compare to other technical gatherings like NANOG or Kubecon? What unique aspects of the IETF setting enhance collaboration and discussions?

 

A1:
The on site meetings provide much better opportunities for hallway conversations and the ability to resolve difficult technical conversations in person. I think the online participation in IETFs has greatly improved and provides a very good experience for working group meetings but still lacks the personal touch of offline/hallway conversations. I have also attended other technical gatherings such as 3GPP, Broadband Forum, Kubecon etc. The IETF feels very different due to the fully open nature of participation including from virtual participants. One key differentiator is also that people attend the IETF and participate as individuals even though they might be sent by a company. So it feels a lot less commercial than other technical gatherings which also have a commercial aspect to them (e.g. Kubecon).

 

--- 

 

Q2: Maintaining the Unique IETF Atmosphere
The IETF is known for its unique atmosphere where participants engage as individuals rather than company representatives. How does the IETF maintain this environment? What specific actions are taken to encourage individual engagement, and how does this model influence discussions and outcomes compared to other conferences?

 

A2:
Even though some people state their affiliations while talking most of the people do not. So you can understand their position without being influenced by the size or strength of their company. This means that people have a better chance to bring up their concerns and improvements.

 

--- 

 

Q3: Informal Gatherings at IETF
Informal gatherings like dinners and lunches are a staple of IETF meetings. How do these gatherings differ in atmosphere and interaction compared to other conferences such as 3GPP and Broadband Forum? Can you share any memorable experiences and how they contrast with similar events at other conferences?

 

A3:
Since the lunches and dinners are informally organized there is a wider variety of groups with varying interests that can gather. Usually people who are interested in similar technologies hang out together and rotate these meetings to accommodate the preferences of the participants. This leads to a lot of informal discussions and high bandwidth opportunities to resolve disputes and concerns.

 

--- 

 

Q4: Chairing IETF Working Groups: Online vs. Onsite
How does the experience of chairing an IETF working group differ when you are online versus onsite? What challenges and advantages do each setting present?

 

A4:
I think chairing online works pretty well over the past few years. IETF working groups usually have two chairs (sometimes more) and if at least one of the chairs is on site the meeting can run smoothly. If all of the chairs are remote there might be some issues in the room (e.g. Audio levels from the mics, temperature in the room etc.) that might be difficult to manage. We now have a way to explicitly have an in-person delegate who can perform these functions when all the chairs are remote.

 

--- 

 

Q5: Handling Harassment and Heated Discussions
As a chair, have you ever had to address harassment or overly heated discussions during IETF meetings? What mechanisms are in place to handle such challenges and ensure a respectful and inclusive environment for all participants?

 

A5:
Yes, I have had to sometimes step into discussions to moderate them. The chairs have some training materials and presentations to guide them in this and the IETF also has an ombudsteam to escalate to. The IETF is an inclusive forum and we are actively working on making this more accessible to people from diverse backgrounds so that we can best serve the needs of a global community of users.

 

----

 

What I thought from Suresh's response:

> The IETF feels very different due to the fully open nature of participation including from virtual participants.

I felt this a lot. The MeetEcho tool and team does a great job at making the online participation as seamless as possible. I'm very thankful for this and I think the IETF is the only conference that has this much of a perfect "hybrid" experience during the sessions.


Suresh's answer about the job as chair made me very appreciative of chairs a lot more. The work chairs do to make sure there is no issues in the room may be forgotten easily but is very important for a great meeting.

 

----

 

How I know Suresh: I don't remember the first time we've met but Suresh has always been nice to me at IETF meetings. We had dinner together as a group in IETF118 Prague and had Japanese food together and went to the Pecha Kucha session.

第57回 情報科学若手の会 に参加した。

今年も参加したので(2回目) 

去年のブログ⇩

momoka0122y.hatenablog.com

楽しかった

Twitter実況はこちらから。

https://x.com/hashtag/wakate2024?src=hashtag_click&f=live

参加者数は最多の39人。

 

夜のセッション1日目 QRコードの誤り訂正の凄さを身をもって感じました。

QRコード危機一髪ゲームとてもおもしろかった。

QRコードが理論的に読み取れるものかどうかと、カメラマンのスマホでの読み込み方によって読み込めるかは別。

発表たち

全部じゃないです。メモ書きです。

JVM は Web フロントエンド開発の夢を見るか?

speakerdeck.com

GPUの実行モデルを理解してうまく使いたい

speakerdeck.com

 

トヨタにおけるシステムソフトウェア開発の取り組み [スポンサー]

金津 穂
(トヨタ自動車(株))

[感想] 人が乗る車は完全にソフトウェアレベルで完全性、安全性を示したい、けどどても複雑なハードウェアに対しては困難。安全性は要件であって目的ではない。他の目的が安全を超えてはいけないけど、安全以外の目的もあるっぽい。

なぜオープンソースソフトウェアにコントリビュートすべきなのか[招待講演]

須田 瑛大
(日本電信電話株式会社 ソフトウェアイノベーションセンタ)

スライド

github.com

piyolog.hatenadiary.jp

めも:

Linuxは遅れて出てきただ、GNUは技術的に、BSDは法的に難航している間に漁夫の利を得る形で勢力を勝ち取った。

OSSは譲与経済か?譲与論とは→ 贈与論:Essai sur le don

(discord chatの聴講者のコメントたち)

Apache 2.0 は GPLv2 と非互換なので Rust コミュニティでは MIT とのデュアルライセンスを勧めています。デュアルライセンスは、どちらのライセンス条項で使っても良いという意味で、両方に従わないといけないという意味ではないです

佐渡さんはOSS 誕生そのものに関わった  VA Linux の日本側法人の設立した人ですね。所属もヤフーではなくて VA Linux現地法人が死んだあとも OSDN とか Slashdot の日本側のあれこれをずっとやってた方 Shuji Sado – 佐渡秀治, Open Source guy

1998年の2月から4月までの期間がオープンソース元年?

 

リーガルテックにおける検索・推薦技術[スポンサー]

リーガルテック:自然言語処理、ソフトウェアの力で法務処理をサポート

係り受け解析を用いた法律文書中の略称規定の解析についての報告

speakerdeck.com

解析している答えが文章読解依存なので難しい。

そもそも人間が正しく文章読解できなくて困ってるなら、このプログラムの正答率を検証できないのではないか?

公開されてる。

 

Kubernetesって何? -大規模なKubernetesを運用するKubernetes as a Serviceチームの話を添えて

1400クラスタもあるの多すぎすごい。大企業だから多いって言うのもあるけど、プロダクトにつき1つだけでなく、プロダクト内部のチームで一つのクラスタを持っている場合もあるためらしい。(チームによってk8sへの理解度も違うのでプロダクトで統一しているわけではないっぽい)

アラート処理を短くする自動化すごい。

 

「認証認可」という体験をデザインする ~NekkoCloud認証認可基盤計画

永見 拓人
(千葉工業大学)

docs.google.com

(from chat) Discordによる認可(サーバー所属とか)、Auth0のHookみたいな機能でスクリプトを書いて対応した記憶がある…

musaprg.hatenablog.com

発表の結論(今後の展望)は、以下のIngress Controller主体しくみを、

SideCar主体でつくりたい。

(from chat) 「実運用上はEnvoyをside-carに入れてJWT Authentication Filterを使っている人が多いのだろうか JWT Authentication — envoy 1.32.0-dev-8cd214 documentation

Kubernetes 内部で完結するサービスとかは  Bound Service Account Token を使う場合もありそう Bound Service Account Tokenとは何か #kubernetes - Qiita

「認証認可サーバーは Nekko Cloud 上に立つんでしょうか?そうするとブートストラップ問題が起きそうですが……」「そうです。。。ブートストラップ問題あります」

 

基礎の言葉の説明から始まり、とてもアツい話でした。logicaさんはすごい。

 

モノレポのすゝめ[通常]

github.com

Q. リリースのサイクルでgithubのReleasesで複数のコンポーネントが一緒くたにされたくない。

A. tagのprefixでリリース分割。Releaseでコンポーネントごとにリリースして全部リリースしなければいい。

Googleのなぜモノレポへの回答としては以下があるよね。

Why Google Stores Billions of Lines of Code in a Single Repository6

Advantages. Supporting the ultralarge-scale of Google’s codebase while
maintaining good performance for
tens of thousands of users is a challenge, but Google has embraced the
monolithic model due to its compelling advantages.
Most important, it supports:
˲ Unified versioning, one source of
truth;
˲ Extensive code sharing and reuse;
˲ Simplified dependency management;
˲ Atomic changes;
˲ Large-scale refactoring;
˲ Collaboration across teams;
˲ Flexible team boundaries and code
ownership; and
˲ Code visibility and clear tree
structure providing implicit team
namespacing. 

 

Terraform × cloud-init で VM のセットアップをいい感じにする話

speakerdeck.com

 

(from chat) 「libvirt / virsh を素で叩いてもいい気がするけどやはり GUI の利便性でウケてるのだろうか > Proxmox」

クラスタリング / スケジューリングを向こうでやってくれるのが良さみなんじゃないかな~とか思ってますけどどうなんですかね」

 

eBPFはネットワークソフトウェア開発の何を変えたか

speakerdeck.com

 

スライドの中で紹介されてた、hayakawa-sanのスライド↓

speakerdeck.com

Prism: Proxies without the Pain | USENIX

カーネル自身が検証を行うのが大事。

質疑:(こことても自信がないので間違った書き起こしになっているかも)

Q:「どれくらいVerifierを気にして書いている?」

A:「2019年の論文の話ですね。その頃はVerifierを気にして書いていた。その頃は理不尽にリジェクトされることとかあった。でも今はそんなことはVerifierはしてない。LLVMコンパイラとeBPFコンパイラを作っているのは同じ人たち。GCCで作っている人たちもいるけど今どうなってるかわからない、Clangが強いですね」

 

Q: 「WebAssenblyとなんか近い気がするけど、WebAssemblyをカーネル空間で動かしたいというのとかもあった。」

A: 「WebAssemblyとの違いとしては、ランタイムで検査をすると言うアプローチの近い。eBPF for Windows とかでも、動かされるコンテキスト(ネットワークのパケット処理なのかトレーシングの処理なのか)でメモリの安全性の汎用的なセーフティプロパティと別でコンテキストの違いがある。Windownカーネルの中で動くeBPFプログラムとLinuxカーネルで動くプログラムは、コンテキストが違うと言う意味でセーフティプロパティも違うと言える。WebAsseblyでも違うのではないか。」

 

Q: 「カーネルポインタ、ネットワークでは。アドホックな構造は欲しいか?」

A: 「話はあるがCilliumでは一旦大丈夫そう。」

 

Q: 「eBPFコードのVerifierと検証にどれくらい時間的制約が高速があるのでしょうか?Verifierとコンパイラがオーバーヘッドにならないのか知りたい。」

A: 「Verifierを通った後にeBPFのプログラムははるかに長い時間動いている。Ataccheして動かしているので。eBPFの検証に制限がかけられているのは制限なくやられて、メモリが使われるのが防ぐため。」

 

Q: 「つまりVerifierが制限されていると言うことはeBPFの機能が制限されていると言うことではないか?」

A: 「確かにeBPFに新しい機能を入れるのが難しいなど硬直化につながっているかもしれない。」

 

(from chat) 「The rapid growth of io_uring [LWN.net] io_uring API のようなものとか、Linux の upstream である種の bypass をする汎用のフレームワークが整ってきたのもあるはずで、それはなぜかというと kernel bypass 派の成果が bypass を sandboxing してでも仕組みで提供する意義を示せたからだと思う」

チャットよりこうゆうのもあるのね。

Linux Kernel Exploitation | PAWNYABLE!

github.com

とても面白かった。

ウェアラブルバイスを用いた長期的な生体信号による概日リズムの推定[ショート]

みんなで見てみた。朝型夜型?

朝型夜型質問紙

Q: 「やりたかったけど、倫理的な理由でできなかった実験はありますか?」

A: 「長い期間でやる実験。倫理というより自分がやり続けるかという問題だが」

 

Q: 「人が朝方から夜型に変わったりすることはあるがどうなんでしょう?」

A: 「日本語の質問の答えてによってやってて、いつも通りの生活をするようにお願いしている。」

Discordのコメントががとても盛り上がっていた。

プログラム検証入門

speakerdeck.com

playground:  jsCoq – The Coq Theorem Prover Online IDE

 

すいません。全くついていけてなかったです。

Rustはコンパイラを通るだけである程度の検証を通っている。

 Rust で形式検証 GitHub - model-checking/kani: Kani Rust Verifier

展望の「実用に基づいた理論を研究したい。Rustの形式検証とOS開発に興味がある。」のところでやっとなぜ検証入門の勉強をして嬉しいのか何を目指しているのかがちょっと雰囲気がわかりました。

まず『言語』から始めるソフトウェア開発

wakate2024_中神悠太_発表資料.pdf - Google ドライブ

コンパイラ(フロントエンド)が好き

字句解析とか構文解析とかがコンパイラ(フロントエンド)で、さっきの発表の意味論とかがバックエンドらしい。

TypedCFG面白い。発表の流れがうますぎて「これ今までなかったの?」という気持ちに。

中神さんはとても楽しそうに、とてもわかりやすいスライドで発表していて、聞いていて楽しかった。

LT会

たくさん面白い発表があって面白かった。

 

あなたの知らないiOS開発の世界

SwfitとLLVMは親が同じ。

Swift言語の基礎的知識をクイズ形式で。

Automatic Reference Countingの話とか。SwiftUIとか。

餅から米!神エクセルを(ほぼ)全自動再構成して爆速でバス時刻表を作る話 [ショート]

GTFSの話。

時刻表を作るの大変。ありえん周り方のバスとか。

「時刻表を立てる」とか専門用語が出てた。

 

Q. (名古屋市で)GTFS公開されていないのにGoogle Map載ってるのなぜなのか
A. 名古屋市交通局は乗換案内を含めたWeb構築をジョルダンに委託(随契?)していて、ジョルダンがデータをGoogleに提供してるから(そこまで含めた委託契約なのかは不明)

(が、更新が遅いのでダイヤ改正時期に問題になってます
ちなみに、GTFSは有効期限を設定するパラメータがあるのでその問題は起こりえないです

時刻表の時間が違う! - Google マップ コミュニティ (公共交通利用促進ネットワークさん))

 

Q: なぜやる?

A: 私がバスが好きだからです。

 

Q: なぜ公開されてたりしない?GTFS等のオープンデータ作成を通してバス利用者増加に繋げようとしない理由は何かあるのか。

A: わざわざデータを公開するメリットがない。地元の人たちには地方報とかで出してるかもしれないが、オープンにやる金銭的メリットがない。富山県だとGTFSの公開が義務付けられていたりする。

 

Q: 地図アプリによって使いやすさの違いはあるか?

A: 裏のデータがアプリによってちがう。ジョルダンか(もう一つどこか)。名古屋での乗り換えを使う時はジョルダンを使っている。一般的に使いやすいと感じるのはGoogle MapsYahoo!乗換案内とか?

最後に自分が作った名古屋市内のバスの時刻表の厚い同人本を一冊売ってた。

 

楽しかった。

今年も楽しかったです。去年と比べて同じ団体(大学のサークル、会社)からたくさんきていることが多くて賑やかだった。夜の会も楽しかった。また来年も参加したいですね。

去年はLT発表をしたけど今年はネタがなかったので来年来るとしたら何か発表したいですね。

wakate.org

去年のブログ。

momoka0122y.hatenablog.com

JANOG53.5 行ってきた(LT発表した)

janog53.5に現地参加しLTもしてきたのでメモ書き。

 

JANOG Open MIC

JANOGミーティングの形式の議論。ストリーミングの形は議論が続きますね。

JANOG slackもいいけど、非公式Discordあるよという言う話とか。

若者支援ありがたいね。

 

インターネット・ホットトピック - CONECT 吉田 友哉(エヌ・ティ・ティ・コミュニケーションズ株式会社)

CONNECTというインターネットトラフィック流通効率化検討協議会

トラフィック予測情報とか出してるらしい。

コンテンツ事業者とISP事業者が同じ部屋に集まって配信にあたるの面白そう。

総務省|電気通信政策の推進|インターネットトラヒック流通効率化検討協議会

 

インターネット・ホットトピック - RPKIホットトピック 渡辺 英一郎(エヌ・ティ・ティ・コミュニケーションズ株式会社)

RPKIの話 

リソースPKI (RPKI; Resource Public Key Infrastructure) - JPNIC

2024/4よりnot foundよりvalidの方が多いのがIPv4/IPv6双方で達成 (IPv6の方が先)

isbgpsafeyet.com

 

インターネット・ホットトピック - インターネットセキュリティ 猪俣 敦夫(大阪大学

「技術のBCPと組織のBCPは別物」技術的な面ではなく組織的な面で対応できないといけない。

 

インターネット・ホットトピック - APNIC  松崎 吉伸(株式会社インターネットイニシアティブ)

APNICの乗っ取りを狙った候補者がAPRICOT2023にいましたね。(あの当選者発表のドキドキに立ち会えたのは面白かったです。)

momoka0122y.hatenablog.com

議論に出たプロポーザル4つそのうち合意に至ったやつ2つ

合意に至ったProp-I56 Assignment of temporary IP resources 

IXPようにIPv4アドレスと所得しやすいように/26の割り当てを。

(あとあとリナンバリングが必要になったりしないか?)

IPv4アドレスを使用しないピアリングを行いたいねという意見 (RFC8950など)

Director General (DG) of APNICのPaul Wilsonさんが退任とのこと。

blog.apnic.net

 

LT1 LPO:Linear Pluggable Optics土屋 師子生(アリスタネットワークスジャパン合同会社

概要
オプティクスは光信号を電気信号を変換する役割を持ちますが 各スイッチングチップの世代が進み、SerDesのスピードが増加すると処理が複雑になります。 800Gオプティックスをフル実装した場合にはオプティクスの消費電力がシステム消費電力を上回ると予想されています。
LPO:Linear Pluggable OpticsはオプティクスのDSP処理を取り除き、大幅な省電力化を実現し、かつプラガブルモジュールの柔軟性を実現する規格です。 JANOGの皆さんへの情報提供と意見交換が出来ればと思います。

https://www.janog.gr.jp/meeting/janog53.5/doc/janog53.5_lt1.pdf

 

LT2 OHT: Outer Header TranslatorのIETF 6man WGへの提案松平 直樹(網手順技研)

概要
NPTv6(IPv6版NAT)のスタンダードトラック化の提案を踏まえ、OHT(Outer Header Translator)という技術をIETF 6man WGに提案しました。この経緯とOHTを共有します。

www.ietf.org

 

LT3 IPアドレスの例で 例示アドレス帯使ってます?山本 桃歌

概要
みなさんはドキュメント作成などでアドレスを書く時例示アドレスを使用していますでしょうか? IPv4 では 192.0.2.0/24 TEST-NET-1 198.51.100.0/24 TEST-NET-2 203.0.113.0/24 TEST-NET-3 がRFC5737で IPv6では 2001:DB8::/32 がRFC3849で定められています。
昨年IPv6の例示アドレスに/20の新しいブロックを追加しようというドラフトがIETF v6ops wgに提出されwg adoptionされました。

自分の発表。

例示アドレスの話、IETFの話、ARINのISPではない会社へのIPv6 の/16割り当て

の話をしました。

スライド:

docs.google.com

会場から笑いをとることができたので我ながら成功のLTかなと

終わったあと川島さんに6bone用のアドレスを例示アドレスとしてデファクトにしようという動きはお行儀が悪いという意見をいただき、確かに過去の6boneの資料と例示アドレスが被ってしまうのはドキュメント用ととしてもわかりにくいのでよくないなと思った。

ドラフトはLastCall通ったのでこれからIANAの方が決めていくフェーズ。

 

LT4 Apple NAT64 環境下でのIPv6検証、それもうIPv6検証にはなっていないかも?佐藤 元彦(株式会社コナミデジタルエンタテインメント

概要
ApplemacOSにNAT64+DNS64構築の機能を搭載し、それを使ってIPv6対応の検証を行うように、と「WWDC 2015」で告知して以降、ゲーム業界では「Appleのアプリ審査を通すため」というモチベーションを主とし、それに取り組んできた。

しかしそれから10年近くが経過した今、この状況は大きく変わった。なんと、最新のiOS17で冒頭の環境での通信テストを行った場合「IPv6対応の検証」を行うことはできなくなってしまったのだ。

どういうことかというと、iOSはiOS12からCLATの機能がOSに組み込まれており、LTE/5Gでの通信時にNAT64を検知した場合は、通信キャリアによってはCLATが有効になり、464XLAT(https://datatracker.ietf.org/doc/html/rfc6877)という方式での通信に切り替わっている。通信を行うクライアントの目線でわかりやすく言い換えると、これはクライアントが「IPv4でSocketをBindし、IPv4の通信先に従来通り通信が行える」という環境であり、IPv6未対応のOS/アプリであっても、ほぼ正常に動作するものである。

WiFiでの通信においてiOSのCLAT機能はこれまで有効ではなかったが、iOS17以降ではWiFiでも有効となり、464XLATでの通信になっている。すなわち、冒頭の環境でテストしようにもIPv4で正常に通信が行えてしまい、IPv6通信のテストが成立しなくなっているのだ。

今回は、iOS16,17とApple NAT64+DNS64の検証結果から発覚した上記の変化について共有する。また、この状況下でIPv6対応の検証をどうすべきかについて問題提起を行い、いくつかの解決策を併せて紹介する。

資料

https://www.janog.gr.jp/meeting/janog53.5/doc/janog53.5_lt4.pdf

LTと思えない深さ。IPv6対応の検証しやすい環境づくり大事ですね。

AppleのCLATの実装面白いですね。(CLATは今はandroidAppleですけど、Windowsももう直ぐ、linuxもきっと)

話のモチベーションとしては昔の記事でIPv6対応の検証にAppleNAT64を使うと言う情報がたくさん出たが、それは今は使えないので情報をきちんとアップデートしたいと言う思いがある。

 

LT5 ハイブリッドクラウド接続検証環境をフル仮想化してみた山本 泰士(NTTデータ

クラウド利用が進む中で仮想環境での学習や検証をしやすい時代となっていますが、それでもクラウド〜オンプレミス間のハイブリッド接続については回線などの物理設備を準備することのハードルが高く、それ故に触れる機会も少なく経験値を積みにくい実情があります。
このような状況を踏まえて、クラウドだけでなく回線・オンプレミスまで含めてインターコネクトサービスや仮想アプライアンス等で仮想化することにより、準備・片付けが容易、コストも限定的、メンバは実際手を動かすことで作業イメージを膨らませることができ、様々な効果を出すことができた事例をご紹介したいと思います。
資料

https://www.janog.gr.jp/meeting/janog53.5/doc/janog53.5_lt5.pdf

 

LT6 JANOG Web Update矢田 一樹 (JANOG運営委員)

 

告知

間瀬 太陽(JSNOG)

discord.gg

 

wakamonogコミッティ(wakamonog)

wakamonog - インターネット支える若者たちのコミュニティ

 

今回はslackの雑談チャンネルと勝男さん運営の非公式JANOG discordで議論が盛り上がったのが見えて面白かったです。

 

懇親会も二時間みっちりピザと飲み物食べながらたくさんの人と話せて楽しかったです。

52.5に引き続き53.5でもLTをさせていただいて、会場の人に笑いを提供できた気がするので満足です。