Hi Prakash,

Thanks for this further clarification. 

>From my perspective the document is Ready. 

Regards,

Dan




> -----Original Message-----
> From: Prakash Venkatesen, ERS-HCLTech [mailto:prakashvn@hcl.com]
> Sent: Wednesday, April 03, 2013 3:16 PM
> To: Romascanu, Dan (Dan); gen-art@ietf.org
> Cc: mark_bakke@dell.com; david.black@emc.com; Martin Stiemerling;
> storm@ietf.org
> Subject: RE: Gen-ART Review of draft-ietf-storm-iscsimib-03.txt
> 
> Hi Dan,
> An RFC 4544 based implementation should continue to work. The value of
> iSCSIProtocolLevel to be 2 or higher is required to enable use of
> features in iSCSI SCSI Feature update (iscsi-sam). The new objects are
> required only when the iSCSIProtocolLevel is negotiated to 2 or higher.
> It is defined as a Conditionally mandatory group. Please note the
> corresponding portions of the MIB module below:
> --
> iscsiNewObjectsV2 OBJECT-GROUP
>     OBJECTS {
>         iscsiInstXNodeArchitecture,
>         iscsiSsnTaskReporting,
>         iscsiSsnProtocolLevel,
>         iscsiSsnNopReceivedPDUs,
>         iscsiSsnNopSentPDUs,
>         iscsiIntrLastTgtFailurePort,
>         iscsiTgtLastIntrFailurePort,
>         iscsiPortalDescr,
>         iscsiInstSsnTgtUnmappedErrors,
>         iscsiTgtLogoutCxnClosed,
>         iscsiTgtLogoutCxnRemoved
>     }
>     STATUS current
>     DESCRIPTION
>         "A collection of objects added in the second version of the
>         iSCSI MIB."
> --
>     GROUP iscsiNewObjectsV2
>     DESCRIPTION
>         "This group is mandatory for all iSCSI implementations
>         that support a value of the iSCSIProtocolLevel key of
>         2 or greater."
> --
> When an implementation is upgraded to enable using the features of
> iscsi-sam, it should start using the new MIB module as well. Until then,
> the new objects are not required.
> 
> regards
> Prakash
> 
> ________________________________________
> From: Romascanu, Dan (Dan) [dromasca@avaya.com]
> Sent: Wednesday, April 03, 2013 5:01 PM
> To: Prakash Venkatesen, ERS-HCLTech; gen-art@ietf.org
> Cc: mark_bakke@dell.com; david.black@emc.com; Martin Stiemerling;
> storm@ietf.org
> Subject: RE: Gen-ART Review of draft-ietf-storm-iscsimib-03.txt
> 
> Hi Prakash,
> 
> Thank you for addressing the issues raised in the Gen-ART review. The
> changes made on issues 2 and 3 are fine, however, one clarification is
> still needed regarding the first issue. See below (agreed stuff
> deleted).
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Prakash Venkatesen, ERS-HCLTech [mailto:prakashvn@hcl.com]
> >
> > Summary: Almost Ready
> >
> > Major issues:
> >
> > 1) This document will obsolete (when approved) RFC 4544, and add
> > support for iSCSI protocol evolution according to the consolidated
> > version of the iSCSI protocol (as per draft-ietf-storm-iscsi-cons) and
> > for the updates to iSCSI (as per draft-ietf-storm-iscsi-sam) for
> ProtocolLevel.
> > There is no indication however in for the operators when an upgrade is
> > recommended or becomes mandatory, and which version of the protocol is
> > to be used during the transition, function of the iSCSI versions of
> > the protocol.
> >
> > Prakash> As per rough consensus of STORM group, the new features are
> > required when implementation supports a value of the
> > iSCSIProtocolLevel key of 2 or greater. The new draft has this change.
> >
> 
> [[DR]] 'the new features are required' means that the MIB support MUST
> be updated accordingly when the iSCSI updates are deployed? In other
> words, would an RFC 4544 - based implementation break, or it will
> continue to work (with functional limitations) until the updated MIB
> version is introduced?
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> ::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.
> 
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> ----