RE: Some thoughts

[Avi Lior <avi@bridgewatersystems.com>]

So this is a very interesting...

If you look at prepaid for example you will see that that approach taken was
to use subtypes.  One of the reason for doing so was due to the lack of
attributes space.  If we were to expand these attributes then we would run
out of space (maybe not within the two features we are considering now but
pretty soon.)  Note that using subtypes also increases the size of the
attribute.

Furthermore, you still have a potential issue about the size of the
attributes.  

Nobody addressed the problem I have put forward.  How do you map a (3 octet)
length Diameter attribute to a (one Octet) length Radius attribute?



> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Friday, August 22, 2003 2:16 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Some thoughts
> 
> 
> Bernard Aboba writes..
> 
> > So far, I'm not clear about the link between "attribute 
> extension" and
> the
> > above goals.  Currently there are more than enough RADIUS attributes
> left
> > to handle the needs that have been described so far -- which would
> suggest
> > that attribute extension is not essential, and therefore is a
> candidate
> > for being removed from the charter.
> > 
> > Comments?
> 
> Acknowledging the existing RADIUS attributes in the IANA 
> registry (both approved by standards action and 
> "grandfathered") it does seem that attribute space 
> exhaustion, within the scope of currently proposed work, is 
> not imminent.  I would support removing this work from the charter.
> 
> -- 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/>