Carl Malamud: Internet Talk Radio, town crier to the glob­al village. 

How do you pro­nounce your name?

Erik Huizer: [Pronounces as rough­ly ​“howz­er”]

Malamud: Huizer. Is that right?

Huizer: No, that’s not right. 

Malamud: Try it again.

Huizer: Huizer.

Malamud: Huizer.

Huizer: Huizer.

Malamud: Huizer. Am I right?

Huizer: No. Still wrong. 

Malamud: Not even close.

Huizer: Not even close, no. It’s my run­ning gag, real­ly. Whenever some­body has to intro­duce me for a talk or some­thing like that I always in an inter­na­tion­al con­fer­ence or what­ev­er, IETF meet­ing, I always jump in on the pro­nun­ci­a­tion of my name. I even now have in our X.500 pilot—you know you’ve got this world­wide pilot with every­body hooked up and every­body who does some­thing with X.500 direc­to­ry ser­vices is reg­is­tered in there. I’m reg­is­tered inter­est­ed in that too, and one of the attrib­ut­es I’ve got to my name is an audio attribute. If you have the right user inter­face you just have to click it and you can prac­tice all day how to pro­nounce my name.

Malamud: Oh. As as opposed to your favorite scotch or some oth­er attribute or that sort.

Huizer: I’ve got that one also, my favorite drink. But I thought in this case a very use­ful thing is to put my name in audio.

Malamud: Okay.

Huizer: I hope it works. I don’t sus­pect it will work.

Malamud: So why don’t you give me the whole name, then, for pos­ter­i­ty’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 impor­tant than… Let’s see. You’re part of the Internet Engineering Steering Group. You’re one of the direc­tors in the OSI Area, right?

Huizer: In the for­mer OSI area.

Malamud: The for­mer 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 activ­i­ties were kept sep­a­rate from the usu­al activ­i­ties of the IETF by putting them in a sep­a­rate area called the OSI Integration Area. However this was a kind of para­dox, because by keep­ing all these work­ing groups in a sep­a­rate area, inte­gra­tion was nev­er very easy. And since by now we’re con­vinced that we will nev­er build a full OSI Internet, and I think every­body more or less agrees that what­ev­er is use­ful in OSI we should try and take that and inte­grate it into a multi-protocol Internet, we thought that the best way to do that was to have the work­ing groups that are obvi­ous­ly 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 inte­gra­tion work­ing groups have moved into the Applications Area, some has moved into the Internet Area, and so on. And not keep­ing them sep­a­rate in an OSI Area which which we feel is a los­er, because those work­ing groups would always be sep­a­rate. For exam­ple, I think if you look at what has been real­ly going on with OSI in an oper­a­tional way on the Internet, X.400 is the obvi­ous 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 small­er than the RFC 822. I mean we’re not talk­ing big­ger than the RFC 822 world, we’re talk­ing about my esti­mate is between 10, 20% per­cent of the RFC 822 traffic—of the mail traf­fic, sorry—is X.400.

Malamud: Well that’s significant.

Huizer: It’s sig­nif— It’s real­ly sig­nif­i­cant. And that means we’ve got a lot of oper­a­tional prob­lems already in the X.400 world due to holes in the stan­dard. Things that the standard-making peo­ple nev­er real­ly thought about that you would run into when you’re doing oper­a­tional X.400. And one of the very use­ful groups work­ing on that is the IETF Working Group on X.400 Operations. And they’re doing a very use­ful job in try­ing to make oper­a­tional pro­ce­dures that more or less fill the holes in the stan­dard con­sid­er­ing rout­ing of X.400 mail mes­sages, and how do we dis­trib­ute rout­ing tables, and stuff like that.

Malamud: Now some would say that those were fun­da­men­tal flaws in the orig­i­nal stan­dards. 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 how­ev­er I don’t think the CCITT will feel very much for it. For some of the things we’re doing, prob­a­bly yes. But I would con­sid­er it flaws in the stan­dard. If you ask the CCITT peo­ple, they would­n’t. Because you have to remem­ber the CCITT peo­ple rep­re­sent the PTTs. And for them the rout­ing mod­el in X.400 is quite sim­ple. you give every­thing to PTT ADMD, the Administrative Management Domain, and they make sure it gets some­where. And you pay for it. And that’s their mod­el. And in all its sim­plic­i­ty that would work. If all the ADMDs in the world were con­nect­ed, and you had an lim­it­ed bud­get so you could­n’t care less whether you had to pay for each and every mail, that mod­el works. So, in their eyes, the PTTs eyes, the mod­el is not flawed at all.

