Subject: [Netconf] comments on draft-zhang-netconf-subtree-00

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Mar 2009 09:38:24 -0800

Hi,

I just read this draft that was recently published.
It seems the NETCONF WG will revisit the question: subtree or XPath?

The WG decided when RFC 4741 was published that XPath was
the future, and it would not be a good idea to reinvent
XPath, in the form of complex subtree filtering.

Although this advanced subtree filtering solution is simpler
than XPath 1.0, it is also much more limited in capabilities.
XPath is also an established standard outside of NETCONF,
which is quite important.

IMO, the better long term plan is to make :xpath mandatory.

The fact that data retrieval is not the core function
of NETCONF was one of the significant factors when
deciding :xpath filtering should be optional.
However, XPath is now used in the 'instance-identifier' built-in type,
and partial-locking.  Access control will almost certainly
be instance-identifier based (plus optional full XPath) as well.

Most importantly, the limitations of subtree filtering have
a significant impact on data model design.  It doesn't
work on nested containers or lists, unless the filtering
criteria is within direct children of the desired 'table entry' node.
This fatal flaw forces data to be 'flattened' into a 2-d table,
losing all the advantages of NETCONF/YANG to mirror native structures
in the agent.

E.g., try to construct a subtree filter to
retrieve just the <candidate/> configuration entry in the
netconf-state data model. You can't.  Here is the XPath to do it:

   /netconf/configurations/configuration[name/candidate]

IMO, subtree filtering should be deprecated, not developed further.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Mar 2009 15:43:42 -0500

>IMO, the better long term plan is to make :xpath mandatory.

Sure and IMO, an even better long term plan is to make :candidate
mandatory.  Or a plan to make :junos manditory.  ;^)

Seriously, the point of NETCONF is that we have flexibility and
expressiveness.  Devices are not all forced into one grand universal
model and are not forced to lie when we tell clients that we are
something we aren't.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Mar 2009 13:11:13 -0800

> model and are not forced to lie when we tell clients that we are

Not sure what these comments are supposed to mean.
XPath is the standard path language for XML.
It is far superior to subtree filtering.
It is also widely deployed.

Reinventing the features of XPath in a NETCONF-only solution
seems like a low priority item which goes against the
whole "use off-the-shelf XML tools" goal.  Let alone
the whole "Not Invented Here" thing.

I don't see what :candidate or :junos has to do
with this issue.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Mar 2009 17:28:28 -0500

>Not sure what these comments are supposed to mean.

Sorry for not being clear.  My point was that while you view xpath
as better, this isn't a universal view.  If I like :candidate, that
doesn't mean that everyone will.  Trying to force the rest of the
world into your favorite pattern is not good.

>It is far superior to subtree filtering.

This is a blanket statement.  I find subtree far superior for my
needs.  We can debate this, but changing 4741 to make :xpath mandatory
because you like it is a non-starter imho.

>It is also widely deployed.

My guess is that subtree filter is more widely deployed,
but I'll admit it's just a guess.  Juniper's been shipping
it since 2001.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Mar 2009 14:55:02 -0800

> because you like it is a non-starter imho.

I never said I wanted to make :xpath mandatory now.
It was the intent of the WG (at the time) to revisit
the :xpath issue in the future to see if it was universal
enough to be mandatory.  I agree with you that it
should remain optional for the foreseeable future.

It is fine to leave subtree filtering alone and work
on more important things, like the current charter.
New work on NETCONF-only solutions to solved problems
like XML instance document filtering is not a good use
of resources.

> but I'll admit it's just a guess.  Juniper's been shipping

XPath is used outside of NETCONF, and I bet XSLT usage
dwarfs NETCONF usage by a huge margin.

Andy