RE: RFC3576bis and Session State

["David B. Nelson" <d.b.nelson@comcast.net>]

Glen Zorn writes...

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

Ah, I see.

This still seems problematic for RFC 3576bis, however.  If we leave the
selection of session "marker" attributes that need to appear in
Access-Request and CoA-Request messages to support a particular application
open ended, then we can't easily task someone to write a test plan to verify
multi-vendor interoperability of RFC 3567bis, because the attribute
selection is not deterministic, or at least not determined within the scope
of the document.

If we are looking at RFC 3576bis as simply a base document that is used by
other SDO documents to form a complete solution, but that is not a complete,
interoperable protocol unto itself, then let's at least say so.  I think it
may be best to specify a minimum set of session "marker" attributes for
generic RADIUS applications as SHOULDs in RFC 3567bis and indicate that
there are an unlimited number of other session "marker" attributes that MAY
appear, based on the requirements of other documents, e.g. from non-IETF
SDOs.

That would at least put the implementer on notice.




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