Charter issues

[Avi Lior <avi@bridgewatersystems.com>]

We need to make progress here.

We use terms like subtypes, RADIUS attributes are flat etc... 

But I don't think we have any definitions for these.

I asked the chairs to provide a definition for subtypes etc.... And I have
received no definitions.

If the chairs are saying the Attributes of type String that contains other
attributes are subtypes, and that these are prohibited, then I have a huge
issue with that.

Many of the existing RADIUS attributes meet this criteria.  And David if
that is your definition of subtypes then you are wrong in saying that RADIUS
attributes are flat.

To the chairs, please provide defintions / justification for the terms you
use in the proposed charter.  Otherwise please remove these restrictions.


> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: January 9, 2004 3:47 PM
> To: Mike Bean; radiusext@ops.ietf.org
> Subject: RE: Potential work items 
> 
> 
> Mike Bean writes...
> 
> > We have code in our RADIUS server that parses many 
> structured RADIUS 
> > attribute types, some RFC, most VSA.
> 
> VSAs are fine... for what VSAs were intended for.  I have 
> worked on RADIUS Servers that parsed VSAs, too.  
> 
> > I understand that this group does not want to add new 
> attribute types
> to
> > the RADIUS standard; however, since 3GPP2 standards have 
> been adopted
> and
> > require RADIUS support for sub-type values, it may be 
> helpful to write
> an
> > informational RFC that describes the use of sub-types in a RADIUS 
> > attribute.
> 
> IMHO, it is unfortunate if 3GPP2 has standardized use of 
> RADIUS attributes that substantially "bend" the well-accepted 
> RADIUS architecture.  Having done so, the debate is over how 
> to "promote" these VSAs into some form of standards or 
> multi-vendor status.  Like it or not, the standard RADIUS 
> attribute space is "flat".
> 
> > Perhaps IS-835 and IS-878 can be changed to flatten these sub-type 
> > attributes into separate attributes.
> 
> That would probably be my preference, but I haven't seen the 
> documents you reference.
> 
> > My concern is it may be too late...
> 
> Too late because the implementers have shipped product and 
> don't want to go back and re-implement, in an effort to move 
> into an IETF standards-based arena?  I've heard the argument 
> that the closure of the IETF RADIUS WG created an "open 
> season" for other SDOs to revise the RADIUS architecture, but 
> I just don't buy it.
> 
> > ...providing additional information on how sub-type attributes are
> used
> > can only help developers.
> 
> Help developers to continue to "make the same mistakes"?  
> Sorry for what might be perceived as a cheap shot, but IMHO 
> use of sub-types in non-VSA attributes is a mistake. 
> 
> > I suspect most vendors supporting 3GPP2 in their
> > RADIUS server have already written code to support at least the
> display of
> > sub-type attributes.  My two cents.
> 
> I suppose you are correct.  Is this a case of the de-facto 
> standard forcing the hand of the de-jure standard development?
> 
> Thanks for your contribution to the discussion.  I don't know 
> how this will come out, but having more concrete data helps.
> 
> -- Dave
> 
> 
> 
> --
> 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/>