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 >