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

["Prakash Venkatesen, ERS-HCLTech" <[e-mail]>]

Hi All,
I have posted an updated version of the draft:
http://www.ietf.org/id/draft-ietf-storm-iscsimib-04.txt

The new draft has option (b) as per rough consensus of STORM group: new features are required when implementation supports a value of the iSCSIProtocolLevel key of 2 or greater.

All the review comments from Gen-ART review have also been incorporated.

regards
Prakash

________________________________________
From: Mark Bakke [[e-mail]]
Sent: Tuesday, March 26, 2013 11:35 PM
To: Black, David; [e-mail]; Prakash Venkatesen, ERS-HCLTech
Subject: RE: iSCSI MIB changes - compliance requirements Q

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


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------