Subject: Re: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 14 May 2005 15:50:25 +0100

Hi Tom,

Thanks for your comments which we are (finally) addressing.

> I find the IANA Considerations section less than clear.  I suggest that
you
> differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB

OK.

> I would also reword it slightly as follows.
>
> **   MPLS and GMPLS related standards track MIB modules are rooted under
the
>    mplsStdMIB subtree.
>
>    One of the MIB modules contained in this document extends tables
>    contained in MPLS MIB modules.

OK

> **  The two MIB modules contained in this document, like that in
> GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB
subtree.

OK

> **   New assignments in the mplsStdMIB subtree can only be made via a
Standards
> Action as specified   in [RFC2434].

OK

> 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB
>
> ** The IANA is requested to assign { mplsStdMIB yy } to the
>    GMPLS-LABEL-STD-MIB module specified in this document.

Yes, as above.

Thanks,
Adrian and Tom
(Your other emails on these MIBs will be responded to separately.)

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 14 May 2005 15:57:20 +0100

Hi Tom,

Next in the series of your comments on the GMPLS MIBs.

> A minor comment; this document has
>  false (0),
> in several places; following RFC 2579, I think this should be
>  false (2)

OK

> A larger question,; this mib augments tables in the mpls mib (RFC3812);
is there
> a reason why the AUGMENTS construct was not used?

You and I discussed this on the list a bit. I think we came to the
conclusion that:
- Augments is what we intended
- it fits the usage
- the indexing is needed because the new table is a separate table.

So, no action, but I expect the MIB Doctors (TM) will pick up on it if
there are any issues.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 14 May 2005 17:26:08 +0100

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
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
>
>
>