Re: comments on version 2 of protocol draft

[Bobby Krupczak <rdk@krupczak.org>]

Hi!

> I suspect we'll need to agree to disagree, as our definitions of clear
> and understandable are not the same.  Our definitions of usable are
> not the same either, because in your environment and applications you
> don't have a problem with increased bandwidth and computation.  Your
> environments probably have fewer boxes than mine do, and have less
> bandwidth constraints.

If you do the math, passing a few extra parameters (instead of
default) hardly constitutes an increase in bandwith and computation.
Seriously.  A few extra characters in a message is really just
roundoff error.  In order for extra bandwidth to be meaningful, you'd
have to at least double the message sizes.

In terms of parser complexity, I do not feel removing defaults greatly
increases parser size nor computation.  If an argument is not
specified, you still need code and logic to spec its default.  Whether
the logic/computation is in the parser or in your application code is
arbitrary to the overall size/complexity issue.  We're really not
taking about anything significant which is my point.  What we get is
clearer, easier to read/understand specs (and resulting code) and we
pay little if anything for it in bandwidth/computation/size.

If you could better quantify your arguments, I guess my tiny brain
would have an easier time understanding the size/complexity/bandwidth
argument.  I actually worked the math here on the back of an envelope
and found the differences to be virtually zero.

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

That, however, is not the point of debate over the issue of defaults
or not.  I have doubts about the number and type of transport mappings
as a barrier to interoperability but thats an argument for the next
round of discussions :)

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