[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on NetConf Requirements

Juergen Schoenwaelder wrote:

Having another TCP connections for this would not kill me... I am also
not sure that you really need another channel. The primary reason I
think is that netconf assumes that _all_ exchanges over a single
channel form a valid XML document. If you consider each protocol
message a single XML document (similar to EPP), then you can probably
get away with just one channel.
First, I think the channels are important because the abstraction also assists connections from either direction (element connects or server connects). This is important to deal with firewalls, a problem that SNMP has be dogged by.

Eliot> 2.  The security profiles are well specified.

I remember operators telling us that they love ssh and to some extend
tls/ssl. EPP for example runs over tls/tcp.
Right. BEEP is tls-based, as well as SASL based. TLS/TCP is probably insufficient, because the existing operating model of the devices in question is username-based. The protocol will need to be tied into an device's radius/TACACS+/{diameter in the future?} implementation.

Eliot> 3.  Proper framing of XML channels within a channel.  You don't
Eliot> have to have parsed the entire page in line to know that
Eliot> there's more coming.  In fact you don't have to parse anything-
Eliot> it's byte counts.

See <draft-ietf-provreg-epp-tcp-06.txt> for a nice simple way to
achieve framing.

I will do this.


Eliot> 4.  It was pretty much designed with XML in mind as well as
Eliot> HTTP's shortcomings.  In essence, it was meant to address
Eliot> things that HTTPng started to tackle.

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.
Yes it is. We're not looking to replace the console interface. We're looking to provide a programmatic interface. Many *many* vendors have a way to do this with HTTP today. In fact that's as much a problem as it is a good thing, since there's no interoprability.

Just be clear: I am concerned about the combination of netconf with
beep as it is currently defined. My thinking is:

a) If a decision is made to rely on beep services, I think the
   requiremens for the transport should just be more demanding and
   thus at least some of the rpc stuff in netconf can can just go
   away.

b) On the other hand, if a decision is made to keep netconf self
   contained, then we have reduced requirements for the transport
   and in this case I believe using beep is a bit too heavy.
I would agree that BEEP is about 110% of what you need for XMLCONF. On the other hand, it covers the 100% that needs covering.

Eliot



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