Carl Malamud: Internet Talk Radio, flame of the Internet.

Malamud: This is Geek of the Week, and we’re talk­ing to Dr. Jeff Case. He’s President of SNMP Research and a pro­fes­sor at the University of Tennessee. Welcome to Geek of the Week, Jeff.

Jeff Case: Thank you.

Malamud: You were one of the orig­i­nal four authors of SNMP ver­sion 2. I was won­der­ing if you could tell us what is SNMP ver­sion 2, and why do we need it?

Case: SNMP ver­sion 2 is a sec­ond gen­er­a­tion of the high­ly suc­cess­ful SNMP ver­sion 1 net­work man­age­ment frame­work. When we talk about SNMP ver­sion 2, we’re talk­ing about two things. We’re talk­ing about the pro­to­col, SNMP, but more impor­tant­ly com­ing with that pro­to­col is an net­work man­age­ment framework. 

The SNMP ver­sion 2 pro­to­col suite con­sists of a total of twelve documents—about 400 pages of very very inter­est­ing read­ing, espe­cial­ly if you have insomnia—that include oth­er things like the struc­ture of man­age­ment infor­ma­tion which defines how we name infor­ma­tion, often called the SMI, and man­age­ment infor­ma­tion bases, the man­age­ment infor­ma­tion base often called the MIB. So these doc­u­ments work togeth­er to define an entire frame­work for net­work management.

Now, in terms of your ques­tion how is this dif­fer­ent from SNMP ver­sion 1, it gives us increased capa­bil­i­ties in sev­er­al areas. These increased capa­bil­i­ties were select­ed as a result of feed­back and com­ment from peo­ple who had used the SNMP ver­sion 1 frame­work over time. Things like high-speed retrieval of bulk data was a crit­i­cism of SNMP ver­sion 1 and has been addressed quite nice­ly in SNMP ver­sion 2 and it’s one of the things that I’m per­son­al­ly most proud of.

Malamud: How did SNMP ver­sion 1 han­dle the prob­lem of get­ting lots of data back from an agent to a manager?

Case: Normally if you had a large table you would retrieve that table one row at a time, and if that table had five columns you might pull back those five infor­ma­tion items in a sin­gle row, one row at a time, five columns at a time. As a result, if there were 10,000 rows in the table, it might take 20,002, approx­i­mate­ly 20,000 pack­ets 10,000 round trips—10,001 round trips to retrieve that infor­ma­tion. So you were bring­ing back lots and lots of pack­ets that were not full. 

Malamud: So an exam­ple of that might be ​“Show me the rout­ing table on that router because we’re wor­ried that some­thing’s going wrong.” Would that be a—

Case: Two of the clas­si­cal exam­ples are the rout­ing data­base, and on a MAC Layer bridge the bridge for­ward­ing data­base. The bridge for­ward­ing data­base typ­i­cal­ly has a few columns, and a typ­i­cal Media Access Control MAC Layer bridge such as an Ethernet-to-Ethernet bridge might have 8,000 rows in it.

Malamud: And you’d want to look at it if you sus­pect you have a loop or some­thing like that.

Case: Some peo­ple do that. Some peo­ple, for exam­ple the MAC for­ward­ing data­base, they use that to detect when a new node has been added to their net­work because the bridges here, every pack­et from every host gets through at least one time and there­fore it shows up in the entry. And if you scan those entries from time to time you can detect the appear­ance of new sys­tems that’ve been added to the net­work. Perhaps with and per­haps with­out the knowl­edge of the net­work administrator.

Malamud: So how do we han­dle this prob­lem now in SNMP ver­sion 2?

Case: Basically the par­a­digm is that one adds more infor­ma­tion to the pack­et until the pack­et is full. Or until a man­ag­er station-specified lim­it is reached, whichev­er comes first. And the pow­er of trans­fer­ring full pack­ets is fair­ly obvi­ous. Because if you as a result are now able to put as many as forty or fifty rows in a sin­gle pack­age, there are sav­ings in terms of work on both the man­ag­er sta­tion and agent, sav­ings in terms of band­width on the net­work, and a reduc­tion in terms of the com­pute cycles on both ends of the sys­tem. And for the user, they see it as a tremen­dous improve­ment, a tremen­dous reduc­tion in the laten­cy between the time they ask for a par­tic­u­lar table and the time that table is ful­ly retrieved. In some tables we can retrieve that entire table in one pack­et, for short­er tables. 

