RE: Issue 102: NAS/QoS Filter Rule

[<Pasi.Eronen@nokia.com>]

paul.congdon@hp.com wrote:

> Since these rules govern access policies, it is believed that a
> strong hammer is better than simply ignoring things that aren't
> understood or implemented.  These should apply equally for
> permit rules or deny rules.  If the NAS can't interpret the
> rule, it can't enforce the desired policy either and still MUST
> terminate the session, so if it gets lost parsing things, this
> rule should also apply.

I agree.

> I agree that we need to make sure parsing is unambiguous.  
> I suppose we need a line feed at the end of each rule and 
> perhaps this needs to be escaped as well for the 
> tunnel-assignment-ID issue.

Yes, I also think that having an unambiguous "rule end" (or "rule
separator") character (LF, NUL, or something) would simplify the
parsing... It would be even nicer if the escape mechanism for
tunnel-assignment-ID would "hide" these characters somehow.

Perhaps we should use "percent-hex-hex" escaping like URIs?
(e.g. NUL would turn to "%00", not backslash+NUL).

Best regards
Pasi

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