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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Sunday, April 09, 2006 23:19
> To: Wijnen, Bert (Bert)
> Cc: Romascanu, Dan (Dan); Bill Fenner (E-mail); Mreview (E-mail)
> Subject: 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.
> 

OK,OK, 1850 was more SMIv2 like, although I would not really call it 
an SMIv2 MIB. I guess that was caused by the fact that it was based
on (i.e. an update to) RFC 1253. I am somewhat surprised how you can
say that RFC1253 contains an SMIv2 MIB module and would like to 
understand why you think that.

But the summary is that the new document in fact is still an update
(so not a rewrite) of some very old MIB work and so for compatibility
reasons and for (I assume) existing deployment, we are prepared to
accept the module as is (preferably with some additional explanations
as to why things are as they are, so we do not have to have this
discussion again at the next update). If this were a new MIB module, 
we would bark quite badly at it.

Bert
> > 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
>