RE: Strawman RADIUSEXT WG charter

[Avi Lior <avi@bridgewatersystems.com>]

> Given there is a claim of usefulness and apparently some 
> uncertainty, 
> > is it desirable to preclude this work in the charter itself, as 
> > opposed to simply not having a current work item for the attribute 
> > space until need can possibly be demonstrated?
> 
> That's reasonable.
First:

Why not just not have an explict workitem for this until its needed.  Why
are we prohibiting this explicitly in the charter?
Second, given the following statement in the charter: "In order to ensure
backward compatibility with RADIUS, the following restrictions are imposed
on extensions considered by the RADIUSEXT WG:"  Attribute Space Extension
does not break backwards compatiblity in RADIUS so I don't see why it is to
be excluded in the first place.

The same is true about half the other "NO" items in the list.


Second:

I read packet cable specification.  The problem is that their method of
dealing with large attributes is not general.

The Vendor Attribute length is still only 1 octet.  Therefore they have to
know which attributes are longer and they would have some difficulty in
supporting multiple large attributes of the same kind.

The solution that we proposed (in an earlier email) provides a clean
approach to this problem.

-Use a Vendor Attribute length that is 2 octets.  If the length is greater
than 247 then the next attribute is an extension.  Repeat the concatenation
until you satisfied the original length.  This way you at least know how
long the attribute is.

A) Use Vendor Id zero to extend RADIUS attribute space;
B) Use 2 octets for the internal length of the attribute;

This is a slight modification on the recommendation in 2865.  Instead of
having a 1 octet length for the Vendor Attribute Length you have 2 octets of
length.

You can easily solve both these problems.  What are we afraid of here?  What
is the issue? 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Monday, August 25, 2003 11:21 AM
> To: Greg Weber
> Cc: radiusext@ops.ietf.org
> Subject: Re: Strawman RADIUSEXT WG charter
> 
> 
> > Given there is a claim of usefulness and apparently some 
> uncertainty, 
> > is it desirable to preclude this work in the charter itself, as 
> > opposed to simply not having a current work item for the attribute 
> > space until need can possibly be demonstrated?
> 
> That's reasonable.
> 
> > > Are they useful for newer applications as well as legacy ones?
> >
> > I'm not sure I can answer that right now, but my main point 
> was that I 
> > don't think we want to preclude describing something that we've 
> > defined and allocated in RFC 3575.  I'm fine with the 
> language in your 
> > subsequent strawmen.
> 
> OK.
> 
> > > Can you describe the issues that came up in the PacketCable 1.0 
> > > spec?
> >
> > Some of the attributes needed to support lawful intercept for voice 
> > exceeded the maximum length for VSAs.  The PacketCable spec 
> defines a 
> > scheme for fragmenting data across VSAs in section 13.1.5.2 
> of their 
> > event messaging spec:
> >   
> http://www.packetcable.com/downloads/specs/PKT> -SP-EM-I07-030815.pdf
> >
> > RFC 2865 already offers SHOULD advice on the VSA attribute 
> encoding.  
> > I think it would be helpful to offer some guidance on long VSA 
> > attributes, so we don't end up with a profusion of incompatible 
> > techniques like PacketCable's.
> 
> That seems reasonable, particularly since this issue has come 
> up in a deployed application.
> 
> 
> --
> 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/>