Subject: RE: iscsi : numerical negotiation wording is ambiguous

From: "Julian Satran" <[email-masked]>
Date: Mon, 1 Oct 2001 14:19:14 +0200

Sanjeev,

You are just missreading my text.
In your example there is no need for a reject.
Both parties will KNOW that the value selected is the lower of the 2 i.e. 
8192.
There is no reject.

Julo

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
01-10-01 14:00
Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        RE: iscsi : numerical negotiation wording is ambiguous

Thanks Julian, please find my further comments in the message
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Sunday, September 30, 2001 6:07 PM
To: [email-masked]
Subject: RE: iscsi : numerical negotiation wording is ambiguous

Sanjeev, 

I am not sure clear I made the tiny diference between what I say and what 
Santosh said: 

Santosh says: 
1.      a requester sends A=valuex 
2.      a responder sends B=valuey 
3.      the responder assumes that the value y is the correct value and so 
does an external observer 
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather say it this way the 
responder computes the value with its own supported values and responds 
with a value y which the responder thinks is correct and so does an 
external observer 
4.      the requester checks that valuey is conformant (he will not 
believe it) and will reject it if not conformant else it will accept it 
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, but it is highly 
unlikely for the responder to reject the final result because the rule 
states that (lower or higher of two will be the result) and so the 
offering party should be able to accept the lower or higher range as 
defined by rule. In case the key is dependent upon some range of fixed 
values then the negotiation should be performed as list negotiation and 
not numerical negotiation.

This might be what you "conventionally" do - I don't and that shows that 
convention like morals are a matter of geography :-) 
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) 

The advantage of this set of rules is that it allows an external observer 
to know what was selected without knowing the rules 
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this case, I guess that the 
external observer has to know the rules to double check the value is 
correct or not
The disadvantage is that messages have to be "built", an additional reject 
states exists and MOST IMPORTANT you need both messages 

In what I said: 

1. The requester sends A=valuex 
2. The Responder has to send either nothing (if valuex is enough on both 
sides to compute the result like in the case in which the function is a 
Boolean AND and the value is NO) or valuey 
3. Both the requestor and responder have to compute the value (they have 
to know the rules anyhow) and so does the external observer 

The disadvantage is that the external observer has to know the rules 
The advantage is that there is no reject, in binary negotiations you can 
go away with shorter negotiations and you can set strings at fixed values. 
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is no reject , but it 
can be a problem in future . Consider your example of DataPDULength in 
your own message. Suppose offering party sends a value of 16,384 (this is 
also lowest value it can send) and responding party responds with 8,192. 
In this case the offering party will have to reject the negotiation. So a 
reject message is needed in this case also.
 
Sanjeev 

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]> 
Sent by: [email-masked] 
30-09-01 16:32 
Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" 
        
        To:        "'Santosh Rao'" <[email-masked]>, Julian 
Satran/Haifa/IBM@IBMIL 
        cc:        [email-masked] 
        Subject:        RE: iscsi : numerical negotiation wording is 
ambiguous 

All,

I agree with Santosh that the responding party must respond the result of
the negotiation as compared with the value from offering party. All
negotiations in SCSI like (sync, disconnect etc) are also done the same 
way.
I also object to Julian's reason of a simple minded target which wants to
send certain fixed values only. In case a simple minded target identifies 
a
value which it cannot support or is less than the value a target can
support, then there should be a method for target to reject such a
negotiation and the default values be accepted on both side as a result of
negotiation. 

1 Because even if simple minded target sends its fixed value which is
greater than the value sent by offering party then the final result of
negotiation will be taken as ( lesser of the two) and in this case target
which which cannot support the lower value will produce some illegal
results.

2. if simple minded target wants to send its own value and wants it to be
accpeted then the responding party is not negotiating but forcing the 
result
on initiator(this method should not be allowed unless explicitly 
mentioned).

