[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 14.1: Retrieval Subset specification proposal
On Fri, Mar 19, 2004 at 12:04:12PM -0800, Andy Bierman wrote:
> >You missed the point of my question. Please tell me the reason
> >why the filter cannot be a parameter in the protocol operation and
> >the reason why the 'operation' attribute has to be in the payload.
>
> Because it's possible (and useful) to include config data from
> different data models in the same edit-config operations, and
> different operation and XPath values will be relevant in
> each data model. Also, one operation or filter parameter may
> not apply to the entire payload.
If you have followed my postings, you will have noticed that I have
argued for
(a) protocol operations (verbs) that have clear semantics
(b) payload that is just data not does not define verbs
(c) sequences of operations to achieve a complex edit/retrieval
(d) if really necessary, add a compound operation to group things
I believe this gives us the benefit of a clear boundary between the
protocol operations and their semantics and the payload exchanged by the
protocol operations.
Saying the real semantics of the edit-config is somehow embedded in
the payload or the filter for a get-config is something we do not
specify at all since it is data model dependent sounds odd to me.
> >And please tell me the precise semantics of the <config/> parameter
> >of get-config (and how that is going to be data model independent).
>
> The <config> element is the container for the configuration
> data payload, which may be any valid XML (not in the netconf:base-1.0
> namespace).
Why do I send a <config> element when I retrieve information? For me,
the <config> parameter of get-config is not payload - it is a filter.
And this is how I read the current document. However, the real semantics
are not clearly written down (and I believe they cannot be written down
without making assumptions of the data model or coming up with something
as powerful as XPATH).
Am I the only one worried about this?
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>