RE: RADEXT charter, Take 8

[Avi Lior <avi@bridgewatersystems.com>]

I wont say much on this either except:

Point 1:
An attribute of type string containing multiple elements of data is already
in common use in RADIUS and DIAMTER.  We already gave you lots of examples
of that.

Point 2:
Seems to me that you are the only one having issues with this.  Looking at
past emails the consensus seems to be that Attribute falling into my point 1
(above) are okay.  Its only when we start talking about a new RADIUS
attribute type called SUBTYPE that we have further discussion.  There is no
draft infront of us that want this.  But if you want to create this new
attribute be my guest.


> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Wednesday, March 24, 2004 4:59 PM
> To: radiusext@ops.ietf.org
> Subject: RE: RADEXT charter, Take 8 
> 
> 
> Wolfgang Beck Writes...
> 
> > If this does not translate into 'string attributes must not be 
> > structured', I can live with it.
> 
> What is a structured string?  It could be:
> 
>      - XML
>      - HTTP
>      - X.500 directory name
>      - X.509 certificate
>      - A sonnet
>      - A limerick
>      - The collected works of William Shakespeare
> 
> A structured string could also be a binary protocol encoding 
> (such as a TLV 3-tuple) represented as printable ASCII (or 
> UTF-8) characters.
> 
> I may be confusing your posts with someone else, but I seem 
> to recall that you were advocating one or more of the above 
> definitions of structured string.  
> 
> *If* the intent of structured strings is to "hide" 
> multi-level (nested) sub-attributes in a "bag of 
> undistinguished octets", only to later open that bag and 
> effectively "get around" the requirements for compatibility 
> with existing RADIUS RFCs and recommended attribute formats, 
> then you equally know my opinion about this!  :-)  *If* we 
> are ever to embrace complex, multi-level sub-attributes, we 
> need to do it explicitly, following the process outlined in 
> the draft charter (Take 8).
> 
> > You know my opinion about this.
> 
> I think I do.  But maybe you could refresh my memory.  
> Basically, your position is that "flat" RADIUS TLV attributes 
> are "bad".  They cramp one's creativity, flexibility and the 
> ability to arbitrarily "group" data items, as you could in a 
> C-language data structure or as in an SMIv2 based MIB.  Is 
> that correct?
> 
> -- Dave
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > 
> > 
> > Wolfgang
> > 
> > 
> > 
> > --
> > 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/>
> 

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