The speed-up is bet­ter if you have few­er columns and those columns tend to be short­er. For exam­ple a sin­gle inte­ger or a six-byte MAC address, you will have quite a bit more speed-up com­pared to where each col­umn is a 255-character print­able string. The small­er the infor­ma­tion item, the bet­ter the speed-up.

Malamud: Because the more rows you’re able to pack into a sin­gle packet.

Case: The more you can get into a sin­gle— Exactly. You under­stand perfectly.

Malamud: Well we try to here on Geek of the Week. So you used to have an operator—you still do—call the ​“pow­er­ful GETNEXT oper­a­tor.” So it sounds like you’ve added a bunch of new oper­a­tors to the protocol?

Case: Basically there are a few new oper­a­tors. One new oper­a­tor is this GETBULK oper­a­tor, which is a descen­dant from the pow­er­ful GETNEXT oper­a­tor. We call it the ​“awe­some GETBULK operator.” 

Malamud: Now, I thought the pow­er­ful GETNEXT oper­a­tor could do every­thing. If you read Marshall Rose’s book he was very clear that there’s no need for oth­er new oper­a­tors. We want to keep the pro­to­col sim­ple. Was there some kind of a trade­off you had to make here between the sim­plic­i­ty of the pro­to­col and these special-purpose oper­a­tions like GETBULK?

Case: Oh yes, very much so. And SNMP ver­sion 1, we attempt­ed to— I per­son­al­ly argued to have a fea­ture like GETBULK in SNMP ver­sion 1 and was unable to get con­sen­sus amongst the three coau­thors of SNMP ver­sion 1. The joke, and it is a joke, is that I was able to get it to be a part of SNMP ver­sion 2 but I had to get three dif­fer­ent co authors in order to rewrite it SNMP ver­sion 2 to get this GETBULK in. But some of the peo­ple who worked with SNMP ver­sion 1 in the design phas­es have said that boy it worked out far bet­ter than they ever imag­ined that it could have. Management sta­tions for SNMP ver­sion should be writ­ten around GETNEXT. Management sta­tions on SNMP ver­sion 2 should be writ­ten around GETBULK. 

There are sev­er­al oth­er improve­ments to GETBULK as well. One is that GETBULK will nev­er return a Too Big error, for exam­ple. Whereas the GETNEXT oper­a­tor will occa­sion­al­ly do so. That if you ask a ques­tion where the answer is that it’s too large to fit the response, the size of the response, in SNMP ver­sion 1 GETNEXT—and SNMP ver­sion 2 GETNEXT—you get back a Too Big error. A GETBULK will nev­er return a Too Big error. And so it’s just one less excep­tion that a man­ag­er sta­tion has to pro­gram around.

Malamud: You, in SNMP ver­sion 1 had a clean slate to work off. There was a great lack of net­work man­age­ment in the Internet. With SNMP ver­sion 2, you’ve got a very large installed base to con­tend with. How did you han­dle the prob­lem of tran­si­tion of that installed base? Is there a flag day in which every­one’s going to have to run SNMP v2? Are you gonna be able to keep SNMP v1 out there for a long time?

Case: One of the twelve SNMP ver­sion 2 doc­u­ments is the coex­is­tence and tran­si­tion doc­u­ment that address­es these kind of issues. Which is a way of con­crete­ly say­ing that these sorts of prob­lems were thought about a great deal, enough that we write some things down about it.

At the time that SNMP ver­sion 2 was first announced, and in those days we were call­ing it SMP—and SMP being the input to the stan­dards com­mit­tee and SNMP ver­sion 2 being the out­put of the stan­dards com­mit­tee. In those days, we had imple­men­ta­tions of the two basic strate­gies to let this peace­ful coex­is­tence occur. These are both dis­cussed in the doc­u­ment. Marshall Rose imple­ment­ed the proxy approach and I imple­ment­ed the bilin­gual sys­tem approach. 

Malamud: Could you describe those two approaches?

Case: In one case, in proxy approach, you have a SNMP ver­sion 2 man­ag­er, an SNMP ver­sion 1 agent, and a third device—we’ll call it a proxy device—which receives an SNMP ver­sion 2 query or com­mand, trans­lates that into an SNMP ver­sion 1 query or com­mand, for­ward­ing it on to the ver­sion 1 agent. When the response comes back it does a sim­i­lar trans­la­tion. So, in some ways it’s like a trans­lat­ing gate­way, or a pro­to­col con­vert­er. There are sev­er­al names you could give this sort of a thing.

