Subject: [storm] iSCSI MIB changes - compliance requirements Q

From: "Black, David" <[email-masked]>
Date: Mon, 4 Mar 2013 18:48:20 -0500

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Mark Bakke <[email-masked]>
Date: Thu, 7 Mar 2013 13:15:06 -0600

David,

Option b seems most practical to me -- I would suspect that the old MIB is sufficient for most purposes, and there's no need to create a rush to go implement it sooner.

Mark

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Monday, March 04, 2013 5:48 PM
To: [email-masked]
Subject: [storm] iSCSI MIB changes - compliance requirements Q

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.

- 0: No version claimed

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.

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:

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.

Thanks,
--David

_______________________________________________
storm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/storm

---

From: "Black, David" <[email-masked]>
Date: Mon, 25 Mar 2013 18:50:50 -0400

I believe we have rough consensus for option b):

> 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:
> 

The MIB draft authors should update the draft accordingly.

Thanks,
--David (as storm WG co-chair)

> From: Mark Bakke [mailto:[email-masked]]
> Sent: Thursday, March 07, 2013 2:15 PM
> To: Black, David; [email-masked]
> Subject: RE: iSCSI MIB changes - compliance requirements Q
> 
> David,
> 
> Option b seems most practical to me -- I would suspect that the old MIB is
> sufficient for most purposes, and there's no need to create a rush to go
> implement it sooner.
> 
> Mark
> 
> 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.
> 
> 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.
> 
> implementation claims compliance to the new iSCSI MIB draft/RFC-to-be), the
> new features are required when:
> 
> 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
> 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.
>

---

From: Mark Bakke <[email-masked]>
Date: Tue, 26 Mar 2013 13:05:01 -0500

Great; thanks, David.

Mark

-----Original Message----
From: Black, David [mailto:[email-masked]] 
Sent: Monday, March 25, 2013 5:51 PM
To: Mark Bakke; [email-masked]
Subject: RE: iSCSI MIB changes - compliance requirements Q

I believe we have rough consensus for option b):

> 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:
> 

Thanks,

> Option b seems most practical to me -- I would suspect that the old 
> MIB is sufficient for most purposes, and there's no need to create a 
> rush to go implement it sooner.
> 
> Mark
> 
> 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.
> 
> based on the older RFCs (primarily 3720 and 5048) plus the new 
> features draft/RFC-to- be.
> 
> 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:
> 
> 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.
> 
> that associates the moderate functional changes in the new MIB with 
> the moderate functional changes in the new features (SAM) draft.
> 
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748