Subject: RE: iSCSI:Target Reset

From: [email-masked]
Date: Wed, 25 Apr 2001 21:02:32 +0300

It looks close to a decent solution. As we are still trying to minimize
options we may want to specify a response code telling that the result was
"good" but no reset was really done (except for authorized users)
This will satisfy legacy software and will avoid the harm John is so
concerned about and avoid adding an option.

I said already on this list that removing it is really a bad idea as any
management program will need probably full access to the SCSI command set.

Julo

[email-masked] on 23/04/2001 18:19:29

Please respond to [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI:Target Reset

With my co-chair hat off, my inclination would be to
specify it (since it's in SAM) but include words about
the risks, make support for it OPTIONAL, and point out
that implementations may want to have access controls
on which initiators are permitted to do this.  I'm
assuming that at least two implementations will do
this so that we don't get into that issues of potentially
needing to remove this in order to go from Proposed
Standard to Draft Standard in the future.

--David

> -----Original Message-----
> From:   John Hufferd [SMTP:[email-masked]]
> Sent:   Sunday, April 22, 2001 5:52 PM
> To:     [email-masked]
> Subject:     iSCSI:Target Reset
>
> (resend of message with iSCSI in Subject)
> I thought we had a number of discussion previously about Target Reset
> (Warm
> or Cold).  I thought there was general feeling that this command is so
> dangerous that it should not be supported by iSCSI.  The long distance
> capability of iSCSI makes the risks involved unmanageable.  There should
> only be an Admin way to do this.
>
> Some folks have said that we could permit it and have special
> authorization
> etc.  This would probably cause a separate section in the spec. to define
> the authorization approach,  and what ever other security is needed to
> prevent this from inappropriately being used.  All for what purpose?
This
> can not be part of error recovery from a normal initiator.  The wide
> spread
> effect is too great for that.
>
> I would like to hear from the list about their feeling on this item.
>
>
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Internet address: [email-masked]

---

From: "Robert D. Russell" <[email-masked]>
Date: Wed, 25 Apr 2001 16:02:19 -0400

Julo:

A simple question:
  During the Login Phase, or during an exchange of text and text-response
  messages during the Full Feature Phase, can the target introduce a
  key=value or key=list pair that has not previously been offered by the
  initiator?

Example:
  Suppose the initiator is happy with the default value of 8 for
  MaxConnections, and therefore does not offer this key in any of the
  login or text messages it sends to the target during the leading
  connection for the session.  Further suppose that the target cannot
  support 8 connections but only 1 connection and wants to inform the
  initiator of this fact.  The only way it can do this is to send a
  login-response or text-response that includes "MaxConnections=1", even
  though this is not a "response" to anything offered by the initiator.

Reference:
  It seems possible to use parts of the current standard (v6) to justify
  either of 2 answers to this question: YES, or NO.  (And therefore, the
  real answer is currently a non-interoperable "maybe"!)

YES, the target can introduce a key=value or key=list pair in a
  login-response or a text-response even though the initiator did not
  previously offer this key in a login or text message.
  
  Justification:
  On page 16, the last paragraph of Section 1.2.4 on Text Mode Negotiation
  talks in terms of "the offering party" and "the responding party",
  presumably implying that either the initiator or the target can be the
  "offering party".

  On page 51, the last paragraph of section 2.9.1 about the F (Final) Bit
  says "if (the Final Bit is) set to 0 in a response to a text command with
  the Final Bit set to 1 it indicates that the target has more work to do
  (invites a follow-on text command)".  It is unclear what this "more work"
  might be, and it is also unclear whether that "follow-on text command"
  from the initiator could include the initiator's "response" to a key=value
  or key=list pair introduced by the target in this response.

NO, the target cannot introduce a key-value pair in a login-response or a
  text-response -- it can ONLY respond to keys explicitly offered by the
  initiator in the login or text message being responded to.

  Justification:
  On page 84, the second paragraph of Section 4.3 on Operational Parameter
  Negotiation During the Login Phase says "Operational parameter negotiation
  MAY involve several request-response exchanges (login and/or text) always
  driven by the initiator."  Further, on page 85, the second paragraph of
  Section 5 on Operational Parameter Negotiation Outside the Login Phase
  again reiterates "Operational parameter negotiation MAY involve several
  text request-response exchanges always driven by the initiator."
  Depending on what you understand by "driven", this could mean that only the
  initiator can offer keys, and the target can only respond to offered keys.
  (It could be that "driven" on both these pages refers only to the setting
  of the F bit, in which case it implies nothing about key=value pairs).

  Furthermore, on page 51, the first paragraph of Section 2.9.3 on Text
  Response Data says "The Text Response Data Segment contains responses in
  the same key=value format as the Text Command and with the same length and
  coding constraints.  Appendix C lists some basic Text Commands and their
  Responses."  This clearly says that a Text Response from the target
  can only contain responses.  The rest of section 2.9.3 also gives the
  impression that the target cannot introduce any new key=value pairs
  in a response, because it says what to do "if the Text Response does not
  contain a key that was requested", and that "Text response key=value
  pairs MUST be delivered in the same order as the command key=value pairs
  whenever applicable".  This section gives no indication that new key=value
  pairs are allowed in the response, and if they are, where they could be
  inserted in the ordering of key=value pairs in the response.

In general, except for the use of the terms "the offering party" and "the
  responding party" in Section 1.2.4, the whole tone of the standard reads
  as if only the initiator can offer key=value or key=list pairs, and the
  target can only respond with values for offered keys.  I say this because
  when you read section 2.8 on the Text Command, nowhere does it say anything
  about what to do if the target sends a response that offers a key that
  had not previously been requested by the initiator.  Likewise, section
  2.9 on the Text Response includes nothing to indicate that the keys in
  this response can be different from those offered in the previous Text
  Command.  Likewise, section 4.2 starting on page 82 describes primarily
  the Security and Integrity Negotiation, but frequently mentions iSCSI
  non-security parameters.  The last paragraph on page 82 explicitly
  says "The initiator sends a text command with an ordered list of the
  options it supports for each subject (authentication algorithm,
  iSCSI parameters and so on)", which implies that operational parameters
  can be offered in this way by the initiator.  The description of the
  target response on page 83 implies that the target can only select
  the appropriate choice to keys offered by the initiator.  There is no
  hint of the target offering the initiator any new keys.

  Even section 1.2.4 on page 15, which generally talks about "offering party"
  and "responding party", does not do so in paragraph 5:
  "If a target is not supporting, or not allowed to use with a specific
  initiator, any of the offered options, it may use the value "reject".
  This clearly says that only targets can do this, not initiators, and
  would therefore seem to imply that targets cannot offer options.

Resolution:
  The standard should unambiguously state the answer to this question
  someplace.  I would suggest in section 1.2.4, but it would not hurt
  to reiterate it in other places as well, such as in section 4 on the
  Login Phase.  In addition:

  if the answer is "YES", then add some statements in sections 2.8 and 2.9
  to describe how to handle these offers from the target at the same level
  of detail as is now done in those sections for handling offers from the
  initiator.

  if the answer is "NO", then get rid of the terms "offering party" and
  "responding party" in section 1.2.4 (this is the only place in the
  standard where those terms are used), and add statements in sections 2.8
  and 2.9 to explicitly state that targets cannot offer new keys to an
  initiator.

  Furthermore, if the answer is "NO", then what should the target do in
  the example I gave at the start of this e-mail?

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 26 Apr 2001 16:04:01 -0400

Bob,

Excellent question.  I agree that it's unclear too, and I'm not even
sure what's `right' independently of what the spec says.  I think the
problem goes deeper than a simple yes/no.

My reading of the spec is that it (the spec) is 90% convinced that the
target can not `talk out of turn' (once a channel guy....).  However,
you have pointed out one (MaxConnections) of several examples where
this assumption doesn't work right.  Another example is marker
parameters---the target might want to ask for them even if the
initiator's not into it.  Furthermore, even if the initiator does
enable markers with an FMarker parameter, the targer may respond with
FMarker AND MarkInts, even though the initiator is satisfied with the
default values, and so, did not send the parameters.

I have proposed that we precisely specify the exchange characteristics
for each parameter in the operational set (security parameters already
seem to be well specified by merit of the fact that security exchanges
are themselves precisely defined).

Beyond the exchange characteristics of the parameters themselves comes
how they should appear in PDUs.  If the parameter exchanges are very
free-formed, the implementation complexity increases massively for no
corresponding increase in capability.  I.e. who really cares if
parameters must be sent in a specification-defined order versus any
order you feel like?  Who cares if you the target can return responses
in a single PDU or multiple?

I have a well formed opinion about how to specify to cut the
implementation complexity, but I want to get the requirements on the
table first.

Steph

---

From: Sandeep Joshi <[email-masked]>
Date: Thu, 26 Apr 2001 17:40:26 -0400

Steph,

It seems that the target is allowed to propose parameter values.
See http://ips.pdl.cs.cmu.edu/mail/msg03273.html

It seems that the statement which was added to resolve this 
is in Sec 2.8.3
 "All these keys except the X- extension formatted MUST be 
  supported by iSCSI initiators and targets"

I agree that the legal permutations need to be more clearly stated.
  
And your efforts to cut any implementation complexity will undoubtedly 
earn much goodwill :-)

regards,
-Sandeep