Subject: Re: Review of the 07 draft

From: "Jim Hafner" <[email-masked]>
Date: Fri, 3 Aug 2001 14:26:47 -0700

Bob,

Nice job!  I have a couple of things I want to remark on.

You wrote:

>Section 1.2.7
>On page 28, in the fourth to last paragraph in this section, there is a
>description on how a target can assume an iSCSI Initiator Name, as
>learned through authentication.  This is a confusing paragraph, and we
>cannot determine if it is implying that the target should use the
>initiator name it has been given through some service, or that it was
>authorized to use by an initiator that discovered its iSCSI functions.
>Can this paragraph be further expanded to clarify how the name was
>determined?

In my opinion (as I stated in an earlier note), I think this whole
paragraph, and any other text related to third-party stuff should be
deleted from the draft, not expanded on.  This is a complex issue with many
different points of view and differing interpretation of requirements, from
application and management requirements, to simplicit/complexity of the
protocols involved with lots of security sprinkled in.  I would like this
dropped from the current draft and addressed at a later time (if necessary
-- and I'm not convinced that it is, at least at the level of the iSCSI
protocol).

You also wrote:
>Section 1.5.3
>The second paragraph on page 39 uses the term nexuses, but does not
>clearly build the relationship that the ISID rule is attempting to
>explain.  Can the level (I_T, I_T_L, I_T_L_x) of nexus be identified
>that is being referred to here, to help clarify the ISID rule mentioned
>in the previous paragraph?

This text is mine.  What this is referring to is just the I_T part of the
nexus (as that is the only part that iSCSI is involved in).  The text does
say "between the same two SCSI initiator and SCSI target ports".  I had
hoped that was clearly refering to the I_T.

And...
>The third to last sentence in this section alludes to the ability to use
>key=value pairs to perform active operations.  Since iSCSI active
>operations are interpreted by us as related to SCSI operations, what is
>being said here?  Does this mean that an initiator could perform
>mode-parameter or task management operations inside of Text Messages?
>If so, then more definition of this behavior is needed.

Well, in fact, the draft is supposed to say that MODE_SELECT for the
transport-specific mode page will NOT be done via SCSI, only via Text
commands.  I read that as saying that from the SCSI layer, all fields in
these pages are "unchangeable" (even though they can change in the iSCSI
layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
CHANGED unit attentions get thrown up at the SCSI layer when this happens
at the iSCSI layer.... You later have a clarifying question (Section 3) on
this as well.

Regards,
Jim Hafner

---

From: "Dev" <[email-masked]>
Date: Fri, 3 Aug 2001 17:18:45 -0700

Jim,

You wrote:
>Of course, the draft doesn't say whether MODE PARAMETERS HAVE

Yes it is necessary to return  unit attentions for Mode parameter changes
(changed through SCSI command).
it is within the domain of SCSI, not iSCSI . However a note on
implementation in the iSCSI spec that
discusses the mode parameters will be good.

Thanks

Deva
Platys communications

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 9 Aug 2001 15:07:47 -0400

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to him
and there may not be a user interface to the iSCSI driver. pSCSI sets these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI layer
can set the mode pages. That would solve everything.

Eddy