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

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 14 May 2005 18:53 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 OAA25656 for <ccamp-archive@ietf.org>; Sat, 14 May 2005 14:53:31 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX21h-0002Rd-5O for ccamp-archive@ietf.org; Sat, 14 May 2005 15:10:17 -0400
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DX1d9-0004z4-GG for ccamp-data@psg.com; Sat, 14 May 2005 18:44:55 +0000
Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DX1d7-0004yp-M9 for ccamp@ops.ietf.org; Sat, 14 May 2005 18:44:53 +0000
Received: from du-069-0037.access.clara.net ([217.158.132.37] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DX1d5-000KYN-IJ; Sat, 14 May 2005 19:44:52 +0100
Message-ID: <01a101c558b5$4e61e310$04919ed9@Puppy>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Tom Petch <nwnetworks@dial.pipex.com>
Cc: ccamp@ops.ietf.org
References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> <000e01c52b94$e310a440$0601a8c0@pc6>
Subject: Re: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Sat, 14 May 2005 17:26:08 +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.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit

Hi Tom,

This is a very good point.

We have been struggling with this for a while (I believe that Bert gave me
a pointer, but I don't think I understood the issue properly before).
Thanks to your explanation and the new text in the MIB guideline, we have
taken care of the issue.

Cheers,
Adrian
----- Original Message ----- 
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Friday, March 18, 2005 9:29 AM
Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt


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