Re: Definitions of "Console" and "CLI" expanded

[Mike O'Connor <mjo@dojo.mi.org>]

:>
:> George Jones <gmj@pobox.com> writes:
:> > I'm finishing off loose ends/respond to outstanding comments
:> >
:> > One is trying to reconcile the "RS232 is old as dirt and just works"
:> > style console with the reality that it's *starting* to go away, and a
:> > ethernet based interface, possibly supporting its own IP stack and
:> > HTTP/HTML interface could meet the console requirements.
:>
:> Far better, IMHO, is the console processor/console ethernet supporting
:> ssh. It is secure and you can get to a nice CLI that way that's
:> compatible with the one on your RS232 equipment. When stuff ends up
:> being done by HTTP, you just end up building page shredders ("screen
:> scrapers") to get back the data you needed from the web page.
:>
:> It would be nice if the language didn't imply that HTTP/HTML is the
:> preferred replacement for a CLI over RS232...
:
:Well, this (including private replies) is sounding unanimous....

I agree completely with the sentiment that HTTP should not necessarily
be presented as the "preferred" replacement.  I cited it as reflective
of what I think is coming down the pipe.  USB may be another interface
option.  Finding builtin serial on new laptops gets harder.  When we're
specifies software requirements in a document with which to play "beat
the vendor" with, it's something they usually can adjust more "on the
fly" than hardware requirements.  That's why I'm suggesting that we be
a little forward-thinking here with the hardware specifics.  You aaren't
going to have someone suddenly graft a serial port on already-released
product, citing some BCP.  You want to target hardware considerations
for immediate next generation.  If I'm way off track here, and a bunch
of router/switch hardware designers want to speak up and say "we're
committed to the long life of RS232 and these notions of alternative
management interfaces in nextgen gear are offbase", by all means.

I disagree that it's impossible for "dumb HTTP" to function as a dumb
management interface, as long as it's dumbed down sensibly.  I think
the future of management ports will ultimately be something like dumb
WWW interfaces, and if we want it to be a good future, we ought to be
articulating what we want and don't want out of such things, using
RS232 and CLI as a guide.

I think that SSL/SSH/other encryption over the management interface
would be equally necessary (or unnecessary) in the RS232 space.  It's
about as easy to sniff RS232 connections as IP.  But adding strong
crypto to the management interface equation, whatever flavor, makes
things decidedly not dumb.  Folks have gotten working TCP stacks in
256 bytes of code embedded on PICs, which fits my definition of "dumb".
Securing the networking that connects the management client to the
management port is as "out of scope" as securing the management client
itself, AFAICT.

I'm not subscribed and this is enough words from me on the matter.
Take it FWIW.

-- 
 Mail: mjo@dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Never underestimate the power of a dark clown!"     -Bobo, Tripping The Rift