RE: RADEXT Issue 148 Item 6

["Nelson, David" <dnelson@enterasys.com>]

Bernard Aboba writes...
 
> I agree with Emile on this.  During the discussion of "malformed" 
> in the original RADEXT WG, the intent was to catch syntax errors, 
> not unknown attributes.

And the inference is that the recommended or suggested VSA format in RFC
2865 is not sufficient to establish syntax rules for VSAs, is that
right?  I think that Alan DeKok's position is that some implementations
chose to interpret the VSA suggestions as syntax rules, and enforce them
as such.

<snip>

> To fix the issue, you've got to choose one interpretation or 
> the other.  This may require some implementations to change their
> code -- but shying away from this will only sacrifice 
> interoperability, which isn't a good tradeoff.

Is your recommendation to (a) document the current state of affairs,
that "malformed" is defined by the implementation, or to (b) normatively
define "malformed" someplace, potentially causing some implementations
to be non-compliant?

I think Alan's suggestion was (a).  From an interoperability
perspective, (b) is to be desired, but it will likely draw criticism
from those whose implementations don't match the new normative
definition of "malformed".  While the "legislative intent" information
from the RADIUS WG deliberations is enlightening and instructive, at the
end of the day we are left with the text that was actually incorporated
in the RFCs.

I'm just looking for consensus on some text to include in the MIB drafts
to close this issue.  :-)


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