however if there is another proposal of numeric negotiation in which the
responding party can force its result to be over ridden by the offering
party's result then it is acceptable for offering party and responding 
party
to send there own supported key-value result and it can then be computed 
at
offering party's end.

IMP: (May be I am missing something here) I do not see how a numeric
negotiation can be rejected. Is it possible to reject such kind of
negotiaion?

Sanjeev

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Friday, September 28, 2001 11:15 PM
To: Julian Satran
Cc: [email-masked]
Subject: Re: iscsi : numerical negotiation wording is ambiguous

Julian & All,

I request the group to take a close look at this negotiation process
again and [re-]evaluate the alternative being proposed.

Further, it appears that the login stage negotiation  is also following
the same algorithm as the login key negotiation, wherein originator &
responder offer their respective values and both sides need to determine
the result of the negotiation. i.e. both initiator and target need to
compare their NSG with the other party's NSG and pick the lower of the
2.

I suggest that both the login key negotiation and the login stage
negotiation follow the policy that the originator offers a value and the
responder picks the result of the negotiation based on (the offered
value & its own value). The value picked by the responder is sent back
to the originator.

This model has the following advantages :

1) Only one side picks the result of the negotiaton. Hence, the 2 sides
cannot go out of sync on the value picked.

2) The originator knows the negotiated result at the the responder since
the responder sends back the result of the negotiation.

3) This model is easier to debug because of (1) & (2).

4) Less code since only 1 party (responder) needs to perform the
computation to pick the result of the negotiation.

5) This scheme leaves less room for interop problems and
mis-interpretation since it is the more familiar negotiation technique
that is in use in most other mass storage protocols. (ex : FC PLOGI, FC
PRLI, etc). From a first reading of the current negotiation scheme, it
is'nt readily apparent that the currently defined model is different
from the above and requires both sides to be picking the result of the
negotiation, instead of just the responder.

Comments ?

Thanks,
Santosh