However. Of course in the aca­d­e­m­ic and research world, and not only in there I might add, you see more in Europe than out­side of this world peo­ple are find­ing that it’s ter­ri­bly expen­sive to use the PTTs for rout­ing, and they want to put up direct con­nec­tions. So what the X.400 world is start­ing to look for is the equiv­a­lent of MX records. And there’s noth­ing like that. I mean, the CCITTs nev­er worked on that. 

So, if we are going to devel­op some­thing like that, we will feed it back into ISO. Because the ISO stan­dard for mail mes­sag­ing is called MOTIS, and it’s in par­al­lel with the CCITT X.400. For most of the things these two stan­dards are real­ly the same. Only ISO does­n’t favor the ADMD rout­ing, while CCITT does.

So if you’re ever going to feed back some­thing for rout­ing in between [MPAs?] on a one-to-one basis, it will prob­a­bly nev­er be accept­ed by the CCITT but you might stand a good chance of get­ting it back into ISO. However I could­n’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 stan­dard in the first place? It seems a lot of ener­gy is wast­ed on wor­ry­ing about what was in the orig­i­nal stan­dard and fix­ing that. Wouldn’t it make sense just to start from scratch?

Huizer: That would make a lot of sense. The rea­son why we’re using this, and that’s prob­a­bly the rea­son why it’s espe­cial­ly in Europe, is that the European gov­ern­ments and CEC have com­mit­ted to the ISO stan­dards. And for exam­ple in the Netherlands all the gov­ern­ment depart­ments now have X.400 up and run­ning. That means that if you want to be able…like a net­work ser­vice provider like I’m work­ing for, like SURFnet, to make sure that my cus­tomers can also com­mu­ni­cate with the gov­ern­ment, I have to take some ini­tia­tive and pro­vide X.400. If I don’t I can sit back and wait and say I’ll wait for the gov­ern­ment to pro­vide some con­nec­tion to RFC 822. However they nev­er will, and— As always the research net­works are run­ning years and years ahead. So it’s us who will have to pro­vide the connectivity. 

So we start­ed by build­ing a gate­way between RFC 822 and X.400. And that’s very large­ly used. Not only by SURFnet, it’s also used by NLnet in the Netherlands, and the pub­lic X.400 net users. We have it open to every­body, for the time being. Until it’s cost­ing us too much mon­ey, probably. 

And when we did that we dis­cov­ered that sev­er­al cus­tomers of ours had more com­mu­ni­ca­tions with the X.400 world than they had with RFC 822, the Internet world. And those peo­ple want­ed to migrate to X.400. And they asked us whether we would sup­port that. And by the time…this was not one cus­tomer but sev­er­al, we decid­ed to sup­port X.400 as a pro­to­col too. We are not hap­py with X— And we’re not doing it for X.400 per se. It’s being forced by the envi­ron­ment we have to work in.

Malamud: It’s strict­ly a polit­i­cal compromise.

Huizer: It’s a polit­i­cal com­pro­mise, right. And because we have a rather trans­par­ent gate­way which is spec­i­fied in RFC 1327 which is now a pro­posed stan­dard, we can do this. Otherwise it would be a dis­as­ter, of course, hav­ing two pro­to­cols. But with this gate­way it’s a work­able sit­u­a­tion. Although I fear for the future when more and more of these gate­ways will be oper­at­ed and we’ll have the dif­fi­cul­ty of keep­ing them syn­chro­nized. And that’s one of the things that this IETF Working Group on X.400 Operations is work­ing on, try­ing to get some­thing out there to make sure we can syn­chro­nize this, either by use of DNS or maybe who knows, even X.500. But that’s of course depend­ing on anoth­er OSI-based pro­to­col to save the first one.

Malamud: You’re lis­ten­ing to Geek of the Week. What to this pro­gram is pro­vid­ed by Sun Microsystems. Sun Microsystems, open sys­tems for open minds. Additional sup­port for Geek of the Week comes from O’Reilly & Associates, pub­lish­ers of books that help peo­ple get more out of computers. 

Don’t touch that mouse. Internet Talk Radio will be right back. 

[Incidental Tourist seg­ment omitted]

Malamud: What’ the impacts of the new MIME mul­ti­me­dia mes­sag­ing on the Internet stan­dards on the oper­a­tion of things like gate­ways between domains?

