Re: iSCSI - revised 2.2.4

[Dave Sheehy <dbs@acropora.rose.agilent.com>]

Santosh,

> Please take a second look at my mail below. My question was targeting
> all the operational keys that have a default defined for them.
> Specifically, that an initiator that uses the defaults must be
> considered the originator for that negotiation. 

I agree with this. A default is an implicit offer to my thinking.

> (Incidentally, all operational keys either have defaults specified or
> are mandated to be explicitly sent by the initiator. Thus, for all
> operational keys, initiator would be the originator.)

Agreed.

> The proposal does NOT attempt to prohibit targets from originating
> vendor specific keys.
> (Though I'm not certain,  what real value vendor specific target keys
> are going to be providing.)

Me either. That's for the target vendor to decide though. :-)

Dave

> 
> Thanks,
> Santosh
> 
> 
> Dave Sheehy wrote:
> > 
> > Marjorie,
> > 
> > Right, but Santosh's intent is to specify that the initiator is always
> > the originator. If that is true then targets cannot originate keys for
> > which there is no default. Other than a general bias in favor of
> > simplifying the protocol I don't feel strongly about this issue one way or
> > the other.
> > 
> > Dave
> > 
> > > In which case the initiator cannot be expected to know the default - Santosh
> > > explicitly referred to behavior WRT "protocol defaults".
> > >
> > > It makes sense to me to state that an initiator that does not offer a key
> > > specified by the iSCSI protocol document to have a default has essentially
> > > "implicitly offered" that key's default.  In which case, the target (even
> > > though it's the first to explicitly include the key) is the responder.
> > >
> > > When can the target assume that the initiator will not explicitly offer the
> > > key?
> > >
> > > Marjorie
> > >
> > > > -----Original Message-----
> > > > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com]
> > > > Sent: Monday, October 08, 2001 4:41 PM
> > > > To: ips@ece.cmu.edu
> > > > Subject: Re: iSCSI - revised 2.2.4
> > > >
> > > >
> > > >
> > > > Vendor specific keys have no (standard specified) default,
> > > > yes? Targets can
> > > > source vendor specific keys, yes? Aren't targets the
> > > > originator in this case?
> > > >
> > > > Dave
> > > >
> > > > > 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
> ##################################
>