Carl Malamud: Internet Talk Radio, town crier to the global village.
How do you pronounce your name?
Erik Huizer: [Pronounces as roughly “howzer”]
Malamud: Huizer. Is that right?
Huizer: No, that’s not right.
Malamud: Try it again.
Malamud: Huizer. Am I right?
Huizer: No. Still wrong.
Malamud: Not even close.
Huizer: Not even close, no. It’s my running gag, really. Whenever somebody has to introduce me for a talk or something like that I always in an international conference or whatever, IETF meeting, I always jump in on the pronunciation of my name. I even now have in our X.500 pilot—you know you’ve got this worldwide pilot with everybody hooked up and everybody who does something with X.500 directory services is registered in there. I’m registered interested in that too, and one of the attributes I’ve got to my name is an audio attribute. If you have the right user interface you just have to click it and you can practice all day how to pronounce my name.
Malamud: Oh. As as opposed to your favorite scotch or some other attribute or that sort.
Huizer: I’ve got that one also, my favorite drink. But I thought in this case a very useful thing is to put my name in audio.
Huizer: I hope it works. I don’t suspect it will work.
Malamud: So why don’t you give me the whole name, then, for posterity’s sake.
Huizer: Erik Huizer.
Malamud: And it sounds to me like Erik Huizer.
Huizer: Well… Not even close. [crosstalk] I’m sorry.
Malamud: Okay. Well let’s talk about thing that’re more important than… Let’s see. You’re part of the Internet Engineering Steering Group. You’re one of the directors in the OSI Area, right?
Huizer: In the former OSI area.
Malamud: The former OSI area. Does that mean OSI is no more, or… In the Internet.
Huizer: OSI is still very much there. But up to about a month ago, all the OSI activities were kept separate from the usual activities of the IETF by putting them in a separate area called the OSI Integration Area. However this was a kind of paradox, because by keeping all these working groups in a separate area, integration was never very easy. And since by now we’re convinced that we will never build a full OSI Internet, and I think everybody more or less agrees that whatever is useful in OSI we should try and take that and integrate it into a multi-protocol Internet, we thought that the best way to do that was to have the working groups that are obviously doing a good job to keep them but put them in the area where they’re most appropriate.
Malamud: Mm hm.
Huizer: That means that most of the OSI integration working groups have moved into the Applications Area, some has moved into the Internet Area, and so on. And not keeping them separate in an OSI Area which which we feel is a loser, because those working groups would always be separate. For example, I think if you look at what has been really going on with OSI in an operational way on the Internet, X.400 is the obvious one to note. Not in the United States as much, although ESnet uses X.400 there is not as much around. But in Europe, a large part of the Internet in Europe talks X.400. And it’s smaller than the RFC 822. I mean we’re not talking bigger than the RFC 822 world, we’re talking about my estimate is between 10, 20% percent of the RFC 822 traffic—of the mail traffic, sorry—is X.400.
Malamud: Well that’s significant.
Huizer: It’s signif— It’s really significant. And that means we’ve got a lot of operational problems already in the X.400 world due to holes in the standard. Things that the standard-making people never really thought about that you would run into when you’re doing operational X.400. And one of the very useful groups working on that is the IETF Working Group on X.400 Operations. And they’re doing a very useful job in trying to make operational procedures that more or less fill the holes in the standard considering routing of X.400 mail messages, and how do we distribute routing tables, and stuff like that.
Malamud: Now some would say that those were fundamental flaws in the original standards. Is some of the work that’s being done in the IETF gonna feed back into the CCITT process?
Huizer: Well, we will feed back, but however I don’t think the CCITT will feel very much for it. For some of the things we’re doing, probably yes. But I would consider it flaws in the standard. If you ask the CCITT people, they wouldn’t. Because you have to remember the CCITT people represent the PTTs. And for them the routing model in X.400 is quite simple. you give everything to PTT ADMD, the Administrative Management Domain, and they make sure it gets somewhere. And you pay for it. And that’s their model. And in all its simplicity that would work. If all the ADMDs in the world were connected, and you had an limited budget so you couldn’t care less whether you had to pay for each and every mail, that model works. So, in their eyes, the PTTs eyes, the model is not flawed at all.
However. Of course in the academic and research world, and not only in there I might add, you see more in Europe than outside of this world people are finding that it’s terribly expensive to use the PTTs for routing, and they want to put up direct connections. So what the X.400 world is starting to look for is the equivalent of MX records. And there’s nothing like that. I mean, the CCITTs never worked on that.
So, if we are going to develop something like that, we will feed it back into ISO. Because the ISO standard for mail messaging is called MOTIS, and it’s in parallel with the CCITT X.400. For most of the things these two standards are really the same. Only ISO doesn’t favor the ADMD routing, while CCITT does.
So if you’re ever going to feed back something for routing in between [MPAs?] on a one-to-one basis, it will probably never be accepted by the CCITT but you might stand a good chance of getting it back into ISO. However I couldn’t care less, as long as we can get it to work on the Internet.
Malamud: Well then why aren’t we using this CCITT ISO standard in the first place? It seems a lot of energy is wasted on worrying about what was in the original standard and fixing that. Wouldn’t it make sense just to start from scratch?
Huizer: That would make a lot of sense. The reason why we’re using this, and that’s probably the reason why it’s especially in Europe, is that the European governments and CEC have committed to the ISO standards. And for example in the Netherlands all the government departments now have X.400 up and running. That means that if you want to be able…like a network service provider like I’m working for, like SURFnet, to make sure that my customers can also communicate with the government, I have to take some initiative and provide X.400. If I don’t I can sit back and wait and say I’ll wait for the government to provide some connection to RFC 822. However they never will, and— As always the research networks are running years and years ahead. So it’s us who will have to provide the connectivity.
So we started by building a gateway between RFC 822 and X.400. And that’s very largely used. Not only by SURFnet, it’s also used by NLnet in the Netherlands, and the public X.400 net users. We have it open to everybody, for the time being. Until it’s costing us too much money, probably.
And when we did that we discovered that several customers of ours had more communications with the X.400 world than they had with RFC 822, the Internet world. And those people wanted to migrate to X.400. And they asked us whether we would support that. And by the time…this was not one customer but several, we decided to support X.400 as a protocol too. We are not happy with X— And we’re not doing it for X.400 per se. It’s being forced by the environment we have to work in.
Malamud: It’s strictly a political compromise.
Huizer: It’s a political compromise, right. And because we have a rather transparent gateway which is specified in RFC 1327 which is now a proposed standard, we can do this. Otherwise it would be a disaster, of course, having two protocols. But with this gateway it’s a workable situation. Although I fear for the future when more and more of these gateways will be operated and we’ll have the difficulty of keeping them synchronized. And that’s one of the things that this IETF Working Group on X.400 Operations is working on, trying to get something out there to make sure we can synchronize this, either by use of DNS or maybe who knows, even X.500. But that’s of course depending on another OSI-based protocol to save the first one.
Malamud: You’re listening to Geek of the Week. What to this program is provided by Sun Microsystems. Sun Microsystems, open systems for open minds. Additional support for Geek of the Week comes from O’Reilly & Associates, publishers of books that help people get more out of computers.
Don’t touch that mouse. Internet Talk Radio will be right back.
[Incidental Tourist segment omitted]
Malamud: What’ the impacts of the new MIME multimedia messaging on the Internet standards on the operation of things like gateways between domains?
Huizer: Well, I feel that the impact is quite enormous. But that’s a one-time impact, I expect. We’ve been studying this, again in an IETF working group, the MIME-MHS Working Group, and looking at the operational issues I feel that the problem will be to get it working—mapping MIME body parts into X.400(88) body parts with appropriate object identifiers and on the MIME side with appropriate MIME identifiers. That’s going to be a pain, to install these gateways, get them up and running, and make sure they work. That’s going to cost a lot of manpower for one year, let’s say.
After that I don’t see that we get more operational problems than with usual text-based stuff. Once we get it up and running, I expect that the operational problems for binary or textual body parts disappear.
Malamud: It sounds like you view a world in which there’s several message-handling domains and gateways between them unless as a normal way of doing things. Would you agree with that?
Huizer: I’m afraid I have to agree with it. I don’t see that as the ideal way of doing it. I’d rather have one protocol and you know, just keep it RFC 822 with PEM for the people who want secure and authenticated mail, and with MIME for the people who want to ship around all kinds of body parts.
However that’s not the situation we end up in. And I must say, we now support the X.400—and I’m quite positive. I’m much more positive about X.400 than most people are. There’s a lot of good things to X.400. The bad thing—the worst thing about X.400’s probably the size of the standard, which has forced implementers to be frightened and not get real good implementations out there in a relatively short timeframe. Implementation are getting on the market more and more now, and we will end up with—hopefully—with an Internet where RFC 822, MIME, PEM will still be the dominant protocols. I foresee that in especially commercial companies, in the commercial world, PTOs and stuff like that, that X.400’s going to play a major role in wide-area email networking. I think that X.400 is on the market too late to have its original goal achieved, which was end-to-end connection by X.400. I think that that marketplace has now being taken over by the local area email products like cc:Mail, Leonardo DaVinci mail, and Microsoft mail and stuff like that. Those are much more popular and especially now Lotus and Microsoft have gone together and defined MAPI and CIM and those interfaces. I think that’s the standard of the future on local area networks, especially in commercial environments, and that all these islands of local area networking mail will be coupled by either SMTP maybe in the United States, but certainty in Europe and Asia and I expect a lot of X.400 to be used in between those islands.
And the only thing I’m very much worried about is that Microsoft or Lotus, or other big companies will start on having their own wide-area protocol, which is happening more or less now by— Both Lotus and Microsoft have now defined a tunneling mechanism where they can tunnel their own mail format through SMTP or X.400, it doesn’t matter, to another Microsoft mailer or Lotus mailer who can read the stuff, the binary stuff. And the problem you get then is that you get more or less a sort of wide-area Microsoft mail or wide-area Lotus mail. And then you have to gateway that into MIME or into X.400(88). And then we have x protocols with x over n gateways in between them. And then if we ever get that situation, email has lost. I mean the users, the end users, have lost. Then we lose global connectivity, and that’s the worst that can happen. We can still manage it with two protocols. The ideal would be one protocol. We can still manage it with X.400(88) and RFC 822. We would still be able to swing it. If we get anything more than that than, then…
Malamud: With two backbone protocols. [crosstalk] Two kind of wide-area—
Huizer: Two backbone— Yeah. Whatever people use in the local area network, one doesn’t care. I mean, as long as they’ve got a good gateway, and that’s something that will be dictated by the market, whether a gateway is good or not. So I’m not too frightened about that. But for the wide-area, we’ll have to keep it down to two. And preferably one but that’s politically an non-goal. So, let’s try and keep it down to two, and then we might still swing it. If we get more than that, we’ve got a problem.
And this is one of the things that the MIME-MHS Group is currently discussing with Lotus and Microsoft and trying to— I managed to get contact people there of the project teams that work on wide-area and gatewaying the local area protocols to wide-area email protocols. And we’re currently involving them in discussions, trying to show them that we’ve got the experience now, and trying to develop a MIME to X.400 gateway, what a disaster it would be if we would have to develop a Microsoft mail to to X.400 gateway for the wide-area stuff.
Malamud: Do you see the IETF as a good place to bring companies together and force [crosstalk] that kind of a compromise?
Huizer: Certainly. It’s the only place I know where we can do that. I don’t think there’s… I don’t know of any other body where we would be able to do that.
Malamud: Well now there’s private consortia. There’s ATM Forum, there’s a Frame Relay Forum. Do you think those also play a role, or are those just kind of aberrant efforts?
Huizer: I think they play a role in their respective areas. But for the… If you’re still at the basis of trying to develop an operational view of the future, I think that none of these platforms work in that direction, especially for email. There’s no other platform where I would know where you can think about such things.
Malamud: Well, why is it that the IETF works as a place to bring these kinds of issues to the table and maybe even get them resolved?
Huizer: It works because you’ve got all kinds of people in there. You’ve got people from universities who manage the…who either develop the protocols through research studies or manage the university networks. You’ve got service providers who manage regional or national backbones. Or international, even. You’ve got software developers. You’ve got even hardware people in there. And you’ve got network consultants in there. That means you’ve got really—all the players in the field come to the IETF, and it’s the only place I know where you get all the players in the field.
Malamud: Now some people say getting all the players after a while makes it just so big that you can’t get any work done. Do you think that’s happening?
Huizer: That’s a risk we run. That’s a risk that the IETF runs. But I think that the IETF will survive in situa— It will still be a success because it has built a history of how people have to deal with each other. There’s a modus operandi which is defined without really having been written down. But there is a modus operandi, and newcomers to the IETF are being taught how to do that. And if everybody keeps to that, I think we stand a very good chance of getting all these people in and still being able to get useful work done, but with lots of consensus and a large consensus because you’ve got all the people in there.
Most of the consortia you were talking about are built by implementors. That means that users and service providers have no say whatsoever in what’s happening. And they just have to take whatever comes out of a consortium like that, while and one of the reasons that SURFnet pays me to do work in the IETF and to sit on the Internet Engineering Steering Group is that we feel that SURFnet as a service provider gets a chance there to have its opinion expressed and taken into the consensus-building. And that’s important.
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 O’Reilly & Associates, and by Sun Microsystems.
[Book Bite segment omitted]
Malamud: Internet Talk Radio, town crier to the global village.
Malamud: You think you can have working groups when there’s 900 people showing up at the same time?
Huizer: Well, I’m going to say two things about that. First of all, I still have to see what we will grow to 900 people and over 1,000 people. If you look at the last three meetings, there was an enormous growth in the beginning of ’92 but it seems to have stabilized during 1992. The three places the IETF visited in 1992 were quite popular places—San Diego, Boston, Washington. In 1993 we will see which people really came to do work, because we are visiting Columbus, Ohio. That’s not a place, as far as—I’ve never been there but I’ve heard that it’s not a place you go to for fun. You just go there for your work.
The next meeting will be in Amsterdam. I’m the local organizer for that one. It will be here in Amsterdam. And that means that most people won’t be able to go there just for fun, they will have to have serious business there to be able to swing the budget to come over to Amsterdam. And I expect on the other end in Amsterdam a rather large influx of Europeans, who never managed to get the money to go all the way to the US but are on all the distribution lists of the IETF and now want to come over there and see some faces and have some face-to-face talking and discussions.
And I don’t know where the fall meeting will be. But I expect that this year will show whether we have this enormous increase or whether we’ve stabilized.
So that’s my first remark. The second one was to your question whether you can write this modus operandi down—I don’t think so. One of the things of the IETF is that everybody’s quite free to operate in the way he wants. And because we’re so big now you have to invent something…you have to write down some procedural rules to guard the process. But you have to be very careful that you don’t extend that in such respect that nobody gets a chance anymore to have its own freedom within those rules, to interpret the process in its own way. And that amount of freedom has been one of the big advantages of the IETF. If you try to document the whole process down to the littlest detail, we’ll end up with the same problems that ISO and CCITT-like bodies have been experiencing.
Malamud: I see two conflicting things happening here. Part of it is the IETF is the culture. You’re there, you kind of—you get a feeling for how it operates. The other thing is internationalization. We move over to Amsterdam and many of the people that normally would show up at a US meeting can’t go. Is it possible to have an international IETF and still preserve that feeling of being there and of community that we have when we were smaller?
Huizer: This is one of the things I’ve been giving most of my time to, about thinking about how you should structure that. I think that going to Amsterdam with the IETF is a very courageous and difficult decision. We’ve been thinking a lot about that and I’m very guilty in this respect that I’ve been pushing a lot of people very very hard to do this, to take this step. And I think it’s necessary to see how much enthusiasm there is for an IETF outside of Northern America. And not as much for me as a European to see how much enthusiasm there is because I know it, but I think it’s necessary to convince the Northern Americans that there’s a lot of people who want to spend a lot of time working on those issues but who are faced with budgetary constraints. And the only way to show that is my having a meeting outside of North America and showing them how many people show up. I would even expect that if you had the meeting in Australia you would still have an enormous influx of Australians because I know there’s a lot of people there too who are very active in the IETF. And probably Japan is the same.
Malamud: And in Japan you’d have a lot of people. Now all the sudden you’ve got four meetings. One in North America, one in Europe, [crosstalk] one in Asia, one in Australia.
Huizer: So, the system you… I’m not envisaging a fact that you’re going to continue with IETFs which travel all around the globe. I think that for the time being we will probably have to go into a modus where one IETF meeting per year, one of the three per year, will be held outside of Northern America. By the time we see that there’s so many people inside European, inside Japan, inside Australia and so on that are participating that we run into a really unmanageable situation with this IETF traveling around, we will have to switch over to some sort of regional IETF system where you have a Pacific region IETF, you have a North American IETF, and you’ll have a European IETF. And…I don’t know, bodies like RIPE or RARE can organize or help organize the European IETF—
Malamud: Well in a sense RIPE is already the European IETF when you think about it. Its people get together, they get real work done…on some limited problems. Is that accurate? [crosstalk] Does it just not have the scope of the IETF?
Huizer: …no. No, it doesn’t have the scope of the IETF. RIPE is more concerned with operational problems. In that respect they cover part of the IETF, surely. But they don’t have the whole scope of the— You would have to combine RIPE with the RARE working groups, and together you end up with something which covers a lot of what the IETF is covering but still not the whole of it.
Malamud: Mm hm.
Huizer: And You probably will never be able to cover the whole of the IETF from Europe. There’s just some subjects where there’s no interest for them in Europe, because those are techniques that are not used at all in Europe and so nobody’s interested in having a working group on that. For example some of the older routing protocols. Like RIP is now being updated to RIP 2 and RIP is barely used in European so nobody in Europe is really interest in that.
Malamud: Well some people have said that RIP 2 is still a bad idea, um, but— [laughs]
Huizer: I’m not going to comment on that. But it’s just an example of one of the things that Europeans are not…you know, standing in line for, joining up to work on that. On the other end BGP4 yes, and stuff like that. And I feel that if you look at the attendance of the last three IETFs, you’ll see that there was an average of 650 people the last three, fifty of whom were from Europe. So that’s not a very big percentage. It’s one out of every thirteen. But if you look at the X.400 Operations Working Group for example, you see that 40% are from Europe. And—
Malamud: Is that because they’re all PTT representatives and have the budgets to be able to come over?
Huizer: None of them were PTT representatives. It’s all from the academic and research community in Europe. But most academic and research networks in Europe like SURFnet where I come from, are being forced by the political situation that I explained earlier to run X.400. And by now have a pretty good operational network. I would claim that the European part of the Internet has an X.400 operational network that is much better than what PTTs are offering on X.400. I think we’re doing a pretty good job in getting things hooked up, connectivity, getting transparently hooked up to the Internet’s mail protocol. So we’ve got a lot of experience. We’ve also got a lot of problems. And that’s why we flock together in the IETF meetings in trying to solve them.
Malamud: Why is that the the PTTs don’t join in in an effort like this? You would think it would be in their self-interest to get X.400 up and running.
Huizer: Let me tell you a little story about PTTs—European PTTs and the Internet. And I take the Dutch PTT for this as an example.
When the Dutch PTT started with X.400, they had to create an ADMD network. They wanted to give it a name. The first name they chose was “Internet.” And we from SURFnet ran in and convinced them just in time that maybe that wasn’t such a very good idea.
Malamud: That one was taken already.
Huizer: That one was taken already. However, they thought, and they still think is my feeling, that the Internet is a bunch of researchers, maybe a couple of thousand, who have hooked up their workstations with some telephone lines and every now and then they set up a connection and they exchange something.
About two years ago for the first time I had the X.400 to RFC 822 gateway up and running. And we started delivering this as a service to our customers. And then we hooked up with X.400 to the PTT network as soon as that came into being, the X.400 network. And I went off to the PTT boys who [explored?] this network and I said, “Now listen. You just started an X.400 network. You almost have no users. I’m offering you free use of our gateway so your users can transparently send mail to the Internet. And in return the favor I want from you is that we don’t have to pay anything for any mail we deliver to 400Net.” And they refused. I offered them—
Malamud: Connectivity to the world.
Huizer: Connectivity to let’s estimate two years ago maybe 2 million users. I think that’s a very conservative after estimate. And they refused.
So I went back half a year later and they still refused. And the last time we talked about it they still didn’t want to do this. And so the situation we’re in now is that SURFnet still… SURFnet delivers the service. The gateway is open for the users of the PTT and the 400Net users. With the ridiculous situation that if somebody from the US sends some mail to somebody, a customer of the PTT, it goes through our gateway and we have to pay for that mail to be delivered to the PTT. So we’re paying for third-party mail.
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 Windows system, and other technical topics. Additional support for Geek of the Week comes from Sun Microsystems. Sun, the network is the computer.
Our acronym du jour is the DLAL, and its more popular corollary, the MLAL. Reverse engineer these fine acronyms.
This is Internet Talk Radio you may copy these files 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 DLAL: Dual-Letter Acronym Listing, sometimes referred to as a glossary. Unfortunately the DLAL often expands into the MLAL: the Multi-Letter Acronym Listing.
In the US, MCI Mail is famous for its gateways. They have gateways to telex, to fax, to you know—there were some of the earlier ones. Now, they seem to have learned the lesson early on that every time somebody uses a gateway, they’ve sent a message and they’ve discharged their customer. That’s a good thing. And I guess I’m trying to understand why so many PTTs have problems with that. You would think increasing traffic would be a good thing for a PTT.
Huizer: The reason is the mentality. The PTT doesn’t want to acknowledge that the Internet is a big network. They just don’t want to buy into that. That’s the whole problem.
Malamud: They’re too busy building the intelligent network and they don’t realize it’s here already.
Huizer: And even if you put the convincing figures— I went with these famous DNS host count tables and so on. I put it in front of them. I put all the figures in front them, showed them the ISO news and Larry Landweber’s collectivity metrics and whatever. They just don’t believe it. Because there’s no PTT involved, they say it can’t be a real network. Don’t forget that in Europe, by definition, SURFnet is not a service provider. A service provider is only a PTU.
Malamud: Okay, so SURFnet is the research network provider for the Netherlands, but you’re not a service provider by PTT rules.
Huizer: By PTT rules.
Malamud: You’re a value-added network. Is that—
Huizer: Something like that. John Postel explained it to me. He said, “You not a service provider. You’re too busy providing a service. You can’t be a service provider.” I think that’s probably explaining the mentality of the PTT… They just have to learn what the Internet is. And one of the other issues you see in this is one of the current political issues, probably some other people you interview will be talking about, is the European multi-protocol backbone. It’s one of the hot political issues in Europe.
Malamud: Give us a thirty-second version of what this multi-protocol backbone is.
Huizer: Okay. Well, we’ve got a running backbone in Europe, it’s called EBONE. It’s working fantastically but it’s based on everybody cooperates, everybody puts in a little bit of money who uses the network, and together we can build [crosstalk] a backbone.
Malamud: EBONE’s a voluntary consortium of various service providers.
Huizer: Exactly. You wrote about it in your book, that’s how it came to be. And that’s still a very good effort. I mean, right at this moment that we’re talking, my boss is in a meeting about EBONE getting the money on the table for the coming year. And besides that there is an initiative by the European community, the commission, in putting on the European backbone. And the original idea was to put it into place based on X.25, two-megabit X.25.
Malamud: So EMPB is two-megatbit X.25 infrastructure for European research network.
Huizer: Exactly. That was what it was meant to be.
Huizer: But Kees Neggers, my boss, he jumped in from the beginning and said, “Well, if you’re going to do X.25 forget about it. We won’t even want to connect. And probably apart from the UK and Germany and maybe one or two others nobody will connect at all. You’ll have to make multi-protocol. That means you have to support CLNS 2 and you will have to support TCP/IP.”
And that was a major problem, of course. Because the European Commission especially at that time was very anti-IP. They turned around on this. And it takes time. It’s a government institution so it takes time. But by now they’ve seen the light and they’ve written the specifications for EMPB to include IP and CLNS.
Malamud: Okay now, are these services offered on top of X.25 or are they separate?
Huizer: No. They are to be delivered separate from X.25. So not on top of X.25. Real multi-protocol. They put out a call for tender. And there the first mistake was made in my view, that the call for tender was put out and there were IP specifications there in which no European IP expert I know of has been asked to participate. I think that at least they should have gone to RIPe or something like that. But okay. Maybe in the hurry and it was summertime or something like that…there will have been an excuse. And the Dutch PTT has won the tender and has gotten the contract. And that’s already quite a long time ago, half a year by now. And up to now we still haven’t seen any single IP connection. And what’s even worse in my view, we haven’t seen much of the PTT to show up and show interest in IETFs or RIPE meetings and show that they’re really concerned about their lack of knowledge on how to international IP. I mean, that’s not something you can think of behind your desk. You have to go out and get yourself involved in this whole world of IETF and RIPE and stuff like that to be able to operate—
Malamud: Is that the basic problem, that the PTTs have just been operating in the wrong world? Because they certainly go to meetings. They go to the CCIT meetings, and the ISO meetings. They’ve just invested in the wrong meetings, is that what happened?
Huizer: Well… Probably from their own point of view they haven’t. And I would even wonder even from our point of view can you say that they’ve invested in the wrong reason. I mean, they started out making a specification and I think with the right frame of mind, essentially to build global networking. And by now a lot of people are convinced that this isn’t working out. The CCITT, ISO model isn’t working out. And the PTTs will have to change over. You see with a lot of PTTs in Scandinavia, they switch over quite easily and quite fast. And I expect the rest of the PTT will come around, but… I wouldn’t call it really…really a big mis—that they’ve always been investing in the wrong thing. I mean, I think every company makes a decision for a long-term plan and they invest in that. And okay, every now and then one of these long-term plans falls out wrong. And it’s hard to say then that you have been investing in the wrong thing. You—
Malamud: Okay, so there was a temporary detour. It’s kind of like the corporation that spends a lot of time with the MVS operating system and after a while decides that downsizing is maybe another option worth investigating. Do you think the PTTs and X.25—
Huizer: It’s… In Dutch we would call it—I don’t know how you translate it, something like “proceeding inside” or something, you know. You’re inside and matters change. And for some of the PTT that goes slower than for other PTTs. But they will…they will come around eventually. I think. And we don’t have… I think one of the things…to defend…I was a bit harsh, maybe. But one of the things is that for the Dutch PTTs for example, the big bucks are still in X.25. I mean, all the banks in Holland, all the insurance companies, they want a closed X.25 network, with closed user groups. And that’s where they get the big bucks, not from…
Malamud: From closed IP networks and indistinct; crosstalk.
Huizer: They will have to get a feel for the fact that there’s a market in IP. And we can see it by now because with the RIPE NCC, SURFnet is distributing the B and C class numbers for the Netherlands. And so we’ve got a pretty good insight in who in the Netherlands is planning foreign IP connectivity. And we see that there’s a lot of potential customers there for the PTT. At least there’s a lot of customers that SURFnet is not allowed to serve because we’ve got a limited group which we are allowed to sell services to. We’re restricted to the academic and research community.
Malamud: Is there a commercial service provider in the Netherlands for IP networking?
Huizer: Not really. NLnet is providing network service—
Malamud: NLnet is the local EUnet affiliate, right.
Huizer: Yes. And they’re selling IP service to anybody. But I wouldn’t call them a real commercial service provider. A commercial providers is somebody who’s out to gain money from it, and NLnet is not. They’re just trying to spread around the network as much as possible. And they’re doing a very good job at it. And SURFnet is— And NLnet is…most of NLnet’s customers are the smaller companies with UUCP connections. But there’s a lot IP connectivity there too. SURFnet is aiming for the research and academic environment, including the commercial research, by the way. We’re restricted to research and academic, but [Shell?] for example Research is one of our customers. The biggest one by the way is Elsevier Science Publishers, with [indistinct] Publishing Company and stuff like that…
Malamud: Oh yeah, I’m familiar with them.
Huizer: …emails with the whole world all these articles that before were delivered by paper mail then had to go out to referees by paper mail. And so, everything now goes by email, which makes the…the path through time has been shortened from something like half a year to something like a couple of months. So, there is still an enormous possibility in the Netherlands—and not only in the Netherlands, in most countries—for commercial IP service, yeah.
Malamud: This has been Geek of the Week, brought to you by Sun Microsystems. And by O’Reilly & associates. To purchase an audio cassette or audio CD of this program, send electronic mail to email@example.com.
Internet talk radio, flame of the Internet.