Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt

From: <[email-masked]>
Date: Thu, 20 Apr 2006 20:33:14 -0400

Hello Tom and Adrian,

Here are a few comments on
draft-ietf-ccamp-gmpls-te-mib-14.txt.
Thank you for the great updates.

Thanks,
-Joan

Compiles with both smicngPRO and smilint.

1) There is a disconnect in the numbers under the
under gmplsTeGroup, was this intentional, if so,
please explain, otherwise, please correct it.

1.3.6.1.2.1.10.166.555.3.1  gmplsTeGroups  [GMPLS-TE-STD-MIB]:
oid-value-assignment
1.3.6.1.2.1.10.166.555.3.1.1  gmplsTunnelGroup  [GMPLS-TE-STD-MIB]:
object-group
1.3.6.1.2.1.10.166.555.3.1.2  gmplsTunnelSignaledGroup  [GMPLS-TE-STD-MIB]:
object-group
1.3.6.1.2.1.10.166.555.3.1.3  gmplsTunnelScalarGroup  [GMPLS-TE-STD-MIB]:
object-group
1.3.6.1.2.1.10.166.555.3.1.6  gmplsTunnelOptionalGroup  [GMPLS-TE-STD-MIB]:
object-group
1.3.6.1.2.1.10.166.555.3.1.7  gmplsTeNotificationGroup  [GMPLS-TE-STD-MIB]:
notification-group

2) Expiration date in the page header is incorrect
Nadeau and Farrel             Expires April 2006             [Page 1]

3) 1.1. Migration Strategy
   "The gmplsTunnelLSPEncoding may be set to tunnelLspNotGmpls to allow an
   MPLS-TE LSP tunnel to benefit from the additional objects and tables
   of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols.

Think you mean, GMPLS-TE-STD-MIB in the latter part of the above sentence.

4) 1.1. Migration Strategy
   "Textual conventions are defined in [RFC3811] and [GMPLSTCMIB]."

There aren't any TCs from GMPLSTCMIB, but there are
from the IANA-GMPLS-TC-MIB, so perhaps adding IANA-GMPLS-TC-MIB to this
statement would be appropriate.

5) (NIT) 2. Terminology

   "These segment and cross-connect objects are defined in the MPLS Label
   Switch Router MIB (MPLS-LSR-STD-MIB) [RFC3813], but see also the
   GMPLS Label Switch Router MIB (GMPLS-LSR-STD-MIB) [GMPLSLSRMIB] for..."

Please be sure to use "Label Switching Router" (and not Label Switch
Router).

6) Typos:
       gmplsTunnelLinkProtection

          This glag is set to indicate that the LSP should not use any
          link layer protection.

s/glag/flag

        shared
          This flage is set to indicate that a shared link layer

s/flage/flag

7)    gmplsTunnelErrorEntry OBJECT-TYPE

The use of the term "discontinuity" implies that the counters
suffered a discontinuity,but the situation you are describing is
that another error occurred.  Please rephrase this to something
like:

"Note that systems which read the objects in this table one at
a time should read gmplsTunnelErrorLastTime prior to the first
object and after reading the last object of this table to
ensure that no additional errors occurred."

8) gmplsTunnelUnnumIf does not appear in the
ReadOnly Conformance.

9) I am still unclear about what objects can be supported within
MPLS only.  Was expecting to see this clarified in the conformance
statements.  There does seem to be more of a division here than
in the GMPLS-LSR-STD-MIB.

Could some clarification be made to this point?

10)  IANA-GMPLS-TC-MIB

Would remove parts of the DESCRIPTION clauses which
refer to the GMPLS-TE-STD-MIB module.  The reason is
that these TCs may eventually be used in other MIB modules
and since this particular module will be controlled by
IANA, these sort of statements don't appear in IANA
MIB Modules as far as I know.

            "This data type is used as the syntax of the
             gmplsTunnelLSPEncoding object in the definition of
             GMPLS-TE-STD-MIB's gmplsTunnelTable."

            "This data type is used as the syntax of the
             gmplsTunnelSwitchingType object in the definition of
             GMPLS-TE-STD-MIB's gmplsTunnelTable."

            "This data type is used as the syntax of the
             gmplsTunnelGPid object in the definition of
             GMPLS-TE-STD-MIB's gmplsTunnelTable."

            "This data type is used as the syntax of the
             gmplsTunnelAdminStatusFlags object in the definition of
             GMPLS-TE-STD-MIB's gmplsTunnelTable."

-- the end --

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 25 Apr 2006 13:40:23 -0400

> Thank you for the great updates.

	First, removed references to 4201, 4003
and 4420 that were added as per last email from
Joan. Things are back to the original state
WRT these.

> 8) gmplsTunnelUnnumIf does not appear in the

	Fixed all of above.
