You miss my point. The point is that an appropriate level of documentation is always correct, but at some level, the system should explain itself to some degree. No programmer worth their salt goes through and writes comments like, "This is a function. The function "get_an_integer" gets an integer." That's inane, because any programmer taking over should be able to look at the system and figure it out, because there are industry/practice-standard ways of writing and doing things that are meant to make such knowledge transferable.

Hence with documenting the network -- some of it should simply explain itself. Yes, if there's specific, custom ways it is configured, it should be documented, but those custom configs should be few and far between to keep the need for documentation low. I only say all this because the way the OP phrased his question made it sound like the entire contraption was this Rube Goldberg machine of networking components that would require some complex PhD to understand, and that sounds like a problem with implementation, not with documentation.

Am I the only one who first thought, "If you have done the network correctly, it should explain itself"? Overly-complex networks take overly-complex documentation and overly-complex people to run and maintain. Mind you, there's a difference between correctly-complex and incorrectly-complex, but at the same time, every level of difficulty you go upwards in the configuration scale you exponentially increase the need for carefully calculated and layed-out systems. Ok, ok...now that I'm thrust back into reality...and given that you aren't likely to rebuild your network (although you might consider some re-work to help the self-explanatory aspect)... High level details, locations of closets, routers, switches, major cable runs, passwords, IPs, big details. All the small things the other person will have to figure out anyway and catalogue in their own mind in their own way, so doing it for them won't help a ton. Give them the tools to do their job properly and you'll be sitting fine.

I imagine so. :) And I've done without a sewer for 48 hours once because ours backed up. It sucked like no other suck. Yes, of course I'm joking, because RMS takes everything to the extreme and beyond the intention instead of lodging a legitimate concern. Fact is, some things I care about if I can patch the system or modify the code, and some things -- I don't. I really don't give a rat's ass about some things because I just really want to get work or life done and out of the way. Hence, sewers. By letting the city dictate my sewage handling prices, how my house hooks up to it, and what I'm allowed to put into it, I'm giving up control but, really? I don't want control of that, and I'm happy enough not to have to handle it.

"'Sewer as a service' means that you think of a particular sewer as doing your poop disposal for you. If that's what the sewer does, you must not use it! If you do your pooping on someone else's sewer, you hand over control of your poop to whoever controls the sewer. It is like using truck-stop toilet paper, only worse: it's even harder for you to wipe an ass that's sitting on someone else's toilet than it is to wipe an ass sitting on your own bog. Just like dye-free Charmin, 'sewer as a service' is incompatible with your bowel freedom."

When I was in college, I completely had a crush on this terribly cute Russian exchange MIS student (much more business-savvy than CS savvy) who always needed help with her programming courses. Unfortunately, due to the different body language characteristics, I never could interpret whether she thought I was more than just a tutor or not, so I never made that leap. She was terribly delicious, however. Alas. Ahem. Computer labs -- needed! :)