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

["Adrian Farrel" <adrian@olddog.co.uk>]

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