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

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

Martin Bjorklund wrote:


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.


IMO we can't write a super-detailed elements of procedure without knowing
many or all the problems areas, i.e., same input on 2 boxes that supposedly
support the same data model produce different sets of <rpc-error> elements.
We need real data from real implementations, indicating interoperability problems.
You have to characterize exactly what differences are allowed (e.g., error order) 
vs. not allowed, which errors depend on the particular operations supported
in a given data model, etc.  This is not an easy problem.


 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?


If the peer never gets a complete <hello> message, the transport layer has
to shut down the session.  I don't think malformed XML is any different
than a malformed binary PDU. It can't be processed.  You didn't really
get an <rpc> request if it was malformed XML or missing, so you can't send
an <rpc-reply>.

Side bar:  We need a monitoring module for NETCONF, especially in
the early days, to debug the protocol.  I'm working on a set of counters
(rpcs-rcvd, rpc-replies-sent, rpc-parse-errors, bad-hello-msgs-received, etc.). 
I would really appreciate your input (and all fellow implementors) on this
initial set of counters. 


 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?


Yes -- the base protocol URN would be different in a new version.
We will probably add minor features as capabilities instead of
obsoleting version 1 of the protocol.


 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). 

How much should a manager application be able to do without knowledge
of the underlying networking technology being managed?  How much can
it do without even loading the domain-specific schema?  The human operator
sure knows that 'name' is the key, not 'mtu', so what's the best way to
document that in the schema?  Should there be any PDU tagging to
help applications process PDUs without needing to load a schema?
(I think OASIS has made good progress in this area, so we may want
to look closely at their work.)

In your example, it seems the manager has no schema loaded,
or you have a schema but you want a standard way to identify instances.
I think netconfmodel is supposed to address this issue.



/martin



Andy


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