Huizer: Well, I feel that the impact is quite enor­mous. But that’s a one-time impact, I expect. We’ve been study­ing this, again in an IETF work­ing group, the MIME-MHS Working Group, and look­ing at the oper­a­tional issues I feel that the prob­lem will be to get it working—mapping MIME body parts into X.400(88) body parts with appro­pri­ate object iden­ti­fiers and on the MIME side with appro­pri­ate MIME iden­ti­fiers. That’s going to be a pain, to install these gate­ways, get them up and run­ning, and make sure they work. That’s going to cost a lot of man­pow­er for one year, let’s say.

After that I don’t see that we get more oper­a­tional prob­lems than with usu­al text-based stuff. Once we get it up and run­ning, I expect that the oper­a­tional prob­lems for bina­ry or tex­tu­al body parts disappear. 

Malamud: It sounds like you view a world in which there’s sev­er­al message-handling domains and gate­ways between them unless as a nor­mal 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 ide­al way of doing it. I’d rather have one pro­to­col and you know, just keep it RFC 822 with PEM for the peo­ple who want secure and authen­ti­cat­ed mail, and with MIME for the peo­ple who want to ship around all kinds of body parts.

However that’s not the sit­u­a­tion we end up in. And I must say, we now sup­port the X.400—and I’m quite pos­i­tive. I’m much more pos­i­tive about X.400 than most peo­ple are. There’s a lot of good things to X.400. The bad thing—the worst thing about X.400’s prob­a­bly the size of the stan­dard, which has forced imple­menters to be fright­ened and not get real good imple­men­ta­tions out there in a rel­a­tive­ly short time­frame. Implementation are get­ting on the mar­ket more and more now, and we will end up with—hopefully—with an Internet where RFC 822, MIME, PEM will still be the dom­i­nant pro­to­cols. I fore­see that in espe­cial­ly com­mer­cial com­pa­nies, in the com­mer­cial world, PTOs and stuff like that, that X.400’s going to play a major role in wide-area email net­work­ing. I think that X.400 is on the mar­ket too late to have its orig­i­nal goal achieved, which was end-to-end con­nec­tion by X.400. I think that that mar­ket­place has now being tak­en over by the local area email prod­ucts like cc:Mail, Leonardo DaVinci mail, and Microsoft mail and stuff like that. Those are much more pop­u­lar and espe­cial­ly now Lotus and Microsoft have gone togeth­er and defined MAPI and CIM and those inter­faces. I think that’s the stan­dard of the future on local area net­works, espe­cial­ly in com­mer­cial envi­ron­ments, and that all these islands of local area net­work­ing mail will be cou­pled by either SMTP maybe in the United States, but cer­tain­ty 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 wor­ried about is that Microsoft or Lotus, or oth­er big com­pa­nies will start on hav­ing their own wide-area pro­to­col, which is hap­pen­ing more or less now by— Both Lotus and Microsoft have now defined a tun­nel­ing mech­a­nism where they can tun­nel their own mail for­mat through SMTP or X.400, it does­n’t mat­ter, to anoth­er Microsoft mail­er or Lotus mail­er who can read the stuff, the bina­ry stuff. And the prob­lem 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 gate­way that into MIME or into X.400(88). And then we have x pro­to­cols with x over n gate­ways in between them. And then if we ever get that sit­u­a­tion, email has lost. I mean the users, the end users, have lost. Then we lose glob­al con­nec­tiv­i­ty, and that’s the worst that can hap­pen. We can still man­age it with two pro­to­cols. The ide­al would be one pro­to­col. We can still man­age it with X.400(88) and RFC 822. We would still be able to swing it. If we get any­thing more than that than, then…

Malamud: With two back­bone pro­to­cols. [crosstalk] Two kind of wide-area—

Huizer: Two back­bone— Yeah. Whatever peo­ple use in the local area net­work, one does­n’t care. I mean, as long as they’ve got a good gate­way, and that’s some­thing that will be dic­tat­ed by the mar­ket, whether a gate­way is good or not. So I’m not too fright­ened about that. But for the wide-area, we’ll have to keep it down to two. And prefer­ably one but that’s polit­i­cal­ly 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 cur­rent­ly dis­cussing with Lotus and Microsoft and try­ing to— I man­aged to get con­tact peo­ple there of the project teams that work on wide-area and gate­way­ing the local area pro­to­cols to wide-area email pro­to­cols. And we’re cur­rent­ly involv­ing them in dis­cus­sions, try­ing to show them that we’ve got the expe­ri­ence now, and try­ing to devel­op a MIME to X.400 gate­way, what a dis­as­ter it would be if we would have to devel­op a Microsoft mail to to X.400 gate­way for the wide-area stuff. 