Julian Satran wrote:
> 
> Santosh,
> 
> I understood what you wording means but I am not sure that we want all 
the
> side-effects.
> The negotiation as defined  now allows both parties requester or 
responder
> to state their wishes and the LAW
> insatiate the result in both.
> 
> Your wording means that the responder selects the value according to the
> rule. What if the responder is either a rogue or
> just a simple minded target.  Let me give an example:
> 
> I am building a simple minded target that has an 8K buffer and says
always
> (has it wired) DataPDULength=8192
> in its first Login response (that is his buffer).
> 
> If an initiator sends him as a "offer" or as a "responder" 16192 then 
with
> the current wording things are fine and both will
> have settled to 8192.
> 
> If the initiator sends an offer of 4096 and the target gives his (only
> thing he knows) 8192 it is still fine - both select 4096.
> 
> With your wording some of the negotiations will fail since you assume 
that
> the rule should be expressed in building the answer and not in selecting
> the result.
> 
> In the end in both case you have to do selections at both target and
> initiator but the current rule enables simple-minded prewired messages
> while your does not (the responder message defines the selection and the
> offerer has to check it).
> 
> Sorry for this long message for such a simple question.
> 
> Julo
> 
> 
>                     Santosh Rao
>                     <santoshr@cup.       To:     [email-masked]
>                     hp.com>              cc:
>                     Sent by:             Subject:     Re: iscsi :
numerical negotiation wording
>                     owner-ips@ece.        is ambiguous
>                     cmu.edu
> 
> 
>                     26-09-01 23:16
>                     Please respond
>                     to Santosh Rao
> 
> 
> 
> Julian,
> 
> What is the responding party supposed to offer ? Is it supposed to
> determine the result of the
> negotiation (higher or lower value, as the case may be) and send that as
> its response ?
> 
> Or, is it supposed to send in its numerical value and the initiator 
picks
> the higher or lower of
> the 2 ?
> 
> This does'nt come across clear enough in the definition and is open to
> mis-interpretation. Please
> see the suggested re-word in its place.
> 
> Thanks,
> Santosh
> 
> Julian Satran wrote:
> 
> > Santosh,
> >
> > I am missing something. The rule states what value both parties should
> have
> > after both have seen the two values.
> > Obviously we assume that no error occurs and the responder value is 
seen
> y
> > the offering party or the negotiation fails.
> >
> > What exactly is ambiguous about it?
> >
> > Julo
> >
> >
> >                     Santosh Rao
> >                     <santoshr@cup.       To:     [email-masked] (ips)
> >                     hp.com>              cc:
> >                     Sent by:             Subject:     iscsi : 
numerical
> negotiation wording is
> >                     owner-ips@ece.        ambiguous
> >                     cmu.edu
> >
> >
> >                     26-09-01 19:59
> >                     Please respond
> >                     to Santosh Rao
> >
> >
> >
> > Julian & All,
> >
> > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97
> > reads :
> >
> > "In numerical negotiations, the offering and responding party state
> >  a numerical value. The result of the negotiation is key dependent;
> >  frequently the lower or the higher of the two values is used."
> >
> > The above definition is ambiguous, since it does not specify whether 
it
> is
> > the originator or the responder that computes the result of the
> > negotiation.
> >
> > i.e. Is it the responsibility of the target to pick the higher or 
lower
> of
> > the 2 values and respond with the result of the negotiation ?
> >
> > OR :
> > Is it the originator that has to pick the result of the negotiation
> > based on the key it sent and the key it got back ?
> >
> > I would suggest that the wording be clarified to indicate that the
> > responder picks the result of the negotiation and sends this result 
back
> > in its response for this key.
> >
> > Perhaps, some re-wording along the following lines may be in order :
> >
> > "In numerical negotiations, the offering party states a numerical
> >  value, and the responding party states the result (operational value)
> >  after the negotiation.  The result of the negotiation is key
> >  dependent; responder determines it based on the lower or the higher
> >  of the two values - offering party's value, and what the responder
> >  can support."
> >
> > Comments ?
> >
> > Regards,
> > Santosh
> >
> > --
> > #################################
> > Santosh Rao
> > Software Design Engineer,
> > HP, Cupertino.
> > email : [email-masked]
> > Phone : 408-447-3751
> > #################################
> 
> #### santoshr.vcf has been removed from this note on September 27 2001 
by
> Julian Satran

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Mon, 1 Oct 2001 21:20:31 +0200

Oke, i can accept this because  a renogotiation still allows some room for
flexibility where a little misbehaving devices can still work.

So if we come to conclusion of this thread we dont need an reject message in
both case and there should be a consensus call for the way of negotiation
whether (initiator determined negotiation or responder determined)

Sanjeev          

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Monday, October 01, 2001 9:07 PM
To: Sanjeev Bhagat (TRIPACE/Zoetermeer)
Cc: [email-masked]
Subject: Re: iscsi : numerical negotiation wording is ambiguous

Sanjeev,

I do not believe your example is in line with the discussion. I'd rather
you considered the case of an FC initiator that got back a PLOGI
response with parameters that are not acceptable for that initiator. Do
you expect the initiator to send a LS_RJT to the target ??? 

I would hope not :)

The FC initiator would give up on that Nx_Port and move onto another
one. Ditto for iSCSI. Either re-negotiate parameters, or close the TCP
connection. REJECTs are only sent from targets to initiators.

