RE: iSCSI: keys/parameter dependence

["Julian Satran" <Julian_Satran@il.ibm.com>]

Jeff,

We had a statement about dependencies that we now deferred to individual keys (as it is explicit in the security exchanges).
For operational parameters we have 2 choices:

1. State the dependency and force ordering
2. Take all values and check before committing
   
   
   Taking into consideration that a negotiation is atomic - i.e., failure must return ALL values to the status before and as such we have to keep them
   and that most of the dependencies are of a kind that can be checked at the end and rather trivial it looks to me that 2 is slightly better than 1.
   
   Julo
   
   
   

   Jeff Fellin <jkf@research.bell-labs.com> 06/04/2002 08:36 PM Please respond to Jeff Fellin

   To:        Julian Satran/Haifa/IBM@IBMIL         cc:                 Subject:        RE: iSCSI: keys/parameter dependence

   
   
   Julian,
   I never saw any place in the document when or if consistency was done. By your
   proposing a final last stage consistency check to end the negotiation appears
   to be adding semantics that are not present to eliminate the issue of parameters
   having consistency requirements. When the definition of the parameters, for example
   FirstBurstSize MUST NOT exceed MaxBurstSize implies that when FirstBurstSize is received
   the value CANNOT exceed the current value of MaxBurstSize, the the value of MaxBurstSize
   at some later point in time. The state transistions for Login do not mention this
   overall parameter value consistency check, so how can you state it was already present.
   
   Jeff Fellin
   Bell Labs
   
   > From owner-ips@ece.cmu.edu Tue Jun  4 13:08:42 2002
   > X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
   > To: "Robert D. Russell" <rdr@io.iol.unh.edu>
   > Cc: ips@ece.cmu.edu
   > Subject: RE: iSCSI: keys/parameter dependence
   > From: "Julian Satran" <Julian_Satran@il.ibm.com>
   > Date: Tue, 4 Jun 2002 20:06:55 +0300
   > X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
   >  04/06/2002 20:06:56,
   >                  Serialize complete at 04/06/2002 20:06:56
   > Content-Type: multipart/alternative; boundary="=_alternative 005D5E07C2256BCE_="
   > Sender: owner-ips@ece.cmu.edu
   > Precedence: bulk
   > X-Lines: 192
   > Content-Length: 7481
   >
   > Bob,
   >
   > Thanks.  That matches my list although I have a somewhat different
   > approach to some of them.
   >
   > 1. FirstBurstSize - MaxburstSize is not exactly a dependency as it means
   > only that the negotiated values have to relate to each other
   > at commit time or you have negotiation failure (login failure)
   >
   > 2 & 3 as above.
   >
   > I think tact we may want to say somewhere that value consistency to the
   > rules is to be determined a the end of the negotiation.
   >
   > Thanks,
   > Julo
   >
   >
   >
   >
   >
   > "Robert D. Russell" <rdr@io.iol.unh.edu>
   > 06/04/2002 11:13 AM
   > Please respond to "Robert D. Russell"
   >
   >  
   >         To:     Julian Satran/Haifa/IBM@IBMIL
   >         cc:     ips@ece.cmu.edu
   >         Subject:        RE: iSCSI: keys/parameter dependence
   >
   >  
   >
   > Julian:
   >
   > I have found the following dependencies between keys in draft 12-96,
   > and would ask other people on the mailing list to contribute others
   > they have found so we can all be aware of the complete set.
   >
   > There seem to be very few dependencies, which I believe is a credit
   > to a clean, orthogonal design.
   >
   > With a bit of work, we could probably get rid of all the dependencies
   > between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps,
   > as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker)
   > key and substituting a default (and response) value of 0 for the
   > OFMarkInt (IFMarkInt) to mean "no markers in that direction".
   >
   > This would also eliminate the need for a "Reject" reply to an OFMarkInt
   > (IFMarkInt) offer.
   >
   >
   > "Meaningful" dependencies (i.e., those that cannot be ignored because
   > they effect operation):
   >
   > 1.  Between FirstBurstSize and MaxBurstSize
   >       Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize."
   >
   > 2.  Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker)
   >       Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt)
   >       offer) is unacceptable the responder answers with "Reject".
   >       Reject is resetting the marker function (i.e., OFMarker
   >       (IFMarker)) in the specified direction (Output or Input) to No."
   >
   > 3.  Between SessionType and MaxConnections
   >       Section 11.22: "The discovery session implies MaxConnections = 1
   >       and overrides both the default and an explicit setting."
   >
   >
   > "Trivial" dependencies (i.e., those that only allow the option of
   > replying with "Irrelevant" instead of a normally selected value, and
   > therefore can be ignored).
   >
   > 1.  Between FirstBurstSize, InitialR2T, and ImmediateData
   >       The table in section 11.12 implies that the combination
   >       InitialR2T=Yes and ImmediateData=No allows the response
   >       FirstBurstSize=Irrelevant.
   >
   > 2.  Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt).
   >       Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No)
   >       allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant).
   >
   >
   >
   > Bob Russell
   > InterOperability Lab
   > University of New Hampshire
   > rdr@iol.unh.edu
   > 603-862-3774
   >
   >
   >