Subject: [MIB-DOCTORS] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 13 Jan 2011 13:15:46 -0500

Hi Masonori,

Thank you for the new version of this document.  There were many good
updates, particularly, the Conformance section.

Please see following comments.

Thanks,
  -Joan

COMPILER RESULTS
------------------------------
* MIB compiles cleanly with smicngPRO

* MIB compiles cleanly with smiLint

DOCUMENT COMMENTS
-------------------------------------
*) NIT: Does not strip cleanly with smicPRO's mstrip.
(This does not have to be fixed for MIB Dr. purposes,
only mention as an fyi.)

*) Author contact info needs to be updated.

*) Dates and copyright need to be updated

*) RFC references probably need to be updated.

RFC3784 was obsoleted by RFC5305
RFC4205 was obsoleted by RFC5307

IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section.

*)  2. Introduction

Since this document supports both OSPFv2 and OSPFv3, please
say this explicitly.

*)  The following 2 RFCs should be referenced also.

a. OSPFv3 MIB is defined in rfc5643
b. TE extensions to OSPFv3 are described in RFC5329

*) 3.3 Acronyms

These should be in alphabetical order (or some order that
is defined at the beginning of this subsection.)

Should include TED:  Traffic Engineering Database

*) Section 4. Motivations

The motivation statement leads one to believe that this
document will provide "for the management of all of the
extensions to the OSPF and ISIS protocol.".

There are 2 inconsistencies here:
a) Since this is a read-only MIB, (no configuration) then the
statement should be revised because management includes configuration.
b) As previously mentioned, the use of OSPF and then references
to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3
along with relevant documents.

*) Section 5.1

s/information of/information for/

*) Section 5.3

s/This is also independently utilized,because/Also, this is utilized 
independently
because/

*) Section 5.4

This is referred to as Switch Capable and also
as Switching Capability, please be consistent.  If SwCap is
supposed to be Switching Capability, then please use that
Switching Capablity consistently.

COMMENTS ON MIB MODULE
--------------------------------------------

*) TEXTUAL-CONVENTIONS

The names of these TCs are already used in the OSPFv2 MIB
and while this may have been done intentionally, would prefer
a TED specific name.

For example:

RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750)

Could these be renamed to be prefixed with "Ted"
and suffixed with "TC", such as TedRouterIdTC" ?

*) tedCreateDeleteNotificationMaxRate and tedStatusChangeNotificationMaxRate

a) Why are these objects not located closer to the Notifications?

b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}.  The DESCRIPTION 
clause
does not indicate that 0 has a special value (as it does for 
tedStatusChangeNotificationMaxRate,
so just want to check on this?  Do you really mean 0 here?

*)  tedInfoStatus object

I think there is still some confusion about my request for status/state 
information.
Obviously, if there are rows in these tables, then
the MIB has been configured by some means other than SNMP, and granted 
notifications are sent (unless
they are dropped due to throttling or lost), but what is the Operational 
Status
link?

The RowPointer object, tedLinkInformationData, might provide this 
information, however,
the DESCRIPTION clause makes it sound completely optional since it looks 
like 0.0
can be entered under any circumstance, so again, I have to ask, how is an 
operator
supposed to know if the TE link is acting as intended?

If tedLinkInformationData is supposed to provide this, then it needs to be 
rewritten to
be mandatory.  That means that there are dependencies on other MIBs also. 
That is
unclear in this document.

In summary, tedInfoStatus object does not provide any additional 
information, as
I can see if the MIB is populated.  What I'm asking for is Operational 
Status/State
information.

Please discuss.

*) tedSwCapSwitchingType

Please rename to tedSwCapType.

*) tedNotificationAreaId and tedNotificationRouterId

Not sure why these are needed.  Couldn't you include
an object from the tedTable (such as tedLinkInformationSource)
rather than have these accessible for Notify objects.  Seems like
extra work on all parts and not sure I see the advantage when
you already have this info in a table.

Please discuss.

*) 8. Security Considerations

s/read-write../read-write./

*) 10.1 Normative References

a) Some of the Informative References should
probably moved to Normative, specifically, any of the MIB
docs that are IMPORTED or appear in a REFERENCE clause.

*) 10.2 Informative References

a) NIT: should be listed in increasing RFC Order.

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jan 2011 10:11:15 -0500

Joan,
	Thank you for the very thorough review!

Authors,
	Please respond, letting us know how your propose to resolve each raised 
point.  Please note that some of the comments require discussion which 
can/should take place over e-mail prior to a new version being submitted.

Much thanks,
Lou

On 1/13/2011 1:15 PM, Joan Cucchiara wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>