Re: sub-tree filtering proposals

[Phil Shafer <phil@juniper.net>]

Juergen Schoenwaelder writes:
>> [...] Given that high-end devices are likely
>> to just pick up a full implementation (libxml2), the subset
>> will be broken day one.  Even then, the ability of the
>> device to implement arbitrary bits of XPath logic and
>> expressions will be an immense and changing burden.
>Please elaborate.

Here's a recent elaboration:

 >Message-Id: <200404082233.i38MX0BE011229@idle.juniper.net>
 >To: j.schoenwaelder@iu-bremen.de
 >cc: Andy Bierman <abierman@cisco.com>, netconf@ops.ietf.org
 >Subject: Re: Proposal to do away with netconf attributes in data model payloads 
 >In-Reply-To: Your message of "Thu, 08 Apr 2004 23:45:28 +0200."
 >             <20040408214528.GA1702@iu-bremen.de> 
 >Date: Thu, 08 Apr 2004 18:33:00 -0400
 >From: Phil Shafer <phil@juniper.net>
 >
 >Juergen Schoenwaelder writes:
 >>> >I think all approaches require changes to <get-config> retrieved data 
 >>> >to compose a meaningful <edit-config> arguments.
 >
 >I think the only change required is to add the 'operation="replace"'
 >attribute to the top-level element of the configuration tree returned
 >from <get-config>.
 >
 >>I do fail to understand why creating something new for all netconf
 >>boxes instead of subsetting XPATH only for small devices will at 
 >>the end be a winning situation. 
 >
 >Subsetting will lead to differing subsets.  You won't know what you
 >can do until you know what implementation you're talking to.  Unless
 >you believe users will restrain themselves and stay within the
 >defined subset.  
 >
 >Your other mail asked about the cost of xpath and why it's easier to
 >parse elements than xpath expressions.  I don't think there's much
 >difference between parsing the following:
 >
 >
 >(a)
 >  set interfaces so-0/0/0 unit 0 family inet address 10.1.2.3/24
 >
 >(b)
 >  <configuration>
 >    <interfaces>
 >      <interface>
 >        <name>so-0/0/0</name>
 >        <unit>
 >          <name>0</name>
 >          <family>
 >            <inet>
 >              <address> <!-- adding a new one -->
 >                <name>10.1.2.3/24</name>
 >              </address>
 >            </inet>
 >          </family>
 >        </unit>
 >      </interface>
 >    </interfaces>
 >  </configuration>
 >
 >(c)
 >  interfaces/interface[name='so-0/0/0']/unit[name='0']/family/inet/address[name='10.1.2.3/24']
 >  <!-- where 'name' is the only element name supported inside a predicate -->
 >
 >But there is an order of mangnitude difference in handling:
 >
 >  interfaces/interface/unit/family/inet[starts-with(../../../name, 'so-') and string-length(../../name) = 1]/address[substring(name,3) != '/24' and (not(@inactive) or disable)]
 >
 >If I subset most of xpath out of netconf-xpath, why use it?  Just
 >because slashes are more stylish that xml elements?  If we're making
 >an xml api, it makes no sense to prefer strings to real xml.
 >
 >The element sub-tree is a good match between what the device can
 >do easily and what the app writer needs.
 >
 >Also worth noting that the use of xpath implies that the intermediate
 >nodes already exist, which isn't always the case.  In JUNOS, we
 >effectively remove empty levels from the database when an empty
 >level would be meaningless, so a <delete> could remove levels that
 >were not it's target and a <create> that is depending on the existence
 >of that level would fail.
 >
 >I'm looking to make an API that contains the abilities of the CLI
 >so that we can stamp out screen scraping,  not to create new
 >technology that can be implemented six months after the MIB is
 >implemented (and twelve months after the feature ships).
 >
 >Thanks,
 > Phil

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