[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: do we need filtering or some such
Ahh, you're reading more into the target configuration capability
than we intended when writing the draft.
Since you haven't specified any identifier for the ospf interface,
you're getting ospf instance 1, area 2, which would include
all configuration for that area. The interface and adminStatus
elements as specified are superfluous (in fact one would assume
the configuration fragment as specified wouldn't validate, because
there's no identifying attribute on the interface and the schema would
require one).
thanks,
Rob
On Tue, May 27, 2003 at 02:10:31PM -0500, Chen, Weijing wrote:
> Let's use a better example to illustrate the problem not just for
> "edit-config", but also for "get-config" (and merge, modify, replace, etc.)
>
> In the following,
>
> <ospf id="1">
> <area id="2">
> <interface>
> <adminStatus>"up"</adminStaus>
> </interface>
> </area>
> </ospf>
>
> Do we just get all the sub-elements of up interface (status equal "up"), or
> do we also get all the other sub-elements of ospf=1, and area=2 if they have
> up interface? With operation as attribute (not target as attribute), we can
> have:
> <ospf id="1">
> <area id="2">
> <interface operation="read">
> <adminStatus>"up"</adminStaus>
> </interface>
> </area>
> </ospf>
>
> for just sub-elements of interface.
>
> And
> <ospf id="1">
> <area id="2" operation="read">
> <interface>
> <adminStatus>"up"</adminStaus>
> </interface>
> </area>
> </ospf>
>
> for sub-elements of area=2 with up interface, and so on.
>
> The operation and its intended target need to be clearly stated to avoid
> ambiguity.
>
>
> --
>
> Weijing Chen
>
>
>
>
> > -----Original Message-----
> > From: Rob Enns [mailto:rpe@juniper.net]
> > Sent: Tuesday, May 27, 2003 12:32 PM
> > To: Chen, Weijing
> > Cc: netconf@ops.ietf.org
> > Subject: Re: do we need filtering or some such
> >
> > On Tue, May 27, 2003 at 11:11:05AM -0500, Chen, Weijing wrote:
> > > Rob wrote:
> > >
> > > > > <rpc id="101" xmlns="http://ietf.org/xmlconf/1.0/base";>
> > > > > <get-config>
> > > > > <source>
> > > > > <running></running>
> > > > > </source>
> > > > > <config xmlns="http://example.com/schema/1.2/config";>
> > > > > <users>
> > > > > <type>admin</type>
> > > > > **** <username/>
> > > > > </users>
> > > > > </config>
> > > > > <format>xml</format>
> > > > > </get-config>
> > > > > </rpc>
> > > > >
> > > > > for the attribue "username". However, there is problem with this
> > one:
> > > > what
> > > > > if there is another XML elements named "users" as in
> > > > > "/running/acme/level1/users" besides "/running/users"? What does
> > this
> > > > > "get-config" means? Which "users" is the "get-config" wants?
> > > >
> > > > You lost me here, why is this ambiguous? In other words, why would
> > > > the above get-config return a users element from somewhere other
> > > > in the configuration hierarchy than under /config? The target is
> > > > rooted at the root of the configuration hierarchy, so I don't believe
> > > > there's any ambiguity in this case.
> > >
> > > Do we have configuration hiearachy to distinguish "/config/users" and
> > > "/config/somewhere/users"?
> >
> > Yes, the idea is that the configuration data is an XML document
> > that can be specified with a schema or a DTD. If the document allows
> > /config/users, and /config/somwhere/users, it is not ambiguous to say:
> >
> > <config xmlns="http://example.com/schema/1.2/config";>
> > <users>
> > <name>foo</name>
> > </users>
> > <somewhere>
> > <users>
> > <name>bar</name>
> > </users>
> > </somewhere>
> > </config>
> >
> > as the argument to get-config to retrieve the foo user from /config
> > and the bar user from /config/somewhere.
> >
> > > If not, then we have an ambiguity. If yes, then
> > > besides "user" with type "admin" under "/config/users", do we also get
> > other
> > > elements possible under "/config"? Another ambiguity.
> >
> > Please be specific, what other ambiguity are you referring to?
> >
> > > (Also see Larry's ospf and md5 example in other thread.)
> >
> > Larry's issue was that there was no way to indicate if, for an
> > edit-config operation, the identifying elements in the hierarchy
> > should be created (ospf instance, area, neighbor, in the example), or if
> > the device should generate an error if they don't exist.
> > Phil has posted his thoughts on that issue and I concur.
> >
> > > In other words, what is the patten matching rule for intended operation
> > if
> > > operation is defined in outmost level? My argument is that if operation
> > is
> > > defined in the innermost level, then pattern matching rule will be no
> > > ambiguity yet simple.
> >
> > The intent of the draft is that the document provided as an argument
> > to get-config can identify the objects to be retrieved--this isn't
> > ambiguous as I explained above. It's not particularly complex either.
> > The advantages of this approach over specifying the target
> > as an attribute using xpath or other method were identified in
> > Phil's earlier message.
> >
> > thanks,
> > Rob
> >
> > >
> > >
> > >
> > > --
> > >
> > > Weijing Chen
> > >
> > > SBC Laboratories, Inc.
> > >
> > > 9505 Arboretum Blvd.
> > >
> > > Austin, TX 78759
> > >
> > > 512 372 5710
> > >
> > > wchen@tri.sbc.com
--
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/>