Hello,
If you go back to my second reply, this is what I was suggesting
with the action-dominant encoding. I never restricted it to one operation
at a time. If you support a sequence of operations like that I also do not
see this having any issue on the fail-on-error model (again, I'm mainly
commenting on the encoding). IHMO, however, it make the creation of the
PDUs more forward and it clears up the separation between what NetConf
wants to define (the operations and the RPC mechanisms) and what
it wants to defer (the data model).
I therefore agree with this (a bit more with the first than the second proposal
but not enough to argue about it).
Thanks
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Sunday, March 28, 2004 6:53 PM
To: j.schoenwaelder@iu-bremen.de
Cc: Gagnon, Gilbert [CAR:NM10:EXCH]; Waters, Glenn [CAR:IO47:EXCH]; netconf@ops.ietf.org
Subject: Proposal to do away with netconf attributes in data model payloads
Hi Juergen,
Would this idea make you like edit-config any better?
What if we formalized the edit-config verb as a node under <config> instead of putting it in the data model?
I.e., instead of
<edit-config>
...
<config>
<foo operation="create"> ... </foo>
<goo operation="modify"> ... </goo>
</config>
</edit-config>
where <config> is the standard container
we have:
<edit-config>
...
<config>
<create>
<foo> ... </foo>
</create>
<modify>
<goo> ... </goo>
</modify>
</config>
</edit-config>
where <create>, <modify>, <merge>, <replace> and <delete>
are the standard containers. The verb applies to the innermost nest-level specified in the data model content. Each of these containers can appear zero or one times (in any
order) within a <config> element. The agent will execute
them in the order they appear.
In addition, the same technique could be used to eliminate the need to have an xpath attribute in the data model:
<get-config>
...
<config>
<filter value="xpath-expr-for-foo">
<foo/>
</filter>
<filter value="xpath-expr-for-goo">
<goo> ... </goo>
</filter>
</config>
</get-config>
<filter> can appear zero or more times. Data like <foo>
can appear instead of <filter>.
----------------------------------------------------------------
Separate proposal:
I wouldn't even mind if we put the 'config' in the
element path, so we had:
<edit>
<config>
... normal edit-config parmameters like <error-option> ...
<config-data> (container renamed from <config>)
<create> ... </create>
</config-data>
</config>
</edit>
This way <config> could be a 'choice' in the XSD, and
we could add other 'filters' later. For <get> the
choice is between <config> or <all>:
<get>
<config>
... get-config specific params
<config-data>
...
</config-data>
</config>
</get>
OR
<get>
<all>
... get-all specific params
<data>
...
</data>
</all>
</get>
Andy