|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: default valuesI 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: marjorie_krueger@hp.com > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, October 15, 2001 4:03 PM > To: ips@ece.cmu.edu > 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 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- >
Home Last updated: Wed Oct 17 13:17:26 2001 7268 messages in chronological order |