Re: Proposal to do away with netconf attributes in data model payloads

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