See below... > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, October 18, 2006 6:32 AM > To: openradius-radextwg@e-advies.nl; radiusext@ops.ietf.org > Subject: Filter Separation using a NULL? > 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 Can we be stronger and state MUST NOT instead of SHOULD NOT on the mixture of NAS-Traffic-Rule and NAS-Filter-Rule? If we stick with SHOULD NOT, then what is the expected behavior of the NAS when both appear? RADIUS packet or RADIUS message? I thought the right term was message. > attribute is present, then implementations of this specification > MUST silently discard NAS-Filter-Rule attributes, if present. > 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. The current wording of "...filter rules separated by a NULL" makes it sound like multiple rules can be put in within a single NAS-Filter-Id attribute. Is this the case? If not, consider instead the wording "filter rules terminated by a NULL (0x00)" and stating that the start of a new rule should always use an additional attribute. MS
Attachment:
smime.p7s
Description: S/MIME cryptographic signature