Malamud: Do you see the IETF as a good place to bring com­pa­nies togeth­er 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 oth­er body where we would be able to do that.

Malamud: Well now there’s pri­vate con­sor­tia. There’s ATM Forum, there’s a Frame Relay Forum. Do you think those also play a role, or are those just kind of aber­rant efforts?

Huizer: I think they play a role in their respec­tive areas. But for the… If you’re still at the basis of try­ing to devel­op an oper­a­tional view of the future, I think that none of these plat­forms work in that direc­tion, espe­cial­ly for email. There’s no oth­er plat­form 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 peo­ple in there. You’ve got peo­ple from uni­ver­si­ties who man­age the…who either devel­op the pro­to­cols through research stud­ies or man­age the uni­ver­si­ty net­works. You’ve got ser­vice providers who man­age region­al or nation­al back­bones. Or inter­na­tion­al, even. You’ve got soft­ware devel­op­ers. You’ve got even hard­ware peo­ple in there. And you’ve got net­work con­sul­tants in there. That means you’ve got really—all the play­ers in the field come to the IETF, and it’s the only place I know where you get all the play­ers in the field.

Malamud: Now some peo­ple say get­ting all the play­ers 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 sur­vive in situa— It will still be a suc­cess because it has built a his­to­ry of how peo­ple have to deal with each oth­er. There’s a modus operan­di which is defined with­out real­ly hav­ing been writ­ten down. But there is a modus operan­di, and new­com­ers to the IETF are being taught how to do that. And if every­body keeps to that, I think we stand a very good chance of get­ting all these peo­ple in and still being able to get use­ful work done, but with lots of con­sen­sus and a large con­sen­sus because you’ve got all the peo­ple in there. 

Most of the con­sor­tia you were talk­ing about are built by imple­men­tors. That means that users and ser­vice providers have no say what­so­ev­er in what’s hap­pen­ing. And they just have to take what­ev­er comes out of a con­sor­tium like that, while and one of the rea­sons 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 ser­vice provider gets a chance there to have its opin­ion expressed and tak­en into the consensus-building. And that’s important. 

Malamud: This is Geek of the Week, fea­tur­ing inter­views with promi­nent mem­bers of the tech­ni­cal com­mu­ni­ty. Geek of the Week is brought to you by O’Reilly & Associates, and by Sun Microsystems. 

[Book Bite seg­ment omitted]

Malamud: Internet Talk Radio, town crier to the glob­al village. 

Malamud: You think you can have work­ing groups when there’s 900 peo­ple show­ing 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 peo­ple and over 1,000 peo­ple. If you look at the last three meet­ings, there was an enor­mous growth in the begin­ning of ​’92 but it seems to have sta­bi­lized dur­ing 1992. The three places the IETF vis­it­ed in 1992 were quite pop­u­lar places—San Diego, Boston, Washington. In 1993 we will see which peo­ple real­ly came to do work, because we are vis­it­ing Columbus, Ohio. That’s not a place, as far as—I’ve nev­er 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 meet­ing will be in Amsterdam. I’m the local orga­niz­er for that one. It will be here in Amsterdam. And that means that most peo­ple won’t be able to go there just for fun, they will have to have seri­ous busi­ness there to be able to swing the bud­get to come over to Amsterdam. And I expect on the oth­er end in Amsterdam a rather large influx of Europeans, who nev­er man­aged to get the mon­ey to go all the way to the US but are on all the dis­tri­b­u­tion lists of the IETF and now want to come over there and see some faces and have some face-to-face talk­ing and discussions. 

And I don’t know where the fall meet­ing will be. But I expect that this year will show whether we have this enor­mous increase or whether we’ve stabilized. 

So that’s my first remark. The sec­ond one was to your ques­tion whether you can write this modus operan­di down—I don’t think so. One of the things of the IETF is that every­body’s quite free to oper­ate in the way he wants. And because we’re so big now you have to invent something…you have to write down some pro­ce­dur­al rules to guard the process. But you have to be very care­ful that you don’t extend that in such respect that nobody gets a chance any­more to have its own free­dom with­in those rules, to inter­pret the process in its own way. And that amount of free­dom has been one of the big advan­tages of the IETF. If you try to doc­u­ment the whole process down to the lit­tlest detail, we’ll end up with the same prob­lems that ISO and CCITT-like bod­ies have been experiencing.

