RE: RFC3576bis and Session State

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

David B. Nelson <> allegedly scribbled on Monday, May 28, 2007 11:06 AM:

> Glen Zorn writes...
> 
>> 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. 
> 
> By "deployment-specific" I presume you to infer customization by (or
> on behalf of) the end-user, by others than the equipment
> manufacturer.  

Not necessarily.  For example, I can imagine that an SDO other than the
IETF might decide what constitutes a "session" for their system.  I
think that that qualifies as "deployment-specific", with a market
possibly significant enough to warrant manufacturing customization.

> I still fail to see how the NAS behavior regarding
> session identification information in a CoA-Request can be modified
> at the time of deployment, unless the NAS operating firmware can be
> modified by the installer or customer.  

The only reason firmware modification would be necessary is if the
equipment vendor didn't include a session ID "marker" that was required
in a particular situation (note that the creation of that situation (by
this WG) is exactly what I'm arguing against).  OTOH, maybe the rest of
the folks on this list are bright enough to be able to predict & specify
now and forever what the identifying characteristics of any session
would be; in that case, carry on.

> I'm not aware of any such
> equipment.  Please enlighten me.      
> 
> Maybe someone has a NAS implementation that allows such customization
> via a CLI or MIB?  If so, details would be instructive. 

Cisco provides a range of configurable means to identify sessions of
various varieties; every once in a while, we have to change the firmware
because the existing set of markers is insufficient.

--
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/>