Malamud: Now, if there’s more func­tion­al­i­ty in SNMP ver­sion 2 isn’t it pos­si­ble you’re ask­ing to do some­thing that can’t be done in a ver­sion 1 agent? I mean, how does the proxy han­dle the mis­match in func­tion­al­i­ty between the two versions?

Case: Well, a GETBULK can always be down­grad­ed to a GETNEXT of a sin­gle row. So in GETBULK we go retrieve rows until the pack­et is full— And I’m over­sim­pli­fy­ing here a bit. And basi­cal­ly with when we down­grade that to a GETNEXT the pack­et comes back, it’s per­fect­ly what one would expect, it’s just not quite as full as you might hope for to get get the max­i­mum per­for­mance. But inter­op­er­abil­i­ty does not suf­fer through this trans­lat­ing gate­way, although the per­for­mance win does not hap­pen. The per­for­mance is not worse, it’s just not better.

The sec­ond approach is this ​“bilin­gual” approach, and that is where you have a sys­tem which for exam­ple, a bilin­gual agent would be one which sup­ports both pro­to­cols simul­ta­ne­ous­ly. And if it receives an old pack­et it process­es it accord­ing to the old rules and pro­duces an old response. And if it gets a new pack­et it process­es accord­ing to the new rules and pro­duces a new response. 

I per­son­al­ly have imple­ment­ed both approach­es in the time since we first announced this. I per­son­al­ly pre­fer the bilin­gual. It’s one less thing to go wrong. It’s one less thing you have to con­fig­ure. But both approach­es are viable, and either one will work, and a net­work admin­is­tra­tor can select them as they see fit.

Malamud: Are these tem­po­rary tran­si­tion mech­a­nisms, or do you antic­i­pat­ed that SNMP ver­sion 1 agents and nodes will be out there for a long time?

Case: Yes, it is tem­po­rary and we expect that tem­po­rary is on the order of ten years.

Malamud: Now, SNMP ver­sion 2 has a lot more func­tion­al­i­ty and there­fore one would expect that the code is big­ger? It’s takes more CPU and mem­o­ry and resources to be an SNMP ver­sion 2‑compliant agent or man­ag­er. Is that correct?

Case: Well there are sev­er­al fea­tures that we haven’t men­tioned in addi­tion to GETBULK that do add some size. The GETBULK frankly adds only about thir­ty to forty lines of code in a typ­i­cal agent imple­men­ta­tion. One of the things that we did is that in any agent implementation—and we’re focus­ing on keep­ing the agent imple­men­ta­tion small because that’s where the pres­sure is rather on the man­age­ment station. 

One of the things that we did is that we tried to make it so that the changes for tran­si­tion­ing from ver­sion 1 to ver­sion 2, or from ver­sion 1 to bilin­gual, were con­cen­trat­ed where you would have min­i­mum pain. That is, on a typ­i­cal imple­men­ta­tion you have a part that is protocol-dependent and MIB-indepen­dent, and anoth­er part that is MIB-dependent but protocol-indepen­dent. And much of the exist­ing invest­ment that’s out there in the world today is in the MIB-dependent/protocol-indepen­dent part. Well that is, we worked very hard to design it so that exist­ing MIB mod­ules and exist­ing code which imple­ments MIBs could con­tin­ue to be protocol-independent to the max­i­mum extent pos­si­ble, not require changes in appli­ca­tion pro­gram­ming inter­faces. And I believe that we’ve been real­ly suc­cess­ful at doing that. And so there­fore the changes are in the core part of which there are a rel­a­tive­ly small­er num­ber of imple­men­ta­tions, and that it con­cen­trates the pain in one place instead of dis­trib­ut­ing it through­out the entire imple­men­ta­tion. So that in order to add SNMP ver­sion 2 to an agent imple­men­ta­tion, for exam­ple, you might need to make changes to the core agent engine, but all of the MIB instru­men­ta­tion and the soft­ware to sup­port those addi­tion­al MIBs, that invest­ment con­tin­ues to be preserved. 

