[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Filter Separation using a NULL?
A respin of the document based on your suggestion is available here:
Here is what Section 2 now looks like -- it is indeed much simpler, and I
can't see that any functionality has been lost. What do people think?
2. NAS-Filter-Rule Attribute
This attribute indicates filter rules to be applied for this user.
Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
Accept, CoA-Request, or Accounting-Request packets.
The NAS-Filter-Rule attribute is not intended to be used
concurrently with any other filter rule attribute, including
Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and
SHOULD NOT appear in the same RADIUS packet. If a Filter-Id
attribute is present, then implementations of this specification
MUST silently discard NAS-Filter-Rule attributes, if present.
Where multiple NAS-Filter-Rule attributes are included in a RADIUS
packet, the String field of the attributes are to be concatenated
to form a set of filter rules. As noted in [RFC2865] Section 2.3,
"the forwarding server MUST NOT change the order of any attributes
of the same type", so that RADIUS proxies will not reorder NAS-
A summary of the NAS-Filter-Rule Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type | Length | String...
The String field is one or more octets. It contains filter rules
in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
filter rules separated by a NULL (0x00). A robust implementation
SHOULD support the field as undistinguished octets.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.