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

[Mark Bakke <[e-mail]>]

Great; thanks, David.

Mark

-----Original Message----
From: Black, David [mailto:[e-mail]] 
Sent: Monday, March 25, 2013 5:51 PM
To: Mark Bakke; [e-mail]
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:
> 
> 	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