I kind of want to write up my #ietf121 experience, but I don't think what I would write will impart the meaning it has to me unless you are me, which most of you are not.
-
I kind of want to write up my #ietf121 experience, but I don't think what I would write will impart the meaning it has to me unless you are me, which most of you are not.
I went there for #DNS reasons. I did not take part in all of the DNS related working groups, because I am at this time most interested in networking and figuring the organization out better. That includes specifically the people involved with DNS, of course, but not exclusively.
Let's focus on DNS first.
I'm glad the BoF...
-
... for the Restful Provisioning Protocol went well! The charter is up to see at https://github.com/SIDN/ietf-wg-rpp-charter/blob/main/rpp-charter.md
It's driven by SIDN, but my colleagues are also in favour, so it was good to see overwhelming support for developing a more modern protocol for domain provisioning.
Other DNS related working groups made more sense to me after I just sat in them.
That's generally my approach here. It seems like reading charters gives you the stated intent, reading drafts reveals more about how things...
-
... work, but attending the meetings gives you a much better impression of what everybody wants. That then provides the context for interpreting the fuzzier bits of charters and drafts. So that was very useful!
The other big takeaway for me was that I made some kinds of friends along the way, that I didn't quite expect. A lot of the times when you meet people once a year, so much happened between events that context is lost, and you have to reacquaint yourself with the other person and vice...
-
... versa.
I can't list all the ways in which this *wasn't* necessary, but I do think the puzzle table tradition stands out.
Last year in Prague, the organisers put up a table with a puzzle, which stood around unnoticed for a few days. At some point I asked what that was about, and was told it was an experiment, to see whether people liked working on it together. That led to me becoming one of the first #IETF puzzlers.
It also was where I met someone whose company I joined half a year...
-
... later, so you can't quite deny the networking effect.
Not only has this tradition continued, it apparently is now the case that other standards organization also put up puzzle tables. It's small things like this which created an instant connection between myself and a number of relatively random other people in the IETF, which seems stronger that I could have expected!
They now also started a board game night, which I hope will continue as well. What's noticeable here more than with the...
-
... puzzle is that it's also a space in which work gets set aside, and you meet the people behind the roles. I actually think that is very valuable to an organization that has to manage cooperation with this amount of complexity!
I'm sorry, no, this isn't about tech... it is about the people and relationships, and that's actually worth more.
With regards to the various working groups, BoFs and side meetings I went to outside of the DNS space, I gained a much better idea than I had before of...
-
... what is relevant in the IETF at the moment and why.
This I find very hard to summarize, except for having an impression confirmed that essentially everything is moving to QUIC. If it can be done im QUIC, there is a lot of pressure to do it in QUIC.
Is this good or bad?
Well, I guess it's a little bit of both. One person put it as TLS eating its way into every part of the stack. Which means that we'll have more transport security by default, while having similar behavior to the TCP we're..
-
... used to. That's good, right?
It generally is. Except for a few annoying parts.
First, transport security isn't end-to-end security. It seems that people can forget that the goal is humans, not machines communicating, so transport security is of limited use.
The second thing is that switching from one protocol to the other means there is a need for a signalling mechanism telling clients how to connect to a service.
And guess what people always get back to?
That's right, DNS.
So now...
-
... it's no longer enough to resolve names to IP addresses, you also have to resolve to choices of transport protocols.
With encrypted transports, you always have a key exchange to deal with, which can be slow.
The TLS issue is that you have a TCP handshake, which exchanges three packets. Once the TCP session is established, you have a TLS handshake, which is also three or more packets. QUIC adds key information from the start, so you only have one handshake that combines both purposes.
So...
