Re: Is beep really what operators would want?

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Tue, 17 Jun 2003 10:29:02 -0700, Eliot Lear <lear@cisco.com> said:

>> The beep protocol forces a fair amount of initial communication
>> upon the connection.  This is a good thing from the management
>> application prospected, but bad from the cut-n-paste prospective.

Eliot> Think perl and it all makes sense ;-)  If they can do it in perl
Eliot> without fancy encoding requirements then they can rapidly prototype
Eliot> new services and features.

Eliot> I would agree, by the way, that BEEP is probably 110% of what
Eliot> is needed in this space.  I just don't think the other
Eliot> transports come close to 100%...

Don't read my statements wrong:  I like the BEEP protocol and think
it has a lot of useful benefits that the netconf work can build on top
of.  Of the transports discussed so far, its my favorite.

My question was that the *operators*, on the other hand, may be less
happy with it.  They always gave me the impression that they wanted to
cut-and-paste into all the management protocols they were using.  I
think that was an unreasonable constraint and I think both sides have
caved at this point toward a more reasonable middle ground.  I'd even
suggest that BEEP is likely the best middle ground.  I just wasn't
sure they'd reviewed the BEEP spec yet (since most of their time is
spent "operating" and not "reading"), so I was trying to cut out a few
useful extractions and concepts from the document.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>