Re: comments on version 2 of protocol draft

[Bobby Krupczak <rdk@krupczak.org>]

Hi!

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

It may indeed double for your example.  However, the increase in
bandwidth (I feel) hardly justifies the extra coding complexity of
detecting absence of arguments and then filling in defaults.

In the netconf draft, the defaults did not reach half of the arguments
(at least that I can come up with).

I do not see the point in further arguing over the topic.

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

In the netconf spec, I do not believe the defaults are half the args.  

I'll go out on a limb and say that even if we double the message size,
I do not feel that is meaningful in the grand scheme of things.

In all the coporate networks that I sold software into, very few if
any were concerned about utilization percentages anymore.  Their
concerns were on complexity, maintainability, debugging,
troubleshooting, etc.

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

The parsers really are not all that bad.

The beauty of the parsing defaults, is your xml parser (or BER, PER,
XDR) *still* has to have the code to decode the statement if its
present.  See what I mean?  If the code already is there, then you
dont gain much -- you still have the size and you still have to jump
over it.  Plus, CPU cycles are soooo cheap these days.

> BTW, we're not talking about the specs.  You mean clearer and easier
> to read data passing on the wire.  

I'm talking abouut all -- specs, data on wire, code, etc.

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

You have a much better memory than I do.

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

I dont see how but we can certainly talk about that offline if you'd
like.  Do you think to-default or not to-default would make the spec
more widely or less widely deployed?  I dont think this issue will
effect adoption.

Thanks,

Bobby

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