(Other perspectives on the same event: Ingrid Melve)
You could almost hear the litany as the plane circled Dallas airport in preparation for landing: "SNMPv2 is falling, SNMPv2 is falling"....32 years after the last time Dallas made world news, it seemed that a new disaster loomed over the world of networking.
All efforts to produce a secure management protocol for the Internet had been in vain, the house of IETF was torn by strife and internal unrest, and the Big Bad Business vultures were hovering around the edges, waiting to tear the Internet limb from limb at the first sign of weakness.
Of course, it didn't happen.
Once you get there on the ground, once you walk into that hotel lobby and see the last remnants of the well-tailored and tie-wearing crowd from the last meeting leave, while the lobby is filling with jeans-clad, T-shirt-wearing, chattering, portable-lugging IETFers, the basic reasonableness of the process seems somehow to reassert itself.
Network management is a small (albeit important) area of the IETF, solutions can be found, goals can be redefined, friends can make up - and the business vultures seem strangely friendly as they walk around making reasonable suggestions, participating in discussions and promising to "play the Internet game" according to the rules.
More details on some things that happened (in slightly less flowering language) follow below. As usual, what happened outside the Applications area is things known by hearsay, "corridor impressions" and vaguely remembered mutterings; handle with care!
But friction is showing at the edges; a suggestion for a "style sheet" addendum to the standard engendered little enthusiasm; the proposals for an extension mechanism to allow "vendor extensions" in HTTP/1.1 were greeted with a distinct lack of enthusiasm. The phrase "too much complexity at the core" was heard more than once.
But still - the fact that HTTP extensions for "persistent connections", with their promise to ease the currently horrendous situation seen on busy Web-servers, where one can find 200 simultaneous connections and 800 connections in "shutdown state" at any given instance, are being deployed even as the standards are being written indicates a strong willingness on the part of the community to come to grips with the problems that the extreme success of the Web have engendered.
A suggestion voiced in the Transport area (the traditional home for TCP and similar things) about designing a protocol that is better for "web-like things" than TCP is needs careful nurturing; watch this space.....
A quite different story is that seen in the "Voluntary Access Control"
BOF, which was faced on one side by the Web consortium saying that "we
have the standard, and we must be in control of it for the time
being", and on the other side by the US congress (with the European
Commission falling over itself to repeat its mistakes) trying to
impose censorship on the Internet without eroding adults' rights to
free speech (an act reminescent of trying to shave with a battleaxe,
or of advocating nuclear weapons as a solution to street littering).
In this maelstrom of politically motivated posturing, little place
seems to be left for the IETF's traditional strong engineering focus
and desire to produce "solutions that work".
The result of the discussions was roughly:
It's somewhat ironic that the documents defining this vital Internet service are rather old, rather vague and rather unsatisfactory in the service they describe.
Some IETF WGs address this:
A new X.400 mapping is expected in early 1996; RECEIPT and DRUMS also expect to be shipping in 1996, but not before Los Angeles (March).
Other Email-related matters:
No less than THREE other management groups are immediately relevant:
We ARE, however, trying to get a handle on what the Directory Problem actually is; the IDS WG is trying to come up with a set of "requirements documents", which may at some point in the future allow us to say with some confidence that "this problem will NOT be solved by the Internet Directory". Then we MIGHT be able to build one!
Other promises include:
Security is implemented in several of the test implementations; this has of course hit the usual hassle of export rules ("by some mischance, it seems that someone forgot to limit access to the xxx directory, so if you are outside the US, close your ears while I write down this URL....."). Key management isn't ready yet (for either V4 or V6); it looks as if two approaches will be standardized - Photuris and SKIP.
The IESG decided that the request from the SNMPv2 working group to standardize a protocol without working security as "the Internet management protocol", because they were unable to agree on one, was simply not going to fly.
On the other hand, the "core" of the management operation itself is well known and stable; there's no pressing need for 128-bit counters, whole-table operations or other exotic changes to the "SNMP core".
So - the IESG has promised to consider the "SNMP core" as candidates for Draft Standard, while the "intro document" that describes how to run SNMPv2 with community strings (just like SNMPv1 - "passwords in the clear") is an experimental protocol - we think that it misses some basic functionality we need.
There are signs that the personal relationships in the SNMP group may be healing too; at least one participant was sighted carrying an olive branch. But it takes two to make peace, and I don't know more....it was a long and bitter discussion, and the end is not in sight yet; we still don't have a secure management protocol.
(Certain people thought that the general problem of access control in operating systems across all kinds of devices might be a mouthful for any group that went to bat with it, and the solution might involve changing the problem description until it's workable. We'll see what the result is....)
Enjoy your Internet surf - the waves crash, but the sky stays up.....