RFC Errata
Found 6 records.
Status: Verified (2)
RFC 4544, "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", May 2006
Note: This RFC has been obsoleted by RFC 7147
Source of RFC: ips (tsv)
Errata ID: 1636
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Verifier Name: Lars Eggert
Date Verified: 2008-12-19
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."
Notes:
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.
Errata ID: 1637
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Verifier Name: Lars Eggert
Date Verified: 2008-12-19
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."
It should say:
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."
Status: Held for Document Update (1)
RFC 4544, "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", May 2006
Note: This RFC has been obsoleted by RFC 7147
Source of RFC: ips (tsv)
Errata ID: 1638
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Held for Document Update by: Lars Eggert
Date Held: 2008-12-19
(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.
^^^^^^^^^^^
(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.
Status: Rejected (3)
RFC 4544, "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", May 2006
Note: This RFC has been obsoleted by RFC 7147
Source of RFC: ips (tsv)
Errata ID: 61
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19
(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.
Notes:
--VERIFIER NOTES--
Item (9) - the situation in which "one of the LC counters wraps back to
zero" is a regular increment of a continuous counter, i.e., it
is not a discontinuity. Thus, this item is unfounded.
Errata ID: 1630
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19
(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.
Notes:
from pending
--VERIFIER NOTES--
duplicate of Errata #61
Errata ID: 1631
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19
(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.
Notes:
from pending
--VERIFIER NOTES--
duplicate of Errata #61