Re: comments on version 2 of protocol draft

[Bobby Krupczak <rdk@krupczak.org>]

Hi!

> It is not how big and complex the messages are. Having faster communication
> channels does reduce latency, but doesn't reduce the costs of buffers
> and computational costs. Remember, a manager supports multiple managed
> systems. You don't want to significantly reduce the number of systems
> that a manager can support. It's the total costs, not just the
> communication cost between a manager and one managed system.
> So, it's not just the bandwidth. Also, as Wes points out, there
> are fixed costs with developing the software and on going costs
> with running the software. (And ongoing costs maintaining and 
> extending the software.) The hard part is making choices so that
> the results are acceptable even when there is not "perfect
> knowledge" on the costs and usage! That is, the ideal approach
> would be self stabilizing. 

Oh yeah, forgot to mention.

Memory is virtually free these days as well.  :)

I'm all in favor, as a protocol designer, of using computational
resources to offset human deficiencies (e.g. lack of memory,
confusion, etc.)

Arguing over a few bytes here and there seems pretty silly.

As a long-time programmer, I just do not understand the
quantification-arguments you and Wes are making.  I do not feel that
taking away defaults and making us specify things explicitly has any
statistically significant impact on the applications we are
developing.  It only makes them clearer, easier to read, and easier to
understand.

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