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

"ietfdbh" <ietfdbh@comcast.net> Thu, 04 June 2015 22:29 UTC

Return-Path: <ietfdbh@comcast.net>
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 09D561A1A9A for <opsawg@ietfa.amsl.com>; Thu, 4 Jun 2015 15:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.409
X-Spam-Level:
X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dtHFQtzQAYG1 for <opsawg@ietfa.amsl.com>; Thu, 4 Jun 2015 15:29:42 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6457E1A1A91 for <opsawg@ietf.org>; Thu, 4 Jun 2015 15:29:42 -0700 (PDT)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-05v.sys.comcast.net with comcast id cNVS1q0032D5gil01NVhsi; Thu, 04 Jun 2015 22:29:41 +0000
Received: from JV6RVH1 ([67.189.237.137]) by resomta-ch2-06v.sys.comcast.net with comcast id cNVg1q00U2yZEBF01NVgbn; Thu, 04 Jun 2015 22:29:41 +0000
From: ietfdbh <ietfdbh@comcast.net>
To: 'Bill Fenner' <fenner@fenron.com>, "'t.petch'" <ietfc@btconnect.com>
References: <CAATsVbY9Goh1r5w4_0y=m-97Kcsx97wOXGywkjuyOVLvmD_tkQ@mail.gmail.com> <Pine.LNX.4.64.1506022030170.5032@shell4.bayarea.net> <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> <CAATsVbbTXG1Uxv7H0HQ8pZivFSQm=HQZagW96ds1CCSNQwEBuQ@mail.gmail.com> <01e401d09ed0$c4d4a200$4001a8c0@gateway.2wire.net> <CAATsVbZMgYR9igetxdfkNQKjMW-Cd4E4xw1mENqEQm-ZX+fQow@mail.gmail.com>
In-Reply-To: <CAATsVbZMgYR9igetxdfkNQKjMW-Cd4E4xw1mENqEQm-ZX+fQow@mail.gmail.com>
Date: Thu, 04 Jun 2015 18:29:33 -0400
Message-ID: <060801d09f15$ef0312b0$cd093810$@comcast.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0609_01D09EF4.67F2F950"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJt5E4vBNJG2CNI7vFP2FXDwAvLtgI79WfJAvCvOjoCT0FVjgHZvHxtAWhEi52cDHFCUA==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1433456981; bh=4PmzcqwYnEZBo/+77xbtM3kv5yVi+uXom33qaSCUe4s=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=W3BC0qCUTMO/fVozE04U+KcC7hj6NsZDMJAIuO4L1jQn287HLOjf+34ckmR9E9txb UGkFUYjXq97Hfnu6sbF4Yzi1rnqX56befw9xauKiuL3gwqGhFJizTxMPXpm/Q1pSYW y82DL8AQU70AzJMJfBdw6neirlITUm8vnBZGjxV1/2Enzf+lsc2oWnKhKl2N9ND6IL nI2yIxThiITD7E4o/+sAcWx3AzL+oApPWSQSBDDCK5TGMZB+YlRALzubpWEqIgQ5Pp darZ9S+lsezDSGNIMDB+2f8Nkca0UMyDqkPtDgne6+y5VX0OTD2h+9lSi2fqnQ0Ica fuWM9kZIf41XA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/tl1FdLt7wgfId_AX2cI4Y4Xr9nI>
Cc: "'C. M. Heard'" <heard@pobox.com>, 'OPSAWG' <opsawg@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: Thu, 04 Jun 2015 22:29:44 -0000

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:ietfdbh@comcast.net> ietfdbh@comcast.net

+1-603-828-1401

From: OPSAWG [mailto:opsawg-bounces@ietf.org] 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

 

On Thu, Jun 4, 2015 at 7:14 AM, t.petch <ietfc@btconnect.com> wrote:

Far simpler just
to declare a status change of the RFC; no RFC needed.


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