SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI - revised 2.2.4



    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
    > ##################################
    > 
    
    


Home

Last updated: Mon Oct 08 22:17:24 2001
7143 messages in chronological order