Re: Thoughts on NetConf Requirements

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Eliot Lear writes:

Eliot> However, here is what BEEP buys you:

Eliot> 1.  Integrated event management related to configuration.  How?
Eliot> You have a separate channel.

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.

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.

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.

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.

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.

Personally, I prefer b) and I think that EPP has nice elements to
consider and steal (if we have to have another protocol).

/js

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