RE: do we need filtering or some such

["Chen, Weijing" <wchen@tri.sbc.com>]

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