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

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Oct 2005 23:34:19 +0200 (CEST)

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: [email-masked]
Date: Tue, 25 Oct 2005 10:21:03 +0200

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Oct 2005 09:33:08 -0700

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

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

>      and then add a new namespace and a new capability for new rpc

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.

>      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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Oct 2005 20:06:40 +0200 (CEST)

> We need real data from real implementations, indicating interoperability 

I was more thinking of errors in the protocol, not data-model related
errors.  As an example, I have to produce some error message if
someone tries to get-config the candidate configuration, if my
implementation does not support it.  Maybe operation-not-supported?
Maybe unknown-element?  Maybe your intention is that it doesn't really
matter and that it's up to the implementation.  I'm just saying that
some guidelines would help.

> I would really appreciate your input (and all fellow implementors) on this

Are these supposed to be readable through netconf, i.e. like a
SNMPv2-MIB for SNMP?  How will you specify these objects?  Using
netconfmodel's guidelines?

> it do without even loading the domain-specific schema?

I think it's reasonable that the manager loads the domain-specific
schema in order to do useful work.

> or you have a schema but you want a standard way to identify instances.

Well, yes I would like that, but that wasn't my point - I just think
it would be helpful if the document mentioned that the semantics of
the edit-config operation is dependant on the data model.  Unlike the
other operations.

I have another comment which I forgot yesterday.  I think the text
about the startup and running configurations could be improved.  I did
not understand what a startup configuration was until I searched the
archives and found a good explanation.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Oct 2005 17:26:53 -0700

>some guidelines would help.

In this case, there are plenty of standard error codes to choose from.
and that's the problem.   There are 3 error-tags that apply:

   Tag:         invalid-value
   Error-type:  protocol, application
   Severity:    error
   Error-info:  none
   Description: The request specifies an unacceptable value for one
                or more parameters.

 Tag:         operation-not-supported
   Error-type:  rpc, protocol, application
   Severity:    error
   Error-info:  none
   Description: Request could not be completed because the requested
                operation is not supported by this implementation.

 Tag:         bad-element
   Error-type:  rpc, protocol, application
   Severity:    error
   Error-info:  <bad-element> : name of the element w/ bad value
   Description: An element value is not correct; e.g., wrong type,
                out of range, pattern mismatch

IMO, 'invalid-value' is most correct, by process of elimination.
Operation-not-supported is meant to apply to protocol operations,
data-specific RPCs, etc. so that's not it.
Bad element applies to schema errors, value-range errors, etc.
Since 'candidate' is a valid value, this can't be it either.

I agree with you that we would benefit from from developer documentation
that made it easy to decide which error to use in every possible case.

>netconfmodel's guidelines?

Yes, readable through the <get> operation.
I don't know about the documentation format -- I suppose XSD because I 
already
kind of know that.

>the edit-config operation is dependant on the data model.  Unlike the

I think it does in the discussion of the 'operation' attribute, but it's 
probably
not that clear.  I KNOW it's not apparent from the text that implementing
edit-config and the operation attribute in a nested, modular, yet 
completely
automated fashion is non-trivial. :-) :-)

>archives and found a good explanation.

okay -- here is the text in question:

5.1: Running Config

  o  Running: The complete configuration currently active on the
      network device.  Only one configuration datastore of this type
      exists on the device, and it is always present.  NETCONF protocol
      operations refer to this datastore using the <running> element.

8.7.1: Distinct Startup

   The device supports separate running and startup configuration
   datastores.  Operations which affect the running configuration will
   not be automatically copied to the startup configuration.  An
   explicit <copy-config> operation from the <running> to the <startup>
   must be invoked to update the startup configuration to the current
   contents of the running configuration.  NETCONF protocol operations
   refer to the startup datastore using the <startup> element.

How can we make this more clear?

I guess it doesn't actually say in 8.7.1 that <startup> is the 
configuration
that will be used upon the next startup of the device.  I guess it shows
that the authors were pretty familiar with router CLI configuration and
may assume too often that these are well-understood terms and concepts.

Andy