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

[Michael Daniele <mwdaniele@adelphia.net>]

Fred Baker wrote:

> At 04:20 PM 2/28/2001 +0100, Wijnen, Bert (Bert) wrote:
> >I strongly recommend that we go with the rules (the MUSTs)
> >as specified in RFC2851.
>
> I have changed the next dsmib draft accordingly
>
> >However, if you really do not want to go with those
> >rules... then we should have a debate on the mibs mailing list
> >to get the rules changed and specify the situations in which
> >such rules may be ignored.
>
> I have attempted to have that debate. Sound computer science does not
> appear to be relevant. What I got back incorporated a distinct
> non-understanding of the format and construction of IP headers, and used as
> a centerpiece of its logic "is this so terrible?". I was hoping for an
> actual discussion; that debate didn't happen.
>

the single line, "is this so terrible?" that i wrote, was in the specific
context of the number of additional sub-identifiers required
by the requirement of using 2 InetAddressTypes instead of 1, within
the 6-tuple defined in a specific MIB.

that is the only adverse affect i can see of the stricture in 2851, which is
what you seemed to be objecting to.

i would appreciate it if you would not deliberately misrepresent
what i wrote.

the "centerpiece" of my argument was that:

1. requiring an smi and snmp version rev to implement generic addresses
in MIBs, is probably not a reasonable software engineering decision.

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.

not much of a debate...

anyway, what bothers you the most is obviously the decision to remove
NetworkAddress from the SMI 10 years ago.  i'm not interested in
having a debate about that.

i suggest you have Bert add this specifically to the eos WG's charter.

i personally agree that we should update the SMI in many ways.
it was for that reason that several of us (juergen included) argued that
SNMPv3 should be able to handle new PDU types and SMI versions.

that did not happen.