Malamud: I see two con­flict­ing things hap­pen­ing here. Part of it is the IETF is the cul­ture. You’re there, you kind of—you get a feel­ing for how it oper­ates. The oth­er thing is inter­na­tion­al­iza­tion. We move over to Amsterdam and many of the peo­ple that nor­mal­ly would show up at a US meet­ing can’t go. Is it pos­si­ble to have an inter­na­tion­al IETF and still pre­serve that feel­ing of being there and of com­mu­ni­ty that we have when we were smaller?

Huizer: This is one of the things I’ve been giv­ing most of my time to, about think­ing about how you should struc­ture that. I think that going to Amsterdam with the IETF is a very coura­geous and dif­fi­cult deci­sion. We’ve been think­ing a lot about that and I’m very guilty in this respect that I’ve been push­ing a lot of peo­ple very very hard to do this, to take this step. And I think it’s nec­es­sary to see how much enthu­si­asm there is for an IETF out­side of Northern America. And not as much for me as a European to see how much enthu­si­asm there is because I know it, but I think it’s nec­es­sary to con­vince the Northern Americans that there’s a lot of peo­ple who want to spend a lot of time work­ing on those issues but who are faced with bud­getary con­straints. And the only way to show that is my hav­ing a meet­ing out­side of North America and show­ing them how many peo­ple show up. I would even expect that if you had the meet­ing in Australia you would still have an enor­mous influx of Australians because I know there’s a lot of peo­ple there too who are very active in the IETF. And prob­a­bly Japan is the same. 

Malamud: And in Japan you’d have a lot of peo­ple. Now all the sud­den you’ve got four meet­ings. One in North America, one in Europe, [crosstalk] one in Asia, one in Australia.

Huizer: So, the sys­tem you… I’m not envis­ag­ing a fact that you’re going to con­tin­ue with IETFs which trav­el all around the globe. I think that for the time being we will prob­a­bly have to go into a modus where one IETF meet­ing per year, one of the three per year, will be held out­side of Northern America. By the time we see that there’s so many peo­ple inside European, inside Japan, inside Australia and so on that are par­tic­i­pat­ing that we run into a real­ly unman­age­able sit­u­a­tion with this IETF trav­el­ing around, we will have to switch over to some sort of region­al IETF sys­tem 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, bod­ies like RIPE or RARE can orga­nize or help orga­nize the European IETF—

Malamud: Well in a sense RIPE is already the European IETF when you think about it. Its peo­ple get togeth­er, they get real work done…on some lim­it­ed prob­lems. Is that accu­rate? [crosstalk] Does it just not have the scope of the IETF?

Huizer: …no. No, it does­n’t have the scope of the IETF. RIPE is more con­cerned with oper­a­tional prob­lems. In that respect they cov­er part of the IETF, sure­ly. But they don’t have the whole scope of the— You would have to com­bine RIPE with the RARE work­ing groups, and togeth­er you end up with some­thing which cov­ers a lot of what the IETF is cov­er­ing but still not the whole of it. 

Malamud: Mm hm.

Huizer: And You prob­a­bly will nev­er be able to cov­er the whole of the IETF from Europe. There’s just some sub­jects where there’s no inter­est for them in Europe, because those are tech­niques that are not used at all in Europe and so nobody’s inter­est­ed in hav­ing a work­ing group on that. For exam­ple some of the old­er rout­ing pro­to­cols. Like RIP is now being updat­ed to RIP 2 and RIP is bare­ly used in European so nobody in Europe is real­ly inter­est in that.

Malamud: Well some peo­ple have said that RIP 2 is still a bad idea, um, but— [laughs]

Huizer: I’m not going to com­ment on that. But it’s just an exam­ple of one of the things that Europeans are not…you know, stand­ing in line for, join­ing up to work on that. On the oth­er end BGP4 yes, and stuff like that. And I feel that if you look at the atten­dance of the last three IETFs, you’ll see that there was an aver­age of 650 peo­ple the last three, fifty of whom were from Europe. So that’s not a very big per­cent­age. It’s one out of every thir­teen. But if you look at the X.400 Operations Working Group for exam­ple, you see that 40% are from Europe. And—

