Subject: [netmod] All Powerful <get> operation (was: Re: capabilities related edits)

From: Phil Shafer <[email-masked]>
Date: Tue, 15 Sep 2009 15:59:55 -0400

Andy Bierman writes:
>I want the <get> function to still get everything.

This is mostly unrelated to YANG, but .....

I just can't understand why one would want an operation that returns
add known data.  It's like having "cat" spit out all files on every
file system.  It's like having "ls" do "ls -lR /" by default.  It's
worse because it's both of those, since files and directories are
data on the device.  Does <get> return file contents?  Does it
return /dev/mem and /proc/*/mem?  If it gets everything, how can
it possibly be useful?  Operationally, this would be a disaster.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Sep 2009 13:37:08 -0700

> it possibly be useful?  Operationally, this would be a disaster.

If I used <get> without XPath filters,
then I would agree with you.

Since the application is already required to have
perfect knowledge of the YANG data model to use the
NETCONF protocol, then <get> 'too much' is already a non-factor.
The application knows what to get and what to ignore,
if there is any 'extra' data in the reply.

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 15 Sep 2009 16:36:26 -0400

>then I would agree with you.

So you see <get> as good, but only if filtered?  Should we have an
error if get is not filtered?  Should the filter parameter be
mandatory?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Sep 2009 13:57:32 -0700

> error if get is not filtered?  Should the filter parameter be

Is there some point to all these absurd strawman proposals?

There is already a 'too-big' error-tag the server can use
if it wants.  If the clients wants /interfaces and gets everything,
then so what?  It's the client's fault the 'extra' work
was done for nothing.  This is no different than the continuous
MIB-walks that some SNMP applications use as a polling mechanism.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Sep 2009 23:22:35 +0200 (CEST)

> MIB-walks that some SNMP applications use as a polling mechanism.

I agree with Andy.  Don't add well-meaning CLRs to <get>.  Use too-big
on the server if you can't stream the data, or if you believe you know
better than the client :)

/martin

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 16 Sep 2009 07:00:01 -0700

>>>>> On Tue, 15 Sep 2009 15:59:55 -0400, Phil Shafer <[email-masked]> said:

PS> I just can't understand why one would want an operation that returns
PS> add known data.  It's like having "cat" spit out all files on every
PS> file system.  It's like having "ls" do "ls -lR /" by default.

FYI, I agree with you.  But with a caveat.  Operationally people really
do those sorts of things to determine what's on the device.  Tell me
you've never heard of an operator doing a complete snmpwalk of a device
to look for data.

I think one of things you hit on, is that there is no "find / -type d"
equivalent, which would be helpful.  One of the biggest reasons that
people walk an entire device, for example, is determine what it's
capable of.  In netconf you have capabilities to report some things, but
that doesn't necessarily report the actual data that a given capability
puts in place.  EG, a capability could report "foo.yang" (it's a bad
name, I know) but an operator doesn't know that translates into "/bar"
and "/baz".

So the result is that if all they have is <get> to get literally
everything, I can assure you it will be used as a discovery mechanism.
Regardless of whether it's right to do so or not.  It's being done today
in SNMP.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Phil Shafer <[email-masked]>
Date: Wed, 16 Sep 2009 09:55:46 -0400

Wes Hardaker writes:
>EG, a capability could report "foo.yang" (it's a bad

Yup, you'd need to retrieve the YANG modules to know about
/bar and /baz.

>Regardless of whether it's right to do so or not.  It's being done today

Yup.  Not something I'd like to see repeated in NETCONF.  We have
a discovery mechanism and people should use it.

Thanks,
 Phil

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 16 Sep 2009 09:13:14 -0700

>>>>> On Wed, 16 Sep 2009 09:55:46 -0400, Phil Shafer <[email-masked]> said:

PS> Yup.  Not something I'd like to see repeated in NETCONF.  We have
PS> a discovery mechanism and people should use it.

Sadly, the number one reason I've seen people doing this is to discover
device features that aren't documented.  Operators who are trying to
hack something together quickly will go digging through data for the
value they're looking for, figure out which OID it's in and then see if
they can modify it via a SET or at least monitor it.

Note that no where in that did common situation they go pull a MIB to
look at the definition (or they often will *after* they're pretty sure
they found the right spot).  This is primarily because they likely don't
have the MIBs in front of them, don't know what device supports even if
they did.  It's actually easier to search through the data and then use
that to find the MIB.  I strongly doubt this will change with the
invention of yang unless netconf.  Functionally operators, whether we
like it or not, rely heavily on a "search" feature that is tied to the
data.