Subject: Cleaning up the state of IPv6 MIBs

From: Bill Fenner <[email-masked]>
Date: Mon, 1 Jun 2015 14:47:01 -0700

Hi,

I've just published
https://tools.ietf.org/html/draft-fenner-ipv6-mibs-obsolete-00 , whose goal
is twofold:

1) Explicitly change the status of RFC2452 (IPV6-TCP-MIB), RFC2454
(IPV6-UDP-MIB), RFC2465 (IPV6-TC, IPV6-MIB), and RFC2466 (IPV6-ICMP-MIB) to
Historic.  They are currently Proposed Standard, Obsoleted by the newer
(2005) version-independent IP-MIB, UDP-MIB, TCP-MIB and IP-FORWARD-MIB.
 (Oddly, RFC2454 is already Historic, but the others remain PS.)

2) Publish the MIBs with the "STATUS" field changed from "current" to
"obsolete". Many MIB repositories are simply populated from the newest RFC
containing a given MIB, so since the original RFCs with their "STATUS
current" remain in place, there is no signal when simply looking at the
MIBs that the IETF has moved in a different direction.

The end goal is to make it more clear that the IP version independent MIBs
are the ones to use.

Since the ipv6 wg published the IP version independent MIBs originally, I
thought that 6man would be an appropriate home for this update.

Your thoughts and comments would be appreciated.

  Bill

(While composing this email, I realized that I accidentally omitted RFC2466
from the list in the document; I'll fix this before the next revision.)

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 2 Jun 2015 20:42:41 -0700 (PDT)

Hello Bill,

My guess would be that the only reason for not republishing these 
MIB modules as obsolete was the work involved, but since you have 
shouldered the burden, it seems to me like a good thing.  That said, 
I am by no means sure that everyone would agree :-)

As for venue, it seems to me that opsawg is arguably more appriate 
than 6man, so I have cc:'d that WG.

I would like to make two small suggestions on the document itself:

- please change the occurrences of "Deprecating this MIB" to 
  "Obsoleting this MIB module" in the REVISION clauses (and if it's 
  not too much trouble, try to hunt down any other occurrences of 
  "this MIB", "these MIBs" etc. and change them to "this MIB 
  module", "these MIB modules", and so on.

- it seems that it would be a good idea to have the metadata for the 
  four obsolete RFCs indicate that they are obsoleted by the RFCs 
  containing the replacement MIB modules AND this document as well, 
  changing section 7 to something substantive that would remain.

Mike Heard

---

From: t.petch <[email-masked]>
Date: Wed, 3 Jun 2015 11:07:54 +0100

---- Original Message -----
From: "C. M. Heard" <[email-masked]>
To: "Bill Fenner" <[email-masked]>
Cc: "OPSAWG" <[email-masked]>; "IPV6" <[email-masked]>
Sent: Wednesday, June 03, 2015 4:42 AM

Bill

I am not a fan of this work.  I think that it will cost more than it
benefits.

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.

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.

And any MIB Module is expensive in terms of IETF effort needed for
review by MIB Doctor, at Last Call, by ADs etc.

So by all means change the status of the RFC but open up a MIB Module,
no, not worth is.

Tom Petch

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Bill Fenner <[email-masked]>
Date: Wed, 3 Jun 2015 11:12:24 -0700

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

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

> 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".

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Wed, 3 Jun 2015 12:36:38 -0700

On Tue, Jun 2, 2015 at 8:42 PM, C. M. Heard <[email-masked]> wrote:

> shouldered the burden, it seems to me like a good thing.

That was my hope :-)

>   That said,

Thanks; that hadn't occurred to me.

>   module", "these MIB modules", and so on.

Sure, thanks for the correction.

>   changing section 7 to something substantive that would remain.

I'm fine with changing section 7 to something that would remain (I wrote it
that way because I thought that we would have a companion document for the
reclassification, but I realized later that procedure is to be used when
you *don't* have another document to use).  However, are you sure it'd be
useful for this document to be referred to in the RFC index for the
historic RFCs?  It seems like it'd just add a level of indirection, since
this document says "go see the other RFC4xxx documents".

  Bill

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 3 Jun 2015 12:40:51 -0700 (PDT)

> this document says "go see the other RFC4xxx documents".

I think it would be useful, since it would allow the metadata to say or imply 
"go see RFCxxxx for the current version of these MIB modules."

//cmh