> Could some clarification be made to this point?

	I guess I am confused. I am not sure why we have
to explain the reverse relationship. All of the objects herein
are for GMPLS only; none apply to MPLS-only TE entries.
So the objects that are supported by
MPLS-only TE entries should have no corresponding
objects in this MIB module.  Tabular entries in this
MIB represent GMPLS entries only, and they also have
corresponding objects in say RFC3812. We also covered this
reciprocal relationship in the conformance statement before
as part of your previous comments RE: "should we
explain each object or explain that they ALL apply."

>              GMPLS-TE-STD-MIB's gmplsTunnelTable."

	Done.

	I will re-compile/re-format the modules and post them
to the ID repository now.

	Thanks Joan!

	--Tom

---

From: <[email-masked]>
Date: Wed, 26 Apr 2006 20:44:01 -0400

Hi Tom,

----- Original Message -----
From: Thomas D. Nadeau <[email-masked]>
To: <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 25, 2006 1:40 PM
Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt

<snip>

> explain each object or explain that they ALL apply."

I was also confused.  If there are no MPLS objects then
the MIB is fine as is.

Thanks,
  Joan

---

From: <[email-masked]>
Date: Wed, 26 Apr 2006 20:50:16 -0400

Hi Tom,

draft-ietf-ccamp-gmpls-tc-mib-10.txt 
same comment as before wrt the expiration date
(this is the same draft that was there prior, so
if you submit a new one, please bump the 
draft number -- if you prefer to leave the fix
to the RFC editor that is fine also).

Thanks, 
 -Joan

---

From: <[email-masked]>
Date: Wed, 26 Apr 2006 20:48:41 -0400

Look great!  

Thanks,
-Joan

---

From: <[email-masked]>
Date: Wed, 26 Apr 2006 20:47:25 -0400

Hello Tom and Adrian,

All MIBs compile with smilint and smicngPRO.

Here are my few comments:

draft-ietf-ccamp-gmpls-lsr-mib-13.txt

(#1 should be taken care of the others are NITs and
could probably be fixed by RFC Editor if you so choose.)

1)  Think this was probably a place holder...but
please just remove this:

     OBJECT       gmplsLabelRowStatus
     SYNTAX       RowStatus { active(1), notInService(2) }
     WRITE-SYNTAX RowStatus { active(1), notInService(2),
                              createAndGo(4), destroy(6) }
     DESCRIPTION
       "TDN QUestion"

2) NIT

         January 2003;
        "

Please change this to:

            January 2003."

3) Informative References

NIT:

Change the order so references are in
ascending order:

Current order is:

   [RFC3472]  

   [RFC3468] 

change to:

   [RFC3468] 

   [RFC3472]  

NIT:
Fix reference:

Current:
   [RFC3468]    Andersson, L., Swallow, G., "The Multiprotocol Label 
                Switching (MPLS) Working Group decision on MPLS 
                signaling protocols", RFC 3468, February 2003.

Should be:

   [RFC3468]    Andersson, L. and G. Swallow, "The Multiprotocol Label 

-- end --

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 27 Apr 2006 10:52:55 -0400

If its okay, I will leave this. It is
likely that I will have to spin another revision
based on IESG revision(s), so I will fix this then.
If there are none, I will keep a note to make sure
this is fixed when the RFC editor reviews.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 27 Apr 2006 10:50:19 -0400

One question below.

>                               createAndGo(4), destroy(6) }

	Thanks for catching this. I remember why I left this.
I was confused by your comments on this, which were:
>>>> 9) Full Compliance:
>>>>        "Support for createAndWait and notReady is not required."
>>>>
>>>>
>>>> Would remove this.
>>>>
>>>
>>> The description or the entire object?
>>>
>>
>> Presumably the Description limitation based on the text below.
>>
>>
>>>> Based on the
>>>> gmplsLabelRowStatus object's DESCRIPTION
>>>> believe you should allow createAndWait and also
>>>> Agent could/should be able to report notReady.

	Based on what is listed in RFC3813, for example,
we have the following:

    OBJECT       mplsInSegmentRowStatus
    SYNTAX       RowStatus { active(1), notInService(2) }
    WRITE-SYNTAX RowStatus { active(1), notInService(2),
                             createAndGo(4), destroy(6)
                           }
    DESCRIPTION "Support for createAndWait and notReady is
                 not required."

	I guess I am looking for some explicit instruction on
what you would like to see in the DESCRIPTION for the
gmplsLabelRowStatus in the FullCompliance statement.

>    [RFC3468]    Andersson, L. and G. Swallow, "The Multiprotocol Label

	OK, fixed the above nits.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 27 Apr 2006 10:53:16 -0400

> I was also confused.  If there are no MPLS objects then

	Cool. Left as-is.

	--Tom