Re: comments on version 2 of protocol draft

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

A few observations about defaults (which are hopefully
just reminders)....
1) if the defaults change between versions of system software
   (or the defaults on models in a product line are different),
   then you get unexpected changes of behavior
2) if "defaults are required" (that is, you don't have defaults),
    then you have to figure out interoperability between old
    mgmt apps and new managed systems!
3) if you allow defaults to be "templated" (or made into rich
    policy with expressions and procedures), it can help the
    differences between the instances stand out. It can also
    make your system "unstable", since a single change can affect
    many instances
4) don't confuse default values with initial values (people do this
    all the time in SNMP object type definitions)
5) Its good to be able to retrieve the default values
6) Its good to be able to retrieve the complete set of
    attribute-value pairs for an instance, and to retrieve
    only the attributes-value pairs whose values were set
    explicitly

At 11:01 AM 3/3/2004 -0800, Wes Hardaker wrote:
>>>>>> 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)
Regards,
/david t. perkins 


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