Subject: Minneapolis terminal room post-mortem

From: Matt Holdrege <[email-masked]>
Date: Thu, 18 Mar 1999 17:18:49 -0800

We aren't actually ready to kill the terminal room yet, but I wanted to get
this out now rather than later.

Overall, the Terminal Room and indeed the total operations of this IETF
meeting went very well. But, as always, there were some snags. Here is a
brief list for the Terminal Room.

Connectivity problems on Sunday. Despite my efforts to use stable software
in all places, some brand new untested router code snuck by me. We didn't
notice any problems till the room started getting busy. Then the Ethernet
card on the router started rebooting every few minutes. Analysis showed us
that a programmer left the Ethernet card in debug and it was writing a log
entry for each packet it forwarded. The large amount of traffic was killing
the card in this mode. A quick recompile followed and we were back in
business.

Wavelan issues. The distances in the hotel were an problem. We wanted to
cover the lobby and bar area, but the run was beyond Ethernet 10base/T
limits. We tried for a few workarounds, but nothing was feasible. Had we
more time and money it could have been done in advance.

DHCP issues. Due to the concerns about NT DHCP at the last IETF, some folks
said they would provide an alternative solution to the NT DHCP server. But
that solution didn't arrive in time and we started out with the NT server.
Later during the week, pressure from various quarters convinced the
volunteer staff to try to switch to a unix based DHCP server. This led to a
lengthy period of instability for some DHCP users. It could have been
handled better, but the volunteer staff on duty at the time did the best
they could. The problem seemed to only last a few hours and things were
running fine from then on. 

DHCP & Wavelan issues. Some people using Wavelan had DHCP problems while
the Ethernet LAN users had no problems. It was theorized that the inheirent
packet loss issues with wireless LAN's led to imperfect DHCP behavior. No
one has had time to perform an intrusive analysis on our network so it's
just a theory. But the fact is that some wireless clients worked much
better with static IP addresses. The vast majority of Ethernet DHCP users
worked fine whether they had Microsoft stacks or non-Microsoft stacks.

As for our guesses on quantity, I think we did OK. We installed 6 T1's in
redundant fashion, but the WAN traffic only peaked above 3.5Mbps once. The
average utilization was less than 1.5Mbps. We had 70 NT workstations and 15
unix workstations and it was rare that they were all in use. We had 100
Ethernet drops for laptops and while we peaked out a few times, most people
were able to work when they needed to. We had 3 high speed paper printers
which seemed to be just the right number. We had one transparency printer
which also seemed fine.

I want to thank all the volunteer workers from Ascend, MR Net, Compaq and
the MBONE staff for the hard work they put in preparing and executing the
setup and operation of the Terminal Room. I also want to thank the IETF
Secretariat for their very helpful assistance. 

Undoubtedly a full time professional outfit that handled all the IETF
terminal rooms would do a better job. But I can tell you that paying for
such a service without corporate sponsorship would cost a very large amount
of money. The IETF needs to decide if the requirements of a perfectly
functioning, adequately furnished Terminal Room is worth the cost. And I'll
remind everyone that our attendance fees pay for the existing meeting
costs. So if we want to pay for better service, it will cost us all more.
The current working alternative is to accept volunteer assistance and live
with whatever bugs we get.

Matt Holdrege		http://www.ascend.com	[email-masked]

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 18 Mar 1999 21:21:22 -0500 (EST)

> with whatever bugs we get.

<CHEEK>
	<TONGUE>

	There's a slew of ex-InteropNet NOC Team members cooling their
	jets now that ZD Events has "reorganized" the InteropNet program.
	We have been known to work for little more than airfare, alcohol,
	and camaraderie. Once or twice, we've even managed to build a
	decent little network <GRIN/>.

	</TONGUE>
</CHEEK>

--
   Tripp Lilley + Innovative Workflow Engineering, Inc. + ([email-masked])
------------------------------------------------------------------------------
  "You know, this /is/ kinda like the community room in a mental ward."

-- 
   Mary Papadopoulos (roommate), commenting on our office/rec room

---

From: Tripp Lilley <[email-masked]>
Date: Thu, 18 Mar 1999 21:21:22 -0500 (EST)

<CHEEK>
	<TONGUE>

	</TONGUE>
</CHEEK>

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 19 Mar 1999 09:05:51 -0600

> terminal rooms would do a better job.

Maybe, maybe not.  I've had aggravating problems in some terminal
rooms, and this time I didn't.  Often a bit of a wait for a unix
machine, but that's the worst I can say.

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 19 Mar 1999 09:05:51 -0600

---

From: Andrew Partan <[email-masked]>
Date: Fri, 19 Mar 1999 10:18:31 -0500 (EST)

> the Ethernet LAN users had no problems.

One suggestion for the Wavelans - mount them up high on the walls
instead of putting them on the floor.
	[email-masked] (Andrew Partan)

---

From: Andrew Partan <[email-masked]>
Date: Fri, 19 Mar 1999 10:18:31 -0500 (EST)

---

From: Marc Horowitz <[email-masked]>
Date: 19 Mar 1999 11:11:08 -0500

Matt Holdrege <[email-masked]> writes:

>> DHCP & Wavelan issues. Some people using Wavelan had DHCP problems
>> while the Ethernet LAN users had no problems. It was theorized that
>> the inheirent packet loss issues with wireless LAN's led to
>> imperfect DHCP behavior. No one has had time to perform an
>> intrusive analysis on our network so it's just a theory. But the
>> fact is that some wireless clients worked much better with static
>> IP addresses. The vast majority of Ethernet DHCP users worked fine
>> whether they had Microsoft stacks or non-Microsoft stacks.

At some point in the week, the wireless network was moved to a
different routed network instead of bridging with the wired network.
This made all the problems go away, so a recommendation for future
terminal rooms is to start that way.

		Marc

---

From: Marc Horowitz <[email-masked]>
Date: 19 Mar 1999 11:11:08 -0500

Marc

---

From: Tony Hansen <[email-masked]>
Date: Fri, 19 Mar 1999 12:18:14 -0500

> brief list for the Terminal Room.

I thought the terminal room worked very well. I spotted two glitches not
on your list that would be worth addressing for the future:

There was no stapler next to the printers. Okay, I saw one person with
his own mini-stapler, so I guess that's an alternative solution. But it
doesn't scale as well as a centrally supplied one.

There was no way to get transparencies printed after midnight, except by
trespassing to the NT box in the help desk territory that controlled the
printer queue. No, I didn't need to do it, but I know of someone who
did.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Fri, 19 Mar 1999 12:18:14 -0500