Malamud: Is that because they’re all PTT rep­re­sen­ta­tives and have the bud­gets to be able to come over?

Huizer: None of them were PTT rep­re­sen­ta­tives. It’s all from the aca­d­e­m­ic and research com­mu­ni­ty in Europe. But most aca­d­e­m­ic and research net­works in Europe like SURFnet where I come from, are being forced by the polit­i­cal sit­u­a­tion that I explained ear­li­er to run X.400. And by now have a pret­ty good oper­a­tional net­work. I would claim that the European part of the Internet has an X.400 oper­a­tional net­work that is much bet­ter than what PTTs are offer­ing on X.400. I think we’re doing a pret­ty good job in get­ting things hooked up, con­nec­tiv­i­ty, get­ting trans­par­ent­ly hooked up to the Internet’s mail pro­to­col. So we’ve got a lot of expe­ri­ence. We’ve also got a lot of prob­lems. And that’s why we flock togeth­er in the IETF meet­ings in try­ing 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 lit­tle sto­ry about PTTs—European PTTs and the Internet. And I take the Dutch PTT for this as an example. 

When the Dutch PTT start­ed with X.400, they had to cre­ate an ADMD net­work. They want­ed to give it a name. The first name they chose was ​“Internet.” And we from SURFnet ran in and con­vinced them just in time that maybe that was­n’t such a very good idea.

Malamud: That one was tak­en already.

Huizer: That one was tak­en already. However, they thought, and they still think is my feel­ing, that the Internet is a bunch of researchers, maybe a cou­ple of thou­sand, who have hooked up their work­sta­tions with some tele­phone lines and every now and then they set up a con­nec­tion and they exchange something. 

About two years ago for the first time I had the X.400 to RFC 822 gate­way up and run­ning. And we start­ed deliv­er­ing this as a ser­vice to our cus­tomers. And then we hooked up with X.400 to the PTT net­work as soon as that came into being, the X.400 net­work. And I went off to the PTT boys who [explored?] this net­work and I said, ​“Now lis­ten. You just start­ed an X.400 net­work. You almost have no users. I’m offer­ing you free use of our gate­way so your users can trans­par­ent­ly send mail to the Internet. And in return the favor I want from you is that we don’t have to pay any­thing for any mail we deliv­er to 400Net.” And they refused. I offered them—

Malamud: Connectivity to the world.

Huizer: Connectivity to let’s esti­mate two years ago maybe 2 mil­lion users. I think that’s a very con­ser­v­a­tive after esti­mate. And they refused. 

So I went back half a year lat­er and they still refused. And the last time we talked about it they still did­n’t want to do this. And so the sit­u­a­tion we’re in now is that SURFnet still… SURFnet deliv­ers the ser­vice. The gate­way is open for the users of the PTT and the 400Net users. With the ridicu­lous sit­u­a­tion that if some­body from the US sends some mail to some­body, a cus­tomer of the PTT, it goes through our gate­way and we have to pay for that mail to be deliv­ered to the PTT. So we’re pay­ing for third-party mail.

Malamud: You’re lis­ten­ing to Geek of the Week. Support for this pro­gram is pro­vid­ed by O’Reilly & Associates, rec­og­nized world­wide for defin­i­tive books on the Internet, Unix, the Windows sys­tem, and oth­er tech­ni­cal top­ics. Additional sup­port for Geek of the Week comes from Sun Microsystems. Sun, the net­work is the computer.

Our acronym du jour is the DLAL, and its more pop­u­lar corol­lary, the MLAL. Reverse engi­neer these fine acronyms.

This is Internet Talk Radio you may copy these files and change the encod­ing for­mat, but may not alter the con­tent or resell the programs. 

You can send us mail to mail@​radio.​com.

Our acronym of the day is DLAL: Dual-Letter Acronym Listing, some­times referred to as a glos­sary. Unfortunately the DLAL often expands into the MLAL: the Multi-Letter Acronym Listing.

In the US, MCI Mail is famous for its gate­ways. They have gate­ways to telex, to fax, to you know—there were some of the ear­li­er ones. Now, they seem to have learned the les­son ear­ly on that every time some­body uses a gate­way, they’ve sent a mes­sage and they’ve dis­charged their cus­tomer. That’s a good thing. And I guess I’m try­ing to under­stand why so many PTTs have prob­lems with that. You would think increas­ing traf­fic would be a good thing for a PTT.