Regards,
Santosh

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> 
> Julian, Santosh,
> 
> Here is what i have to say
> 
> In either of the cases reject message is not needed if there is no double
> check required.
> 
> A reject is needed in both cases to allow some flexibility and i will give
> you an example for this
> 
> All SCSI devices today available have Sync options for more than 10MB/sec.
> 
> Consider a chip designed which works fine for sync negotiation rate of
> upto40MB/sec but misbehaves or behaves illegally for sync options less
than
> 10 MB/sec. In such case a device driver for such a chip will start
> negotiating with the SCSI device for 40 MB/sec. If the SCSI device returns
a
> value of 8MB/sec then in this case the device driver must send a reject
> message for sync negotiation. (although it is an illegal condition but it
> still allows room for slightly misbehaving devices to operate properly in
> Non-SYNC mode). This is my basis of saying that we must have a reject
> message in both cases although it is strictly not required.
> 
> Sanjeev
> Sent: Monday, October 01, 2001 8:38 PM
> To: [email-masked]
> Cc: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Julian Satran'
> Julian & Sanjeev,
> Responding to both your mails......
> 
> Julian :
> 
> I think you may have mis-interpreted my comments. I believe Sanjeev has
> clarified the intent of my suggestions.
> 
> I am *not* suggesting that the responder send back its values and these
> be blindly imposed on the originator. On the contrary, my suggestion is
> that the computation of the result of the negotiation (higher or lower
> of the 2 values) be only performed by the responder and sent back to the
> originator.
> 
> The result of the negotiation is the same in both cases and there is no
> REJECT required in my case nor yours. The difference is the advantages
> I've stated in my model.
> 
> Sanjeev, in response to your comment :
> 
> " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >  no reject , but it can be a problem in future .
> >  Consider your example of DataPDULength in your own
> >  message. Suppose offering party sends a value of 16,384
> >  (this is also lowest value it can send) and responding
> >  party responds with 8,192. In this case the offering
> >  party will have to reject the negotiation. So a reject
> >  message is needed in this case also. "
> 
> There is NO need for any REJECT in the above case. If the initiator
> is'nt satisfied with the value returned by the originator and cannot
> function with the negotiated values, it can simply close the TCP
> connection. There is no need to send any REJECT.
> 
> Thanks,
> Santosh
>

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Oct 2001 15:16:26 +0300

Santosh,

Yes we are getting nowhere.

You do not seem to accept the disadvantages of restricting the selection 
to the responder
and I will not agree to add a restriction unless it has unequivocal value.

Recall please that both sides have to effect the same computation anyhow 
and you add a reject state (and thus make the state machines more complex) 
only for having a clear result on the wire (internally the result is the 
same in all cases).

Julo

Santosh Rao <[email-masked]>
Sent by: [email-masked]
01-10-01 23:52
Please respond to Santosh Rao

Julian,

It does appear that we are getting nowhere with this discussion :<. I
would like to re-iterate the advantages of the "responder computes
negotiation result" model vs. the "both sides compute negotiation
result" model again :

 
 
4) Less code since only 1 party (responder) needs to perform the
computation to pick the result of the negotiation. The originator only
needs to only check that the response it got back is acceptable.
Standard parsing technique in mass storage. (ex : FC PLOGI, FC PRLI,
SCSI Mode Sense parsing by initiator uses the same scheme.)
 
negotiation, instead of 
just the responder.

6) Less protocol rules to be enforced. No need to call out the rules for
each side explicitly. The responder picks the result & sends it back to
originator.

Clearly, at least 3 developers read the draft to imply the negotiation
scheme in use is "responder picks the negotiation result". So, there is
room for mis-interpretation here. Based on the above advantages, I feel
it is a safer model, with no room for mis-interpretations. In addition,
it aids debugging & involves less code.

Lastly, I suggest that the draft call out explicitly that the initiator
is ALWAYS the originating party and the target is ALWAYS the responding
party for ALL security and operational keys. This is due to each key
having either a default value(in case initiator chose to use the default
and not send the key), or the key is mandated to be sent by initiator.

Thanks,
Santosh

