RE: Re: Draft-iet-bridge-bridgemib-smiv2-09.txt

"Wijnen, Bert (Bert)" <[email protected]> Wed, 26 Jan 2005 01:16:45 +0100
Newsgroups gmane.ietf.bridge
Message-ID <7D5D48D2CAA3D84C813F5B154F43B15506497707@nl0006exch001u.nl.lucent.com>
> Juergen Schoenwaelder wrote:
> Sent: Wednesday, January 26, 2005 00:12
> To: David B Harrington
> Cc: 'C. M. Heard'; 'Bridge-Mib (E-mail)'
> Subject: Re: [Bridge-mib] Re: Draft-iet-bridge-bridgemib-smiv2-09.txt
> 
> 
> On Tue, Jan 25, 2005 at 04:41:35PM -0500, David B Harrington wrote:
> 
> > > (a) the text in Sections 3.2 was adapted from the original 1493 but
> > > now points to RFCs 3418 and 2863.  As a result it is now inaccurate.
> > > Details were spelled out in previous e-mail responses to Juergen.
> > > If you wish to leave the prerequisites exactly as they were in 1493
> > > then you should probably revert to referring to RFC 1213.  If you
> > > want to leave the references to 3418 and 2863 then please do
> > > something to fix the inaccuracies, particularly in 3.2.2.
> > > 
> > After reviewing the discussion more closely, I agree. 
> > This text should refer to RFC1213 for backwards compatibility.
> > 
> > There is no MODULE-COMPLIANCE in RFC3418 that appropriately reflects
> > RFC1213 compliance.
> > The same appears to be true for RFC2863.
> 
> I personally hate to see this SMIv2 proposed standard version of the
> BRIDGE-MIB depend on RFC1213. So if the current text is not good
> enough, I would rather prefer to work through the details to come
> up with text that says what we believe RFC 1493 did say, but referring 
> to the current MIB modules we have. In the worst case, we list all 
> the IF-MIB/SNMPv2-MIB objects that we believe were meant when RFC 
> 1493 was written. We may add a note that the IF-MIB/SNMPv2-MIB
> have evolved and that compliance to the current IF-MIB/SNMPv2-MIB may 
> require the implementation of additional objects but doing so is not 
> mandated by the BRIDGE-MIB itself.
> 

I agree with Juergen and would prefer that we try to do so.
At some point it would be good to get rid of normative 
dependecies on RFC1213. I think we have an opportunity to 
help work towards that goal here, and we can do so relatively
easy in this case as Juergen proposes.

Bert
> /js
>