Subject: [CCAMP] MIB Dr. review of draft-ietf-gmpls-ted-mib-06.txt

From: "Joan Cucchiara" <[email-masked]>
Date: Fri, 11 Dec 2009 10:19:56 -0500

Folks,

Please excuse the lateness of the review.  I apologize.

Please lets discuss the comments numbered below and reach convergence
prior to another respin of the MIB.

Thanks,
   -Joan

PS. A comment with a NIT does not need discussion per se, it is more
a minor editorial issue and would be nice if it were fixed, but it is not
necessary to fix for MIB review purposes.

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
W: f(TED-MIB.my), (791,10) Variable "tedAreaId" in notification 
"tedCreation" is an index for a table
W: f(TED-MIB.my), (791,21) Variable "tedRouterId" in notification 
"tedCreation" is an index for a table
W: f(TED-MIB.my), (791,34) Variable "tedLinkStateId" in notification 
"tedCreation" is an index for a table
W: f(TED-MIB.my), (803,10) Variable "tedAreaId" in notification 
"tedDeletion" is an index for a table
W: f(TED-MIB.my), (803,21) Variable "tedRouterId" in notification 
"tedDeletion" is an index for a table
W: f(TED-MIB.my), (803,34) Variable "tedLinkStateId" in notification 
"tedDeletion" is an index for a table

OUTPUT from SmiLint
--------------------
File: TED-MIB.my
Severity level requested: 6

Line  Severity  Problem

105 5 warning: index element `tedAreaId' of row `tedEntry' should be
                not-accessible in SMIv2 MIB
        5 warning: index element `tedRouterId' of row `tedEntry' should be
                not-accessible in SMIv2 MIB
        5 warning: index element `tedLinkStateId' of row `tedEntry' should 
be
                not-accessible in SMIv2 MIB

Comments on the Text of the Document
-------------------------------------
Once comments on the MIB module are converged then I'll do a more
thorough review of this text.

* Renaming of "te" to "ted" has not propogated completely thorough the
text.

* Security Considerations

I disagree with the first paragraph.  First, there are no read-create
objects.  Second, the MIB module may be implemented correctly, but
there could be a risk if objects were set.

Comments on MIB Module
----------------------

1) The warnings above were previously noted in the v5 MIB
review. These warnings should be fixed in my opinion.
Please discuss.

2)(NIT) Cannot extract MIB using mstrip

3) LAST-UPDATED and REVISION dates are incorrect.

4) Comment
-- assigned by IANA, see section 8.1 for details
but the section is 9.1, please say, see "IANA Considerations for TED-MIB" 
section

5) There is not one REFERENCE clause in this MIB.  As I requested in
the version 5 MIB review, given the nature of this MIB where it draws from
documents in several different WGs, I believe REFERENCE clauses should be 
given.
As an agent developer, trying to implement these objects without a pointer
to an RFC would be difficult and potentially error-prone.

Granted there are references to entire RFCs within the DESCRIPTION clauses
but the REFERENCE Clause should be more specific with a section and
sub-section.

6) Although this MIB did go through a LC in the CCAMP, there are
other WGs where this MIB should probably also have a LC.
Please discuss.

7) OID layout, while there were some improvements here, the oid layout as
suggested by Appendix D of RFC4181 (Guidelines for MIB Documents)
was not completely followed.  Was this an oversight or is there a
reason that it was not followed?

Suggested OID Layout

         xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)

This MIB:

- tedMIB
 \-v-0 tedNotifications

   |-1 tedObjects

   \-2 tedConformance
     \-v-1 tedGroups
       \-2 tedCompliances

Compliances and Groups do not follow the "Guidelines for MIB Documents"

