Subject: RE: iSCSI: default values

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 15 Oct 2001 16:27:25 -0700

I agree - especially in light of the fact that (as currently specified) an
initiator can "change it's mind" about when it's ready to exit the OPN phase
of login (section 5 states "In a negotiation sequence, the T bit settings in
one pair of login request-responses have no bearing on the T bit settings of
the next pair.  An initiator having T bit set to 1 in one pair and being
answered with an T bit setting of 0 may issue the next request with T bit
set to 0.") so the target can't even use the setting of the T bit to decide
when to assume the initiator has "implied a default selection".

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 15, 2001 4:03 PM
> To: [email-masked]
> Subject: iSCSI: default values
> 
> 
> 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
> ---------------------------------------------------
>