Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt

"Tom Petch" <nwnetworks@dial.pipex.com> Fri, 18 March 2005 09:47 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14325 for <ccamp-archive@ietf.org>; Fri, 18 Mar 2005 04:47:16 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCE91-0006fJ-5K for ccamp-archive@ietf.org; Fri, 18 Mar 2005 04:51:51 -0500
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCDs7-000K0l-SI for ccamp-data@psg.com; Fri, 18 Mar 2005 09:34:23 +0000
Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCDs6-000K0F-M8 for ccamp@ops.ietf.org; Fri, 18 Mar 2005 09:34:22 +0000
Received: from pc6 (1Cust238.tnt2.lnd4.gbr.da.uu.net [62.188.131.238]) by astro.systems.pipex.net (Postfix) with SMTP id 50F3EE00021A; Fri, 18 Mar 2005 09:34:13 +0000 (GMT)
Message-ID: <000e01c52b94$e310a440$0601a8c0@pc6>
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6>
Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Fri, 18 Mar 2005 09:29:40 +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-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit

This MIB contains several 'enumerations' except they are not enumerations but
text in
DESCRIPTION clauses  -  gmplsTunnelGPid gmplsTunnelSwitchingType
gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference.  So these are
not defined anywhere in SMI; and as this points out, these values will be added
to in future RFC.

I think these should be in a MIB under IANA control and there is already a way
to do just that, namely to put them in an IANA MIB (as opposed to a standards
track MIB) with the RFC specifying under what conditions the IANA MIB can be
updated (standards track, IESG, expert etc).

This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which
also points to previous examples of this.  And this issue has already surfaced,
albeit obliquely, on this list once before in the context of
IANAItuProbableCause which uses this procedure and is now published as part of
the Alarm MIB (RFC 3877).

Not to do this now creates extra work in the future; when an implementor has to
create their own SMI and whenever these values need to be updated.

Tom Petch