[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC3576bis and Session State
David B. Nelson <> allegedly scribbled on Monday, May 28, 2007 10:00 AM:
> Avi Lior writes...
>
>> I don't think therefore that 3576 should prohibit any of the above.
>> It really is up to deployments to determine how these are used.
>
> Freedom to innovate and differentiate your product is a wonderful
> thing, but so is multi-vendor interoperability based on the formal
> specification alone.
If the definition of "session" was vendor- or implementation-specific, I
would agree with you, but it appears to me that it is actually
-deployment-specific; therefore, it's not clear to me that this has
anything to do with multi-vendor interoperability. As Alan noted, the
server must know which session it wants to modify or terminate and thus
it must also know what set of attributes is required to uniquely
identify it.
> I understand that you may wish to have a rich vocabulary to specify
> the "filter" on which sessions to affect, but it also seems to me
> that writing down the rules for everyone to see and implement is
> required.
The problem is that the "rules" are not & cannot be fixed a priori.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>