Re: Netconf on Debian

[Radu.State@loria.fr]

Thanks for the comments.

The current release has an optional encryption and compression module, which is
mere optional. Its just an implementation of our IEEE/IFIP Integrated
Management IM  2005 paper. Anyway, its usage is optional and transparent,
basically if an application does not want to use them, everyhing should work
just fine.

We will support only the SSH binding in the short future: for the moment one has
to rely on standart TCP/SSH tunneling, but we will add a programmatic support
shortly.

Regarding the frame marking, your are right. We will change it tomorrow, we
forgot to change it. Thanks for pointing it out to us.

There are some additional (with respect to the draft) features in the agent
(like role based access control, XSLT pushing/rendering, etc), but they are
optional in usage and transparent for a normal usage.

Thanks one more time and please send us more comments/bugs notification.

Rearding other potential interesting experience for the WG, we can post (if
there is interest for, after IM 2005) a technical report on some implemented
extensions  to the draft and benchmarking results which are rather surprising.

RS



Selon Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>:

> On Mon, May 09, 2005 at 04:14:07PM +0200, Vincent Cridlig wrote:
>
> > The Madynes research team has just released a new implementation of a
> > Netconf agent (YencaP).
>
> [...]
>
> > Any questions, suggestions for improvement or comments are welcome.
>
> Like the previous yenca release (which was written in C), you do not seem
> to support any of the three transport mappings that are discussed in the
> working group. The first yenca release used a TLS stream (but did not
> get the framing quite right) while this release runs netconf over TCP
> (but with a frame marking mechanism that is different from the one used
> in the netconf over ssh specification). In addition, you seems to
> support encryption and compression above the netconf rpc layer, which
> does not match the approach taken by the WG (which is to leave encryption
> and compression to the transport).
>
> I did not look through the other parts of the code but I am wondering
> how much netconf there actually is in yenca. I also like to know why you
> did depart from the netconf transport specifications (and perhaps other
> parts of netconf) and whether there is anything that the WG can learn
> from this.
>
> /js
>
> --
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
>






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