I would suggest MUST for Authorize-Only and MAY for Call-Check.
If I read RFC 2865 correctly, it would seem that an Access-Request containing Service-Type="Call-Check" MUST contain a State ttribute, since this won't contain User-Password, CHAP-Password or any other "authentication attribute". Now, I'm not sure I understand where the NAS is supposed to get the State Attribute from, but that does seem to be what RFC 2865 is saying.
> 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. In the second sentence, did you mean "authentication" rather than "authorization"?
This quote came from RFC 2865, so I'm not sure what it means. That's for us to figure out, I guess :)
I think you meant "new service". I agree. We have previously agreed that unknown values of the Service-Type attribute MUST be treated as an Access-Reject. That much is clear.
That is already in RFC 2865, I believe.
We are debating whether unknown values of other attributes, or unknown attribute types, ought to be treated similarly. The suggestion is that a NAS MAY choose to treat them similarly, i.e. treat unknown attribute types, or unknown values of known attribute types as an Access-Reject based on locally configured policy, with the default being to silently ignore them,for backwards compatibility. NASes MAY implement this local policy feature,and it is RECOMMENDED for any new implementations or significant revisions. We ought not to deprecate any existing implementations that don't have this local policy feature, however.
BTW, I believe that there may be some other hints on this in RFC 2869. For example, in the ARAP section there is some discussion of how NASes that don't support ARAP are supposed to behave.
-- 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/>