Re: [OPSAWG] Cleaning up the state of IPv6 MIBs

[t.petch <[e-mail]>]

----- Original Message -----
From: "Bill Fenner" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: "C. M. Heard" <[e-mail]>; "OPSAWG" <[e-mail]>; "IPV6"
<[e-mail]>
Sent: Wednesday, June 03, 2015 7:12 PM
> On Wed, Jun 3, 2015 at 3:07 AM, t.petch <[e-mail]> wrote:
>
> > The RFC long predate RFC4181, or indeed our guidelines for RFC in
> > general, so you are committing e.g. to tracking down the authors and
> > updating their contact details, into splitting the references into
> > Normative and Informative etc etc.

> No, I am not proposing republishing these RFCs.  I am proposing
> republishing the modules, with a simple wrapper saying why, in a
single
> document.
>
> See https://tools.ietf.org/html/draft-fenner-ipv6-mibs-obsolete, which
> contains all the modules I mentioned, with the STATUS changed to
"obsolete"
> and the DESCRIPTION updated with an explanation as required by
RFC2578.
>
> The change of status may be a single bulk edit but it changes many
many
> > lines in the module with the scope for introducing errors.
> >
>
> I have re-extracted the modules from my I-D and run "smilint" against
them,
> and it reports no errors (other than those in the original modules).
I
> also have reviewed the diffs that I created and published at
> http://fenner.github.io/ipv6-mibs-historic/ to try to catch any
> unintentional changes.
>
> > And any MIB Module is expensive in terms of IETF effort needed for
> > review by MIB Doctor, at Last Call, by ADs etc.
> >
> How much review is needed for "change status of this object to
obsolete and
> update the DESCRIPTION"?  The rules about making sure that MIBs are
good
> ideas to implement presumably don't apply to objects whose metadata
says
> "do not implement this object".

Mmm, I would not presume so.  Publish a MIB Module in an RFC and I would
assume that the rules for publishing MIB Modules apply, requiring
someone to smilint them etc.  Publish an RFC and again, there are
processes that the IETF and IESG follow, which cost.  Far simpler just
to declare a status change of the RFC; no RFC needed.

I did look at your I-D before my first post and, because it contains MIB
Modules, would not be surprised to see a number of objections along the
lines that it does not contain what is expected for an RFC containing a
MIB Module.

Tom Petch

>   Bill
>