In terms of sizes, there are two parts that then are a part of SNMP ver­sion 2. That is the changes in the core part and the changes in those MIB mod­ules. Changes in the MIB mod­ules come as a result of just addi­tion­al MIB that are sup­port­ed as a part of SNMP ver­sion 2. In ver­sion 1 all of the con­fig­u­ra­tion a net­work admin­is­tra­tor need­ed to do to set up what man­ag­er sta­tions are valid and where do I send traps was very implementation-dependent and buried all over the map. In SNMP ver­sion 2, that’s all very well-codified, very well-documented, and can be done through SNMP trans­ac­tions themselves. 

However, the work to make that con­fig­urable through­out SNMP ver­sion 2 has asso­ci­at­ed with it a fair­ly large MIB. That’s where most of the size gain comes as a part of SNMP ver­sion two. The con­fig­u­ra­tion of admin­is­tra­tive rela­tion­ships, the con­fig­u­ra­tion of secu­ri­ty para­me­ters. The addi­tion­al size as a result of the secu­ri­ty code itself is fair­ly small. The size as a result of the con­fig­u­ra­tion of the secu­ri­ty is where all of the bloat is. 

Malamud: When you men­tion secu­ri­ty, what are some of the secu­ri­ty fea­tures in SNMP ver­sion 2, and how does that dif­fer from what was in the orig­i­nal specification?

Case: In SNMP ver­sion 1, we had attempt­ed to define some mech­a­nisms for secu­ri­ty, but every time we attempt­ed to do so, we could­n’t get agree­ment. So in SNMP ver­sion 1 we pro­posed that we have a thing called a com­mu­ni­ty string, and a wrap­per where we sep­a­rat­ed the authen­ti­ca­tion wrap­per from the pay­load, called the pro­to­col data unit. So that at some point in the future, one could make changes to the authen­ti­ca­tion with­out chang­ing the pay­load, the pro­to­col data unit. And that was insight­ful in 1988 and was used recent­ly to make these changes, to keep those changes fair­ly well mod­u­lar and divorced from one another.

The SNMP ver­sion 1 stuff was fair­ly weak in terms of its authen­ti­ca­tion, and could eas­i­ly be mas­quer­ad­ed and sub­ject to var­i­ous kinds of attacks. 

Malamud: It was based on the con­cept of a com­mu­ni­ty string?

Case: That’s cor­rect. The com­mu­ni­ty string is a plain-text piece of the mes­sage head­er that would iden­ti­fy the sender. And if the man­ag­er sta­tion sent a query or com­mand to the agent, the agent would scan a table and see if there was a match. And if there was then it would process that query or com­mand accord­ing to the con­fig­u­ra­tion asso­ci­at­ed with that com­mu­ni­ty string. 

However, any­one who was snoop­ing the net­work could steal that com­mu­ni­ty string and could eaves­drop on it, and then mas­quer­ade as if they were the node that was con­fig­ured to do that. So it’d be like steal­ing some­one’s user­name and pass­word by watch­ing the net­work traf­fic go by and then using that to make access to that account.

Malamud: So it was more of a syn­chro­niza­tion mech­a­nism, just to make sure you did­n’t by acci­dent step on the wrong router or some­thing like that. [crosstalk] I mean you could—

Case: Well it kept the hon­est peo­ple hon­est but it cer­tain­ly did noth­ing for the dis­hon­est people.

In SNMP ver­sion 2, there are three lev­els of secu­ri­ty, and these can be con­fig­ured by the net­work admin­is­tra­tor and can switch from one lev­el to anoth­er lev­el on a transaction-by-transaction basis. So those three lev­els are: No authen­ti­ca­tion and no pri­va­cy; authen­ti­ca­tion based on the mes­sage digest algo­rithm MD5 with no pri­va­cy; and the third level—the top level—is MD5 authen­ti­ca­tion with pri­va­cy based on DES, the Data Encryption Standard. 

These address the var­i­ous threats that were thought to be impor­tant to net­work admin­is­tra­tors. We believe that most net­work admin­is­tra­tors will use no authen­ti­ca­tion and no pri­va­cy for rou­tine mon­i­tor­ing. And that will allow any­one to be able to mon­i­tor the net­work and would not lock any­one out of being able to monitor. 

Authentication with­out pri­va­cy we believe will be used by net­work admin­is­tra­tors for con­trol operations—when they want to change a con­fig­u­ra­tion when they want to per­form an SNMP set request, rather than inspect­ing the con­fig­u­ra­tion to alter it. 

