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. RGC> We have had a similar discussion in the OLSRv2-MIB reviews and within the RGC> working group, specifically the protocol authors on NHDP and OLSRv2. RGC> We had collectively agreed to scope the address support in these protocols RGC> to IPv4 and IPv6 only. I believe this should hold as well for the SMF RGC> protocol framework which is experimental and only defines mechanisms to RGC> support IPv4 and IPv6. My proposal is to leave these SYNTAX statements RGC> as they are, which is consistent with previous WG documents. Is RGC> this OK? 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. RGC> Yes, I agree. There were several address definitions in pairs to define RGC> ranges and these pairs have only a single InetAddressType object for RGC> each. I modified these to a more standard (type, addr, prefexLength) format. RGC> I hope this is OK? 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. RGC> I changed the wording to read "The SMF-MIB also reports iRGC> state information, performance information, and notifications." 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] RGC> I fixed this. 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. RGC> I agree, I removed 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' RGC> I searched through the entire document and made these corrections. 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. RGC> Three TCs are defined: SmfStatus, SmfOpModeID and SmfRssaID. RGC> I pulled the definition of the later two, now IANAsmfOpModeIdTC and IANAsmfRssaIdTC into RGC> Appendices A and B for eventual maintenance by IANA. I left the RGC> SmfStatus TC in the SMF-MIB. RGC> I hope this is OK? 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. RGC> I defined a seperate modules for SmfOpModeID and SmfRssaID that IANA can manage. RGC> I placed these in Appendices for now. 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. RGC> I have added section references to all of the REFERENCE clauses in RGC> the MIB module. 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? RGC> I updated the DESCRIPTION and REFERENCE clauses, now reads: RGC> RGC> IANAsmfRssaIdTC ::= TEXTUAL-CONVENTION RGC> STATUS current RGC> DESCRIPTION RGC> "An index that identifies through reference to a specific RGC> RSSA algorithms. Several are currently defined RGC> in the Appendix A, B and C of RFC 6621." RGC> REFERENCE RGC> "See, e.g., RGC> RGC> Section 8.1.1. 'SMF Message TLV Type', RGC> Appendix A. 'Essential Connecting Dominating Set (E-CDS) RGC> Algorithm', RGC> Appendix B. 'Source-Based Multipoint Relay (S-MPR) RGC> Algorithm', and RGC> Appendix C. 'Multipoint Relay Connected Dominating Set RGC> (MPR-CDS) Algorithm' RGC> RGC> in RFC 6621 - Simplified Multicast Forwarding RGC> (SMF), Macker, J., May 2012." 10. It would be nice if all objects under smfConfigurationGroup (and the following groups) would be similarly prefixed - e.g. smfCfg... RGC> Done. 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. RGC> See response to Comment 14 (below). 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? RGC> See response to Comment 14 (below). 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. RGC> See response to Comment 14 (below). 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? RGC> I did a fairly extensive rework of the CapabilitiesGroup within the MIB based RGC> upon your comments 11-14 which forced me to rethink the intentions RGC> for these Tables. So I combined these into a single smfCapabilitiesTable RGC> which identifies the possible combinations of the Operational Modes and the RSSAs RGC> that can operate on the specific device. Specifically this table RGC> defines an Index which relates to a tuple (SmfOpModeID, SmfRssaID). The RGC> problematic objects such as the Reference or Name objects, I removed. Also, RGC> now the manager can change the combined Operational Mode and RSSA by RGC> setting the value of the smfCfgOperationalMode to the appropriate RGC> smfCapabilitiesIndex value found within the smfCapabilitiesTable. I hope RGC> this clears up your questions and concerns here. 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? RGC> I changed the DESCRIPTION to read: RGC> RGC> If this object is 'disabled', RGC> then no SMF functions are being performed on RGC> the device and all smfIfAdminStatus objects RGC> MUST also be set to 'disabled'. When this RGC> object is changed from 'enabled' to 'disabled' RGC> by the manager, then all smfIfAdminStatus RGC> objects MUST also be automatically set to RGC> 'disabled' by the agent. 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. RGC> I changed the 'should' to 'SHOULD'. RGC> Also, I removed a redundant discussion in the DESCRIPTION RGC> clause of the smfCfgRouterIDAddrType object. 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)/ RGC> Done. 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'? RGC> I removed this object; is it really necessary in the implementation of SMF? RGC> We have defined a bound on the maximum lifetime RGC> of entries to be maintained in the Dpd cache through the object RGC> 'smfCfgDpdEntryMaxLifetime'. Also defined behavior in the RGC> event that the memory is limited by removing oldest entries first within the RGC> 'smfCfgDpdEntryMaxLifetime' DESCRIPTION. 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. RGC> As mentioned above, I removed this object as unnecessary. 20. There is a 'hole' between { smfConfigurationGroup 13} and { smfConfigurationGroup 15}. Where did 14 disappear? RGC> I fixed this. 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? RGC> This table defines filtering rules for SMF forwarding based upon RGC> multicast address ranges. These are statically configured RGC> in this table. RGC> RGC> The Table description was not clear, so I modified the DESCRIPTION clause RGC> for the table, the entry and all of the table objects. Further, I modified RGC> the object definitions to a more standard method for identifying address ranges RGC> based upon the type, address, addrPrefixLength syntax. RGC> I added an Index object and a groupName object to the Table. The Index is now RGC> the INDEX and the Group name allow for administrative association of RGC> address ranges for filter rules. The address range definitions are now read-create, RGC> so the table now allows a manager to build a set of IP filter rules for multicast RGC> packet forwarding as intended originally. 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? RGC> Added the following text to the DESCRIPTION clause: RGC> "If the manager attempts to create a row RGC> for which the ifIndex does not exist on the RGC> local device, then the agent SHOULD issue RGC> a return value of 'inconsistentValue' and RGC> the operation SHOULD fail." 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. RGC> The name is now smfCfgIfName and I chenged the SYNTAX to SnmpAdminString. I left the object RGC> in the MIB module as it is used within some of the smfNotifications to identify the interface RGC> associated with the notification. 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) RGC> No, you are correct, there is the possibility of a discontinuity event for RGC> both the system-wide and interface-specific counters. I added two new RGC> time objects, i.e., 'smfCfgSmfSysUpTime' and smfCfgIfSmfUpTime' with RGC> SYNTAX 'TimeTicks' to allow for an indication of a discontinuity. I also added the RGC> following text (or similar text for interface specific) in the RGC> DESCRIPTION clauses for Counter32 objects: RGC> RGC> "There is the potential for a counter discontinuity RGC> in this object if the system SMF process had been RGC> disabled and later enabled. In order to check for RGC> the occurrence of such a discontinuity when monitoring RGC> this counter object, it is recommended that the RGC> smfCfgSmfSysUpTime object also be monitored." 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? RGC> As there are no currently defined mechanisms or protocols for the MANET nodes to RGC> dynamically discover multicast address ranges to place into this RGC> table for forwarding decisions, I removed the table. There still reamins RGC> the smfCfgAddrForwardingTable which allows for local and management configuration RGC> of address filtering rules. 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. RGC> Added to the security discussion to indicate the implications of RGC> misconfiguration of the following objects: 'smfCfgRouterIDAddrType' RGC> and 'smfCfgRouterID', smfCfgOpMode, smfCfgRssa, smfCfgIpv4Dpd, RGC> smfCfgIpv6Dpd, smfCfgNhdpRssaMesgTLVIncluded and smfCfgNhdpRssaAddrBlockTLVIncluded. 27. The Applicability Statement section is useful, and I would actually recommend to extend it with an example of agent configuration. RGC> I took a crack at this. I gave an example of the minimum configuration required RGC> to get the device to perform classical flooding. Then I showed how to discover RGC> other operational modes and RSSAs on the device and to switch operation to RGC> a more efficient flooding algorithm like ECDS. If this is not complete enough RGC> or you had something more or else in mind, please let me know. I'll be RGC> glad to work further on this section. Thanks and Regards, RGC> Thank you. Dan