[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
More follow up:
I could also envision permitting Framed-Management-Protocol and
Management-Transport-Protection as session identification attributes is a
CoA-Request, similar to their usage in a Disconnect-Request message.
> Add the following text to Section 12 (as currently numbered):
>
> Change-of-Authorization Messages
>
> Request ACK NAK # Attribute
>
> 0 0 0 TBA-2 Framed-Management-Protocol
> 0 0 0 TBA-3 Management-Transport-Protection
> 0-1 0 0 TBA-4 Management-Policy-Id (Note 2)
> 0-1 0 0 TBA-5 Management-Privilege-Level (Note 2)
Request ACK NAK # Attribute
0-1 0 0 TBA-2 Framed-Management-Protocol (Note 1)
0-1 0 0 TBA-3 Management-Transport-Protection (Note 1)
0-1 0 0 TBA-4 Management-Policy-Id (Note 2)
0-1 0 0 TBA-5 Management-Privilege-Level (Note 2)
I don't think it makes any sense to allow re-provisioning of the session
transport parameters, as that would almost certainly require a disconnect
and re-establishment of the session.
> Disconnect Messages
>
> Request ACK NAK # Attribute
>
> 0-1 0 0 TBA-2 Framed-Management-Protocol (Note 1)
> 0-1 0 0 TBA-3 Management-Transport-Protection (Note 1)
> 0 0 0 TBA-4 Management-Policy-Id
> 0 0 0 TBA-5 Management-Privilege-Level
>
>
>
> (Note 1) Where NAS or session identification attributes are included
> in Disconnect-Request or CoA-Request packets, they are used for
> identification purposes only. These attributes MUST NOT be used for
> purposes other than identification (e.g., within CoA-Request packets
> to request authorization changes).
>
> (Note 2) When included within a CoA-Request, these attributes
> represent an authorization change request. When one of these
> attributes is omitted from a CoA-Request, the NAS assumes that the
> attribute value is to remain unchanged. Attributes included in a
> CoA-Request replace all existing values of the same attribute(s).
Similar logic applies to the Disconnect-Request case. Those attributes
which might aid in distinguishing one of a user's concurrent sessions from
among others may be useful. The primary indicator here is likely to be the
Service-Type, but that is already permitted by RFC 5176. We only need to
discuss the newly introduced attributes, in this document.
I'm planning to crate a -04 version of the draft today, to submit prior to
the upcoming "blackout" period on ID submissions. Now would be a good time
to submit comments on this issue (or any other open issue against -03). :-)
--
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/>