Subject: BKF Comments on iSCSI version 14

From: Brian Forbes <[email-masked]>
Date: Sun, 7 Jul 2002 11:25:45 -0700

I've sent a list of editorial comments directly to Julian.

Technical comments:

T1:  

Although it is alluded to in section 11.10, the document must explicitly
define the effective value of Buffer Offset for immediate data.  Possible
sections for doing so include 2.2.4 and 9.3.6.

T2:  

I agree with the recent reflector discussion that decimal is only used for
numbers, hex for numbers and binary, and base64 only for binary items.  I
believe the debate should focus on the utility of the existing iSCSI type
definitions and avoid getting derailed by anecdotal references to data types
in other RFCs.

T3:  

Section 4.3.1, page 80:  "If the reconfiguration of iSCSI portal groups is a
concern in a given environment, the iSCSI initiator MUST use this key to
ascertain that it had indeed initiated the Login Phase with the intended
target portal group."

The use of MUST in the final sentence is untestable and should probably be
lower-case "should".

T4:  

Section 11.8, page 215:  "If the TargetAddress is returned as the result of
a redirect status in a login response, the comma and portal group tag are
omitted."

For interoperability reasons, I believe "are omitted" should be "MUST be
omitted".

T5:  

Section 11.8, page 215:  "If the TargetAddress is returned within a
SendTargets response, the portal group tag is required."

For interoperability reasons, I believe "is required" should be "MUST be
included".

Brian Forbes
Technology
Brocade Communications

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 14 Jul 2002 10:58:54 +0300

Brian,

Thanks - comments in text Julo

Brian Forbes <[email-masked]>
Sent by: [email-masked]
07/07/2002 09:25 PM
Please respond to Brian Forbes

        To:     [email-masked]
        cc:     Robert Snively <[email-masked]>
        Subject:        BKF Comments on iSCSI version 14

Technical comments:

T1: 

+++ fixed in 2.2.4. This was requested also by Eddy +++
T2: 

I agree with the recent reflector discussion that decimal is only used for
numbers, hex for numbers and binary, and base64 only for binary items.  I
believe the debate should focus on the utility of the existing iSCSI type
definitions and avoid getting derailed by anecdotal references to data 
types
in other RFCs.
+++ One of the reasons people want SCSI on IP is to leverage all other IP 
infrastructure.
Unfortunately the usage of decimal is beyond anectodal and we just can't 
ignore it.
We have however - I think removed all the thorny related issues +++

T3: 

Section 4.3.1, page 80:  "If the reconfiguration of iSCSI portal groups is 
a
concern in a given environment, the iSCSI initiator MUST use this key to
ascertain that it had indeed initiated the Login Phase with the intended
target portal group."

+++ we have several such instances. This usage can be certified in lab 
test - although I agree that it untestable at run-time (has no check 
condition). The same goes for many other MUST requirements +++

T4: 

Section 11.8, page 215:  "If the TargetAddress is returned as the result 
of
a redirect status in a login response, the comma and portal group tag are
omitted."

+++ fixed +++

T5: 

+++ fixed +++
Brian Forbes
Technology
Brocade Communications

---

From: Brian Forbes <[email-masked]>
Date: Fri, 19 Jul 2002 09:57:01 -0700

Looks good, thanks.  I agree with the direction the 'decimal discussion' is
now going.
Brian Forbes
Brocade Communications 

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Sunday, July 14, 2002 12:59 AM
To: Brian Forbes
Cc: [email-masked]; [email-masked]; Robert Snively
Subject: Re: BKF Comments on iSCSI version 14

Brian, 

07/07/2002 09:25 PM 

        To:        [email-masked] 

Technical comments:

T1:  

T3:  

+++ we have several such instances. This usage can be certified in lab test
- although I agree that it untestable at run-time (has no check condition).
The same goes for many other MUST requirements +++ 

T4:  

T5:  

+++ fixed +++
Brian Forbes
Technology
Brocade Communications