Scenario: Ad-Hoc networks. discussion Before: There is an ad-hoc network somewhere on the "x" floor. They are sucking people into them. People are complaining. Person from company X walks by: "Hey I have a product that will pin point that person so you can show them the light"
After: Hmm, not as many ad-hoc networks. We can exclude those people from the net so we isolate them. Extra features that come along for the ride, maybe not as proven as previous, but those new features do help the ALL VOLUNTEER NOC TEAM to isolate some of those problems.
My question here is -- how did the NOC folks manage with ad-hoc networks _before_ the new fancy (and often, it seems, brittle) software came in?
Maybe by documenting the procedures used "before" would help others in the similar situation, and would allow non-NOC folks (but those which might have dealt with similar issues in their local organizations) to improve those procedures. And you never know, maybe even more people would then be able to spot the ad-hoc network infidels, leading to less work for NOC.
Scenario: Wired drops for the presenter, jabber scribe, etc. This would be great. However, this of course adds hardware. Quite a bit of it. I put a switch in a central like location and secure it, POE the AP's and run 4-6 AP's in multiple rooms with 4-6 CAT5 cables. Now, I need to put breakout switches in each room, secure them, tape down the cables, possibly pull the cables and put them back down if the meeting rooms get used by other groups. I need to ship the cables, and the extra switches, along with the security cables. These issues continue.
Result: This is no reason that this cannot be accomplished. Why is it difficult? Security, time to deploy & tape down cat5 cable, shipping and acquiring extra hardware.
I agree that the wired drops in each room are probably more trouble than they're worth, especially considering the fact that the jabber scribes and other important people (excluding the chairs) are typically littered all over the room.
[...]right now, the folks doing the choosing pretty much have to guess whatthefolks doing the using want/need. open discussion could eliminate theguessing.
Choosing would be an excellent gift to have when doing a non-hosted terminal room. When there isn't a host, you take whatever you can get. When I did my first terminal room in San Francisco, Cisco stepped up to the plate with 2 pallets of gear. I still had to worry about: Terminals, wiring, placement, extra routers, extra switches, fiber, this list continues ad nauseum. Choice you say? My choice was either Cisco (which worked fabulously I might add) or to be incredibly delusional and wait for something else.
This is not an impossible situation. However, like many of the other notes on this topic have stated, you need consistancy, and persistance of knowledge. The terminal room document is dead. There needs to be a new one. But after a crew gets done doing a terminal room (donating their 3 weeks and having 6 months sucked from their soul)
It is not clear from your text whether you're referring to the whole network (including the backend required for wireless, like DNS and DHCP servers etc.) when you say "terminal room", or only those systems which are provided for free to the IETFers ("open terminals in the terminal room"). I'm assuming the latter.
A constructive suggestion:
We should only provide power sockets and a switch port in the terminal room. Scrap everything else. No computers, no printers, nothing. Simple and easy. No need for a guard to stand by.
Why do we need anything more? Just so that the IETF tourists can read their email? Doesn't seem worth the trouble.
When the meeting is hosted by someone, let's not expect them to provide the terminal room. Let's rather try to channel the resources to something more constructive (like, the equipment or T-shirts ;-)
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf