Subject: RFC 4544 (iSCSI MIB) issues and errata

From: Alfred Hönes <[email-masked]>
Date: Tue, 4 Jul 2006 15:44:56 +0200 (MESZ)

Hello,
after studying the recently published RFC 4544 (iSCSI MIB)
authored by you, I would like to submit a few comments
pointing to issues and errata in the RFC text.

(1)  outdated text

Within Section 6, the first paragraph on top of page 5 says:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module, currently under development,
   may be used to manage SCSI information for a device.

The last apparently sentence is outdated.  There already is an
appropriate Informative Reference given on page 81 of the RFC.
The RFC should say:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module [RFC4455] may be used to manage
   SCSI information for a device.
                                        ^^^^^^^^^^^

(2)  lack of distinguishing DESCRIPTION text

The iscsiDescriptors OBJECT-IDENTITY declarations, on page 16/17
of the RFC, unfortunately contain pairwise identical DESCRIPTION
clauses, making Header and Data Integrity identifiers
indistinguishable.
This obviously needs short-term correction, e.g.:

The DESCRIPTION clause of the iscsiHdrIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
<<page break>>
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the header is being used."

The DESCRIPTION clause of the iscsiHdrIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the header is CRC32c."

The DESCRIPTION clause of the iscsiDataIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the data is being used."

The DESCRIPTION clause of the iscsiDataIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the data is CRC32c."

(3)  4 similar typos

The DESCRIPTION clause of the iscsiInstSsnFailures  OBJECT-TYPE,
on page 20 of RFC 4544, says:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has been failed.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has failed.  If this counter has suffered a
        discontinuity, the time of the last discontinuity is indicated
        in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnDigestErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnFormatErrors OBJECT-TYPE,
on page 23 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

(4)  incomplete descriptions

Within the Target Attributes Table, the objects
    iscsiTgtLastFailureType,
    iscsiTgtLastIntrFailureName,
    iscsiTgtLastIntrFailureAddrType, and
    iscsiTgtLastIntrFailureAddr
apparently have no meaningful value if no error has occurred (yet).
The DESCRIPTION clauses for these objects, on page 38/39 of RFC 4544,
do not indicate the behaviour of these objects in this case, i.e.,
when the iscsiTgtLastFailureTime instance in a given conceptual
row has the value zero.
The respective DESCRIPTION clauses should indicate whether these
objects
  -   should not be instantiated
or
  -   have a certain default value (t.b.d.)
in this case.

A similar issue holds for the objects in the Initiator Attributes
Table,
    iscsiIntrLastFailureType,
    iscsiIntrLastTgtFailureName,
    iscsiIntrLastTgtFailureAddrType, and
    iscsiIntrLastTgtFailureAddr
(The corresponding DESCRIPTIONS can be found on page 46/47.)

(5)  row creation / storageType restriction

Various tables contain rows that can be created/deleted dynamically.
Repeatedly, for these tables the DESCRIPTION clauses for the
corresponding StorageType objects contain the sentence
(e.g., for iscsiTgtAuthStorageType, on page 44):

                                  [...].  Rows in this table that were
         created through an external process may have a storage type of
         readOnly or permanent.

It is not clear from the text what precisely 'external process'
means, and therefore it remains open whether/why the restriction
on values `readOnly` or `permanent` makes sense.

(6)  unpleasant alignment

Any future update to this RFC should correct the unpleasant
staggered tabular alignment of the following row-structure
( SEQUENCE { ... } ) declarations for:
  o  IscsiPortalAttributesEntry,
  o  IscsiInitiatorAttributesEntry, and
  o  IscsiInitiatorLoginStatsEntry

(7)  Semantic gap in Initiator Login Stats Table ??

The Initiator Login Stats Table somehow is a "dual" of the
Target Login Stats Table.
Therefore, I miss an object in the Initiator Login Stats Table
corresponding to iscsiTgtLoginAuthorizeFails, counting received
Login Response PDUs with status class 0x202.

(8)  typo?

The DESCRIPTION clause of the iscsiSsnAuthIdentity OBJECT-TYPE,
on page 58 of the RFC, says:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       method being used on this session, as communicated
        during the login phase."

I strongly suspect that it should say instead:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       identity being used on this session, as communicated
        during the login phase."

(9)  common problem with indiscontinuity tagging

The Session Stats Table defines and admits High-Capacity (64-bit)
and Low-Capacity (32-bit) octet counters.
If both types of counters are implemented, according to the
DESCRIPTION clauses of all these counters,

        [...]
        If this counter has suffered a discontinuity, the time of the
        last discontinuity is indicated in iscsiSsnDiscontinuityTime."

Hence, iscsiSsnDiscontinuityTime must indicate discontinuities
in the HC and the LC counters, i.e. it must be changed whenever
one of the LC counters wraps back to zero, making it almost
useless for efficient surveillance of discontinuities in all
the other counters covered by this object.
Perhaps, as it has been done in a few other IETF MIBs in the past,
inclusion of additional 32-bit counters yielding the high part
(most significant 32 bits) of the HC counters for use with SNMPv1
management stations would have allowed to change the semantics of
iscsiSsnDiscontinuityTime to avoid too frequent changes.

Please comment.
I propose to address items (1)..(3) and (8) above with
an RFC Errata Note, where (1), (3), and (8) apparently are
straightforward, while (2) - directly affecting interoperability -
perhaps needs your consent.
The other items at least should be noted for future consideration.

Best regards
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+