Re: ops-operator-req-mgmt-01

[Bill Woodcock <woody@pch.net>]

      john heasley wrote:

    >    Regardless of the method of physical transport, the developer must
    >    provide sufficient input buffer to accept at a minimum, a
    >    maximum-length configuration at line speed without dropping any
    >    characters from the input.

    > this doesnt make sense.  whether a serial console or a tcp connection,
    > there should be a sense of flow-control and size of buffer space should
    > not matter.

Would that the real world were so accommodating.

    > if anyone has experienced dropped characters, i suggest its
    > lack of flow-control (or mismatch), faulty user-agent (ie: windowing
    > system or tip/cu configuration), etc.  maybe this is lacking specification
    > of s/w or h/w flow-control, data-bits, parity, etc for serial consoles?
   
The problem is that all vendors think the way you are, and assume that
making input work is someone else's problem.  So many vendors have input
overrun problems.

    > i completely disagree with omission of FTP.  ftp is an excellent method
    > to upload router core dumps that exceed the size capabilities of tftp.
    > just as it a good way to download images, while tftp is udp and i sure
    > dont want scp logins from routers to my config servers.  ftpd can be run
    > anonymous only and can use tcp_wrapper like filtering features.  ftp
    > client should be a requirement.

Why would you prefer unencrypted ftp logins to encrypted scp logins?

Can you find a significant number of people who are in agreement with you
and are willing to tell me so?

                                -Bill