Huizer: The rea­son is the men­tal­i­ty. The PTT does­n’t want to acknowl­edge that the Internet is a big net­work. They just don’t want to buy into that. That’s the whole problem.

Malamud: They’re too busy build­ing the intel­li­gent net­work and they don’t real­ize it’s here already.

Huizer: And even if you put the con­vinc­ing fig­ures— I went with these famous DNS host count tables and so on. I put it in front of them. I put all the fig­ures in front them, showed them the ISO news and Larry Landweber’s col­lec­tiv­i­ty met­rics and what­ev­er. They just don’t believe it. Because there’s no PTT involved, they say it can’t be a real net­work. Don’t for­get that in Europe, by def­i­n­i­tion, SURFnet is not a ser­vice provider. A ser­vice provider is only a PTU.

Malamud: Okay, so SURFnet is the research net­work provider for the Netherlands, but you’re not a ser­vice provider by PTT rules.

Huizer: By PTT rules.

Malamud: You’re a value-added net­work. Is that—

Huizer: Something like that. John Postel explained it to me. He said, ​“You not a ser­vice provider. You’re too busy pro­vid­ing a ser­vice. You can’t be a ser­vice provider.” I think that’s prob­a­bly explain­ing the men­tal­i­ty of the PTT… They just have to learn what the Internet is. And one of the oth­er issues you see in this is one of the cur­rent polit­i­cal issues, prob­a­bly some oth­er peo­ple you inter­view will be talk­ing about, is the European multi-protocol back­bone. It’s one of the hot polit­i­cal issues in Europe.

Malamud: Give us a thirty-second ver­sion of what this multi-protocol back­bone is.

Huizer: Okay. Well, we’ve got a run­ning back­bone in Europe, it’s called EBONE. It’s work­ing fan­tas­ti­cal­ly but it’s based on every­body coop­er­ates, every­body puts in a lit­tle bit of mon­ey who uses the net­work, and togeth­er we can build [crosstalk] a backbone.

Malamud: EBONE’s a vol­un­tary con­sor­tium of var­i­ous ser­vice 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 talk­ing, my boss is in a meet­ing about EBONE get­ting the mon­ey on the table for the com­ing year. And besides that there is an ini­tia­tive by the European com­mu­ni­ty, the com­mis­sion, in putting on the European back­bone. And the orig­i­nal idea was to put it into place based on X.25, two-megabit X.25.

Malamud: So EMPB is two-megatbit X.25 infra­struc­ture for European research network.

Huizer: Exactly. That was what it was meant to be.

Malamud: Okay.

Huizer: But Kees Neggers, my boss, he jumped in from the begin­ning and said, ​“Well, if you’re going to do X.25 for­get about it. We won’t even want to con­nect. And prob­a­bly apart from the UK and Germany and maybe one or two oth­ers nobody will con­nect at all. You’ll have to make multi-protocol. That means you have to sup­port CLNS 2 and you will have to sup­port TCP/IP.”

And that was a major prob­lem, of course. Because the European Commission espe­cial­ly at that time was very anti-IP. They turned around on this. And it takes time. It’s a gov­ern­ment insti­tu­tion so it takes time. But by now they’ve seen the light and they’ve writ­ten the spec­i­fi­ca­tions for EMPB to include IP and CLNS.

Malamud: Okay now, are these ser­vices offered on top of X.25 or are they separate?

Huizer: No. They are to be deliv­ered sep­a­rate from X.25. So not on top of X.25. Real multi-protocol. They put out a call for ten­der. And there the first mis­take was made in my view, that the call for ten­der was put out and there were IP spec­i­fi­ca­tions there in which no European IP expert I know of has been asked to par­tic­i­pate. I think that at least they should have gone to RIPe or some­thing like that. But okay. Maybe in the hur­ry and it was sum­mer­time or some­thing like that…there will have been an excuse. And the Dutch PTT has won the ten­der and has got­ten the con­tract. And that’s already quite a long time ago, half a year by now. And up to now we still haven’t seen any sin­gle IP con­nec­tion. And what’s even worse in my view, we haven’t seen much of the PTT to show up and show inter­est in IETFs or RIPE meet­ings and show that they’re real­ly con­cerned about their lack of knowl­edge on how to inter­na­tion­al IP. I mean, that’s not some­thing you can think of behind your desk. You have to go out and get your­self involved in this whole world of IETF and RIPE and stuff like that to be able to operate—

