RE: RADEXT Issue 148 Item 6

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

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. 

Regards,

Dan


 
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Tuesday, December 13, 2005 5:49 PM
> To: radiusext@ops.ietf.org
> Subject: RE: RADEXT Issue 148 Item 6
> 
> 
> 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/>
> 

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