Tony Hansen
	[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Mar 1999 22:28:38 -0500

>meeting went very well. But, as always, there were some snags. Here is a

It's clear that attendees agree with you.  Some snags, but things went well.

>such a service without corporate sponsorship would cost a very large amount

You have concisely stated the issue (and the trade-off).

The current model requires substantial, volunteer effort, with each host 
learning to do the installation and operations task for that one time.  The 
results are variable, though mostly things go well.  It is not unusual for 
the terminal room to have one or two major problems, earlier in the week, 
usually resolved by mid-week.  Usually.

>functioning, adequately furnished Terminal Room is worth the cost. And I'll

Exactly.

Is it reasonable for the IETF meeting's Internet and printing access to be 
run as a unique service, each time, with the operations staff learning the 
considerable detail just the one time, or should this be treated as a 
utility requirement, like electricity and air conditioning?

Again, thanks for your efforts and the results.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Mar 1999 22:28:38 -0500

Exactly.

d/

---

From: Tony Hansen <[email-masked]>
Date: Fri, 19 Mar 1999 23:20:00 -0500

> usually resolved by mid-week.  Usually.

Sounds like an informational RFC begging to be written on how to set up
a terminal room! Or perhaps a BCP?

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Fri, 19 Mar 1999 23:20:00 -0500

Tony Hansen
	[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Mar 1999 09:41:26 -0500

>a terminal room! Or perhaps a BCP?

The Secretariat imparts quite a bit of such knowledge to each host, 
already.  Documenting things formally can't hurt.  However...

I believe the issue is not documentation but, rather, experience.  The 
knowledge you get reading the TCP protocol specification is different from 
writing an implementation of it (and getting it to interoperate.)  Reading 
about C is different from writing in it.  Reading about network operations 
is different from doing it.

No matter how bright and diligent a person is, their lack of direct 
experience in an area of expertise will limit their abilities in that 
area.  Network installation and operation is such an area.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Mar 1999 09:41:26 -0500

d/

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Mar 1999 13:57:40 -0800 (PST)

> area.  Network installation and operation is such an area.

yup.  so why are all these non-operators second-guessing this?

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Mar 1999 13:57:40 -0800 (PST)

randy

---

From: Kent Crispin <[email-masked]>
Date: Sat, 20 Mar 1999 15:01:07 -0800

> yup.  so why are all these non-operators second-guessing this?

Because being aware of what you don't know is a very rare quality? 

-- 
Kent Crispin                               "Do good, and you'll be
[email-masked]                           lonesome." -- Mark Twain

---

From: Kent Crispin <[email-masked]>
Date: Sat, 20 Mar 1999 15:01:07 -0800

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Mar 1999 16:00:44 -0800 (PST)

> Because being aware of what you don't know is a very rare quality?

excuse my continuing a somewhat silly thread.  but friends have told me
that my previous message was far too terse, as is my wont.  apologies.

i can understand dave croker saying "as a user, i had the following needs
..."  but, without saying what needs were not met, he proposed a bcp,
which would seem to be HOW those needs could be met, which would seem not
to be in the user realm.

although i help operate a network, i will refrain from second guessing
the terminal room at least until after the may nanog where i hope to gain
a bit of experience.  as dave 'the duplicitous one' meyer <g> seems to
have our company listed as a co-host.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Mar 1999 16:00:44 -0800 (PST)

randy

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Mar 1999 18:54:16 -0500

>yup.  so why are all these non-operators second-guessing this?

1.  Customers always have the right --- and even the obligation -- to note 
patterns of non-performance, and

2.  Some of us have the requisite operations experience.

The current approach has been in effect for 10 years.  Products are now 
fully off-the-shelf, and there are thousands of well-operated Internet 
services.

Yet more often than not, meetings for the preeminent Internet technical 
body have network service with problems.

It does not take expertise to question the reasonableness of this pattern.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Mar 1999 18:54:16 -0500

d/

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Mar 1999 18:34:25 -0800 (PST)

> patterns of non-performance, and

i missed the part where you said what part(s) of the service did not meet
your needs.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Mar 1999 18:34:25 -0800 (PST)

randy

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 21 Mar 1999 10:35:03 +0100

i was most impressed by the terminal room setup - it seemed to cater
to most needs (modulo the comment on IRDA access, and the same version
of ssh on pc and unix would have been handy, but was workaroundable)

the wide area access was fairly odd - we seemed to alternate routes
between sprint and planet goign to europe - and at one stage, me and a
colleague from london, siting at opposite unix boxes, had completely
different performance (i had 10 mins of ineractive emcas use while he
only got to read 1 email header) so maybe there was some odd load balancing
or something gong on on the bundle of T1s or whatever was in use...but
thatsort of thing is at the whim of the cyber deities, and not really
down to terminal room design....

a ququeing system might be quite nice to manage peak time load
- e.g. ticket # plus time limit - after all a lot of people with realy
urgent work can always dial up from their hotel room and a lot of
folks are always "just browsing"....while those of us with slides to
print or i-d's to check out between WGs are waiting sometimes...
but never for long, so maybe its not a real problem...

oh, in oslo, i expect to find a collection of free GSM phones
for use in the city with an SMS gateway -)

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 21 Mar 1999 10:35:03 +0100

cheers

   jon

---

From: [email-masked]
Date: Mon, 22 Mar 1999 03:50:34 -0500

> It does not take expertise to question the reasonableness of this pattern.

1) The ISP gets to set up his infrastructure under controlled
conditions, not in a hotel he may never have been in before.
And the ISP gets to do the infant-mortality crash-and-burn dance
with just some startup users watching, not all their peers.
And they usually have a much looser timeframe - days/weeks
between hardware showing up and being up and running, instead of
hours.

