[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADEXT Issue 148 Item 6
Hi,
On Tue, Dec 13, 2005 at 11:14:18AM -0500, Nelson, David wrote:
> Dan Romascanu writes...
>
> > I believe that (a) is not an acceptable solution from an
> > interoperability point of view. The currently used term of 'malformed'
> > is not defined properly. If left to the implementation to interpret
> > 'malformed', interoperability cannot be ensured. Rather than
> documenting
> > this situation, I would by now rather deprecate the current objects
> > counting 'malformed', define the term properly, and create new
> objects,
> > now or later.
>
> That seems like a reasonable suggestion. Let me solicit an informal
> poll of the WG Mailing list to see if we have a consensus solution to
> this issue.
>
> Please reply to the list answering these two poll questions:
>
> (1) Should the existing RADIUS MIB objects that count malformed packets
> be deprecated, a normative definition of malformed created, and new
> counter objects be added to count malformed packets according to the new
> definition? {YES|NO}
YES, provided the normative definition is conservative and does not
impose requirements not set forth in RFC 2865.
Optionally, the definition for malformed packets may include packets
containing VSAs whose internal structure do not conform to the rules
defined by the vendor as associated with the PEC or even the exact
attribute in question, if the implementation knows about them. Those
rules may be the ones suggested by RFC 2865 or different ones.
Regardless of whether that is included, I do think that the counter
should only cover the SYNTAX level, not the semantic level. If packets
containing attributes containing semantic errors (eg. out of bounds
values, unroutable IP addresses, and so on) should be counted, then I
think that should be done using an unrelated MIB value.
> (2) Should the normative definition of malformed packets, created as
> described in Question (1), include packets that do not conform to the
> suggested VSA syntax of RFC 2865? {YES|NO}
NO (resoundingly).
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)78 6136282 http://www.e-advies.nl
--
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/>