Julian Satran wrote:
> 
> Santosh,
> 
> We are getting nowhere. Even if requester is doing it's stuff - the
> requester will have to check and be prepared for a mistake. The coding
> will require a reject.
> 
> Julo
> 
>   Santosh Rao
>   <[email-masked]>                 To:        [email-masked]
>   Sent by: [email-masked]          cc:        "Sanjeev Bhagat
>                                 (TRIPACE/Zoetermeer)"
>   01-10-01 20:37                <[email-masked]>, Julian
>   Please respond to Santosh Rao Satran/Haifa/IBM@IBMIL
>                                         Subject:        Re: iscsi :
>                                 numerical negotiation wording is
>                                 ambiguous
> 
> 
> 
> Julian & Sanjeev,
> 
> >      I am not sure clear I made the tiny diference between what I
> >      say and what Santosh said:
> >
> >      Santosh says:
> >
> >        3. the responder assumes that the value y is the correct
> >           value and so does an external observer
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather
> >           say it this way the responder computes the value with
> >           its own supported values and responds with a value y
> >           which the responder thinks is correct and so does an
> >           external observer
> >        4. the requester checks that valuey is conformant (he will
> >           not believe it) and will reject it if not conformant
> >           else it will accept it
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct,
> >           but it is highly unlikely for the responder to reject
> >           the final result because the rule states that (lower or
> >           higher of two will be the result) and so the offering
> >           party should be able to accept the lower or higher
> >           range as defined by rule. In case the key is dependent
> >           upon some range of fixed values then the negotiation
> >           should be performed as list negotiation and not
> >           numerical negotiation.
> >
> >           This might be what you "conventionally" do - I don't
> >           and that shows that convention like morals are a matter
> >           of geography :-)
> >           The advantage of this set of rules is that it allows an
> >           external observer to know what was selected without
> >           knowing the rules
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this
> >           case, I guess that the external observer has to know
> >           the rules to double check the value is correct or not
> >           The disadvantage is that messages have to be "built",
> >           an additional reject states exists and MOST IMPORTANT
> >           you need both messages
> >
> >           In what I said:
> >
> >           2. The Responder has to send either nothing (if valuex
> >           is enough on both sides to compute the result like in
> >           the case in which the function is a Boolean AND and the
> >           value is NO) or valuey
> >           3. Both the requestor and responder have to compute the
> >           value (they have to know the rules anyhow) and so does
> >           the external observer
> >
> >           The advantage is that there is no reject, in binary
> >           negotiations you can go away with shorter negotiations
> >           and you can set strings at fixed values.
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >           message is needed in this case also.
> >
> >
> >      Sanjeev
> >       "Sanjeev Bhagat
> >       (TRIPACE/Zoetermeer)"                    To:        "'Santosh
> Rao'"
> >       <[email-masked]>            <[email-masked]>, Julian
> >       Sent by: [email-masked]   Satran/Haifa/IBM@IBMIL
> >                                                cc:
>  [email-masked]
> >       30-09-01 16:32                           Subject:        RE:
> iscsi :
> >       Please respond to "Sanjeev       numerical negotiation wording
> is
> >       Bhagat (TRIPACE/Zoetermeer)"     ambiguous
> >
> >
> >
> >      All,
> >
> >      negotiations in SCSI like (sync, disconnect etc) are also
> >      done the same way.
> >      send certain fixed values only. In case a simple minded
> >      target identifies a
> >      accpeted then the responding party is not negotiating but
> >      forcing the result
> >      on initiator(this method should not be allowed unless
> >      explicitly mentioned).
> >
> >      party's result then it is acceptable for offering party and
> >      responding party
> >      to send there own supported key-value result and it can then
> >      be computed at
> >      offering party's end.
> >

---

From: [email-masked]
Date: Wed, 3 Oct 2001 12:01:49 -0400

At the risk of complicating this further, I tend to agree
with Sandeep - in the first and third examples, the second
message in the negotiation contains a value that the sender
already knows the other side will not accept (in both cases,
the other side has already said that 16k is the max, and
so sending 24k makes it look like the 16k was ignored).

What's the harm in requiring that such unacceptable values
never be sent?  Under this requirement, the second value
in both the first and third cases would be 16k, and there's
a much easier rule to figure out the result - last value
sent in either direction governs.

--David