We believe that in most net­works, authen­ti­ca­tion with pri­va­cy will be rarely if ever used, but is there for those net­work admin­is­tra­tors who have appli­ca­tions which require it. For exam­ple if you want­ed to use SNMP in a sys­tem admin­is­tra­tion envi­ron­ment and you want­ed to cre­ate a new user­name and pass­word in a host admin­is­tra­tion appli­ca­tion, you might want to use pri­va­cy so that the new pass­word remained secret, that some­one eaves­drop­ping on the net­work would not be able to learn the pass­word of this newly-created account.

But, dif­fer­ent sites can have dif­fer­ent poli­cies. The pro­to­col sup­ports these three lev­els, and dif­fer­ent sites can enforce dif­fer­ent poli­cies. And in fact if one wish­es you can use authen­ti­ca­tion and pri­va­cy on all trans­ac­tions if you wish, or you can use no authen­ti­ca­tion on any trans­ac­tion if you wish. That’s total­ly in the hands of the net­work admin­is­tra­tor. And down on the farm of course we have a say­ing, ​“With free­dom comes respon­si­bil­i­ty.” That is, as they make these choic­es they’ll be respon­si­ble for the con­se­quences of mak­ing those choices.

Malamud: You’re using the MD5 mes­sage digest algo­rithm. You’re using DES. Those are two of the basic build­ing blocks of anoth­er secu­ri­ty envi­ron­ment, Privacy-Enhanced Mail. And there’s a third build­ing block, which is pub­lic key cryp­tog­ra­phy. Do you view the SNMP secu­ri­ty mech­a­nisms some­how inte­grat­ing with PEM and the cer­ti­fi­ca­tion hier­ar­chies that are being built? Or is this just a sep­a­rate secu­ri­ty regime?

Case: I think that it’s a sep­a­rate secu­ri­ty regime. The fact that they use some of the same tech­nol­o­gy was inten­tion­al. I might also add that SNMP ver­sion 2 while it does not present­ly call for the use of pub­lic key cryp­tog­ra­phy, the hooks are there. If one wants to add that one is free to do so. That is that the SNMP ver­sion 2 frame­work was made very exten­si­ble so that addi­tion­al authen­ti­ca­tion types, addi­tion­al key man­age­ment types, and addi­tion­al pri­va­cy types could in fact be added to the pro­to­col in a very straight­for­ward fash­ion, in a very mod­u­lar fash­ion. So that if for exam­ple in a gov­ern­ment appli­ca­tion in a super secret net­work, if they felt that DES was not the appro­pri­ate pro­to­col to use for cryp­tog­ra­phy and they had a dif­fer­ent pro­to­col of choice, that can eas­i­ly be added on a spec­i­fi­ca­tion lev­el, and we’ve made in our imple­men­ta­tion so that it’s very easy to craft that into the code as well.

Malamud: Does that make any sense? Can you think of a sit­u­a­tion where you’d rec­om­mend that?

Case: Yes, but I can’t tell you about it because if I did then I’d have to shoot you.

Malamud: Jeff Case, SNMP ver­sion 2 was devel­oped by you and three of your col­leagues, and was pre­sent­ed to the IETF is the Simple Management Protocol as ​“Here is a pro­pos­al that we’re mak­ing.” And some peo­ple looked at that and said gee, you real­ly should have includ­ed the com­mu­ni­ty ear­li­er in the spec­i­fi­ca­tion process. Do you think that there’s a bal­ance here between the effi­cien­cy of a design team like the group that you put togeth­er for SNMP ver­sion 2 and the open­ness of a stan­dards body like the IETF? Is there a trade­off there?

Case: There cer­tain­ly is a trade­off. The soon­er you get the input, the longer it’s going to take to achieve the result. We were in an envi­ron­ment where pro­pos­als were invit­ed. We put togeth­er the strongest team that we knew how to put togeth­er. We in fact invit­ed some oth­er peo­ple who for var­i­ous rea­sons chose not to par­tic­i­pate that could have made the team even stronger. But, we put togeth­er the strongest team we could pos­si­bly muster, and we pre­pared a proposal. 

