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

From: "Masanori Miyazawa" <[email-masked]>
Date: Tue, 1 Feb 2011 12:04:07 +0900

Hi, Joan

Thank you for your review in this doc.
According to your comments, I think we will revise the document.

Thank you
Masanori

> -----Original Message-----
> From: Joan Cucchiara [mailto:[email-masked]]
> Sent: Friday, January 14, 2011 3:16 AM
> To: [email-masked]; MIB Doctors (E-mail); Tomohiro Otani; Masanori
> Miyazawa; [email-masked]; Thomas D. Nadeau
> Cc: Joan Cucchiara; Dan Romascanu (E-mail)
> Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07
> 
> 
> 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: "Masanori Miyazawa" <[email-masked]>
Date: Tue, 1 Mar 2011 00:32:25 +0900

Hi, Joan

Thank you for your comments.
In accordance with your comments, I am revising the documents.
Please see our answer to your comments as below and let us know if you have
any question

With best regards,
Masanori

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

"Update in next version"

*) Dates and copyright need to be updated
" Update in next version "

RFC3784 was obsoleted by RFC5305
RFC4205 was obsoleted by RFC5307
" Update in next version "

IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section.
" Update in next version "

*)  2. Introduction

Since this document supports both OSPFv2 and OSPFv3, please say this
explicitly.
"Modify in next version"

a. OSPFv3 MIB is defined in rfc5643
b. TE extensions to OSPFv3 are described in RFC5329
" Modify in next version "

*) 3.3 Acronyms

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

" Modify in next version "

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.

" Modify in next version as shown below"
The existing OSPFv2, OSPFv3, ISIS, MPLS and GMPLS MIBs do not provide for
the management interface to retrieve topology information for the MPLS and
GMPLS network.

*) Section 5.1

" Modify in next version "

*) Section 5.3

independently because/
"Modified"

*) Section 5.4

" We use Switching Capability consistently in this document."

COMMENTS ON MIB MODULE

*) TEXTUAL-CONVENTIONS

For example:

" Modify in next version "

*) tedCreateDeleteNotificationMaxRate and tedStatusChangeNotificationMaxRate

"DEFVAL was deleted from tedCreateDeleteNotificationMaxRate"

*)  tedInfoStatus object

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.

Please discuss.

"Thank you for your comment. We think the definition of tedInfosStatus in
previous version was wrong, as you indeicated . It took into account only a
state/status of this MIB itself, not link information. In order to take into
account the operational status of TE link, we think it is necessary to
create new object such as, for example, "tedLinkState" in tedTable as shown
below. If you have comments, please let us know. "

tedLinkState OBJECT-TYPE
    SYNTAX        INTEGER {
                   up(1),
                   down(2)
                   }
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
     " "
::={ tedEntry X }

*) tedSwCapSwitchingType

" Modify in next version "

Please discuss.

" In version 6 of ted mib, tedAreaId, tedRouterId and tedLinkStateId were
utilzed as the Index of notification because it is useful to treat as the
notification with unique value by using combination of these objects.  But,
it cause some error on SMICngPro as shown below. Therefore, we decided to
utilize new objects such as tedNotificationAreaId, tedNotificationRouteId
and tedNotificationLinkStateId. We think we want to use tedAreaId,
tedRouterId and tedLinkStateId as the index of notification again. What do
you think?"

OUTPUT from SMICngPRO
---------------------
W: f(TED-MIB.my), (777,10) Variable "tedAreaId" in notification
"tedStatusChange" is an index for a table
W: f(TED-MIB.my), (777,21) Variable "tedRouterId" in notification
"tedStatusChange" is an index for a table
W: f(TED-MIB.my), (777,34) Variable "tedLinkStateId" in notification
"tedStatusChange" is an index for a table
"

" Modify in next version "

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.
" Modify in next version "

a) NIT: should be listed in increasing RFC Order.
" Modify in next version "