comments on version 2 of protocol draft

[rdk@krupczak.org]

Hi!

Some minor comments.

Bobby

http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-02.txt

Notes

A note on defaults.  In many places, there are default values or
operands that are assigned unless specified otherwise.  As a
programmer, I always found defaults difficult to remember once I've
developed something and am on to the next project.  Unspecified
defaults (I feel) make support and maintenace pretty darn difficult
and add to confusion later on.  For example, lets say you are in the
field and debugging something by looking at a stream of XML.  W/o the
spec handy, one could have a difficult time recalling what exactly the
default value is.  Consequently, my personal vote is that defaults be
eliminated and that all values, operations, options be required to be
explicitly defined.  For a computer, its not big deal; for humans, it
adds a lot of clarity.

3.2 <rpc> Element

  The <rpc> element is used to enclose a NETCONF request sent from the
  manager to the agent.

This is somewhat rhetorical, but why bother to restrict <rpc> element
to only manager-to-agent communications?   Or is it that all entities
are (or can be) dual-role entities?

3.4 <rpc-error> Element

   The <rpc-error> element is sent in <rpc-reply> messages if an error
   occurs during the processing of an <rpc> request.

   The <rpc-error> element includes the following information:

Is this correct?  The example would imply its sent as a base element
(that is, not included inside an <rpc-reply>.  The example for the
<ok> element properly reflects that it is contained in an <rpc-reply>
element.  Does the example need further clarification?

3.6 Pipelining

   NETCONF <rpc> requests are processed serially by the managed
   device.  Additional <rpc> requests MAY be sent before previous ones
   have been completed.  The managed device MUST send responses only
   in the order the requests were received.

Is this really necessary (the sending of responses serially)?  That
is, since <rpc> requests each have their own identifier, and a prudent
implementation would match them to replies, why make this requirement?
I can see down the road whereby one particular operation may take a
while to complete whilst other operations (initiated after the lengthy
one) may finish earlier and the netconf agent could conceivably reply
sooner.  However, processing should be serial.

5.2 <edit-config>

Creation as a side-effect of edit and its only officially documented
in an example.  Regardless of the outcome of the discussion, creation
of an element ought to be a bit better documented.  

5.3 <copy-config>

Creation of an entire "config file" is done with copy-config.
Creation of an element is done with <edit-config>.  Having the two be
done differently is confusing but necessitated by the current protocol
operations.  Am I the only one that finds this semantically confusing?
I understand why this is but cannot help but notice the glitch in the
semantics.


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