iSCSI Parameter Negotiation

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

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
rdr@iol.unh.edu
603-862-3774