Found 4 records.

Status: Verified (1)

RFC 4939, "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", July 2007

Errata ID: 1026
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-14
Verifier Name: Lars Eggert
Date Verified: 2008-12-19

(2)  Section 5 (MIB Module)

(2a,b)  isnsNumPortals and isnsNumPortalGroups  (page 26)

The DESCRIPTION clauses of the isnsNumPortals and isnsNumPortalGroups
OBJECT-TYPE declarations deviate from the wording for used the
related 'sibling' MIB objects making the text a bit too unspecific.
The replacement text proposed below is aligned with the text pattern
used throughout the upper part of page 26.

(2a)
For isnsNumPortals, the RFC says:

          DESCRIPTION
|     "The current total number of Portals registered in iSNS.
       This is the number of rows in isnsRegPortalTable."

It should perhaps better say:
                                                         vvvvv
          DESCRIPTION
|     "The current total number of Portals registered in this iSNS
|      instance.  This is the number of rows in isnsRegPortalTable."
       ^^^^^^^^
(2b)
For isnsNumPortalGroups, the RFC says:

          DESCRIPTION
|     "The current total number of Portal Groups registered in
|      iSNS.  This is the number of rows in isnsRegPgTable."

It should perhaps better say:
                                                              vvvvv
          DESCRIPTION
|     "The current total number of Portal Groups registered in this
|      iSNS instance.  This is the number of rows in isnsRegPgTable."
           ^^^^^^^^^

(2d)  isnsDdIscsiMemberName  (page 36)

The DESCRIPTION clause of the isnsDdIscsiMemberName OBJECT-TYPE
declaration says:

       [...]
       The node index used for a specific node name is only
       persistent across iSNS Server reinitializations for nodes
       that are in a Discovery Domain (DD) or are registered
|      control nodes.  This value is only required during row
|      creation if the storage node is not yet registered in the
|      iSNS Server instance.  If the storage node is not yet
|      registered, then the iSCSI Name MUST be provided with the
|      iSCSI node index during row creation in order to create the
|      1-to-1 mapping."

The tagged text makes almost no sense here, and should better have
been omitted, because row creation (and deletion) via SNMP in the
isnsDdIscsiMemberTable is not supported by (this version of) the
MIB module.

Hence, The RFC should better simply say:
       [...]
       The node index used for a specific node name is only
       persistent across iSNS Server reinitializations for nodes
       that are in a Discovery Domain (DD) or are registered
|      control nodes."


(2e)  isnsDdPortalMemberEntry  (page 37)

The DESCRIPTION clause of the isnsDdPortalMemberEntry OBJECT-TYPE
declaration says:

      "Each entry indicates an explicit addition of a portal to a
       discovery domain.  The explicit addition of an entity portal
       to a discovery domain indicates the portal is preferred for
       access to nodes of the entity for this discovery domain.
       Registered Portal Group objects are used in iSCSI to
|      indicate mapping of portals to nodes across all discovery
       domains.  Portals that have been explicitly mapped to a
|      discovery domain will be returned as part of a query that
       is scoped to that discovery domain.  If no portal of an
       entity has been explicitly mapped to a discovery domain,
       then all portals of the entity that provide access to a
       storage node are returned as part of a query.  The table
       indexes are the server instance, the DD ID of the Discovery
       Domain, and the Portal Index of the portal."

In the coupled context od SNMP and iSNS, the bare term 'query' is
ambiguous and its use might lead to some confusion.
Closely reading all other text in the document related to the
DD Portal Membership table, isnsDdPortalMemberTable, has indicated
to me that it makes only sense to talk about iSNS queries in the
context of the second tag mark above.
Further, IMHO an article is missing in the first tagged line above.

Altogether, the RFC should better say:

      "Each entry indicates an explicit addition of a portal to a
       discovery domain.  The explicit addition of an entity portal
       to a discovery domain indicates the portal is preferred for
       access to nodes of the entity for this discovery domain.
       Registered Portal Group objects are used in iSCSI to
|      indicate the mapping of portals to nodes across all discovery
       domains.  Portals that have been explicitly mapped to a
|      discovery domain will be returned as part of an iSNS query
       that is scoped to that discovery domain.  If no portal of an
       entity has been explicitly mapped to a discovery domain,
       then all portals of the entity that provide access to a
       storage node are returned as part of a query.  The table
       indexes are the server instance, the DD ID of the Discovery
       Domain, and the Portal Index of the portal."


(2i)  isnsServerNotificationGroup  (page 75)

At the very end of the MIB module, the isnsServerNotificationGroup
NOTIFICATION-GROUP declaration says:

      isnsServerNotificationGroup  NOTIFICATION-GROUP
          NOTIFICATIONS {
             isnsServerStart,
             isnsServerShutdown
                        }
          STATUS                  current
          DESCRIPTION
|     "iSNS Server Notification managed objects."
             ::= { isnsGroups 10 }

That DESCRIPTION clause IMHO is misleading and could easily be
confused with the DESCRIPTION clause of the isnsNotificationsObjGroup
OBJECT-GROUP declaration saying:
      "iSNS Notification managed objects."

Perhaps, the phrase used for the isnsServerNotificationGroup (marked
above) should better be:

|     "iSNS Server Notifications."

Notes:

confusion-reducing clarifications to Description clauses

Status: Held for Document Update (3)

RFC 4939, "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", July 2007

Errata ID: 1639
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

(1)  Section 3.3

The text of the second sentence in the second paragraph of
Section 3.3, at the bottom of page 5 of RFC 4939, apparently
is garbled by word omissions.

The RFC says:

   The count of objects registered in each iSNS server instance is shown
|  in the table isnsNumObjectsTable.  The provides a summary of the
|  number Discovery Domain Sets, Discovery Domains, Entities, Portals,
   Portal Groups, iSCSI Nodes, and iFCP FC Nodes and Ports.

It should perhaps say:

   The count of objects registered in each iSNS server instance is shown
|  in the table isnsNumObjectsTable.  This table provides a summary of
              vvv                       ^^^^^^^^
|  the number of Discovery Domain Sets, Discovery Domains, Entities,
   Portals, Portal Groups, iSCSI Nodes, and iFCP FC Nodes and Ports.

Errata ID: 1640
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

(2c)  isnsControlNodeIscsiNodeName  (page 28)

According to the DESCRIPTION clause in the isnsControlNodeIscsiNodeName
OBJECT-TYPE declaration, the SYNTAX clause should have been specified
with a formal SIZE limitation to 223 for this object as well, as has
been done for all other similar objects in this MIB module.

The RFC says:

      isnsControlNodeIscsiNodeName   OBJECT-TYPE
|         SYNTAX                  SnmpAdminString
          [...]

It should say:

      isnsControlNodeIscsiNodeName   OBJECT-TYPE
|         SYNTAX                  SnmpAdminString (SIZE (0..223))
          [...]

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

Report New Errata