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

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

Martin Bjorklund wrote:


Andy Bierman <ietf@andybierman.com> wrote:

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. 

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.


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.


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. 

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?


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




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?


I think it's reasonable that the manager loads the domain-specific
schema in order to do useful 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.


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


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.


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.



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





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