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

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

On Mon, 1 Jun 2015, Bill Fenner wrote:
> 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: 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

---

From: t.petch <[email-masked]>
Date: Thu, 4 Jun 2015 15:14:10 +0100

----- Original Message -----
From: "Bill Fenner" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "C. M. Heard" <[email-masked]>; "OPSAWG" <[email-masked]>; "IPV6"
<[email-masked]>
Sent: Wednesday, June 03, 2015 7:12 PM

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

---

From: Bill Fenner <[email-masked]>
Date: Thu, 4 Jun 2015 14:57:41 -0700

On Thu, Jun 4, 2015 at 7:14 AM, t.petch <[email-masked]> wrote:

> Far simpler just

But it doesn't address my primary problem: if you look at a MIB repository,
you see a nice IPV6-MIB with lots of "STATUS current" objects, and you say
"Ah, cool, here are all the objects I need to implement for IPv6!".  I knew
going into this effort that "just reclassify things as historic" would be
one possible outcome, but I want to aim higher than that.

Despite outward appearances, the IESG is not an inflexible automaton; I
hope to be able to work with them to be able to come to agreement that this
is a worthwhile endeavor and need not be subject to the significant
scrutiny that a MIB module with implementable objects should be.  The first
step down that path is to publish my draft and say "this is what I'm
thinking it'll look like".

  Bill

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 4 Jun 2015 18:29:33 -0400

Hi,

As a MIB Doctor, and one who just worked with the Behave WG’s document to deprecate/obsolete the old NAT-MIB, I think it would be fairly simple to get Bill’s proposed changes through the process. As long as the only thing changing in the MIB is the status of the objects, that should be a slam dunk.

Publishing a new RFC has a few new wrinkles, mostly the legal stuff like copyright and permission from the original authors. But that should be fairly simple.

Just changing the status of the RFC really is not the right way to obsolete a MIB module, because MIB modules often are published separate from the RFC, and when a MIB module is imported into an NMS, the whole RFC is not imported, just the MIB module. It could be helpful to operators to see the current status of the relevant objects, which doesn’t happen in an NMS by re-categorizing the status of the RFC.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: OPSAWG [mailto:[email-masked]] On Behalf Of Bill Fenner
Sent: Thursday, June 04, 2015 5:58 PM
To: t.petch
Cc: C. M. Heard; OPSAWG
Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs

Far simpler just

But it doesn't address my primary problem: if you look at a MIB repository, you see a nice IPV6-MIB with lots of "STATUS current" objects, and you say "Ah, cool, here are all the objects I need to implement for IPv6!".  I knew going into this effort that "just reclassify things as historic" would be one possible outcome, but I want to aim higher than that.

Despite outward appearances, the IESG is not an inflexible automaton; I hope to be able to work with them to be able to come to agreement that this is a worthwhile endeavor and need not be subject to the significant scrutiny that a MIB module with implementable objects should be.  The first step down that path is to publish my draft and say "this is what I'm thinking it'll look like".

  Bill

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 4 Jun 2015 15:44:30 -0700 (PDT)

On Thu, 4 Jun 2015, ietfdbh wrote:
> Just changing the status of the RFC really is not the right way to 
> obsolete a MIB module, because MIB modules often are published 
> separate from the RFC, and when a MIB module is imported into an 
> NMS, the whole RFC is not imported, just the MIB module. It could 
> be helpful to operators to see the current status of the relevant 
> objects, which doesnÿÿt happen in an NMS by re-categorizing the 
> status of the RFC.

Exactly.

//cmh