RE: How do you negotiate a numerical range?

["Martin, Nick (Server Storage)" <Nick.Martin@hp.com>]

Bill,

I agree that there could be more to do if/when we need ranges. 
Ranges are not allowed unless specifically stated for a particular key. 

From working draft 15:

"The value offered or declared can be a numerical-value, a numericalrange
defined by lower and upper value with both integers separated
by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSIlocal-
name-value, a boolean-value (Yes or No), or a list of comma
separated text-values. 
                        A range or a large-numerical-value MAY ONLY be
offered if it is explicitly allowed for a key. 
                                                An iSCSI-name-value
and an iSCSI-local-name-value can be used only where explicitly
allowed. A selected value can be an numerical-value, a large-numerical-
value, a text-value or a boolean-value."


I disagree with your conclusion in Question 1. 
Offering a range for this particular key is an error.  
However presuming for a moment that a range is allowed for the key in the example,  I think this must result in a negotiation failure for this key and login may fail.
As I read you example, the responder seems to support the range 2~2 which has no values in common with 3~10.  Responding with 2 is a protocol violation.  The correct response would be "Reject". 

If a key which requires a single numeric result allows a range to be offered, a value within the offered range must be selected.
Responding with a value outside the offered range would be a protocol violation.
If such a key has a MIN or MAX rule, this should specify whether the largest or smallest value common between the range offered and the range supported by the responder should be selected.  If 3~10 is offered, and 2~6 is supported by the responder, then the result with a MIN rule would be 3 and the result with a MAX rule would be 6.  If there is neither a MIN nor MAX rule then 3, 4, 5, and 6 are all valid responses (implementer's choice).  This is intuitive, but would perhaps need to be clearly stated to prevent other interpretation.

I could envision a key which requires a range as the result.  In this case the rule for the result might be the INTERSECTION of the range offered that the responder also supports.  Thus for an offer of 4~20 the responses 4~8, 5~10, and 10~20 could each be valid depending on the supported range of the responder, but 2~4, 15~25, and 25~30 are all invalid responses because they include values outside the offered range.  There could also be a rule called UNION, but I have trouble imagining a use for it in negotiations.  As I read the excerpt above, keys which require a range as a result are currently prohibited.  

If non-intuitive results such as you describe in Question 1 were not already prohibited, then IMHO the spec would require revision.

Thanks,
Nick


> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> Sent: Wednesday, July 17, 2002 4:11 PM
> To: ips@ece.cmu.edu
> Subject: How do you negotiate a numerical range?
> 
> 
> I think I know the answer, but wanted to double check as 
> AFAICT all the
> numbers we have in the spec are either MIN or MAX; I suspect 
> not much code
> is using numerical ranges at the moment. Also, the spec doesn't say
> anything about negotiating ranges AFAICT. :-)
> 
> Question 1:
> 
> Since all of the numbers we have are MIN or MAX, my 
> understanding is that
> you just take the min or max of the range, and use that for 
> negotiation.
> 
> The initially-non-intuitive thing is that you can readily get 
> a negotiated
> value outside of the offered range. :-)
> 
> Consider an offer of "MaxConnections=3~10" to a device that wants
> MaxConnections=2. Since MaxConnections is a MIN number, the correct
> response (I believe) is "MaxConnections=2". I suspect however 
> this might
> seem counter-intuitive for new implementers.
> 
> Question 2:
> 
> Say you have a number that is not a MIN or MAX number (right 
> now this'd be
> a vendor-specific one), and you are offered a range (say 
> "Foo=3~12"), and
> had you made the offer you would have offered a different range (say
> "Foo=10~16"). Do we want to say anything now about how to handle this
> negotiation, or do we want to wait until we actually have a 
> non-MIN/MAX
> number in the spec?
> 
> I'd vote holding off, and just having everyone understand 
> there will be
> more work for some future version. :-)
> 
> Thoughts?
> 
> Take care,
> 
> Bill
> 
>