comments on draft-ietf-netconf-prot-09

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