> From: Sandeep Joshi [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2001 10:29 AM
> To: [email-masked]
> The first & third example below seem illogical. 
> 
> The responder should not be sending 24K if the initial
> sender has chosen a value of 16K, since there is no
> possibility of that 24K being accepted (unless we want
> three way exchanges for every negotiation??)   
> 
> The problem of a Reject message does not arise since the 
> responder should only be choosing something less than 16K.
> So I guess this puts me in the "responder selects logic" 
> camp.
> 
> -Sandeep
> 
> 
> Julian Satran wrote:
> > 
> > An example:
> >  08.txt logic
> > i->t DataPDULength=16k
> > t->i DataPDULength= 24k
> > 
> > Selected value is 16k
> > 
> > i->t DataPDULength=16k
> > t->i DataPDULength= 8k
> > 
> > Selected value is 8k
> > 
> > t->i DataPDULength=16k
> > i->t DataPDULength= 24k
> > 
> > Selected value is 16k
> > 
> > t->i DataPDULength=16k
> > i->t DataPDULength= 8k
> > 
> > Selected value is 8k
> > 
> > -----
> > 
> > Responder selects logic
> > 
> > i->t DataPDULength=16k
> > t->i DataPDULength= 24k
> > 
> > Error - Initiator Reject - Closes connection
> > 
> > i->t DataPDULength=16k
> > t->i DataPDULength= 8k
> > 
> > Selected value is 8k
> > 
> > t->i DataPDULength=16k
> > i->t DataPDULength= 24k
> > 
> > Error Target has to terminate with parameter error
> > 
> > t->i DataPDULength=16k
> > i->t DataPDULength= 8k
> > 
> > Selected value is 8k
> > 
> >   "Dev - Platys"
> >   <[email-masked]>                To:        "Julian Satran"
> >                            <[email-masked]>,
> >   01-10-01 23:46           <[email-masked]>
> >   Please respond to "Dev -         cc:
> >   Platys"                          Subject:        RE: iscsi :
> > I am not sure why a 'REJECT' is required.
> > Can you please explain why is this required?
> > 
> > I am with Santosh in this.
> > 
> > >There is NO need for any REJECT in the above >case. If the 
> initiator
> > >is'nt satisfied with the value returned by the >originator 
> and cannot
> > >function with the negotiated values, it can simply >close the TCP
> > >connection. There is no need to send any >REJECT.
> > 
> > Thanks
> > 
> > Deva
> > Adaptec
> > 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Julian Satran
> > Sent: Monday, October 01, 2001 1:28 PM
> > To: [email-masked]
> >   Sent by:                     cc:        "Sanjeev Bhagat
> >   [email-masked]   (TRIPACE/Zoetermeer)" <[email-masked]>,
> >                         Julian Satran/Haifa/IBM@IBMIL
> >   01-10-01 20:37               Subject:        Re: iscsi : numerical
> >   Please respond to     negotiation wording is ambiguous
> >   Santosh Rao
> > 
> > 
> > Julian & Sanjeev,
> >

---

From: "ERICKSON,SHAWN (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 3 Oct 2001 19:46:25 -0400

> The first & third example below seem illogical.

I agree.

> So I guess this puts me in the "responder selects logic" 

Same here.

-Shawn

-------------------------------------------------------
 Shawn Carl Erickson           (805) 883-4319 [Telnet]
 Hewlett Packard Company         OV NSSO Joint Venture
  Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
            <http://ecardfile.com/id/shawnce>
-------------------------------------------------------

> Sent: Wednesday, October 03, 2001 7:29 AM
> To: [email-masked]

---

From: "ERICKSON,SHAWN (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 3 Oct 2001 19:48:01 -0400

> Another value-add of the "responder picks the negotiation 
> result model"
> is that the initiator can use the following "query based" negotiation
> model to always use the values the target is capable of offering :
> 
> I -> T : DataPDULength=?
> T -> I : DataPDULength=64K
> 
> Both sides agree to use a DataPDULength of 64K. 

I like the idea!

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 3 Oct 2001 22:57:20 -0700

Julian,
I find your response troubling, perhaps I did not understand what you
intended to say.  Comments below.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 10/03/2001 05:26:58 AM

To:   [email-masked]
cc:

An example:
 08.txt logic
i->t DataPDULength=16k
t->i DataPDULength= 24k

Selected value is 16k

[Huff] If target knows that the Initiator wants 16k, and therefore that its
24k is not going to be accepted, why did the Target send 24K? [/Huff]

i->t DataPDULength=16k
t->i DataPDULength= 8k

Selected value is 8k

t->i DataPDULength=16k
i->t DataPDULength= 24k

Selected value is 16k

[Huff] If Initiator knows that the target wants 16k, and therefore that its
24k is not going to be accepted, why did the Initiator send 24K? [/Huff]

t->i DataPDULength=16k
i->t DataPDULength= 8k

Selected value is 8k

-----

Responder selects logic

i->t DataPDULength=16k
t->i DataPDULength= 24k

i->t DataPDULength=16k
t->i DataPDULength= 8k

Selected value is 8k

t->i DataPDULength=16k
i->t DataPDULength= 24k

t->i DataPDULength=16k
i->t DataPDULength= 8k

Selected value is 8k

                             "Dev - Platys"                                 
                             <[email-masked]>                To:           
                                                      "Julian Satran"       
                             01-10-01 23:46           <[email-masked] 
                             Please respond to        .com>,                
                             "Dev - Platys"           <[email-masked]>     
                                                              cc:           
                                                              Subject:      
                                                      RE: iscsi : numerical 
                                                      negotiation wording   
                                                      is ambiguous          

Julian,

>There is NO need for any REJECT in the above >case. If the initiator
>is'nt satisfied with the value returned by the >originator and cannot

Thanks

Deva
Adaptec

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
Sent: Monday, October 01, 2001 1:28 PM
To: [email-masked]
Subject: Re: iscsi : numerical negotiation wording is ambiguous

Santosh,

We are getting nowhere. Even if requester is doing it's stuff - the
requester will have to check and be prepared for a mistake. The coding will
require a reject.

Julo

      Santosh Rao                                                          
      <[email-masked]              To:        [email-masked]           
      om>                             cc:        "Sanjeev Bhagat           
      Sent by:                 (TRIPACE/Zoetermeer)"                       
      [email-masked]       <[email-masked]>, Julian               
      m                        Satran/Haifa/IBM@IBMIL                      
                                      Subject:        Re: iscsi :          
      01-10-01 20:37           numerical negotiation wording is ambiguous  
      Please respond to                                                    
      Santosh Rao                                                          

Julian & Sanjeev,

Julian :

Thanks,
Santosh

>       (TRIPACE/Zoetermeer)"                    To:        "'Santosh Rao'"
>       30-09-01 16:32                           Subject:        RE: iscsi
:
>       Please respond to "Sanjeev       numerical negotiation wording is

---

From: [email-masked]
Date: Thu, 4 Oct 2001 14:39:02 -0400

How about applying the "responder must send the result" rule to
Boolean negotiations?  The new text could then be:
 
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.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 1:57 PM
To: [email-masked]
Subject: RE: iscsi : numerical negotiation wording is ambiguous

Well - even I got fed-up with this long thread. 

Here the new text I am suggesting for the negotiations ("vox populi"): 

In numerical negotiations, the offering and responding party state a
numerical value. The result of the negotiation is key dependent; frequently
the lower or the higher of the two values is used. 

For numerical 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 result is a
key dependent Boolean function of the two inputs. The negotiation MAY
proceed only up to the point where both parties can unequivocally compute
the result; continuing beyond this point is OPTIONAL (e.g., if the function
is AND and one of the parties says "no" then this may end the negotiation).
Both requestor and responder MUST to compute the negotiated value based on
the new value(s) exchanged 

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). 

Unless specified otherwise the negotiation process is stateless (based only
on newly presented values). 

Comments? 
Julo