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

[Brian E Carpenter <brian@hursley.ibm.com>]

Hi,

Given that we have conceded the point for the diffserv MIB, may I
politely suggest that this conversation belongs on some ops&management
list?

   Brian

Fred Baker wrote:
> 
> 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?