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

Re: sub-tree filtering proposals



On 10. Jun 2004, at 18:15, Andy Bierman wrote:

The code size at runtime, on the runtime platform, is the first
interesting number.  The size of the compressed file on disk is
irrelevant.  You don't show the most interesting number, which
is the static and dynamic data memory usage during the processing
of a <get-config> or <get> operation.  Memory is a precious resource

As far as I know, RAM is much cheaper than flash memory.


on small embedded devices, which do networking as their primary task,
not Xpath.  No customers are asking for Xpath on small devices --

Customers are asking for consistent specs without too many options, since every options might have to be handled differently and cause trouble.

there isn't enough config there to worry so much about retrieval filtering.

That *might* be true. The manager might not know in advance.


IMO, it is unacceptable to make Xpath mandatory because not all devices
need it nor can support it without impacting manufacturing cost.

In situations where resources are really that limited, XML is the wrong
choice anyway. My expectation would be that devices that implement netconf
will not have such limited resources.



Another questions comes to my mind:


If limited devices would receive a request with an unsupported XPath
predicate, would it (a) return an error message or would it (b) return
a result document that might be larger than the document returned by a
full XPath implementation (e.g., by just stripping any occurance of
"[...]")?

I just started thinking about (b). And at first glance, it could
probably be a reasonable compromise: The client would not have to care
about the agent's #xpath capability and the fact that the returned
document contains unrequested nodes would probably not cause any
problems. The response should probably signal somehow that the request
contained an unsupported filtering expression.

What do you think?


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