[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: review for: draft-ietf-ospf-mib-update-09.txt [wasRE: PRELIMI NARY Agenda and Package for April 13, 2006 Telechat ]



On Sun, 9 Apr 2006, Wijnen, Bert (Bert) wrote:
> Yes, but I believe those are all because this is basically an
> update to the old (SMIv1) RFC1850 MIB module.

Actually, RFC 1850 contained an SMIv2 MIB module, but that was
itself an update to RFC 1253 (which did contain an SMIv2 MIB module.

> Adding some text to indeed explain that so that one does not get
> the wrong impression when trying to compile, that would be
> usefull.

I agree that some ASN.1 comments along the lines of those in (e.g.)
RFC 3895 would be a Good Thing for the readable index objects.

For the non-reverse-mappable notifications there is already Section
4.7, "Translating Notification Parameters".  While its contents are
technically correct, I'm not entirely satisfied with it, because it
fails to clearly state the consequences, namely that a trap
originated from a V1 agent won't be converted into the same thing
that a native V2 or V3 agent would emit.  A short paragraph at the
end of the section spelling this out would be helpful IMHO.

There was a similar problem with the recent update to the BGP MIB
but that case was different since the traps were originally defined
in the SMIv1 version of the MIB module and were incorrectly
translated into the initial SMIv2 version.  This was corrected in
RFC 4273.  I don't think that would be appropriate here;  I think
the choices would be to obsolete all the existing notification
definitions and make new ones that comply with the translation
rules, or else to leave the definitions alone and clearly note the
limitations (which is what I suggested above).

Mike