>> >what the hell is the problem with setting it to default
>> >to off upon opening a telnet session
>> How many people user pmwho or other utilities to telnet in every min
>I think you misinterpretted him. If ComOS were to default to the
Quite possiable, I was looking at the reset on opening which is what I based
my answer off.
>equivalent of "set debug off, reset con" on termination of a telnet
>session, this would be a non-issue...and this is what people seem to have
>expected, which is why they're calling this a bug.
Best then to do would write an RFE and submit it to the correct channels.
Also back it up with the reasons why. You are aware of the need for
supporting an RFE with info but a lot of people do the "I what this" with no
reason why.
[---Personal Opinion Follows---]
My personal opinion on it is that IS/IT/ISP people need to be trained in
proper safety/security procedures. One thing I noticed right away getting
rides with the pilots up here is that they have a safety check lists that
they go over each time before they even start the engine. If it takes a
debug checklist to make sure that employees follow the correct procedure
then they need one. All support calls should be logged (for a number of
reasons) and if A debug is called for then part of the log should be the
opening of the debug and closing of the debug session. If I leave my
soldering iron on because I get distracted and start a fire it's my own dam
fault and not the fact the soldering iron does not turn itself off (some
may not agree with this example but to me it's the same as not following the
noted procedure) .
If people are worried about out side people telneting in put up a filter.
People wonder why I do an allow all at the end of a lot of my filters, well
telnet to your equipment from outside should be blocked at the network
border router. You can also put up a filter to allow telnet in for specific
IPs only. I know all of my work / debug was done from a pool of about 5 IPs
when I was still at an ISP. That's the way I would do it but it's not the
way that's best for everyone.
Tom
----
Thomas C Kinnen - <tom@lcp.livingston.com>
[Test Engineer - Radius ABM] - LUCENT Technologies RABU
<URL:http://www.livingston.com/> * <URL:http://www.lucent.com/dns/>
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>