[Fwd: iSCSI - revised 2.2.4]

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

What is the resolution on this issue ?

- Santosh


Santosh Rao wrote:
> 
> Julian,
> 
> I apologize upfront for being so persistent on this.
> 
> However, it would really help if you could give some clear example of a
> scenario as to why the initiator cannot be considered the originator of
> a negotiation, when it offers a key value implicitly, through the use of
> a default.
> 
> Several people on this list (Paul Konning, Sanjeev, Deva, myself, and
> perhaps others, that I cannot recall at the moment) have asked that the
> spec must not differentiate login behaviour when the initiator offers a
> key explicitly vs. when it offers a key implicitly thru the use of the
> default.
> 
> Please help us understand the need for iscsi to distingush the login
> behaviour in the above case. [through some tangible scenarios and
> examples].
> 
> Thanks,
> Santosh
> 
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> >
> > Julian,
> >
> > I would also request an explicit definition of offering party and
> > responding party. The current text still leaves ambiguity when target
> > sends a key in response to implicit default key of the Intiator. In
> > this case who is the offering party and who is the responding party
> >
> > Sanjeev
> >
> >      -----Original Message-----
> >      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >      Sent: Friday, October 05, 2001 2:06 PM
> >      To: ips@ece.cmu.edu
> >      Subject: iSCSI - revised 2.2.4
> >
> >      Here is a revised (complete) part 2.2.4 based on recent
> >      agreed changes:
> >
> >      1.1.1        Text Mode Negotiation
> >
> >      During login and thereafter some session or connection
> >      parameters are negotiated through an exchange of textual
> >      information.
> >
> >      All negotiations are stateless - i.e. the result MUST be
> >      based only on newly exchanged values.
> >
> >      The general format of text negotiation is:
> >
> >      Originator-> <key>=<valuex>
> >      Responder-> <key>=<valuey>|reject|NotUnderstood
> >
> >      The value can be a number, a single literal constant a
> >      Boolean value (yes or no) or a list of comma separated
> >      literal constant values.
> >
> >      In literal list negotiation, the originator sends for each
> >      key a list of options (literal constants which may include
> >      "none") in its order of preference.
> >
> >      The responding party answers with the first value from the
> >      list it supports and is allowed to use for the specific
> >      originator.
> >
> >      The constant "none" MUST always be used to indicate a
> >      missing function. However, none is a valid selection only if
> >      it is explicitly offered.
> >
> >      If a target is not supporting, or not allowed to use with a
> >      specific originator, any of the offered options, it may use
> >      the constant "reject".  The constants "none" and "reject"
> >      are reserved and must be used only as described here.  Any
> >      key not understood is answered with "NotUnderstood".
> >
> >      For numerical and single literal negotiations, the
> >      responding party MUST respond with the required key and the
> >      value it selects, based on the selection rule specific to
> >      the key, becomes the negotiation result.  Selection of a
> >      value not admissible under the selection rules is considered
> >      a protocol error and handled accordingly.
> >
> >      For Boolean negotiations (keys taking the values yes or no),
> >      the responding party MUST respond with the required key and
> >      the result of the negotiation when the received value does
> >      not determine that result by itself.  The last value
> >      transmitted becomes the negotiation result.  The rules for
> >      selecting the value to respond with are expressed as Boolean
> >      functions of the value received and the value that the
> >      responding party would select in the absence of knowledge of
> >      the received value.
> >
> >      Specifically, the two cases in which responses are OPTIONAL
> >      are:
> >
> >      - The Boolean function is "AND" and the value "no" is
> >      received. The outcome of the negotiation is "no".
> >      - The Boolean function is "OR" and the value "yes" is
> >      received. The outcome of the negotiation is "yes".
> >
> >      Responses are REQUIRED in all other cases, and the value
> >      chosen and sent by the responder becomes the outcome of the
> >      negotiation.
> >
> >      The value "?" with any key has the meaning of enquiry and
> >      should be answered with the current value or
> >      "NotUnderstood".
> >
> >      The target may offer key=value pairs of its own. Target
> >      requests are not limited to matching key=value pairs as
> >      offered by the initiator.  However, only the initiator can
> >      initiate the negotiation start (through the first Text
> >      request) and completion (by setting to 1 and keeping to 1
> >      the F bit in a Text request).
> >
> >      Comments ?
> >
> >      Julo
> 
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################