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

"C. M. Heard" <heard@pobox.com> Wed, 03 June 2015 03:42 UTC

Return-Path: <heard@pobox.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6EE1B3361 for <opsawg@ietfa.amsl.com>; Tue, 2 Jun 2015 20:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level:
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wYE2wNh1DOT for <opsawg@ietfa.amsl.com>; Tue, 2 Jun 2015 20:42:55 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD031B3366 for <opsawg@ietf.org>; Tue, 2 Jun 2015 20:42:54 -0700 (PDT)
Received: (qmail 8678 invoked from network); 2 Jun 2015 20:42:41 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Jun 2015 20:42:41 -0700
Date: Tue, 02 Jun 2015 20:42:41 -0700
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: Bill Fenner <fenner@fenron.com>
In-Reply-To: <CAATsVbY9Goh1r5w4_0y=m-97Kcsx97wOXGywkjuyOVLvmD_tkQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1506022030170.5032@shell4.bayarea.net>
References: <CAATsVbY9Goh1r5w4_0y=m-97Kcsx97wOXGywkjuyOVLvmD_tkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/9EuzlS4toihvST_VThh-wXAx8NU>
Cc: OPSAWG <opsawg@ietf.org>, IPV6 <ipv6@ietf.org>
Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 03:42:56 -0000

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