Carl Malamud: Internet Talk Radio. Asynchronous times demand asynchronous radio.
This is Geek of the Week. We’re here with Marshall T. Rose, theorist, implementer, and agent provocateur, as he describes himself. Marshall, welcome to Geek of the Week.
Marshall T. Rose: Thank you very much, Carl.
Malamud: Marshall, you’re known for a variety of things, but rather than starting with the subtle issues of protocol implementation let’s shoot a few ducks in a barrel. You’re probably best known by some at least as the author of ISODE, the ISO development environment. And I guess that makes you the world’s leading OSI implementer. Why do you like OSI so much?
Rose: [laughs] Well actually I think we’re shooting fish in a barrel, not ducks in a barrel. But probably neither is politically correct these days. It’s true that back in 1986 Dwight Cass and I began a research project on implementing OSI, primarily over the OSI upper layers, primarily over TCP. And you know, that gave us a lot of experience in implementing OSI.
At the time we started, we were really interested to find out if the OSI stuff would work, and there certainly appeared to be a lot of promise. Unfortunately, and I think history will bear me out on this—or the market’s already shown us, that OSI per se has generally been a bad idea. The concepts of vendor‐independent computer communications we all like, but when it comes down to the actual details and the way these standards are produced, and the resulting technical merit, it’s certainly been less than sterling. And you know, now having implemented a lot of OSI stuff in the 80s, in the 90s of course I’m one of the more outspoken critics of OSI. Which I imagine must drive the OSI people batty since I often understand the standards better than they do.
Malamud: Well, having actually implemented the standards can sometimes give you that insight.
Rose: Well you know, certainly one of the things which is the strength of the of the Internet process is the fact that we intertwine standardization and implementation experience. And you know, the way the current standards track works now, going to propose to draft to full, there is an increasing burden on the part of the proponents of a specification to be able to demonstrate independent implementation, interoperable deployment, and so on. So by the time you finally reach the ultimate goal of having a full Internet standard, we have excellent confidence in the workability and usefulness of this technology. And clearly that’s something which has been lacking from the OSI process.
Malamud: Well why is that? Why is something so simple as “let’s get some code out there and see if it works” missing from such a large‐scale process?
Rose: Well, there’s the…there’s the polite answer and then there’s the accurate answer. The polite answer of course is that you know, by and large the ISO, the CCITT, the ITU, ANSI, the IEEE, have kinda been overtaken by events. In the past you saw international and national standardization of very well‐defined technologies. For example, if you were going to build nuts and bolts, what the threads look like, and you know, with the proper spacing and height and grip and so on. And so you know, this is not rocket science. It’s critically important to an engineer’s infrastructure to have standardization of these things, but it’s not as if we are trying to somehow codify the laws of physics.
Now in contrast, you look at computer communications and what do you find? You know, this is extremely complicated stuff. None of it’s very obvious. A lot of it is depressingly cutting edge. And yet you know, the market seems to feel that they need a standardized product. And so in come the bodies which traditionally have done this in the international and national arenas, and they find out that they aren’t standardizing existing technology, which in the past has been exactly what they did and why they were successful. No, they are doing research concurrently with standardization, but somehow their model for standardization never made this paradigm shift to including this implementation.
You know, it’s kind of like we could have the Congress of the United State pass a law with regards to time travel, but let’s face it you know, no one has a time travel machine so what’s the point of it? You can’t change physical laws by making administrative policy. Why should you think you can standardized complicated technology without understanding it?
Malamud: Well someone argued that if you try to understand it first you end up with a process which is not fair. And many people point to the ISO process, to the CCITT process, and they say, “Well, we really have to make standards that are fair, that take into account all the views.” Do you think that is maybe the reason that ISO has been continuing to move along that track?
Rose: Well certainly every disaster in history has been very fair in penalizing the victims, hasn’t it? No, you know, let’s be honest here. What we need to do is we need to produce solutions for the marketplace. And you know, having some kind of a process with…everyone is happy and gets apple juice and cookies and gets to express their regional views and so on, may be very fine for international relations, but frankly does not go one iota toward producing good technology.
You know, Marty Schoffstahl of PSI, a person I worked for and have a lot of respect for you know, one time he was giving a talk on his thoughts of standardization. And he says, “You know, I’m really in favor of international agreements. But I also know that they don’t work all the time.” And so the audience is trying to figure out what Marty’s talking about and he says you know, “For example, there were international agreement in place but we still have something like Polish cavalry going up against the German army at the beginning of World War II.”
And what Marty’s pointing out there is that there is a big difference between getting people together to sign a paper and agree that things are going to happen a certain way, and having something in place which is actually going to produce workable result. And you know, we have to keep in mind here that is an engineering task, this is not a political task. And trying to solve engineering problems using political disciplines is bound to failure. Because you simply cannot compromise on what the value of pi, or the gravitational constant are. I mean, how could a committee decide these things? These are like, constants. You can’t compromise a constant. What’s the point?
Malamud: You could have pi 1, pi 2.
Rose: Well, and the…
Malamud: And then you can have pi profiles.
Rose: And pi profiles and then of course we could have various national character sets, and…I’m sorry that’s another target we needn’t go into now.
Malamud: You know, some people look at that and they say, “Well… That’s being unfair. There are certain things that different bodies do well.” And many people point to X.400 for example as one of the success stories of the OSI process. Now, recently there’s been an alternative set of standards that have come out of the IETF known as MIME, Multimedia Messaging for the Internet. Could you compare those two? Do you think X.400 is going to continue to gain steam or lose steam? And is MIME going to do something there?
Rose: Well, you know certainly of all the things OSI has produced, one could point to X.400 as being the most successful. On the other hand that’s kind of like saying that World War II was the successful conclusion of the Great Depression. And what I mean by that of course is that yeah you know, it’s been adopted more than the rest of this OSI stuff, but it’s still a complete disaster. You know, the technology you need to do store‐and‐forward mail is surprisingly simple. And you know, it’s not rocket science. There are some very basic architectural principles, and you may have to have some bells and whistles from time to time, but this isn’t hard stuff.
What the X.400 people did is they started with a model which is fairly well‐regarded, back in the early 80s. Took some technology which had been fairly proven. This is the stuff that came out of Xerox with regard to data representation on the wire. And they built a mail system around it. And you know, one could kinda argue about some of the choices they made, but basically it was kind of overkill for what you needed. There is just far too much computational complexity, to solve what is in theory a very simple problem.
Now unfortunately, after the great success of 84, instead of revisiting it and deciding how to make it simpler and more ubiquitous, they go on to the 88 version and they don’t even bother to figure out how to standardize migratory or transition paths between 84 and 88. It’s kind of like oh, let’s just do this thing in 88 and we’ll forget about the past whether it was good or bad.
Now, what the MIME approach does in contrast, is the MIME says, “Let us assume that we have an existing electronic mail infrastructure. And now we are going to figure out the minimalist set of changes which we can add on top of that so as not to perturb the existing infrastructure, but still add these features to individual endpoints that want them.”
So if you look at the MIME spec, you notice there’s some rules which really seem rather obscure. You know, “do not do the following thing” And then there’s be a little note saying, “The reason this rule here is because we found in practice there is some mail software which behaves poorly under the following conditions, and we want to make sure that when you write MIME software you don’t exercise those problems.”
Now you could say, “Well, you know, this shouldn’t be the point of a…a standard shouldn’t have stuff like that in it. We should just assume that everything works well and people are going to faithfully implement this stuff.” But you know, again, in the real world we see that’s not the case, and the people who did MIME were very very careful to make sure that the stuff they did would fit on top of and not exacerbate existing problems. Whereas you compare that to X.400, there’s this kind of a blanket assumption that someday everything will be X.400 and we won’t have to worry about existing mail systems or what the effect we’re going have.
And of course the result of that is that we see now a lot of X.400-to-such-and-such gateways, and those gateways really don’t work very well because the feature match between X.400 and say the LAN mail system that they’re gateway‐ing to is a very poor match. The mappings are imprecise. You know, basically the addresses are just hopelessly indecipherable. And it’s a big mess.
Malamud: Well there you have it.
Malamud: You’re listening to Geek of the Week. Support for this program is provided by O’Reilly & Associates, recognized worldwide for definitive books on the Internet, Unix, the X Windows System, and other technical topics.
Additional support for Geek of the Week comes from Sun Microsystems. Sun, the network is the computer.
[Incidental Tourist segment omitted]
This is Carl Malamud, the accidental terrorist, for Internet Talk Radio.
Internet Talk Radio, flame of the Internet.
Malamud: Let’s turn our attention instead to network management. You’re one of the leading lights in SNMP, and you recently with three of your colleagues authored SNMP version 2. Now, that was not without some controversy—In fact one of your critics described SNMP as a “dog with fleas” and expressed the hope that it would be a dead dog with fleas. Do we really need a second version? Don’t we have good enough network management software today?
Rose: Well, I guess there are really a couple of issues there. Let’s have a little bit of historical context and then I’ll kind of get your question. SNMP version 1 was developed basically in 1987 and came out of some work that was done by four engineers, one of which was a vendor and three of which had kind of like, network management operational responsibilities. And so it was kind of a very focused…the original technology’s are very focused on primarily monitoring gateways. And it became clear that we needed to evolve network management into not only monitoring but control, and not only gateways but all kinds of devices. And so SNMP version one was kind of like the evolution from this original technology done by these four engineers where they had a very crisp, focus on what they want to do to kind of like trying to solve or provide a basis for a solution to a larger problem.
Now, SNMP has a number of really get things going for it. However you know, as you implement things and see other people implement them and manage real networks, and you know, just gain experience, you find things that you could’ve done better… You know, when the same questions keep coming up or the same request for features enhancement’s coming up, you begin to think maybe we shouldn’t have left that out of the original spec. And so you know, four years after v1 was standardized, there was a call for proposals from the IESG saying, “We’d like evolve SNMP. And the way we’re going to do this is we’re going to ask interested parties to submit proposals which meet the following list of criteria.”
And there were I don’t know, about half a dozen criteria, of which two of the most important were you had to spend a lot of time worrying about coexistence with the installed base because network management on the Internet is a 7 by 24 pervasive thing. And also that you couldn’t offer a proprietary solution. It was something that was going to ultimately be standardized by a working group at the IETF.
This call came out in March of 1992. Now, several months went by and finally one proposal is put forth by myself, Jeff Case, Keith McCloghrie, and Steve Waldbusser. And this was called SMP, or the Simple Management Protocol, and basically this was our proposal.
There was a meeting held at the July 1992 IETF plenary, which about 200 people showed up. We explained what our proposal was. And there was near unanimous—and I’m not exaggerating here, virtually everyone in the room at the end that meeting decided that they wanted to go forward with SNMP v2. They wanted v2 to be the work on SNMP security plus this proposal. And that they wanted a working group formed and they wanted this thing taken care of by year’s end. The critical thing is we do not want to get ourselves involved in more than one transition, you know. Not a transition from v1 to security, and then security to v2; or v1 to SMP, and then SMP to something else. One transition, v1 to v2.
So a working was formed, and comments were solicited. Now, in between the time that there was this meeting in July and the working group formation, the area director encouraged anyone with proposals to put them forth so they could also be considered. Well, three months goes by…no other proposals show up.
Malamud: Is that enough time to put a proposal together?
Rose: Well you know, the original call came out in March. Now, one would imagine that if someone really cared about this, one could put a proposal together in a six‐month period; so basically going from March to September. The fact that there weren’t any proposals tells me either A, people thought that the existing proposal was good enough; B, they didn’t care about; or C, they just didn’t want to do the work. And you know, I guess the only kind of people I would complain about are the ones who fall into C, where they don’t want to do the work to put the proposal together.
So the working group meets. And you know, there are a lot of discussion, and I’ll tell you quite frankly the quality of the documents has improved as a result of the working group examining and revising the documents.
The problem of course is that for every real good improvement we had, there were many suggestions and arguments about things which basically were either technically out of scope of the SNMP v2 charter, or unfortunately were kind of like issues which really hadn’t been thought out all that well.
And this is an area where I kinda get a black eye because I am famous for my lack of tolerance of nonsense. And what I mean by that is that you know, people asking questions I can deal with. When someone brings up an issue which had been discussed and handily dismissed in the past, they’d better have some new points when they bring up that issue because I really do not like rehashing the same arguments over and over again. It’s kind of like, if you’re standing on the deck of the Titanic and you see the iceberg, you have two choices: you jump off the port side of the ship, or the starboard side of the ship. You don’t stand there in the middle of the bow plane deciding which foot you want to lead off with when you jump, it’s time to jump. And once you’ve jumped, you can’t say, “Oh no, I’m jumping in the wrong direction,” you have to go overboard.
And so, when an issue has been thoroughly discussed, as several of these had in the past, to have them be brought up again in the course of this, without any new facts being brought to light you know, just absolutely infuriates me. And so I tend to lose my temper and let people know what I think of them and then that makes Marshall the ogre of the Internet, for which all I can say is well you know, you know what causes me to be an ogre; perhaps you should try not to exhibit that behavior which basically causes that kind of a result.
Malamud: But isn’t that the job of a working group, to make sure these issues are properly hashed out?
Rose: Well you know, you’d think that, wouldn’t you? But you know, on the other hand how many times do you have to hash out the same issue? I don’t have any problems with someone saying, “We’ve discussed Topic A the past, and there’ve been arguments in both directions. But here is something new which we haven’t considered. We really need to reopen A.”
The problem is that never happened. What happens is, “I want to talk about Topic A again. Here’s my proposal.” And instead of going through and making sure that the old arguments have been dealt with, that any new information has been brought, it’s kinda like there’s zero memory on the part of the working group. That this thing has never been discussed in the past and therefore it’s fair game, when in point of fact the two or three topics which got to this level which we call “tar baby status,” are things which have literally been discussed for the last four years, every six months, and every six months they go down in flames.
Malamud: What’s an example of one of those issues?
Rose: Well, the typical example is is the argument as to whether row creation, or more properly row manipulation in SNMP is an artifact of protocol operation or MIB design. Now, that’s a very complicated way of expressing the following concept: A lot of times you have management information of which there are multiple instances, so like, multiple rows in the routing table, each consists of a routing entry. One of the things you have to do in SNMP is have the ability to identify a particular row, and then perhaps you want to create a new routing entry, or you want to modify an existing one, or you want to delete it. Well, modifying things which are already existing is a fairly straightforward thing. Also with deleting them.
The question comes about, how do you go about creating a new row, say in the routing table or something like this, and do it in such a way that you don’t collide with other managers which also might be controlling the router, and make sure that you have all the information in that entry in the routing table before the router starts to use it. Because you may not be able to fit all of the information you need in one packet, in just one transaction to make it happen. You may have to do a little negotiation over the creation.
And so there’s always been kind of this question, or at least this question comes up every six months is, “Well, do you have a special protocol operation called ‘create row,’ or when you design the routing table do you define the semantics of how row creation occurs?” And you know, you can argue it either way. The problem is that if you look at all of the conflicting requirements you have, you find out that the protocol solution simply will not work. There are just some cases it can’t solve, whereas the solution by MIB design or defining the semantics of the routing table can meet all of those requirements although at times it may be a little ugly or a little hairy. But at least you can solve the problem. And again, in a lot of cases you’d have to go for a 100% solution.
So this topic came up in November. And you know, I just absolutely hit the roof. Because this topic has literally been discussed on a six‐month repeating schedule since 1988. And unfortunately the people who put forth the proposal did not put forth a proposal that had been entirely thought through, did not deal with the arguments which had been brought up in the past time and time again. And so basically it’s kinda like, “Oh well, here, we wrote this up. Put it in the standard.” And I’m sorry, wait, did you realize there are all these problems and like, you can’t solve it using the approach you’re using? Do you realize we’ve discussed all this stuff in the past? Why are you doing this now? And so then there’s this huge fight, and instead of handling it in the absolute most diplomatic way, sometimes I regrettably just explain to people that their thinking isn’t entirely as clear as it ought to be.
Malamud: This is Geek of the Week, featuring interviews with prominent members of the technical community. Geek of the week is brought to you by Sun Microsystems and by O’Reilly & Associates.
[Book Bite segment omitted]
Internet Talk Radio, town crier to the global village.
Malamud: You and three of your colleagues went off and invented SNMP version 2. And you did it in a backroom. You didn’t do it in public. You didn’t do it in a working group. And that was kind of unfair, because you had a head start over everybody else. And that you were rushing the process to much. Do you think we need to slow that process down, or involve more people in the design of these things?
Rose: Well to begin with, keep in mind that the four of us did exactly what we were asked to do by the IESG. Which was to go off, form a design team and do this.
Malamud: Well you had already started when that call for proposals came out, hadn’t you?
Rose: Well, I could argue that I had started back in 1988 when had finished SNMP version 1 as chair of that working group and was making my list of things to fix or things I couldn’t get in version 1 that I wanted in version 2. So I mean, in a sense if you’re saying “you had already started,” sure, and I would imagine anyone involved with version 1 had already started the day after version 1 got standardized.
But you know, let’s keep in mind here that the a call for proposals went out, anyone was perfectly free to form their own design team and do this. But the only people who basically committed every free seconds of their time, from March until July, were the four of us and we did the work.
Now, is that unfair? You know, there are a lot of people who kinda complained that Marshall, or maybe Marshall and Jeff Case kinda have a stranglehold on network management, that we’re profiteers, or robber barons or something like that. And I must admit I do like being compared to a robber baron. There’s a lot of kind of old 19th century romance associated with people who owned railroads controlled millions of lives.
Malamud: Although you’re building one, not owning one but that’s okay.
Rose: Yeah. Regrettably it’s also not a very factual description of me. Except of course I do kinda fit the physical caricature but we won’t got into that for now. But I have to learn smoke cigars of course, and appreciate fine brandies.
Be that as it may, you know, the only reason that Jeff and I exert so much control in the world of SNMP is that Jeff and I, and also Keith and Steve, we simply put in more hours than anyone else. This is an entirely democratic process. Someone wants to compete head to head with Marshall Rose or Jeff Case or Keith McCloghrie or Steve Waldbusser, here’s how you do it. You simply match us in quality and quantity of hours. You do that and you’ll be on an equal footing with us. But unless you’re willing to make the investment of time and other resources you know, you should expect to lose arguments.
And a lot of these things in the working group, you know, people brought up proposal which we had thought of ourselves, and done an analysis of, and then figured out one reason or another why it wouldn’t work. And then they’re surprised why we’re against it and why we have all these arguments tailor‐made as to why their proposed will fail. Well gee guys, we thought of that six months ago and decided we couldn’t make it happen. So in a sense this is really kind of an [?] thing.
Now, you know I should point out of course that the four of us do have an advantage because we do spend all this work. And that’s our choice, and certainly people can compete with us. Similar you know, Jeff Case in addition to being at the University of Tennessee at Knoxville, he is also president of SNMP research, and he sells SNMP products for profit. You know, I have a book called The Simple Book, which is about SNMP. And I’m currently working on the second edition. And certainly it’s very much in my financial interest to have this SNMP v2 stuff finished so I can get the book on the shelves and make another killing.
On the other hand I’ll also point out that there are easily two dozen vendors participating in the SNMP v2 effort who basically have not done a lick of work in the working group towards adding to the quality of the SNMP v2 proposal. And yet because they’re going to make a ton of money when they sell SNMP v2 products. And they’re of course interested in having this stuff come out as fast as it can as well.
But no. I mean you know, sure of course I have an interest in this stuff. And in fact I’ll go so far as to say that the people in the process I distrust the most are the ones who don’t have any apparent interest. Because what’s it for them whether this stuff is good or bad, whether this stuff gets advanced in a timely fashion or not? Those are the people I really worry about, you know.
Malamud: What if they represent another segment, another group, another country, another protocol, religion? Shouldn’t they be in that, or do you think you should just deploy the technology as quickly as possible?
Rose: Well I don’t know. I mean, you know, there’s… You can only standardize and be successful on technology which works and people willing to build products to. Certainly we have tried to meet as many of the industry’s requirements as we can in producing SNMP v2. And there are some requirements where basically we just had to say, “Sorry, you can’t have that.” And in cases like that, basically it comes down to adding that particular feature would have a detrimental effect on the overall operation of the system. And this is an engineering trade‐off and you have to decide whether you want to make things run, or whether you want to make sure that everyone has their apple juice and cookies at the end of the day. And I’m sorry you know, we’re here to make the trains run, we’re not here to hand out apple juice and cookies.
Malamud: Well I can think of another instance where a similar decision was faced by the IAB. And they were looking at the routing and addressing crisis, and they said, “We’ve got a train to run,” and they decided at least on a direction for IP version 7. And the community didn’t react nearly as favorable. What is the difference between pushing SNMP v2 out because it needs to be done, and pushing let’s say a connectionless network service out as IPv7?
Rose: Well, the thing to keep in mind is that the SNMP v2 effort did not get it push until the July meeting of the IETF in Cambridge when there was— You know, one of the meetings, the plenary where over 200 people showed up, heard the the proposal, and then as a body they said, “Do this. Do this now. Make it happen. Let go.”
Now, from my perspective, when you have 200 people willing to show up at an IETF meeting and sit in the same room and listen for three hours to a proposal, and then after some questions and answers basically have virtually everyone in the room point to exactly the same goal, that a mandate.
In the case of the IPv7 thing, the problem we have is that everyone agrees there’s a problem. We disagree as to the extent of the problem, whether it is a clear danger or a present danger. And we certainly disagree on what the solutions are. So there is no clear mandate. And so for the IAB or anybody to say, “Okay, this is what we’re going to do,” without having that mandate they certainly open themselves up to just being in a tremendous pressure cooker. And that’s where they found themselves.
Malamud: Now, the result of that pressure cooker was an effort called POISED, which examined how we govern ourselves in the IETF.
Rose: Mm hm.
Malamud: What what’s your feeling on what’s happened with the POISED efforts? You were one of the authors of the compromise proposal at the IETF where it was decided to have a random selection committee and then a change in the roles of the IAB and IESG. Have we fixed things? Are we ready to settle down and get back to work?
Rose: Well the POISED… The outcome of POISED was to try and introduce a level of accountability into the selection process, and basically an advice and consent kinda role between the rank and file and the management structure. And what we came out of that basically, a pool of volunteers randomly selected to make recommendations which then the management structure can approve or deny probably is the best compromise that [?] work. And I think in the long term it’s problem going to serve us very well.
I think what we’re going to end up seeing is more…more new blood coming into the system at a time when we really start to need it. You know, one of the problems we had with the old system is kind of being self‐selecting. While the quality of the individuals was good, we just didn’t have a way of grooming our junior people into becoming senior people. And what my hope is now is that we’re going to start getting some of the people who are working group chairs are going to start becoming area directors. People who are area directors are either going to move on to the IAB or perhaps into some other position. And new working group chairs will come in.
So we’ll kind of like, start to build up more of a collection of people who have Internet management experience. And I think we have to start doing this because a lot of the people we have now in the senior positions are, you know, for better or worse nearing retirement, and they just don’t quite have the energy that they used to.
And you know, furthermore you have to keep in mind that as we’re ever expanding and growing we have new constituencies. We need to provide an outlet so those new constituencies feel that they have adequate representation and so on, and that their views are known.
Now having said all that, there are some things that we absolutely must avoid. The thing which which we must avoid is any concept of participation via affiliation. That is, “Oh, I’m the representative from Company XYX.” Or, “I represent the Scandinavian portion of the Internet,” or something like that.
Malamud: But these are the people that are often paying to send these people to the committees. And so IBM pays IBM employees. Shouldn’t IBM as a corporation have a voice?
Rose: No, absolutely not. In fact I’d argue that no corporation, nor any organization, have a voice as a part of of their corporate entity or identity. No, that’s just wrong. I mean, if you do that you will immediately find yourself devolving into the ISO/ANSI/OIW way of doing things, which would just be absolute disaster. Companies which send people to the IETF do so because they have a financial reason for having people there. Sometimes they have people there for education purposes. Sometimes they have people there to push an agenda. Sometimes they have people there because they view it as a matter community service. And certainly it’s this latter aspect which I would like to encourage. I would like to encourage people to kind of view their participation in the IETF as a matter community service. You know, the fact that you shouldn’t view being on the IESG or the IAB as a reward, you should rather review it as two years of community service, not unlike many countries which require all able‐bodied adults to serve in the military from time to time as a reservist or on standby or something like that. We need to view these management positions the same way, and we certainly shouldn’t view it as well—you know, I’m from corporation XYZ.
Malamud: Don’t touch that mouse. Internet Talk Radio will be right back.
Our acronym du jour is P2C2E. And, if you know that one, how about the ever‐popular M2C2D?
Internet Talk Radio. All material contained in this file is copyright 1993 by Internet Talk Radio. You may copy these files contained and change the encoding format, but may not alter the content or resell the programs. You can send us mail to firstname.lastname@example.org.
Our acronym of the day is the famous P2C2E, a process to complicated to explain. This gem comes from Salman Rushdie’s classic fairy tale Haroun and the Sea of Stories. P2C2Es of course run on M2C2Ds, machines too complicated to describe.
Malamud: So you think anyone ought to be able to just attend the IETF, just walk in off the street.
Rose: Well, traditionally the rank and file has been the strength of the IETF. If you look for example in the area of resource discovery, you will find that over the last two years there have been six separate efforts started across the globe looking at different aspects of resource discovery, and none of these came out of any grand directive from on high that we need to do work in this area. Rather there just happened to—you know, there happened to be people in communities who observed there was a need and decided to have to apply a little elbow grease to that and and came up with some good results. And so you know, certainly that’s always been the strength of the IETF and we need to preserve that.
Malamud: I’m hearing two things here. One is we want to encourage new blood to come in. And the other is it’s hard to get work done because of so many people in some of these working group meetings. Are these two conflicting goals here? Is there a way to solve those?
Rose: Well, it’s certainly quite a conundrum. On the other hand, if you look at the SNMP v1 experience, it was fairly hard to get things done but we all realized there is just such a pressing need, back in ’87 and ’88, that we pulled together and put aside differences and made it happen. There’s one story I really like to tell which kinda goes back to this vendor thing, so humor me for a moment.
We were discussing something in one of the SNMP committees, and a person there who happens to work for vendor says, “You know, if you include this feature, can’t I can implement that on my box. The box is just not built in such a way that I can get at that information. But this would be a very useful, perhaps even critical thing to have for managing boxes like this. So I think we should keep this in even though I’m going to take a hit on it personally in the company for letting this happen.”
Now here’s an example of a guy who, even though he knows that as his better company is not going to do it particularly well on this point, he still understands that the community will be greatly enhanced by having this in the standard. And so you know, the vendor hat, if it was ever there comes off, and the guy says, “Well you know, I’m gonna be taken to the woodshed over this, but let’s do it.”
And you know, this kind of exchange happened perhaps a dozen times over the course of that working group meeting. Because people really had a sense of community spirit. And so as we grow, we need to somehow make sure that people appreciate that there is this greater sense of community.
Now, sometimes this just doesn’t happen. After SNMP was standardized, there was a working group that was formed to develop some definitions of some additional management objects. And Craig Partridge had the great misfortune of being selected as chair. And he did his best to try and get the group to come to consensus. And over the course of a year, he simply could not get that group to get any kind of consensus position at all.
And you know, Craig’s a good guy. He’s bright. He’s innovative. He’s very well meaning. And he just simply could not get results. It was just politically untenable. And you know, finally he had to give up and they had to take some other approach towards getting these definitions out. And you know, this was a really unfortunate thing where they were unable in that working group to have that sense of community come together.
Now, since that time we’ve we’ve tried to fix the particular problems which Craig encountered and we’ve had mixed success, but it is just a constant problem, is we serve a larger community, there are diverse interests, and yet not everyone else is willing to realize that their own fiefdom in the Internet is not the only fiefdom there and it’s not the whole Internet, and that they have to give some.
Malamud: Speaking of community, we’re beginning to look at a truly global Internet. The contributions from outside the US have long been very significant, and one can argue are some of the most vital work going on in the Internet. How is the IETF going to steal from, or the Internet standards‐making process if you will, scale from a US‐centric process into a truly global one?
Rose: Well, that’s… that’s hard. I think that what we need… One of the things which we’ve done fairly well and at and which we need to keep working at is making sure that the vast majority of all IETF communications occur via electronic mail—
Malamud: That’s a novel thought.
Rose: Novel though, yes. Well, it happens most today. —rather than these in‐person meetings. And although these in‐person meetings are necessary and often essential perhaps for hammering out some things, we really have to rely on electronic mail and we’ve been doing that fairly well.
But then there’s also you know, another aspect is we need to get more people from outside the US into the management structure. And I’m not saying this like in terms of quotas or anything else. I’m just saying that we need to make it easier for people outside the US to become working group chairs. We need to make it easier for them to participate in other ways than just being kind of this electronic [wisp?] which sends messages out and receives them. Because we have had a lot of valuable contributions, even in the early Internet. You know, there was a number of Europeans and Australians who contributed quite heavily, and we need to keep building on that.
Malamud: How do you do that? Do you have IETF meetings overseas? Or do you not have IETF meetings? Do we just let the Internet Society handle everything at their INET conference?
Rose: Well I always kinda viewed the Internet Society as more of a promotional organization than a technical or a standards organization. Maybe that’s just my perception, I don’t know. I think that we are going to perhaps try to get more more things going concurrently in the US and in Europe and the Pacific Rim. For example, the video over IP stuff has come a long ways in the last few years. And perhaps we might get to the point where we can hold concurrent plenaries both in the United States and in Europe, or in the United States and the Pacific Rim.
And if we do it right you know, we could probably arrange to have as much overlap, say maybe four or five hours in the day… Oh you know, what the heck we’re Internet people. We’re twenty‐four hour people anyway, you know, so we might have a lot of overlap during the day where the people in one time zone start kinda late after lunch and the people the other time zone start early. And you know, we’ll just give them massive caffeine injections as they walk in the door. So we could perhaps do more of that in that fashion.
Malamud: You’re suggesting a Pan‐Atlantic IETF or a Pan‐Pacific IETF.
Rose: Yes. In a nutshell that’s what I would be suggesting. And you know, I think that there are some working groups which have a fairly high level of international participation, for which that would work. And there are going to be other working groups which are fairly…for one reason or other are only of interest to US people, or only of interest to people in Europe, and those could be held basically not online.
But again, we always have to fall back on electronic mail as the way of doing things.
Malamud: So actually using the technology that we’re building.
Rose: What a novel concept.
Malamud: There you have it. We’ve been talking to Marshall Rose, and this is Geek of the Week. Thanks a lot, Marshall.
This has been Geek of the Week, brought to you by Sun Microsystems. And by O’reilly & Associates. To purchase an audiocassette or audio CD of this program, send electronic mail to email@example.com.
Internet Talk Radio. Same‐day service in a nanosecond world.