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

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

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:
> 
> 	b) The implementation supports a value of the iSCSIProtocolLevel
> 		key of 2 or greater.

The MIB draft authors should update the draft accordingly.

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

> -----Original Message-----
> From: Mark Bakke [mailto:[e-mail]]
> Sent: Thursday, March 07, 2013 2:15 PM
> To: Black, David; [e-mail]
> 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
> 
> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Monday, March 04, 2013 5:48 PM
> To: [e-mail]
> 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.
> 
> 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]
> ----------------------------------------------------
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm