[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: "Issues and Fixes" changes
For example, an Access-Request containing one of the authentication
attributes User-Password or CHAP-Password MAY contain a State
attribute. Other attributes intended to carry authentication
information include EAP-Message, though this list is not exhaustive,
and may be extended in future specifications.
I think we 'd also need to include ARAP & Digest authentication, no?
Access-Request packets that contain a Service-Type attribute with
value Call Chack (10) or Authorize Only (17) MUST contain a State
attribute. Any Access-Request that does not contain an
authentication attribute MUST contain a State attribute. This list
of authorization parameters is not exhaustive, and may be extended in
future specifications.
Think this is "Call Check". I'm curious whether current implementations of
Call Check satisfy this or not.
The following algorithms apply to any client that originates RADIUS
packets, including but not limited to Access-Request,
Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].
This also adds an informative reference to RFC 3576.
The reference should probably be to [RFC3576bis].
We can add a note:
For Accounting-Request packets, the default values for MRC, MRD,
and MRT SHOULD be zero. These settings will enable a RADIUS client
to continue sending accounting requests to a RADIUS server until
the request is acknowledged. If any of MRC, MRD, or MRT are non-
zero, then the accounting information could potentially be
discarded without being recorded.
This is better, thanks.
It's difficult to know that an unknown type is for an unimplemented
service. But I think I know what you mean.
Actually, I meant a known type; for an unknown type, I agree.
--
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/>