Re: iSCSI: default values

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

Black_David@emc.com wrote:
> 
> Default values may be difficult to define for text keys added after
> the first stable version of the spec.  The problem is that an
> originator who does not send a text key cannot distinguish between:
> 
> - a responder who understands the key and implements the default AND
> - a responder who does not understand the key and does something
>         acceptable under a version of the spec prior to introduction
>         of the key.

David,

I see a minor nit in the above described scenario.

During iscsi login, both sides need to agree on a common overlapping
version in their respective ranges of (version_low, version_high) sent
in the login pdu. Lack of a common version results in the target
rejecting the login with an "unsupported version" status explanation.

Once the 2 sides have agreed to a common version, both sides know all
the supported operational & security keys in use. Thus, one side cannot
send a "key defined in a later version of the spec" which the other side
does not understand.

Such an erroneous key usage, would have to be due to a buggy
implementation and would cause the other side to treat it as a vendor
unique key being originated to which it would respond with
NotUnderstood. 

That said, I agree with the intent of your suggestions below.

Thanks,
Santosh


> This whole notion of omitting a key being equivalent to sending
> it with its default value strikes me as potentially problematic.
> I would have thought that omitting a text key was equivalent to
> "Don't Care" with the default values being "RECOMMENDED" rather
> than "MANDATORY".  This leads to the following rule, which I think
> should go in regardless:
> 
> - An implementation whose operational correctness and/or performance
>         depends on the value of a text key MUST explicitly negotiate
>         that key.
> 
> This is somewhat like the old adage about voting - those who do not
> vote should not complain about the results, and leads to more robust
> negotiation exchanges because mismatched assumptions about defaults
> get exposed.
> 
> I realize this yields additional messages in some cases, but would
> suggest that the additional negotiation robustness is an offsetting
> benefit.
> 
> Comments?
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------

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