Re: DS MIB - please review this list...

[Fred Baker <fred@cisco.com>]

At 12:25 PM 2/28/2001 -0500, Michael Daniele wrote:
>1. requiring an smi and snmp version rev to implement generic addresses
>in MIBs, is probably not a reasonable software engineering decision.

I'll give you that one. I'm the guy (or at least one of them) who suggested 
it be a TC, and for that reason.

>2. working within the existing smi, the stricture you object to is a better
>design than not having it. (if for no other reason than it can be completely
>and unambiguosly documented in one place, as opposed to within each
>MIB module that uses it).
>
>i never received a reply from you on either of these points.

I don't see, in this statement, much of an argument. It responds to none of 
the points I made, and the points I made are at least an equally strong 
argument. You said is "I like having the stricture better than not having 
it". So? If I pass a law requiring the wearing of blue boots on Sundays, 
does the fact that the law is written in one place make it a good law? 
Shouldn't the argument be based on some improvement that the law makes?

Talk to me about "defined in every MIB module"? Every MIB that we now have 
is internally defined, and that seems to work. TCs like RowStatus are 
defined in one place and used uniformly, but they relate only to individual 
objects. Having something that makes a requirement of every MIB design 
using and crossing two objects is highly unusual, and is different from 
every other MIB design. This is going to be inherently problem-free? I 
doubt it.

If the TC had said that "every Entry that uses an InetAddress must also 
define an InetAddressType", that would have been a no-brainer. It would 
have covered this case, also, in which there are two InetAddresses that 
*cannot*, even conceptually, differ in type, because the entry is applied 
to IPv4 and IPv6 headers, which always have two addresses and the two 
addresses are always of the type indicated by the type of header. Having it 
say "there must be a separate InetAddressType for each InetAddress, and by 
the way it has to have a certain number in the entry" adds additional cruft 
that produces no obvious benefit. Explain to me why (as in, answer the 
argument I made, rather than simply trying to nullify it) when the reason 
there are two InetAddress objects in an entry for the purpose of describing 
either an IPv4 or an IPv6 header, having two InetAddressType objects, and 
specifically having them located numerically before the InetAddresses, 
produces a benefit?

You made "an absolute requirement of the specification", but you didn't 
support it with a reason. Now that somebody is using it, the stated reason 
("I think it's better") doesn't obviously hold water, unless you can 
enumerate why it is actually better. I'm looking for what is better about it.

I guess I would ask for implementations - how many applications do you know 
that use this hack, as compared to the number that do it in the usual way?