more comments on draft-ietf-netconf-prot-09

[Martin Bjorklund <mbj@tail-f.com>]

Hi,

I have a few more comments and questions.

  1.  What does it mean to lock a remote configuration file, pointed
      to by a URL?  Maybe the lock opertaion should have the same
      restriction as e.g. edit-config, i.e. the URL has to be a local
      file?

  2.  If a manager tries to do an edit-config which contains some
      error, is it correct to assume that 'stop-on-error' (default) is
      supposed to actually modify the configuration so that it is left
      in a possibly inconsistent state?  If this is correct, under
      which cirumstances is this behaviour something the manager would
      choose?

      Would you consider an implementation that did NOT allow
      edit-config with errors when trying to modify the running
      configuration non-compliant?  Today, our implementation will
      refuse to change the running config if an edit-config
      results in an invalid configuration state (even if error-option
      is ignore-error and test-option is set).

      Why is this behaviour controlled by the manager, not the
      agent?
  
  3. [minor] Section 8.3.1 mentions a :lock capability.  Is it just a
     remainder from when lock was a capability?



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