2) The ISP usually only has to get each user up and running once,
after which they usually keep working without config changes.
No wait.. this applies to the IETF too - but everybody hits their
one setup quirk the same afternoon, not spread out over several
weeks/months.

3) Anybody want to make an estimate of what percent of the average
ISP's customers have plain vanilla off-the-CD configurations, and
compare that to the average laptop that arrives at the IETF with
who-knows-what odd configuration on it?  

4) It might also be useful to compare the average consumer's
opinion of "acceptable" downtimes (factoring in browser crashes,
operating system crashes, and the like) to what the average IETF'er
considers "acceptable".  I have systems that measure in unscheduled
outages per year - and know people who think 4-5 blue screens a day
is the cost of doing business.

So.. is there *really* a problem, or are we expecting far
beyond what the average "well operated" ISP usually provides?

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: [email-masked]
Date: Mon, 22 Mar 1999 03:50:34 -0500

Valdis Kletnieks

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Mar 1999 07:56:58 +0800

At 07:18 AM 3/19/99 -0800, Matt Holdrege wrote:
>meeting went very well. But, as always, there were some snags.

Matt:

I too want to thank you and your staff, and your contributors, for the
excellent IETF facilities this time around. Yes, there were some snags in
the terminal room, but on the whole things when very well.

It sounds, then, like you would recommend that future IETF meetings
configure three T-1 links in a redundant fashion, able to support peaks of
3.5 MBPS of traffic, with perhaps a fourth dedicated to the MBONE feed. You
would also recommend roughly comparable numbers of terminals, wireless
attachments, printers, and laptop drops. And you would recommend that the
wireless network be on a separated subnet.

I understand that Steve Coya believes that volunteer staffing and terminal
room management remains perfectly acceptable, but plans to do a better job
of specifying the needs of the terminal room, in order to avoid the few
snags that we experienced.

Fred

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Mar 1999 07:56:58 +0800

Matt:

Fred

---

From: Dennis Fazio <[email-masked]>
Date: Wed, 24 Mar 1999 00:04:17 -0600

--On Tue, Mar 23, 1999 7:56 AM +0800 Fred Baker <[email-masked]> wrote:

> 3.5 MBPS of traffic, with perhaps a fourth dedicated to the MBONE feed.
> You would also recommend roughly comparable numbers of terminals, wireless

Three lines would be full-duplex and would support 4.5Mbits/sec each way.
That would be plenty, even if one failed, to support incoming traffic from
web browsing and RFC fetches. 

Mbone and Real Networks traffic is all outgoing and would also have 4.5
mbits available on the three lines. 

Actually, even just two T1 lines would have been fine in Minneapolis and
will probably be adequate in Oslo. The 3.5Mbit peak was only reached once
and for a very short spell. Details are available at in a GIF attachment to
this message.

The attendance may not be as high in Oslo, so Minneapolis quantities should
be adequate. In Washington in the Fall, I would recommend installing 4.5 -
6.0 mbits/sec of access bandwidth, 20-25 Unix stations, 80-90 Windows or
Mac stations and 120 10BaseT drops (5 24-port switches worth). Four
separate subnets should be deployed and routed: Terminal room systems and
drops, wireless, mbone, and Real Networks. That way nobody can complain
about interference from anyone else. The registration desk can be run off
the main terminal room network.

Some people couldn't get DHCP to work (usually those pesky Linux
individualists :) ), so about 100 static IP addresses would be needed for
the laptops and about 1-2 dozen for the wireless folks.

It would also be nice to have a hub or switch with about 3 or 4 open ports
for those people who only have male interfaces to their laptops.

For future reference, if anyone is interested, the space was 70 x 80 feet
in size (5600 sq ft). There were 240 lineal feet of workstation table space
and another 240 lineal feet of 10BaseT port table space. About 14-15 20 amp
circuits were used at the tables and 5-6 for the servers, printers and
routers. About 85 low-cost power strips were used to fan out power to
everything. 4,000 ft of Cat5 PVC cable was used along with about 250 patch
cables of various lengths.

It took about 2 days and 8-12 volunteers to completely set up (largely
because not all the workstations came on time) and about 3-4 hours with 5-6
volunteers to completely tear down and repack.

