[e2e] Port numbers, SRV records or...?

[John Day]

At 11:52 -0400 2006/08/07, Craig Partridge wrote:
>In message <a0623091dc0fcec9f35de@[10.0.1.12]>, John Day writes:
>
>>they do in IP.  Realizing that applications and application protocols
>>were distinct, etc. CMIP was more powerful and yielded smaller
>>implementations than SNMP, (although HEMS would have been better than
>>either one) etc.  But as I say, it still wasn't right.
>
>[Aside -- smaller isn't always better, though it is often a hint.
>Recall, SNMP launched because, at the start, it was smaller than CMIP/HEMS.
>One issue was that SNMP left out functions that CMIP/HEMS anticipated
>were needed.]

Not really.  I believe you once told me that HEMS was smaller than 
SNMP and another source which is very reliable has told me that CMIP 
is smaller than SNMP, primarily because it takes less code to 
implement scope and filter than lexicographical order.  Which I can 
believe.

Also, by the late 80s we had enough experience with the IEEE 802 
management protocol to know that the SNMP approach was too simple. Or 
as I usually said, it was so simple it was too complex to use.

>Speaking of bandaids, paradigm problems and the like, pardon me while I
>toss a pebble into the pond.  I think, in network management, we're
>in danger of institutionalizing MIB variables for another generation
>of technology (perhaps calling them "objects", but same deal).
>
>Yet when faced with things that are, fundamentally, collections of
>software dip switches, I note that we seem to have no nice elegant
>programming paradigm that allows us to create abstractions that hide
>these switches (rather than expose them as 1,000s of MIB variables).
>The knowledge plane was an attempt to create something intelligent
>that mediated between this miasma of data and the typical clients that
>want to know what is happening (with only selected squalid details).
>But I keep wondering if there's a better paradigm for those virtual
>dip switches.
>
>And I think this problem is orthogonal to the other problem in network
>management -- namely that we still have silo-based management environments
>(e.g. ops different from install different from maintenance...).  Though
>if we had a paradigm that solved both it would be nice.

I completely agree.  The MIB structures we have come up with do not 
have enough commonality.  Not only does lead to the 1000s of MIB 
variables, but there is no way to impose consistent behavior on the 
network.  To do that we need commonality.  We actually did this at 
Motorola in the late 80s. We had a common MIB structure where 
probably 75% of the MIBs for a wide range of devices (everything from 
T-1, LANs, routers, and old stat muxes) was common.  But we couldn't 
get them to allow us to submit to the standards organizations.

But vendors don't want commonality across devices.

Take care,
John