8) The overall structure of the tables is a concern. Several indexes are
Unsigned32(0..4294967295) but there is no need to have such a large index
as far as I can tell.  Further, the use of 0 does not appear to be 
warrented.
(Please see rfc4181, section 4.6.1 and discuss why these indexes need to
be Unsigned32(0..4294967295).

The SwCapTable claims to give additional information about local or
remote TE links but the indexing makes that untennable as far as I can tell.
How does one know if they are looking at a local or remote link?

The tedSwCapIndex has nothing to do with RFC4801 as far as I can tell, so
don't understand what the index (tedSwCapIndex) is really supposed to be.

Additionally, the tedAreaId DESCRIPTION mentions using 0, but the range does 
not
include 0.   Again, a REFERENCE clause to each of the 3 or 4 documents
that this one object draws from (depending on the protocol),
would really be helpful.

Wrt tedLocalIfAdrEntry indexes, why does the tedLocalIfAddrIndex
need to be Unsigned32(0..4294967295), similarly why is the
tedRemoteIfAddrEntry tedRemoteIfAddrIndex Unsigned32(0..4294967295) ?

9) There was some emails back and forth on the MIB v5 review about
adding objects to give the state of the data in this MIB.
That was not done.
To recap an entry is created by local configuration,
then routing (or the specific link?) is supposed to be triggered,
then what is the state of the data in this MIB?

The MIB is NOT viable unless the state of the data can be understood
by an operator.

Please see the Aug 28th email discussion on version 5 MIB.

10) tedNotificationEnabled

Why is this object needed?  Please answer the question wrt rfc3413.

11) tedNotificationMaxRate

This one throttling mechanism is used to control 3 different notifications.
I would think that the status change notification would be sent so much more
often than a create/delete notification, so why is only one value used for
3 notifications?

Additionally, I would expect that the create and delete notifications should
probably be at a higher priority.  In other words, could you discuss why
the one throttle object?

12) tedLinkInformationSource and tedLinkInformationData

Which version of OSPF is being supported?  Looks to be ospfv2.

There may be a desire in the future to also support ospfv3, so
would be best to specify.  Also, this MIB says that it supports
ipv6 and that would be ospfv3.

13) Please change the name of "tedSwCap" to "tedSwitchCapacity".

14) Conformance statements are missing the restrictions for
IpAddress and IpAddressType objects in this MIB.
Please correct this.

Additionally, some of the DESCRIPTION clauses makes it seem that
some objects are optional, but this is not reflected in the Conformance
statements.  Please discuss wrt the following objects:

15) FullCompliance and ReadOnlyCompliance do not contain all of the
groups.  Neither compliance includes the Notifications group.

16) The DESCRIPTION of the Notifications Group states:
   "This group is mandatory for those implementations that can implement
   the notifications contained in this group."

So, why would these not be implementable?  I'm not sure this sort of
DESCRIPTION belongs in a standard's document.  If the intention is to
make these Notifications optional and this is okay with the wg, fine,
but this DESCRIPTION needs to be improved.

---

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Dec 2009 10:34:03 -0500

Joan,
	Thank you very much for your (usual) thorough review.  You mention that 
you'd like to see the document last called in additional WGs.  Our 
current plan is to issue a new LC once your review is complete and to 
notify both the OSPF and ISIS WGs of this LC (but not a joint LC).  Do 
you think there are any other WGs that should be notified/included?

Also, I regret that you had to repeat comments made on the previous 
version.

Authors,

Please reach closure/agreement with Joan on her comments before 
publishing the next version.  This includes addressing issues raised, 
but not addressed, in the prior version. (The WG mail list is a fine 
place for the discussion.)

Lou

---

From: "Joan Cucchiara" <[email-masked]>
Date: Fri, 11 Dec 2009 10:42:12 -0500

Lou,

I think MPLS should also be notified.

Thanks,
  -Joan

----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: "CCAMP" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>; 
"Thomas D. Nadeau" <[email-masked]>; "Masanori Miyazawa" 
<[email-masked]>; "Tomohiro Otani" <[email-masked]>; 
<[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; 
"Brungard, Deborah A, ALABS" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>
Sent: Friday, December 11, 2009 10:34 AM
Subject: Re: MIB Dr. review of draft-ietf-gmpls-ted-mib-06.txt

> you'd like to see the document last called in additional WGs.  Our current 
> plan is to issue a new LC once your review is complete and to notify both 
> the OSPF and ISIS WGs of this LC (but not a joint LC).  Do you think there 
> are any other WGs that should be notified/included?
>
> Please reach closure/agreement with Joan on her comments before publishing 
> the next version.  This includes addressing issues raised, but not 
> addressed, in the prior version. (The WG mail list is a fine place for the 
> discussion.)
>
> Lou
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Dec 2009 10:51:30 -0500

Sounds sensible.  Much thanks.

Lou