[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on NetConf Requirements
>>>>> Eliot Lear writes:
Eliot> First, I think the channels are important because the
Eliot> abstraction also assists connections from either direction
Eliot> (element connects or server connects). This is important to
Eliot> deal with firewalls, a problem that SNMP has be dogged by.
A channel exists on top of a connection and so why does the concept of
a channel make it easier to establish connections?
Eliot> Right. BEEP is tls-based, as well as SASL based. TLS/TCP is
Eliot> probably insufficient, because the existing operating model of
Eliot> the devices in question is username-based. The protocol will
Eliot> need to be tied into an device's radius/TACACS+/{diameter in
Eliot> the future?} implementation.
I agree that authentication has to be tied into radius or something
similar. So how does BEEP help here?
>> Yes, and BEEP is really a nice thing from that perspective. But I
>> fail to see how that relates to netconf since our starting point is
>> not HTTP.
Eliot> Yes it is. We're not looking to replace the console interface.
Eliot> We're looking to provide a programmatic interface. Many *many*
Eliot> vendors have a way to do this with HTTP today. In fact that's
Eliot> as much a problem as it is a good thing, since there's no
Eliot> interoprability.
My understanding so far was that operators script the CLI and do not
use HTTP or other mechanisms (unless the CLI is so hard to script with
ugly menus and such things that they do not have a choice).
/js
--
Juergen Schoenwaelder International University Bremen
Phone: +49 421 200 3587 P.O. Box 750 561, 28725 Bremen, Germany
Fax: +49 421 200 3103 <http://www.iu-bremen.de/>
--
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/>