The IETF is a rather peaceful place for me these days.
Long gone are the days where I was a central participant in administrative restructuring, intramural and extramural conflict resolution, restructuring of areas and architectures, fights to the death about management architectures and the proper use of HTML.
But there's still lots of stuff being worked on in the IETF – some of it minor, some of it major, lots of it interesting, and none of it certain of outcome.
One event that's garnered a great deal of anxiety and debate in the past was presented again at this IETF, to a surprisingly small reaction: If people go on behaving as they do today, the IP version 4 address space, the basic resource for adding new networks to the global Internet, will be exhausted in about 3 years.
That means that anyone who wants an extra block of addresses on the Internet will be unable to simply go to a registry, do the paperwork and get one as today; he will have to figure out a way to get it from someone who currently holds it. We've got absolutely no active theory about what implications this has on how we grow the IPv4 Internet, whether that will speed adoption of the IPv6 Internet (although many hope so), or how people will behave in the run-up to the exhaustion moment.
Perhaps one of the clearest signs of how much things have changed – although so low key I missed it at the time – was the presentation on administrative matters at the Wednesday plenary meeting.
The IETF is spending some 4 million dollars a year – a majority coming from meeting fees, the remainder paid by ISOC from its membership fees. There's a budget – the budget balances; we are building no reserves. But the budget is based on the assumption that every meeting has a sponsor (to the tune of USD 100.000 on the income/covering cost side), and that attendance is flat around 1300.
This time, we were 1150, and there is no sponsor yet found for the 70th IETF meeting in Vancouver. We're looking at a shortfall, and the only way the IETF can make up a shortfall with some predictability is through raising meeting fees. Bad news.
Five years ago, such a suggestion would have people lined up 10 deep at the mikes, suggesting everything from meeting at universities to fewer cookies at breaks – and rendering heartfelt complaints about how we were squeezing the poor researchers out of the IETF, destroying the diversitiy that had made the IETF great – and so on, and so forth. This time, not one comment. Not ONE.
The reason? Could be apathy – could be indifference – could be many things. But I believe part of the reason is that behind the man presenting the bad news was lined up the IETF Administrative Oversight Committee (IAOC), consisting of individuals selected by, and known to, the community. I believe the people on the floor were actually showing by their silence that they were extending trust: They had charged these people with running the economic side of the IETF. They were telling news that was not good, but they were taking the responsibility for fixing it. And if they couldn't, they were willing to live with the consequences.
Trust is a precious thing. And I believe that it has been extended.
But let's wander down the layers of the stack and see what else we can find.... the IETF is still a big organization, and I had only two eyes on the activities.... these are just samples from an ocean of activities.
This is where I started in the IETF. And it's still the one where I feel most at home.
It's slowly turning into one of the smallest IETF areas – only 6 or so WGs were meeting this time, and a couple of BOFs. Some of them, like LEMONADE (IMAP extensions and profiles for the mobile space) have been going on for years, are relatively small and have a stable group of people who all know each others well. Others are newer....
Perhaps the most well-attended Apps BOF was the one on HTTP: Given that the spec is just about 10 years old, and we're seeing HTTP used in an increasingly bewildering number of ways – we know that there are parts of this spec that will seriously mislead someone who try to implement from it, and others where the behaviour described in the spec is so universallly ignored that it would be better if the spec said what everyone does.
The other big mess in HTTP-space is security: HTTP with TLS on a separate port is THE mechanism of choice these days, but there's zero interoperability between the literally thousands of different authentication schemes out there – everyone seems to go for login forms and cookies, with the “authentication” headers and methods being a spottily implemented and rarely used special case. But we know that this area is an extremely contentious one, with many strongly held opinions and a wide range of options for what the IETF can mandate, define or declare obsolete – and an equally wide range of opinions on whether it actually matters what the IETF says in this space.
So one of the overriding concerns of the BOF was to find a way to pry these two issues apart – work on the HTTP clarification without getting hung up in the security flamewars, and find a way to have the security discussin without too much time spent following the nit-fixing of the spec update.
A reasonable charter came out of the BOF – we'll see what happens next.
This BOF – named after the BIFF mail-alert program on Unix, which in turn was named after a dog that (some claim) barked at the postman – was concerned with a possible way to couple our technologies for presence notification (XMPP and SIP) with the job of telling people when it's time to take a look in that mailbox.....
The discussion centered around a proposed architecture where the mail store talks to a “notification server” component in the same admin domain (think of it as part of the same service), and tells it about every single change in state it gets (for instance, number of unread mail in a mailbox) + what caused the change – mail arrival, mail deletion, mail getting read, mail marked as unread..... the notification server will then accept subscriptions from listeners (who may use XMPP, SIP or other protocols), and when it sees an event that matches a subscription, it will send it out as a notification.
There are of course tons of different ways one could slice this problem – does the notification server filter? Does the mail server? Does the notification server keep state? Are there rate limits imposed? And so on and so forth.
Two questions stood out as the ones that were referred to repeatedly:
What are the use cases?
What other situations than mail can it be used for?
The subject of notification has been a seemingly-simple problem in the IETF for many, many years. Every time we look at it, it mutates into this horrendously complex issue that admits of no solution – leaving us with a hodgepodge of limited-scope and proprietary solutions, each solving just part of the puzzle. The BOF tried to limit the problem as much as it could – but even in the seemingly-limited world of “you have mail” and unread-message counts, we may have more different scenarios than we can easily accommodate.
The EAI WG is in that delicious stage that can be characterized as “slogging towards the finish” - its 2.5 hours were well spent in debates on minutiae and design choices that are very important to get right, but if we get them right, nobody outside the WG will ever care about the arguments – so I won't attempt to report much, even though I chaired the BOF – the group's first RFC (“framework”) is published, and the group is trying to get the core specifications (SMTP extension, header formats, DSN, downgrade) finished before the next IETF meeting. They will then be published as Experimental – with the hope that we'll be able to figure out whehter this is in fact useful or not in practice before we put in the final touches and make it a standard (IF it is useful, that is).
I've been watching the Realtime Applications Area from afar, mostly – occasionally wandering into a working group and listening for a little while – so I have nothing much to report here.
It seems currently the most active area in the IETF, and is the one from which the most pepole come who want me to “get the right people at Google” - about emergency calling (ECRIT), numbers management (ENUM) and so on. I haven't been able to route many of those requests.
SIP seems to be in the “growing up” phase – in one session I visited, the speaker was bemoaning the fact that with 20 million users on a single domain, you need a Gbit/sec connection just to support the presence notifications.... it's clear that people actually use it, and that those who manage flat namespaces (think AOL) are discovering that scaling ain't always easy....
Minor cleanups are going on (as always), but I overheard one guy claiming that the ADs of this area think the work is “mostly done”. To me, that's the quiet before the storm – with DCCP and SCTP out the door, we have a reasonable set of tools for performing the transport function as we used to think of it – but we STILL have no idea how to exchange much of the information that would make applications' lives easier through the transport layer (like “is there any sense in trying to push a 5M videostream here?”). So the silence may be either the silence of exhaustion, or the silence of a failure of the imagination. We'll see.
Didn't notice anything special here. Sorry.
NETCONF, the new-and-shiny way to install configuration on boxes, is out the door – the first management protocol from the IETF in a long time that neither resembles nor references SNMP.
The WG capitulated on standardizing an information model, and just shippped a mechanism for moving proprietary XML blobs around – just that can be extremely useful, but having the ability to “understand” configurations in a box-independent way would make even more things possible.
So a few people are working on an information model – if they succeed, and get agreement, there may be some commonality among configuration managers – never perfect; proprietary stuff will always need to be there – but any step may be seen as useful. Hope?
I think TRILL lives here...
TRILL – using a link-state routing protocol for layer-2 forwarding in large Ethernet clouds – started out as a foray into space normally dominated by IEEE. It is now an IETF effort accepted by the IEEE, and is working intensely, with multiple meetings this week. But the difficulty of the IETF consensus process is that it requires consensus to be reached – there are issues on which there is sufficient disagreement that people are considering options like releasing a partial spec - “publish what we can agree on” - much like how some will view the resolution in NETCONF. Which may be a Good Thing – if “what we can agree on” corresponds to “what we have to burn into ASICs”, while “what we disagree on” corresponds to “what we can do in software”, the silicon foundries can do their stuff while the WG continues.
Apart from that, the Internet area seems to be like it has been for a long time - “caught in a twisty little maze of tunneling protocols, all different”, and trying to both show that IPv6 is a finished product and an area for innovation at the same time. Not easy.
The total for the Internet area is 29 WGs, the largest area in the IETF. They range from an NTP update to a “protocol for carrying authentication for network access” (PANA) – lots of stuff going on here, and much that I don't know much about.
Also, the DNSEXT WG lives in the Internet area – it's now in “claim victory and go dormant” mode, planning on a period of inactivity while DNSSEC finally gets deployed on the Internet. If only ICANN can work out the political details, or other efforts like DLV are able to provide viable alternatives....
Here I didn't go to any meetings – but I want to call attention to the SIDR WG (security for BGP, or “route signing in protocols as soon as we've agreed what we need to sign” - the actual agreement on what we need is being done in a different group). It seems to be getting somewhere – which, a few years back, would have seemed improbable, given the lots of bad blood and disconnected world pictures that cluttered up the area. Still, live and learn....
Not many. The IETF is still working. It's not doing much that smells like “the Internet, version 2” - we're doing lots of new stuff, but not reinventing the way the world does business.
Perhaps that's what people want from the IETF these days – getting work done, and not upsetting the apple carts?
We'll see in Vancouver.