Subject: Re: iSCSI: keys/parameter dependence

From: "Robert D. Russell" <[email-masked]>
Date: Sun, 2 Jun 2002 15:07:32 -0400 (EDT)

Hi Mike:

Comments in text below:

> >From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83):
>
> Whenever parameter action or acceptance are dependent on other parameters,
> the dependent parameters MUST be sent after the parameters on
> which they depend. If they are sent within the same command, a
> response for a parameter might imply responses for others.
>
>
> Is an example of this FirstBurstSize being dependent on MaxBurstSize (or
> vis-versa)?

yes

> So MaxBurstSize MUST come before FirstBurstSize?

Not necessarily, since it says "Whenever parameter action or acceptance
are dependent on other parameters, ...".  If you want to offer a value of
FirstBurstSize (say 524288) that is greater than the default value 262144
of MaxBurstSize then a value of MaxBurstSize at least as large as 524288
must be offered first -- otherwise the offered value of 262144 for
FirstBurstSize could not be accepted, since that would violate the
requirement in section 11.14 that "FirstBurstSize MUST NOT exceed
MaxBurstSize." (and the (default) value for MaxBurstSize would be
exceeded if the offered value were accepted at that point in the
negotiations.)

On the other hand, if you want to offer a value of MaxBurstSize (say 32768)
that is smaller than the default value 65536 of FirstBurstSize then a value
of FirstBurstSize no larger than 32768 must be offered first -- otherwise
the offered value of 32768 for MaxBurstSize cannot be accepted, since that
would violate the same requirement at that point in the negotiations.

> I don't see any definition of operational parameters.  Just in section 11
> keys that are not "declarative" are "operational keys".

In draft 12-95, Chapter 11 is entitled "Login/Text Operational Keys",
and the fourth paragraph in this chapter says:
"Keys marked as "declarative" may appear also in the SecurityNegotiation
stage while all other keys described in this chaper are operational keys."

Doesn't that pretty clearly define operational keys?

> Also, the spec goes back and forth between the terms "keys"/"parameters" and
> "operational keys"/"operational parameters"/"operational negotiation
> parameter keys".  Is this something that should be cleaned up?

It would certainly help to use consistent terminology throughout.

Best,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: Martins Krikis <[email-masked]>
Date: Mon, 3 Jun 2002 13:41:58 -0700 (PDT)

> would violate the same requirement at that point in

So, are you really proposing a requirement that
we must look at the values in order to figure out in
which order to send keys? That is so UGLY, it is
hard to believe that this is happening.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com