[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 56: Capabilities Attribute
Bernard pointed out...
> Issue 56: Capabilities Attribute
> Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com Date first
> submitted: January 28, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00034.html
> Document: CUI, IEEE 802
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> Farid mentioned in his last message that we might want to
> move ahead on defining a general Capabilities attribute.
> Here is a strawman proposal:
>
<...strawman proposal removed for brevity...>
> String2
>
> The String2 field is one or more octets. The actual
> format of the
> information is site or application specific as described in
> [RFC2865] Section 5.26.
> [Glen Zorn]
> Why only client & request?
> [Bernard Aboba]
> The usage scenario I had in mind was a NAS announcing to a
> server that it supported various attributes. This could be
> useful, for debugging purposes (oops, I forgot to upgrade
> that NAS!), or backward compatibility (server won't send a
> new attribute to a NAS that doesn't support it).
>
> Can you describe how a server could use a Capabilities attribute?
> Proposed Resolution: Discuss
The question of a capability attribute is one that puts the timeliness
for completion of the ieee802 draft in jeopardy. The design team has
decided to punt in the short-term and not have a direct dependence on a
capability attribute. Proposed text follows:
"2.1. Capability Advertisement
RADIUS does not currently define a method by which a NAS can advertise
its capabilities and in many instances, it would be desirable for the
home network to know what capabilities are supported by the NAS to
ensure proper operational behavior. The attributes defined in this
document are intended to be used to enforce policy by the NAS. If a NAS
does not recognize these attributes it will most likely ignore them and
the desired policy will not be enforced. A method for the NAS
advertising the capability to support these attributes would help the
AAA server understand if the intended policies can be enforced.
Inasmuch, we expect this lack of generalized capability advertisement to
be rectified and when available, should minimally be used in conjunction
with the NAS-Filter-Rule(TBD) attribute. "
MS
--
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/>