Re: ops-operator-req-mgmt-01

[john heasley <heas@shrubbery.net>]

Wed, Dec 26, 2001 at 04:26:29PM -0800, Bill Woodcock:
>       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.

then the problem is not buffers, but rather functioning tcp stack and/or
uarts/tty driver.  no uart has 2M of buffer space, in fact more like 16
bytes or can even address 2M of DMA - and DMA space is usually fixed.
so, "must implement [tcp/ip rfcs] and must have functioning uarts with
functioning flow control that defaults to 9600 8N1 h/w flow-control"?

>     > 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'm suggesting that flow-control (ie: the transport protocol) has to work
properly and there should be no overruns, rather than "must have X amount
of buffer space."  if you specify buffer space, you also need enough to
rx an entire kernel over xmodem (or whatever).  ie: buffer space == duct
tape/bandaids.  and, if the user can't figure out how to configure the
serial line of their laptop or their chosen O/S doesnt handle a serial
line properly, send them home with a cone-shaped hat.

>     > 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?

probably some folks here and i'm sure i could gather others.  leave it to
the operator to use what is at his/her disposal - like ftp a new image
directly from a vendor's site.  how do you allow scp into a config server
(unix box) without an actual login on that server?  with current
implementations, i dont know that there is a way.  i do not want folks who
can login to a router to have any means to connect to my config server - eg:
developers from vendor X.  ftp can be easily chroot()'d, filtered by
connecting ip, anonymous-only, run through a proxy, ....  what about sftp?