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

Report New Errata