Re: [manet] 'MIB Doctor' review of draft-ietf-manet-smf-mib-08 (UNCLASSIFIED)

["Cole, Robert G CIV USARMY CERDEC (US)" <[e-mail]>]

Classification: UNCLASSIFIED
Caveats: NONE

Dan,

Thanks for the review.  I'll start working these issues and get back to you with the updated MIB module and a detailed list of corrections.

Bob

US Army CERDEC
QUEST Program, S&TCD
APG, MD

(c) 443.910.4420
(o) 443.395.8744
[e-mail]


-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2013 2:02 PM
To: [e-mail]; [e-mail]
Cc: MIB Doctors (E-mail)
Subject: 'MIB Doctor' review of draft-ietf-manet-smf-mib-08


Please find below the 'MIB Doctor' review of draft-ietf-manet-smf-mib-08. 

1. Running smilint results in the following level 5 warnings: 

mibs/SMF-MIB:396: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped
mibs/SMF-MIB:421: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
mibs/SMF-MIB:785: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped
mibs/SMF-MIB:806: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
mibs/SMF-MIB:824: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
mibs/SMF-MIB:1112: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped
mibs/SMF-MIB:1126: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
mibs/SMF-MIB:1140: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
mibs/SMF-MIB:1215: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped
mibs/SMF-MIB:1226: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object


Concerning the first category of warnings ' InetAddressType' should not be subtyped ': indeed, as per RFC 4001: 

>        To support future extensions, the InetAddressType textual
         convention SHOULD NOT be sub-typed in object type definitions.
         It MAY be sub-typed in compliance statements in order to
         require only a subset of these address types for a compliant
         implementation.
 
I recommend giving up subtyping in the MIB and miving it to the compliance statements for the respective objects. 

