Re: comments on draft-ietf-netconf-prot-09

[Vincent.Cridlig@loria.fr]

Hi,

Concerning item 4, we met exactly the same problem in our implementation of
Netconf (YencaP). Up to now, we assumed that the first element is the key. But
we also think it would be much better to clearly state what is the key and what
value is to be updated in an edit-config operation.

Sincerly,
Vincent CRIDLIG


Selon Martin Bjorklund <mbj@tail-f.com>:

> Hi,
>
> We have implemented the netconf draft, and have some comments /
> questions.
>
>   1.  In general, it would be helpful with precise "elements of
>       procedure" instructions ala SNMP rfcs.  As it is now, it's a bit
>       unclear how errors should be handled in many cases.  (see
>       e.g. item 2 below).  I suspect different implementations in many
>       cases will generate different error messages for the same input,
>       making it more difficult to write a good manager application.
>
>   2.  How is a peer supposed to handle mal-formed XML in the
>       processing of the <hello> message?  Since section 8.1. says that
>       the transport should be (silently?) closed if the session-id
>       element is wrong, is it correct to assume that the same
>       applies to any similar error?  What about a mal-formed <rpc>
>       message?  Should an <rpc-reply> be generated if the XML is bad?
>       Even if the <rpc> element is missing?
>
>   3.  How is different versions of the netconf protocol supposed to be
>       handled?  Since the <hello> message is sent asynchronously by
>       both peers, and the namespace includes a version number, I
>       assume that the intention is to keep the hello message fixed,
>       and then add a new namespace and a new capability for new rpc
>       operations?
>
>   4.  I understand the separation between the protocol and the
>       underlying application data model.  But wouldn't it make sense
>       to state when the result of an operation depends on the data
>       model?  It's not trivial to understand how the edit-config
>       operation is supposed to be used without knowledge of the data
>       model.  For example, the first example in 7.2 is
>
>           Set the MTU to 1500 on an interface named "Ethernet0/0" in
>           the running configuration:
>
>             <interface>
>               <name>Ethernet0/0</name>
>               <mtu>1500</mtu>
>             </interface>
>
>       In this example, the manager has to know that the <name> of an
>       interface is used as a key (or index) by the agent.  If the same
>       command was issued to an agent which had the <mtu> as key (not
>       very realistic of course), the result had been quite different!
>
>       In fact, does the 'merge' operation make sense at all unless the
>       manager knows which element(s) are used as key/index?  And if
>       there are no keys, does 'merge' mean anything?
>
>       Again, I understand that the draft defines the protocol and not
>       the model, but I think it would be helpful to at least make a
>       note of the problem, and that this has to be solved by
>       implementations (and/or the netconf modelling effort).
>
>
> /martin
>
> --
> 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/>
>




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