|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Questions regarding text parameter 'Reject' and 'Irrelevant' usageReject is a legitimate negotiation option (is is not a reject pdu). The rest is left to the implementor and any of your options is valid. Nothing will prevent the login/negotiation to conclude successfully althugh I assume that a responder that sees too many rejects will take some drastic action to stop being bothered. Julo
--- Julian Satran <Julian_Satran@il.ibm.com> wrote: > Luben, > > I hope I cleared this. > The may reject is only for the responder - the > originator expects a good > selection (according to the rules) or reject and > will end the negotiation > otherwise. So let's suppose originator sent a key with a list of values and received a Reject in response. May the originator now send the same key again? May the responder now offer the same key again? Should the originator now send the same key again? Should the responder now offer the same key again? If they may/should and end up with another Reject for the same key, may/should they do it again? Assuming the key still hasn't been answered with a non-reserved value, should it prevent either party from setting the T/F bits and thus signaling readiness to end the negotiation sequence? None of this is clear to me. > That is the exact meaning of the text. I did look > it again over and I may > add words but it seems that the text is clear as it > is. Here are a couple of things that I personally would change: "All negotiations are stateless and explicit" We all know they are far from stateless. Explicit? Well, I would not allow boolean responses to be omitted under certain conditions. It just complicates the logic necessary to figure out whether I can signal readiness to complete the sequence or whether I'm missing some boolean response. "If a responder does not support, does not understand or is not allowed to use all of the offered options with a specific originator..." This could be interpreted to say that one value which cannot be used is enough to fail the whole list. However, simply replacing "all" with "any" won't make things clearer either. It would be best to rewrite this part and to not mention the previously undefined "options" either... "it MAY use the constant "Reject"" The MAY part is not helpful, as many have pointed out. The less choices there are, the clearer things will become and the less room for unexpected surprises. "The selection of a value not admissible under selection rules is considered a negotiation failure and is handled accordingly" In list negotiations the selection rule seems to be "pick the first value that you support". If so, then should responding with Reject, Irrelevant or NotUnderstood be considered as "value admissible" or "value not admissible"? I.e., by interpreting the reserved words as not admissible, we could already treat them as failure, yet we shouldn't... "Handled accordingly" could provide a reference to a better explanation of how the handling should be done. "The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value" Let's take InitialR2T: function OR, default Yes. Suppose the responder desires to turn this to No. Suppose the offering party sends a No. Now, in the absence of the knowledge of this offer of No, the responder would be forced to stick with the default Yes, right? So according to the quotation above, the value to respond with is OR(No, Yes) = Yes. This way we can't ever turn it to No, even if both sides want it. "An offer of a value not admissible MAY..." This is after boolean negotiations. Was it meant for boolean or for anything? And what is "not admissible"? Illegal value according to iSCSI standard or simply unwelcome value by the receiver? "However the negotiation is not considered as failed if the response is Irrelevant" Does it mean that it is considered as failed if the response is Reject? All the questions I asked above about Reject apply again here... i.e., may/should each of the parties offer this key again and should the current state of this key allow signalling readiness to complete the sequence? Why not disallow Irrelevant to simplify things? Make the response be mandatory. Let each side deside for themselves whether it is of any use, but negotiation should be completed for it. We aren't considering any operational parameters dependent on each other anymore, are we? So why the Irrelevant---for being extra nice during security negotiation? Thanks for considering these concerns, Martins Krikis, Intel Corp. Disclaimer: These opinions are mine and may not reflect those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
Home Last updated: Wed Apr 24 17:18:25 2002 9772 messages in chronological order |