Malamud: Is that the basic prob­lem, that the PTTs have just been oper­at­ing in the wrong world? Because they cer­tain­ly go to meet­ings. They go to the CCIT meet­ings, and the ISO meet­ings. They’ve just invest­ed in the wrong meet­ings, is that what happened?

Huizer: Well… Probably from their own point of view they haven’t. And I would even won­der even from our point of view can you say that they’ve invest­ed in the wrong rea­son. I mean, they start­ed out mak­ing a spec­i­fi­ca­tion and I think with the right frame of mind, essen­tial­ly to build glob­al net­work­ing. And by now a lot of peo­ple are con­vinced that this isn’t work­ing out. The CCITT, ISO mod­el isn’t work­ing out. And the PTTs will have to change over. You see with a lot of PTTs in Scandinavia, they switch over quite eas­i­ly and quite fast. And I expect the rest of the PTT will come around, but… I would­n’t call it really…really a big mis—that they’ve always been invest­ing in the wrong thing. I mean, I think every com­pa­ny makes a deci­sion 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 invest­ing in the wrong thing. You—

Malamud: Okay, so there was a tem­po­rary detour. It’s kind of like the cor­po­ra­tion that spends a lot of time with the MVS oper­at­ing sys­tem and after a while decides that down­siz­ing is maybe anoth­er option worth inves­ti­gat­ing. Do you think the PTTs and X.25—

Huizer: It’s… In Dutch we would call it—I don’t know how you trans­late it, some­thing like ​“pro­ceed­ing inside” or some­thing, you know. You’re inside and mat­ters change. And for some of the PTT that goes slow­er than for oth­er PTTs. But they will…they will come around even­tu­al­ly. 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 exam­ple, the big bucks are still in X.25. I mean, all the banks in Holland, all the insur­ance com­pa­nies, they want a closed X.25 net­work, with closed user groups. And that’s where they get the big bucks, not from…

Malamud: From closed IP net­works and indis­tinct; crosstalk.

Huizer: They will have to get a feel for the fact that there’s a mar­ket in IP. And we can see it by now because with the RIPE NCC, SURFnet is dis­trib­ut­ing the B and C class num­bers for the Netherlands. And so we’ve got a pret­ty good insight in who in the Netherlands is plan­ning for­eign IP con­nec­tiv­i­ty. And we see that there’s a lot of poten­tial cus­tomers there for the PTT. At least there’s a lot of cus­tomers that SURFnet is not allowed to serve because we’ve got a lim­it­ed group which we are allowed to sell ser­vices to. We’re restrict­ed to the aca­d­e­m­ic and research community.

Malamud: Is there a com­mer­cial ser­vice provider in the Netherlands for IP networking?

Huizer: Not real­ly. NLnet is pro­vid­ing net­work service—

Malamud: NLnet is the local EUnet affil­i­ate, right.

Huizer: Yes. And they’re sell­ing IP ser­vice to any­body. But I would­n’t call them a real com­mer­cial ser­vice provider. A com­mer­cial providers is some­body who’s out to gain mon­ey from it, and NLnet is not. They’re just try­ing to spread around the net­work as much as pos­si­ble. And they’re doing a very good job at it. And SURFnet is— And NLnet is…most of NLnet’s cus­tomers are the small­er com­pa­nies with UUCP con­nec­tions. But there’s a lot IP con­nec­tiv­i­ty there too. SURFnet is aim­ing for the research and aca­d­e­m­ic envi­ron­ment, includ­ing the com­mer­cial research, by the way. We’re restrict­ed to research and aca­d­e­m­ic, but [Shell?] for exam­ple Research is one of our cus­tomers. The biggest one by the way is Elsevier Science Publishers, with [indis­tinct] Publishing Company and stuff like that…

Malamud: Oh yeah, I’m famil­iar with them.

Huizer: …emails with the whole world all these arti­cles that before were deliv­ered by paper mail then had to go out to ref­er­ees by paper mail. And so, every­thing now goes by email, which makes the…the path through time has been short­ened from some­thing like half a year to some­thing like a cou­ple of months. So, there is still an enor­mous pos­si­bil­i­ty in the Netherlands—and not only in the Netherlands, in most countries—for com­mer­cial IP ser­vice, yeah.

Malamud: This has been Geek of the Week, brought to you by Sun Microsystems. And by O’Reilly & asso­ciates. To pur­chase an audio cas­sette or audio CD of this pro­gram, send elec­tron­ic mail to radio@​ora.​com.

Internet talk radio, flame of the Internet.