Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-storm-iscsimib-03.txt

From: "Prakash Venkatesen, ERS-HCLTech" <[email-masked]>
Date: Tue, 2 Apr 2013 22:23:13 +0530

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

All the review comments from Gen-ART review have been incorporated. Please note my comments inline, marked Prakash>.

regards
Prakash

________________________________________
From: Romascanu, Dan (Dan) [[email-masked]]
Sent: Sunday, January 27, 2013 10:35 PM
To: [email-masked]
Cc: Prakash Venkatesen, ERS-HCLTech; [email-masked]; [email-masked]; Martin Stiemerling; [email-masked]
Subject: Gen-ART Review of draft-ietf-storm-iscsimib-03.txt

(I missed one of the authors at the first send)

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-storm-iscsimib-03.txt
Reviewer: Dan Romascanu
Review Date: 1/27/13
IETF LC End Date: 1/28/13
IESG Telechat date: (if known)

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.

2) A number of changes where agreed by the WG, as reflected in the message http://www.ietf.org/mail-archive/web/storm/current/msg00652.html, according to which:

> In order to move forward, I suggest that the authors make the functional changes [1] - [6], not make changes [A] - [F] and [I}, and use their best judgment on what (if anything) to do about [G] and [H]

My understanding is that the changes [1]-[6] were implemented, and the authors applying their best judgment did not implement [G] and [H]. However, changes [1]-[6] are npt reflected in Section 5.

Prakash> Fixed this in the new draft: updated Section 5.

3) I did not perform a MIB Doctor review of the document. I notice however that the text Security Considerations section and the corresponding references do not conform to the latest version of the guidelines for the Security Considerations sections in MIB documents, as per https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security#

Prakash> Fixed this in the new draft: updated Security Considerations section.

Minor issues:

Nits/editorial comments:

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Apr 2013 11:31:03 +0000

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:[email-masked]]
> 
> 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

---

From: "Prakash Venkatesen, ERS-HCLTech" <[email-masked]>
Date: Wed, 3 Apr 2013 17:46:08 +0530

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) [[email-masked]]
Sent: Wednesday, April 03, 2013 5:01 PM
To: Prakash Venkatesen, ERS-HCLTech; [email-masked]
Cc: [email-masked]; [email-masked]; Martin Stiemerling; [email-masked]
Subject: RE: Gen-ART Review of draft-ietf-storm-iscsimib-03.txt

Hi Prakash,

Thanks and Regards,

Dan

::DISCLAIMER::

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Apr 2013 12:20:22 +0000

Hi Prakash,

Thanks for this further clarification. 

>From my perspective the document is Ready. 

Regards,

Dan

> Sent: Wednesday, April 03, 2013 3:16 PM
> To: Romascanu, Dan (Dan); [email-masked]
> 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:
> --
> 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
> 
> 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).
> 
> 
> 
> 
> 
> > 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.
> > to be used during the transition, function of the iSCSI versions of
> > the protocol.
> >
> > 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.
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> ----