I think about 2 dozen 10-ream boxes of paper were on hand and we went
through about 1/2 of that. I think thats around 50,000-60,000 sheets. (My
reference table doesn't have a sheets to trees ratio entry on it.) Only one
printer didn't make it through the week with its original toner cartridge
still in place. I don't have good data on transparency usage, but I think
we used about 2/3 of what was provided.
--
Dennis Fazio, MRNet
GabNet:  612-362-5850

---

From: Dennis Fazio <[email-masked]>
Date: Wed, 24 Mar 1999 00:04:17 -0600

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Mar 1999 08:26:26 -0500

On Wed, 24 Mar 1999 00:04:17 -0600 Dennis Fazio <[email-masked]> 
wrote:

>...

Let me add a few recommendations to Dennis's, the first of which 
should be obvious from the recent correspondence:  

(i) We need to view this as a production facility, not a test 
lab.  If "new stuff" is introduced, there must be a clear, and 
non-disruptive, plan for pulling it back out if it causes any 
problems.  And there should be no attempted to introduce "new 
stuff" after Sunday turn-on unless it is very clear that it 
won't cause disruption. even in transition.

(ii) The idiosyncracies of DHCP in practice, combined with 
Murphy's law, seem to be such that we may need to be ready to 
pull down one server and insert another (even if no one insists 
on their right to introduce new software mid-week). The attempt 
to do a midstream switch was apparently one of the reasons we 
had so much DHCP trouble one evening.  The only clean way to do 
a switch apparently involves starting the "new" server with a 
different address range than the old one was using so the old 
leases can quietly expire in the normal course of events. Hence, 
the terminal room staff should have an unused address range on 
standby that is large enough to accomodate a switch in DHCP 
servers.

(iii) Whether it primarily involves Linux idiosyncracies (as 
Dennis suggests) or NT ones (as others have suggested), we need 
to decide whether NT's DHCP server is acceptable for IETF use.  
That is a technical issue, fairly easily settled in a bakeoff if
it can't be settled in some other way, and there ought to be 
enough interest in this to get someone to conduct the bakeoff 
if the answer is uncertain.  If it is acceptable, the whining 
and MS-bashing should stop.  If it is not acceptable, we should 
stop trying to use it: as I've said before, my sense is that 
many of the perceived terminal room problems in the past come 
from lack of effective transmission of the lessons of previous 
efforts and this may be an outstanding example.

One general observation that has little to do with the terminal 
room itself: one of the consistent complaints has been about 
DHCP problems and interoperability.  One of the things the IETF 
is supposed to be about is standards and interoperability.  I 
suggest that the ongoing perceived problems and finger-pointing 
should be taken by the DHC WG and the appropriate ADs as an 
indication that the applicable standards and standards-track 
documents should be reexamined to be sure that they specify 
enough, in enough detail, and that they are crystal-clear about 
their expectations of clients and servers so that, if things 
don't interwork, it is not due to good-faith variant 
interpretation of the standards.

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Mar 1999 08:26:26 -0500

john

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 24 Mar 1999 10:07:50 -0500 (EST)

Date: Wed, 24 Mar 1999 00:04:17 -0600
   From: Dennis Fazio <[email-masked]>

Well, my problem was that my DHCP client was standards conformant, so
that when the NT DHCP server (which was apparently dropping packets left
and right, although to be fair that might have been fault of the fact
that MBONE traffic was swamping the wavelan net; however other folks who
were monitoring things claimed the NT DHCP server was dropping packets
even on the terminal room subnet, but I don't have personal knowledge of
that) failed to renew the lease, my interface would get turned off.  So
I finally I got tired of the nonsense, and got a static IP address so I
wouldn't get shafted by DHCP.

So here are a few lessons which apparently needs to be consistently
relearned at the last couple of IETF's, which hopefully we can
institutionalize.  So we don't have to repeatedly relearn them the hard
way.

1) Don't even think about running an NT DHCP server.  Really.  Other
folks who are more knowledgeable about DHCP can go on about how it
violates the DHCP standards in this way and that, but what I know as a
user is that it simply doesn't work well, and that things get better
after people give up on NT DHCP, and replace it with something real.  So
why can't we simply use the ISC dhcpd from the beginning, instead of
waiting until people complain to fix things?

