RFC Errata
RFC 4939, "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", July 2007
Source of RFC: ips (tsv)
Errata ID: 1641
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-14
Held for Document Update by: Lars Eggert
Date Held: 2008-12-19
(2f) isnsRegEntityNumObjectsTable / isnsRegEntityNumObjectsEntry (page 44) Studying the MIB module, it turns out that the isnsRegEntityNumObjectsTable is a (dense) augmentation of the isnsRegEntityTable : a conceptual row in the former must be instantiated if an only if the corresponding row (with identical index values) is instantiated in the latter. Therefore, according to the strong recommendation '(1)' given in Section 7.8.1 of the first part of STD 58, RFC 2578, the isnsRegEntityNumObjectsTable should be formally represented as an augmentation of the isnsRegEntityNumObjectsTable. This means that, in the isnsRegEntityNumObjectsEntry OBJECT-TYPE declaration, where the RFC says ... isnsRegEntityNumObjectsEntry OBJECT-TYPE [...] | INDEX { isnsServerIndex, | isnsRegEntityIndex } ::= { isnsRegEntityNumObjectsTable 1 } ... it should have specified: isnsRegEntityNumObjectsEntry OBJECT-TYPE [...] | AUGMENTS { isnsRegEntityEntry } ::= { isnsRegEntityNumObjectsTable 1 } Note that the similar relationship between the isnsNumObjectsTable and the isnsServerTable has correctly reflected in the RFC; the isnsNumObjectsEntry OBJECT-TYPE declaration already contains the clause: AUGMENTS { isnsServerEntry } (2g) isnsRegIscsiNodeAuthMethod (page 55) The DESCRIPTION clause of the isnsRegIscsiNodeAuthMethod OBJECT-TYPE declaration says: | "This attribute contains a null-terminated string containing UTF-8 text listing the iSCSI authentication methods enabled for this iSCSI Node, in order of preference. The text values used to identify iSCSI authentication methods are embedded in this string attribute and delineated by a comma. The text values are identical to those found in RFC 3720 - iSCSI. Additional vendor-specific text values are also possible." This is very unusual. 'null-terminated' have been introduced in some very popular programming languages in place of length counts for string variables. (Some people believe this has been one of the most serious errors ever in the history of programming languages, because it makes transparent strings (with 0x00 allowed) impossible, and practice sadly has proven it is a pathway to the hell of very many security flaws.) ASN.1 OCTET-STRINGs are counted strings, and the SMIv2 *is* a qualified subset of ASN.1. SnmpAdminString is a proper subtype of OCTET-STRING. Hence, there is no need to include a terminating null into an object of type SnmpAdminString. Apparently, this has been recognized throughout this MIB module, with explicit explanations for all OCTET-STRING (SIZE (0..223)) typed objects. This single deviation from standard practice is a significant inconsistency in the MIB module and it might well lead to interoperability problems if it is not recognized by implementors! (2h) object names in the isnsNotificationsInfo branch (pages 64/65, used later on as well) It is common practice, and makes life easier, to have object names built in a manner that reflects the OID tree: most significant part(s) left, finer granularity right. The object names introduced in most parts of the MIB module conform to that rule. But unfortunately, the object names in the isnsNotificationsInfo branch are not built this way. IMHO, it would have been much more preferable to have the following name changes applied (unfortunately, it's too late now for such modification): isnsAddressNotificationType --> isnsNotificationAddressType isnsAddressNotification --> isnsNotificationAddress isnsTcpPortNotification --> isnsNotificationTcpPort isnsUdpPortNotification --> isnsNotificationUdpPort