Concerning the second category of warnings ' `InetAddress' object should have an accompanied preceding `InetAdressType' object ': Actually such objects exist but they are defined for a pair of IP addresses for the two ends of a range. The warnings can be ignored, but I recommend to clarify in the DESCRIPTION clauses of each object with an InetAddress SYNTAX what is the relevant object with the InetAddressType SYNTAX. 

2. In the abstract: 

> The SMF-MIB also reports state information,
   performance metrics, and notifications.  

It is actually the performance information that is being reported - I suggest to change the wording. 

3. In Section 4.1: 

>   Figure 1 (reproduced from Figure 4 of [RFC6621]) shows ...

Actually Figure 1 here is reproduced from Figure 1 (and not 4) of [RFC6621]

4. When copying Figure 1 the asterisks in the RFC6621 figure were also copied. They are not relevant (I think) and not explained here - I suggest to delete them. 

5. In several places in the text I see the contruct 'this MIB' (e.g. first bullet in 4.2) or MIBs (e.g. in 6.3) - we prefer to say 'this MIB module'. 'MIB modules' 

6. This document is Experimental and the SMF-MIB is routed under the Experimental subtree. Will the TCs defined here be used only in Experimental MIB modules? If there are any chances that they will be needed in Standards Track MIB modules better take these out and define them in a separate document that defines a separate MIB module under mib-2, otherwise they risk to create downrefs in the future, as RFCs that define IMPORTed TCs must be Normative References.

7. The SmfOpModeID and SmfRssaID have commented enumerated ranges of values for future extensions. These two TCs seem to be good candidates for IANA administered TCs. 

8. Most of the optional REFERENCE clauses look like: 

       REFERENCE
          "RFC 6621 - Simplified Multicast Forwarding
           (SMF), Macker, J., May 2012."

These are not useful. Please add specific section numbers that can help implementers of the MIB objects to find easier the information needed for each object. 

9. In the DESCRIPTION clause of SmfRssaID: 

            Several are currently defined
            in the appendix of RFC 6621."
 
There are several appendices in RFC 6621. Which one? 

10. It would be nice if all objects under smfConfigurationGroup (and the following groups) would be similarly prefixed - e.g. smfCfg...

11. The following definition is problematic: 

smfOpModeCapabilitiesName OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The textual name of this operational
            mode.  Current operational modes include:
               'independent',
               'routing', and
               'crossLayer' Mode.
            Others may be defined
            in future revisions of [SMF]."
       ::= { smfOpModeCapabilitiesEntry 2 }

Why define a redundant SnmpAdminString object, and not an object with the SYNTAX of SmfOpModeID? Especially if the TC will be extended in the future, maybe in a different MIB module. 

12. I do not understand this object: 

smfOpModeCapabilitiesReference OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION	
           "This object contains a reference to the document
            that defines this operational mode."
       ::= { smfOpModeCapabilitiesEntry 3 }

This does not seem the type of information that needs to be stored on an agent. How does the agent know this information at all? 

13. The following defintion is problematic: 

smfRssaCapabilitiesName OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The textual name of this RSSA algorithm.
            Currently defined names are:
                'cF',
                'sMPR',
                'eCDS',
                'mprCDS'.
           "
       ::= { smfRssaCapabilitiesEntry 2 }
 
Why define a redundant SnmpAdminString object, and not an object with the SYNTAX of SmfRssaIDID? Especially if the TC will be extended in the future, maybe in a different MIB module. 

14. I do not understand this object: 

smfRssaCapabilitiesReference OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object contains a published reference
            to the document that defines this algorithm.
           "
       ::= { smfRssaCapabilitiesEntry 3 }

This does not seem the type of information that needs to be stored on an agent. How does the agent know this information at all?

15. In the DESCRIPTION clause of smfAdminStatus: 

          If this object is 'disabled',
          then no SMF functions SHOULD be performed on
          the device and all smfIfAdminStatus objects
          SHOULD also be set to 'disabled'.  

First why the SHOULDs? Are there any exceptions? Second - who is this recommendation for? Managers or Agents? If this object is changed from 'enabled' to 'disabled' then MUST all smfIfAdminStatus be turned automatically to 'disabled' or this is something that the manager is supposed to do using SETs? 

16. In the DESCRIPTION clause of smfRouterID: 

          should select a routable IP address
          assigned to this router for use as
          the 'smfRouterID'.

To be consistent with the rest this 'should' seems to need capitalization.

17. In the DESCRIPTION clause of smfRssaMember: 

          The value 'always(1)' forces the selected
          RSSA include this agent in the RSS.

s/always(1)/always(2)/

18. in the DESCRIPTION clause of smfDpdMaxMemorySize: 

          The local SMF device should protect itself
          against the SNMP manager from requesting
          too large a memory value.  If this is the case,

What does 'too large a memory value' mean? Is this the higher limit of the range? Then no condition is needed. Is this some other value within the range? How does the agent know it? Maybe there is a need for another object to threshold 'too large'? 

19. In the same clause: 

          an error indication should be returned in response
          to the SNMP SET request.

Seems like this 'should' needs to be capitalized. 

20. There is a 'hole' between { smfConfigurationGroup 13} and { smfConfigurationGroup 15}. Where did 14 disappear? 

21. I do not understand the table

   smfConfiguredAddrForwardingEntry OBJECT-TYPE
      SYNTAX     SmfConfiguredAddrForwardingEntry
      MAX-ACCESS not-accessible
      STATUS     current
      DESCRIPTION
         "An entry (conceptual row) containing the information on a
          particular multicast scope."
      INDEX { smfConfiguredAddrForwardingAddrType,
              smfConfiguredAddrForwardingFirstAddr,
              smfConfiguredAddrForwardingLastAddr }
      ::= { smfConfiguredAddrForwardingTable 1 }

   SmfConfiguredAddrForwardingEntry ::= SEQUENCE {
      smfConfiguredAddrForwardingAddrType      InetAddressType,
      smfConfiguredAddrForwardingFirstAddr     InetAddress,
      smfConfiguredAddrForwardingLastAddr      InetAddress,
      smfConfiguredAddrForwardingStatus        RowStatus
   }

So there are three indices and one RowStatus object. What kind of information does this table provide? Or what are the consequences of dynamically creating or deleting a row? 

22. For the object smfIfIndex: 

          The ifIndex for this SMF interface. This value
          MUST correspond to an ifIndex referring
          to a valid entry in The Interfaces Table."

What happens if the manager creates a row which does not correspond to such a valid entry? 

23. The DESCRIPTION clause of smfIfName copies the DESCRIPTION clause of IfName from RFC 2863. If this is exactly the same information this object is not needed, as IfName can always be retrieved for a valid entry in the Interfaces Table. If there is some SMF-specific information that this string carries than the information is missing. In any case the SYNTAX should be SnmpAdminString.

24. All counter objects in this MIB module miss discontinuity information, the counters at the agent level, and interface level as well. Is this OK? No need for counter discontinuity objects? (see section 4.6.1.2 in RFC 4181)

25. I do not understand the object: 

   smfDiscoveredAddrForwardingSource OBJECT-TYPE
      SYNTAX     SnmpAdminString
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
         "The textual description of the method by which
          this multicast address range was discovered."
   ::= { smfDiscoveredAddrForwardingEntry 4 }

If I was writing an implementation of this MIB module I would not know where to take this information from and how to express it. How does the agent fill this information and in what format? 

26. In the Security Considerations section some of the objects have only a functional description, but not a description of the security risks operators encounter if they are misconfigured. For example 'smfRouterIDAddrType' and 'smfRouterID', 'smfConfiguredOpMode', 'smfIpv4Dpd', o  'smfIpv6Dpd', etc. 

27. The Applicability Statement section is useful, and I would actually recommend to extend it with an example of agent configuration. 

Thanks and Regards,

Dan


Classification: UNCLASSIFIED
Caveats: NONE