2) Make sure the MBONE traffic doesn't get let onto the Wavelan network;
since Wavelan is only 2 megabits, the MBONE traffic really hoses it
down.  This is again one of these mistakes which has been made
consistently over the last couple of IETF's, only to get fixed midweek
when enough people complain so the terminal room staff have to scramble
to make a correction during the week.

I'm really glad we're having this terminal room post-mortem discussion,
and kudos the Ascend folks for starting this conversation.  Hopefully we
can learn from what went well and what didn't work well, instead of
apparently forcing each host to learn about these pitfalls as they go
during the IETF week.

						- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 24 Mar 1999 10:07:50 -0500 (EST)

- Ted

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 24 Mar 1999 09:08:59 -0600

> Only one printer didn't make it through the week with its original
> toner cartridge still in place.

Interesting.  I can imagine N printers using up, say, 1.1 toner
cartridges each, requiring 2N cartridges unless the staff plans in
advance: Start with N+1 cartridges and each day swap a different
printer's cartridge for the idle one.

Obvious to the puzzle-minded, but maybe worth putting in the Terminal
Room BCP.

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 24 Mar 1999 09:08:59 -0600

---

From: "Michael H. Warfield" <[email-masked]>
Date: Wed, 24 Mar 1999 10:18:28 -0500 (EST)

Dennis Fazio enscribed thusly:

	[...]

> the laptops and about 1-2 dozen for the wireless folks.

	I didn't make Minneapolis but I was in Orlando and was one of those
pesky Linux individualists...  Except that my system worked just fine.
When I had trouble getting a dhcp address, I just told it to try it again.
At the worst of times, it took three tries.  Most of the time, it got one
on first try.  In fact, of all the Linux dudes I talked to, I only know
of one who was having trouble with DHCP and went and got a static address.
Maybe there were a lot more and I just missed them...  :-)

	One person sitting next to me one day asked me what I was
running.  I told him Linux and he said that he was just about fed
up with Windows screw-ups and was ready to look for something that worked
reliably.  He was considering Linux or Solaris-x86 and had been having
a real bad time with Windows.

	I met some guys I knew professionally from New York while down there.
One of them had tried to get his Windows NT laptop working with the terminal
room DHCP.  He ended up totally disabling his laptop to the point where he
couldn't even get a login prompt.  The laptop was a total loss for the
entire conference.  I never did hear back from him about whether he ended
up reinstalling the whole thing like he thought he would have to.

	I saw a wide mix of Linux, Windows 95, Windows NT, Solaris (some
Sparc book, some x86) and *BSD.  It would be REAL interesting to get
some feedback about experiences in the terminal room broken down by
operating system and see if there WAS a correlation.

	BTW...  One of the guy's I was hanging out with mentioned the
total lack of security on many of the Windows laptops in the terminal
room.  You could browse the network neighborhood and it was amazing
how many people had shared out their entire hard drives with full access.
I'll bet we didn't have a firewall up to protect them against getting
hammered from the outside network either...  Some people should GET REAL.

	[...]

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: "Michael H. Warfield" <[email-masked]>
Date: Wed, 24 Mar 1999 10:18:28 -0500 (EST)

[...]

	[...]

	Mike

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 24 Mar 1999 08:54:30 -0800

>for those people who only have male interfaces to their laptops.

An easier option that IMC has found works just fine at our interop events: 
have a handful of female-to-female RJ45 connectors handy. They cost about 
$1.50 apiece. People with male adapters on their laptops really should be 
carrying these around anyway. Maybe buy 20 of them and sell them at a 
slight profit to the folks who need them.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 24 Mar 1999 08:54:30 -0800

--Paul Hoffman, Director

---

From: [email-masked]
Date: Wed, 24 Mar 1999 08:54:58 -0800 (PST)

