Re: comments on version 2 of protocol draft

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Wed, 3 Mar 2004 13:44:24 -0500, Bobby Krupczak <rdk@krupczak.org> said:

Bobby> If you do the math, passing a few extra parameters (instead of
Bobby> default) hardly constitutes an increase in bandwith and
Bobby> computation.

Please, do the math.  Write it up and send it to the list.  Take a
case where half of the parameters can be left out for a given
configuration data set because they match the defaults that are likely
to be there.

Are there cases where defaults would rarely be used?  Certainly, this
is why they're left out of some MIB objects, for example, because
there isn't a good value to pick from.

Picking an example at random, the ipCidrRouteTable from SNMP contains
the routing table (I actually wasn't even sure till I looked that it
contained a suitable set of default values).  There are defaults for
ifIndex, route age, next hop as, and the 5 metrics...  Thats roughly
half the columns.  How often have you needed to specify all 5 metrics
when defining a new route.  If you send every new route entry with all
the parameters, I bet you'd find that you'd roughly double your data
since many of those parameters to most frequently be the default.  Go
look at a real existing large routing table and do the math on it and
let me know what you get numerically.

Bobby> A few extra characters in a message is really just roundoff
Bobby> error.  In order for extra bandwidth to be meaningful, you'd
Bobby> have to at least double the message sizes.

Agreed.  I'm thinking what you're proposing will double the message
size in many cases, if not worse.

Bobby> In terms of parser complexity, I do not feel removing defaults greatly
Bobby> increases parser size nor computation.

FYI, I wasn't talking about complexity.  I was talking about
computational cycles in a parsing of a completely full message.

One is an assignment.  You're arguing that this:

  int routemetric1 = -1;

is equal in speed to this:

  int routemetric1 = xml_parse("<routemetric1>234234</routemetric1>");

I don't buy that.

Bobby> What we get is clearer, easier to read/understand specs (and
Bobby> resulting code) and we pay little if anything for it in
Bobby> bandwidth/computation/size.

BTW, we're not talking about the specs.  You mean clearer and easier
to read data passing on the wire.  I'd disagree, but hey.  I like
seeing only the relevant data.  A config file that has only the config
parameters for how something is configured is easier and faster for me
to read (and the CPU, for that matter) than one which contains every
parameter possible in it.

>> I'm more and more convinced daily that netconf will never be a generic
>> configuration protocol suitable for most environments.  It's targeting
>> itself at a small subset of device types, which is disappointing in my
>> mind.  I was really hoping it would be able to meet the criteria from
>> multiple, different camps.  That's my naivety showing through I guess.

Bobby> That, however, is not the point of debate over the issue of defaults
Bobby> or not.

(actually, they were very related but I won't argue it further)

-- 
"In the batht

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