We were very con­cerned that we had to come in with a strong pro­pos­al, because we did not want to freeze the mar­ket. If there’s a lot of fear, doubt, and uncer­tain­ty in the mar­ket for an extend­ed peri­od of time, this is not healthy for ven­dors, this is not healthy for con­sumers or the tech­nol­o­gy. So we put togeth­er a pro­pos­al and pre­sent­ed it. It turned out that that pro­pos­al was found to be worth­while and was used at the basis to the input to the stan­dards community.

The stan­dards com­mu­ni­ty did make some changes. I think they made some good changes. I think they made some bad changes. They delet­ed some things that I think should’ve been in there that were in their ear­ly drafts that did­n’t make it through the end of the pipeline. And they added some things that I don’t ful­ly agree with, but the process worked. And the gen­er­al peo­ple that want­ed to have input, who want­ed to invest the time to par­tic­i­pate, had their day. And they could make changes. And what we see now is SNMP ver­sion 2. Still not per­fect, but much much bet­ter as a result of hav­ing gone through that open process.

Malamud: Are you begin­ning work on SNMP ver­sion 3 at this point?

Case: [laughs] Uh, no.

Malamud: No. No ​“but,” just no. [laughs]

Case: Would you like me to expand on that?

Malamud: Yeah, that’s one of those words that has sev­er­al mean­ing some­times. Are we gonna need a new net­work man­age­ment frame­work in ten years? Do we need to add object-oriented this or client-server that? Or do you think we have some­thing that’s gonna last for a long time.

Case: Well, ten years is a long time and I can’t pos­si­bly see that far into the future. Will we need some­thing dif­fer­ent in ten years, my guess is yes. The ques­tion is will the infra­struc­ture that we have be enough to car­ry that and the new tech­nol­o­gy will be sim­ply lay­ered on top of that, or will it be a replace­ment? I have no clue. I have absolute­ly no clue. But you did poke me with some­thing here that does get me start­ed, and that’s this object-oriented thing. 

SNMP ver­sion 1, some of the anti-SNMP big­ots would say gosh, SNMP sim­ply can’t be used for net­work man­age­ment because it’s not object-oriented. But then the pro-SMP big­ots would say of course this is non­sense. And they’d go back and forth, back and forth. Let me use an exam­ple that will maybe help you under­stand where I stand on that. 

If you think about a typ­i­cal Unix work­sta­tion based upon a RISC proces­sor, it has a par­tic­u­lar way of access­ing mem­o­ry, a fair­ly prim­i­tive address­ing scheme, a way it names where data is stored. It has an address, typ­i­cal­ly 32 bits wide. And sequen­tial address­es are num­bered sequen­tial­ly. And it has a rel­a­tive­ly lim­it­ed amount of data types. You might have char­ac­ters, you might have short inte­gers, and you might have long inte­gers, and per­haps one or two dif­fer­ent float­ing point for­mats. No object ori­en­ta­tion here. Just a very sim­ple flat address­ing space, not near­ly as com­plex as that object iden­ti­fi­er tree from SNMP, and a rel­a­tive­ly lim­it­ed num­ber of data types—again not near­ly as rich as the data types found in SNMP.

Now. Does this mean that we can’t imple­ment an object-oriented data­base on that Unix work­sta­tion with that RISC proces­sor? Of course not. People do it every day. Does this mean that you can’t imple­ment an object-oriented infra­struc­ture on top of the SNMP man­age­ment frame­work? No, it does­n’t mean that. Quite the con­trary, of course you can do that. The infra­struc­ture is there. Just get busy. It’s just code. Take as long as you need. Take all weekend.

Malamud: Well there you have it. This has been Geek of the Week and we’ve been talk­ing to Dr. Jeff Case. Down on the farm, he’s got a say­ing. Thanks a lot Jeff.

Case: Sure. Thank you for hav­ing me. 

This is Internet Talk Radio, flame of the Internet. You’ve been lis­ten­ing to Geek of the Week. You may copy this pro­gram to any medi­um and change the encod­ing, but may not alter the data or sell the con­tent. To pur­chase an audio cas­sette of this pro­gram, send mail to radio@​ora.​com.

Support for Geek of the Week comes from Sun Microsystems. Sun, The Network is the Computer. Support for Geel of the Week also comes from O’Reilly & Associates, pub­lish­ers of the Global Network Navigator, your online hyper­text mag­a­zine. for more infor­ma­tion send email to info@​gnn.​com. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by MFS DataNet and by UUNET Technologies.

Executive pro­duc­er for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysad­mins. This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.