> won't cause disruption. even in transition.

	Here I would beg to differ.  IETFs have been the
	palce to do any number of interesting testbeds (BGPv4
	deployment, NSAP testing, multicast(mbone), IPv6 all come
	to mind) in part because it is so easy (or use to be) to
	have all the players in one place. Remember that wireless
	was a "bag on the side" not too long ago. Treating the
	network access as "production" is fraught with danger
	in that it becomes very easy to get stuck with antique
	technologies. This was discussed in Mark Prior's draft on
	hosting an IETF.  People will want support for their latest
	stuff, regardless of what is offered.  Having the ability
	to respond to these types of requests is what makes for 
	a good network access facility.
 
--bill

---

From: [email-masked]
Date: Wed, 24 Mar 1999 08:54:58 -0800 (PST)

--bill

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Mar 1999 09:51:06 -0800 (PST)

> Maybe there were a lot more and I just missed them...  :-)

First time I've been called that.

FWIW, I used a Linux laptop in both Orlando and Minneapolis and had only
one brief spot of trouble in Orlando, when as you say retrying a couple
of times fixed it. My Linux setup is also _very_ vanila.

> a real bad time with Windows.

Happens to me too...

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Mar 1999 09:51:06 -0800 (PST)

Happens to me too...

				Ned

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 24 Mar 1999 11:28:08 -0800

Hi,

> So

I have already spoken with Steve Coya and indicated ISC is more than
willing to do this.

Regards,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 24 Mar 1999 11:28:08 -0800

Hi,

Regards,
-drc

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Mar 1999 17:16:29 -0500 (Eastern Standard Time)

> 	was a "bag on the side" not too long ago. Treating the

Bill,

I think this is all fine. But, while we can quibble about 
the use of the word "production", it is clear that a lot of 
people and activities are dependent on the "terminal room" 
functioning and functioning well and that implies that we 
need to be *very* careful that "new stuff" doesn't 
interfere with the operations of the base stuff and/or that 
we have clear plans in place to eliminate the offending 
stuff if there are problems.  The examples you cite were 
mostly consistent with that principle.

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Mar 1999 17:16:29 -0500 (Eastern Standard Time)

Bill,

   john

---

From: [email-masked]
Date: Wed, 24 Mar 1999 15:06:39 -0800 (PST)

...
> mostly consistent with that principle.

Prudent use.. very wise.

-- 
--bill

---

From: [email-masked]
Date: Wed, 24 Mar 1999 15:06:39 -0800 (PST)

...

Prudent use.. very wise.

-- 
--bill

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Mar 1999 19:28:04 -0500 (Eastern Standard Time)

> slight profit to the folks who need them.

A generalization would be to let someone open a small 
concession, perhaps as an adjunct to shirt-selling, with 
small accessories that people should have had the sense to 
bring but that the terminal room shouldn't have to supply.  
F-F RJ45 connectors, cube taps, AC plug adapters from 
<whatever> to <local> (although I'd love to see IETF obtain 
some of the "almost anything fits in" plug strips that were 
in use during Apricot in Singapore), and maybe even some 
PCMCIA Ethernet cards, spare dongles for popular 
models, RJ11 cords, diskettes,...  Premium prices on this 
sort of thing could make the business turn a profit in a 
hurry :-)

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Mar 1999 19:28:04 -0500 (Eastern Standard Time)

john

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Wed, 24 Mar 1999 17:11:08 -0800 (PST)

Yeah, and maybe Sony TL-W30 retracting phone cords, Japanese "tilting"
plugs, Fujitsu My-Phones, 4-inch extension cords to get power bricks off
the powerstrips, etc. And a personal guided tour of Akihabara as a special
bonus. I think I know someone who could do that :-)

Ole

Gadgets for Geeks (TM)

Ole J. Jacobsen 
Editor and Publisher
The Internet Protocol Journal
Tel: +1 408-527-8972
e-mail: [email-masked]
URL: http://www.cisco.com/ipj

VP for Chapters, The Internet Society.
See you @ INET'99, San Jose, CA, June 22-25. http://www.isoc.org/inet99/

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Wed, 24 Mar 1999 17:11:08 -0800 (PST)

Ole

Gadgets for Geeks (TM)

Ole J. Jacobsen 
Editor and Publisher