Re: comments on version 2 of protocol draft

[Rob Enns <rpe@juniper.net>]

On Mon, Feb 23, 2004 at 11:11:46AM -0500, rdk@krupczak.org wrote:
> 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.

I agree with this. Does anyone on the list have a problem with 
removing the default parameter values?
 
> 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?

The design team's proposal is that NETCONF entities must be one or the other, 
it's going to be up to the substrate drafts to indicate how an entity will
indicate that it wants the manager or agent role.
 
> 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?
 
Ugh, thanks for catching this. The description of <rpc-error> ambiguous 
in a number of places and needs to be clarified. <rpc-error> should appear 
inside an <rpc-reply>.


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

We're making serial processing mandatory to keep things simple. I agree
out of order processing is something that might be handy in the future,
if so we can add it.

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

Agreed... see the other mailing list thread for Andy's list of operations,
which includes explicit create.
 
> 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.

The draft needs to do a better job of explaining the difference
between a config file, and a config datastore (database). I'll take
a crack at cleaning it up.

thanks,
 Rob

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