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

t.petch <ietfc@btconnect.com> Wed, 03 June 2015 10:12 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341F11A0146; Wed, 3 Jun 2015 03:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 TZRiGhhbw1Br; Wed, 3 Jun 2015 03:12:27 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD0F1A0141; Wed, 3 Jun 2015 03:12:26 -0700 (PDT)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
Received: from pc6 (81.151.162.168) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 3 Jun 2015 10:12:10 +0000
Message-ID: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "C. M. Heard" <heard@pobox.com>, Bill Fenner <fenner@fenron.com>
References: <CAATsVbY9Goh1r5w4_0y=m-97Kcsx97wOXGywkjuyOVLvmD_tkQ@mail.gmail.com> <Pine.LNX.4.64.1506022030170.5032@shell4.bayarea.net>
Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs
Date: Wed, 03 Jun 2015 11:07:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: AM3PR03CA024.eurprd03.prod.outlook.com (10.141.191.152) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20)
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062;
X-Microsoft-Antispam-PRVS: <DBXPR07MB062A4A63C47CDDF08AB1319A0B40@DBXPR07MB062.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DBXPR07MB062; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB062;
X-Forefront-PRVS: 05961EBAFC
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(199003)(13464003)(24454002)(51444003)(189002)(14496001)(76176999)(50226001)(105586002)(81816999)(44716002)(19580405001)(189998001)(44736004)(42186005)(33646002)(19580395003)(61296003)(66066001)(64706001)(47776003)(116806002)(81686999)(50986999)(5001960100002)(87976001)(62236002)(1556002)(122386002)(40100003)(62966003)(77156002)(1456003)(5001860100001)(5001830100001)(84392001)(101416001)(86362001)(77096005)(15975445007)(92566002)(106356001)(50466002)(46102003)(68736005)(23756003)(4001540100001)(5001770100001)(97736004)(81156007)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2015 10:12:10.3497 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/7mLmlBkMpvNJpOF6vm73KEvzcys>
Cc: OPSAWG <opsawg@ietf.org>, IPV6 <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 10:12:30 -0000

---- Original Message -----
From: "C. M. Heard" <heard@pobox.com>
To: "Bill Fenner" <fenner@fenron.com>
Cc: "OPSAWG" <opsawg@ietf.org>; "IPV6" <ipv6@ietf.org>
Sent: Wednesday, June 03, 2015 4:42 AM
> 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.

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


> 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.)
> >
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg