Re: iSCSI - revised 2.2.4

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

I think that's at least 6 people who're in favor of keeping login
behaviour identical when the initiator uses implicit keys (thru
defaults) vs. explicit keys. When do we get to call for consensus on
this one ? 

- Santosh


Dave Sheehy wrote:
> 
> 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
> > ##################################
> >

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