[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Radext vlan,priority, filtering RFC - new draft (00d)
- To: "Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com>
- Subject: RE: Radext vlan,priority, filtering RFC - new draft (00d)
- From: Bernard Aboba <aboba@internaut.com>
- Date: Wed, 22 Jun 2005 19:18:35 -0700 (PDT)
- Cc: radiusext@ops.ietf.org
- In-reply-to: <D6D515539AD08046B7E6A4C02E72623E02B23F2A@cacexc08.americas.cpqcorp.net>
- References: <D6D515539AD08046B7E6A4C02E72623E02B23F2A@cacexc08.americas.cpqcorp.net>
> Here is a new updated draft, -00d. Changes in this version are:
> - section 3.5: Propose new NAS-filter-rule argument (redir_cnt) to an
> http redirect rule. Allows a rule to match a set number of times before
> NAS removes it from the active rule set.
Before adding this, I'd like to see if there is widespread support for
this particular "whistle".
> - section 3.5 & 4.1: Propose new accounting attribute
> (acct-nas-filter-rule) for NAS-filter-rule to provide some insight into
> how many matches have occurred on specific rule(s).
This seems like something that is more appropriate for logging or
management than RADIUS Accounting. If the desire is to initiate logging,
then it might make sense to add "log" as an appendage to a rule.
> - section 3.6: Added some wording regarding the possible need to
> fragment a qos filter across multiple qos-filter-rule attributes due to
> RADIUS message limits of <253 bytes.
> - section 6: Enumerated need for IANA assignment of new values for
> attributes in this document
OK.
BTW, I am wondering if the group has done a comprehensive look at IEEE 802
documents to understand what RADIUS attributes are needed. For example,
my understanding is that there are 802.1X implementations that can choose
whether to only allow a single MAC address on a port (more than one MAC
causes port shutdown) or whether to allow shared media (the default). In
the former mode, the behavior is roughly equivalent to MAC filering in
that only packets originating from the supplicant MAC address are allowed
(e.g. the port cannot operate as a trunk port).
--
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/>