Subject: iSCSI: default values

From: [email-masked]
Date: Mon, 15 Oct 2001 19:02:35 -0400

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.

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Santosh Rao <[email-masked]>
Date: Wed, 17 Oct 2001 10:19:50 -0700

>         acceptable under a version of the spec prior to introduction

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

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