Re: do we need filtering or some such

[Rob Enns <rpe@juniper.net>]

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