[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iSCSI: key negotiation - Unrecognized value?
>>>>> "Luben" == Luben Tuikov <firstname.lastname@example.org> writes: Luben> Marjorie, Julian, all, When a value doesn't belong to the Luben> valid set of assignable values to a key, but is offered, as Luben> Marjorie's example, shouldn't the following take place: Luben> Originator-> MaxConnections=yes Luben> Responder-> MaxConnections=NotUnderstood That doesn't sound right, because the spec says that NotUnderstood applies to keys, not to values. The best fit is "reject" though the wording of the spec doesn't really say that. Actually, the spec is unconfortably fuzzy about all this stuff; for example, the fact that it says '...may use the constant "Reject"' is weird. I assume that should be "...MAY use..." but why does it say "may" -- what other alternative is there? For the case here, a single (non-list) key with a syntactically invalid value, I can't get particularly excited about the answer. Dealing elegantly with defective initiators isn't all that critical. Sure, if it's easy and reasonable (which it seems to be) let's generalize the wording for "Reject" so it clearly applies to this case. Luben> Also, isn't ``Reject'' used for a valid, assignable value, but Luben> for which the responder has no resources: Luben> Originator-> MaxConnections=4294967296 Luben> Responder-> MaxConnections=Reject I don't think so. That's a numeric negotiation, lower value wins. So the responder must pick a number it supports <= the value supplied by the originator. "Reject" would be valid if there is no such number. (That's not possible for this particular key.) A way to justify "reject" is with the argument that 4294967296 is not a valid integer string here because it is out of range. True, and that would justify treating it as no different from initiator saying "yes" for this key. Then again, I'd expect that a lot of responders would simply run the key through atoi(), observe that this worked, see that the value is too large, and reply with an acceptable value. paul
Last updated: Wed Feb 20 18:18:00 2002
8816 messages in chronological order