[storm] iSCSI MIB changes - compliance requirements Q

["Black, David" <[e-mail]>]

I'm finally resurfacing from the day job (once again) getting in the way
of IETF work :-).

In working through the IETF Last Call comments on the iSCSI MIB, an issue
has arisen around MIB compliance requirements.  A number of new objects are
being added to the revised iSCSI MIB, and the proposed approach is to make
them optional vs. mandatory to implement based on the reported value of
iSCSIProtocolLevel.

Here's the list of changes (not all of which are in the current MIB draft):

>   . Added iscsiInstXNodeArchitecture to InstanceAttributes
>   . Added iscsiSsnTaskReporting of type BITS to SessionAttributes
>   . Added iscsiSsnProtocolLevel to SessionAttributes
>   . Deprecated the marker objects
>   . Fixed the errata to [RFC4544]
>   . Added NOP counters at iSCSI session scope for heartbeat tracking
>   . Added port number to the iscsiTgtLoginFailure and
>      iscsiIntrLoginFailure notifications, and to the last failure info
>      in iscsiInitiatorAttributesEntry
>   . Added description string to the iSCSI portal
>   . Added iscsiInstSsnTgtUnmappedErrors to support "Target Unmapped"
>      session failure reporting in the iscsiInstSessionFailure
>      notification
>   . Added iscsiTgtLogoutCxnClosed and iscsiTgtLogoutCxnRemoved which
>      maintain the count of Logout Command PDUs received by the target
>      with reason codes 1 and 2 respectively
>   . Changed the conformance statements to match the above

And here are the values of the iSCSI Protocol Level key:

- 0: No version claimed
- 1: iSCSI consolidated draft/RFC-to-be
- 2: iSCSI consolidated draft/RFC-to-be + new features (SAM) draft/RFC-to-be

It's also possible to report the value 2 for an implementation that's
based on the older RFCs (primarily 3720 and 5048) plus the new features
draft/RFC-to-be.

None of the new objects require the new features (SAM) draft/RFC-to-be.
Also, we can't put any requirements on the value 0 for obvious reasons.

That leaves two choices - when the revised MIB is implemented (i.e., the
implementation claims compliance to the new iSCSI MIB draft/RFC-to-be),
the new features are required when:

	a) The implementation supports a value of the iSCSIProtocolLevel
		key of 1 or greater; OR
	b) The implementation supports a value of the iSCSIProtocolLevel
		key of 2 or greater.

Option a) would encourage a MIB update when an implementation is updated
to the iSCSI consolidated draft/RFC-to-be (minor work, as there's very little
functional change).  Option b) would encourage a MIB update when an
implementation is updated to the new features (SAM) draft/RFC-to-be (moderate
functional changes).  While the existing MIB RFC will be obsoleted by the new
MIB draft/RFC-to-be, it's always possible to implement the old MIB with
a newer implementation.

I've dithered on this, but my current inclination is to go with b), as
that associates the moderate functional changes in the new MIB with the
moderate functional changes in the new features (SAM) draft.

What do people think we should do?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------